Como lidar com feedback e code review sem levar pro pessoal

Tem uma cena que se repete com quase todo programador em algum momento da carreira: você abre um Pull Request, sente aquele friozinho na barriga esperando a revisão, e quando os comentários chegam, mesmo que sejam totalmente razoáveis, alguma coisa dentro de você reage como se tivesse levado uma bronca. O código voltou com observação e o corpo inteiro reage como se o problema fosse você.

Por que isso dói mais do que deveria

Quando você escreve código, principalmente algo em que se esforçou de verdade, é fácil misturar duas coisas que deveriam ser separadas: o código que você produziu e o seu valor como profissional. Um comentário de review dizendo "essa função tá fazendo coisa demais, dá pra quebrar em duas" é uma observação técnica sobre um arquivo. Mas o cérebro, sem pedir permissão, costuma traduzir isso pra "eu não sou bom o suficiente".

Isso é ainda mais comum em quem tá começando, porque ainda não teve repetição suficiente pra perceber um padrão importante: todo código recebe comentário. Não importa o nível de quem escreveu. Sênior recebe comentário em PR de sênior. A revisão não existe porque alguém é ruim, existe porque nenhum código sai perfeito na primeira tentativa, e um segundo par de olhos sempre enxerga algo que quem escreveu não enxergou, só de estar mais distante do problema.

Código não é você

Uma forma prática de reduzir esse peso é lembrar, de verdade, que o código de hoje é só a sua melhor tentativa com o que você sabia até agora. Daqui a seis meses, olhando esse mesmo trecho, é bem provável que você mesmo teria algo a apontar nele. Isso não é falha, é o processo normal de melhorar.

Separar as duas coisas na prática ajuda a ler um comentário de review como informação, não como veredito. "Esse loop pode ficar mais simples com um .map" não é sobre a sua capacidade, é sobre uma linha específica de código, num momento específico, que agora tem uma alternativa melhor à vista. Trocar de perspectiva, de "estão me criticando" para "estão me passando uma informação que eu não tinha", muda completamente como o resto do dia rende depois de ler aquele PR.

Pergunte o porquê antes de aceitar calado

Tem um hábito que ajuda bastante e que pouca gente cultiva: quando um comentário não fica claro, perguntar por quê, em vez de simplesmente aceitar e mudar sem entender. Não é sobre discordar por discordar, é sobre extrair o raciocínio por trás daquela sugestão.

"Por que fica melhor com composição em vez de herança aqui?" é uma pergunta que, respondida, vira aprendizado que fica pra sempre, muito além daquele Pull Request específico. Quem revisa também gosta de ser perguntado, porque mostra que o feedback está sendo levado a sério, não só engolido pra fechar o ciclo mais rápido.

E do outro lado, quando você é quem revisa

Dar feedback também é uma habilidade, e vale pensar nela com o mesmo cuidado. Comentário técnico direto ao ponto ajuda, comentário genérico ou irônico não ajuda ninguém, só faz a pessoa se fechar. Existe uma diferença grande entre "isso tá errado" e "essa validação passa direto se o campo vier vazio, dá pra tratar isso com um early return aqui em cima". O segundo aponta o problema e já sugere caminho, sem deixar ninguém adivinhando o que fazer com aquilo.

Vale também comentar o que ficou bom, não só o que precisa mudar. Não como forma de suavizar a crítica, mas porque reforçar o que funcionou também é informação útil, e ajuda quem tá aprendendo a construir critério próprio sobre o que é um código bom.

Vira treino

Com o tempo, ler comentário de review sem doer é uma habilidade que se constrói, igual qualquer outra. Não é sobre parar de se importar com a qualidade do que você escreve, é sobre desligar o gatilho automático que transforma "essa função pode melhorar" em "eu não sirvo pra isso". Quanto mais você separa as duas coisas, mais rápido consegue extrair o que realmente importa de cada revisão: ficar um pouco melhor no código de amanhã.