Insegurança no Código

Leandro
wearejaya
Published in
3 min readNov 24, 2023

Fala pessoal! E ai, tudo bem?

Para começar, peço que leiam este artigo de coração aberto, pois trata de algo que já aconteceu comigo e provavelmente acontecerá com todos em algum momento.

Durante um One on One aqui na Jaya, tive uma conversa com um colega que compartilhou sua insegurança ao abrir Pull Requests (PRs) junto à equipe. Notei que o código dele retornava com frequência e que, muitas vezes, as revisões pareciam puro preciosismo.

Pode ser que fossem as duas coisas, mas achei crucial compartilhar com ele uma experiência que vivi no início da minha carreira ao estudar Python. Farei o mesmo com você agora, então pegue sua pipoca e se acomode, pois a história é engraçada.

Quando começo a estudar uma linguagem de programação e sinto que entendi os fundamentos e a sintaxe, procuro imediatamente um projeto open source para aprender enquanto contribuo com a comunidade.

Lembro-me de ter escolhido um projeto grande para compartilhar e uma feature básica para desenvolver. Fiz a codificação e abri o primeiro PR. No dia seguinte, ao abrir o GitHub, vi um desenvolvedor irlandês que fez várias sugestões. Apliquei as mudanças e submeti novamente. Surgiram mais sugestões, corrigi e submeti novamente, e assim continuamos por quase um mês. Lembro-me de ter recebido um e-mail informando que a issue havia sido cancelada, pois não havia mais necessidade.

Fiquei frustrado na hora, afinal, nos apegamos ao nosso ego. Pensei: “Fiz um monte de coisas, e não foi para frente”. No entanto, veio a surpresa: o desenvolvedor que fechou a issue disse que não a achavam muito importante, mas perceberam, pelas minhas interações, que eu estava empenhado em aprender e contribuir. Por isso, mantiveram a issue por mais tempo, dando-me a oportunidade de aprender alguns truques.

Na verdade, aprendi muito na época, especialmente durante um pair programming. Foi uma das melhores experiências colaborativas da minha vida.

A parte mais desafiadora para nós, desenvolvedores, são as interações sociais. Precisamos aceitar ajuda e criar limites. Acreditem, houve muitas sugestões que ignorei e questionei, assim como muitas que apliquei. Me senti incompetente, cansado e por duas vezes quase desisti do PR. Lembro o desenvolvedor que estava me acompanhado disse : — Somos artesãos, eu quero ver o seu jeito de fazer.

Existem padrões, mas seguir não significa replicar o código exatamente igual ao do outro. Às vezes, ele sai parecido, assim como acontece no artesanato.

Um exemplo disso é a figura abaixo:

Não importa qual você ache mais bonito, ambos são girafas, porém feitas de formas diferentes.

Aqui estão algumas dicas para você:

  1. Entenda que uma sugestão não é obrigatória. Não se sinta obrigado a aceitar cada sugestão. Cada pessoa tem sua abordagem e estilo, e nem sempre as sugestões são universais.
  2. Diferencie sugestões de problemas. É crucial distinguir entre sugestões construtivas e problemas reais em seu código. Muitas vezes, escondemos nossos problemas, mas lembre-se de que o problema está no código, não em você.
  3. Não encare seu código como algo exclusivamente seu. Se algo der errado em um produto, a responsabilidade não recai apenas sobre você. O desenvolvimento é um esforço colaborativo, e todos compartilhamos o sucesso e as falhas. Não leve tudo para o lado pessoal.
  4. Não deixe a insegurança assumir o controle. A insegurança é comum, especialmente ao expor seu trabalho à revisão. No entanto, não permita que ela o impeça de produzir e aprender. Cada feedback é uma oportunidade de crescimento.
  5. Busque alternativas para melhorar a comunicação. Se não conseguiu se fazer entender, ou não compreendeu o que seu amigo disse, vá a mesa dele, ou chame ele para um bate papo por vídeo.
  6. Sempre continue aprendendo.

Espero que tenham gostado deste aprendizado e sintam-se a vontade de compartilhar suas experiências também.

--

--