Como aprendi a dar e receber feedback técnico
Em 2020 fiquei na defensiva no meu primeiro code review sério. Levei um tempo para entender que o código não é você — e que feedback bom tem uma estrutura específica.
Meu PR tinha 14 comentários.
Cada comentário era uma coisa que eu tinha feito errado segundo o reviewer. Função sem teste. Variável com nome ruim. Lógica que podia ser simplificada. Tratamento de erro ausente.
Minha primeira reação foi defensiva. "O código funciona. Esses são detalhes."
Não eram detalhes.
A defensividade é natural. Você passou horas naquele código. Ele funciona. O reviewer está apontando problemas que você não viu. Parece crítica pessoal.
Não é.
O que ajudou a mudar minha perspectiva: separar o código de mim. O código que escrevi não é uma extensão de quem eu sou — é um artefato que existia num momento, com o conhecimento que eu tinha naquele momento, e que pode melhorar com mais perspectiva.
Reviewer vê coisas que você não vê porque ele não está no mesmo contexto. Esse é o ponto. Se ele estivesse no mesmo contexto, o review seria inútil.
O que aprendi sobre receber feedback:
Antes de responder "mas...", leia o comentário de novo tentando entender o que o reviewer está tentando proteger — legibilidade para o próximo dev, testabilidade, manutenibilidade, segurança. Se você entende o que ele está protegendo, a conversa fica menos sobre "quem está certo" e mais sobre "qual abordagem protege melhor isso".
E se você discorda, diz. Review é diálogo, não decreto. "Entendo a preocupação com X, mas nesse contexto Y porque Z" é resposta legítima.
O que aprendi sobre dar feedback:
Específico > genérico. "Isso pode ser mais simples" não ajuda. "Essa lógica pode ser um any() em vez de loop manual — mais legível e mesma performance" ajuda.
Explica o porquê. Comentário que diz o que mudar sem dizer por que vai ser ignorado ou aplicado às cegas. Comentário que explica o raciocínio educa e pode ser contestado com argumento.
Distingue bloqueador de sugestão. "Esse código não tem teste para o caso de string vazia e vai quebrar em produção" é bloqueador — PR não deve ser mergeado assim. "Esse nome poderia ser mais descritivo" é sugestão — não bloqueia, mas melhora.
Em 2020, aqueles 14 comentários fizeram meu código muito melhor.
Mais importante: aprendi a ler review como informação, não como julgamento. Depois disso, review ficou sendo a parte do processo que mais me ensinou — porque era o momento em que alguém mais experiente olhava para o meu trabalho e dizia exatamente o que eu poderia melhorar.
Grátis. Com exemplos concretos. Apontando exatamente onde.
Difícil de achar feedback melhor do que esse.