De acordo com Jean Pierre Lessa e Santos Ferreira, o feedback técnico é uma das ferramentas mais poderosas de desenvolvimento profissional disponíveis em times de tecnologia, e uma das mais frequentemente mal utilizadas. A diferença entre um code review que eleva a qualidade do código e do desenvolvedor que o escreveu e um que gera defensividade, ressentimento e relação deteriorada não está no conteúdo técnico do feedback: está na forma como ele é construído, comunicado e recebido no contexto de uma relação de trabalho com dinâmicas que vão muito além da qualidade do código.
Se você já recebeu um code review que pareceu mais um ataque pessoal do que orientação técnica, ou se já deu feedback que tinha como objetivo ajudar e foi recebido como crítica injusta, este artigo vai oferecer perspectiva e ferramentas concretas para transformar essa dinâmica.
Continue lendo: construir a habilidade de dar e receber feedback técnico de forma eficaz é um multiplicador de desenvolvimento profissional que poucos times cultivam de forma deliberada.
Por que o feedback técnico frequentemente falha em produzir o efeito desejado e quais são os mecanismos que explicam esse padrão?
Conforme Jean Pierre Lessa e Santos Ferreira, o feedback técnico falha quando é percebido como avaliação da pessoa e não do trabalho. Essa distinção, que parece óbvia quando enunciada, é muito mais difícil de manter na prática do que parece. Quando um revisor escreve “este código está errado” sem mais contexto, a afirmação é tecnicamente sobre o código, mas é recebida psicologicamente como julgamento de competência de quem o escreveu. A resposta natural a julgamentos de competência é defensividade, não aprendizado, e a defensividade fecha exatamente o canal de comunicação que o feedback precisaria manter aberto para ser útil.
A ausência de contexto e de racionalização técnica é o segundo mecanismo de falha mais frequente. Comentários de code review que apontam um problema sem explicar por que é um problema, sem oferecer referência a um princípio técnico que o justifica ou sem sugerir uma alternativa deixam o desenvolvedor em uma posição em que não tem como aprender com o feedback, apenas aceitar ou rejeitar a opinião de quem revisou. Feedback sem contexto técnico é percebido como arbitrário, e pessoas que percebem feedback como arbitrário não mudam de comportamento: buscam o próximo revisor que vai aprovar o que foi rejeitado.
Quais características distinguem o feedback técnico que desenvolve profissionais do que corrói a motivação e o relacionamento?
Feedback técnico eficaz começa por separar explicitamente questões de estilo e preferência de questões de correção e segurança. Quando um revisor trata uma escolha de nomenclatura de variável com o mesmo peso que uma vulnerabilidade de segurança, o desenvolvedor que recebe o feedback não consegue priorizar o que realmente importa. A prática de categorizar comentários de code review em bloqueadores que precisam ser resolvidos antes do merge, sugestões que melhorariam o código, mas não são obrigatórias, e apontamentos que são preferências pessoais do revisor que o desenvolvedor pode considerar ou ignorar, cria uma estrutura que clarifica prioridades e reduz o atrito gerado por comentários de baixo impacto.
Segundo Jean Pierre Lessa e Santos Ferreira, a formulação de feedback como questão em vez de afirmação é uma técnica de comunicação que muda fundamentalmente a dinâmica da revisão. Em vez de “este código tem um problema de performance”, a formulação “você considerou o impacto de performance desta abordagem em consultas com volume alto de dados?” convida o desenvolvedor a um processo de raciocínio conjunto em vez de comunicar um veredicto. Essa diferença de formulação não é apenas estilística: ela mantém aberta a possibilidade de que o desenvolvedor tinha uma razão legítima para a escolha que o revisor não tinha visto, e que o resultado da conversa pode ser aprendizado mútuo em vez de correção unilateral.
A inclusão de reconhecimento explícito de escolhas técnicas bem feitas é um componente do feedback que times com boa cultura de revisão cultivam e que times com cultura de revisão exclusivamente crítica sistematicamente omitem. Código é majoritariamente composto de escolhas corretas e competentes, e um processo de revisão que só comenta as que são problemáticas cria uma distorção de percepção em que o desenvolvedor sente que tudo que fez foi ruim porque é tudo que foi comentado. Balancear o feedback com reconhecimento das escolhas que merecem reconhecimento não é protocolo de polidez: é prática de calibração que mantém a relação e a motivação saudáveis.
Como times de tecnologia podem construir uma cultura de feedback técnico que eleve consistentemente qualidade e relações profissionais?
A definição explícita de acordos de equipe sobre o processo de code review é o ponto de partida de uma cultura de feedback saudável. Times que nunca discutiram de forma explícita o que esperam de um revisor, quanto tempo um pull request deve esperar sem revisão, quais tipos de comentários são bloqueadores e quais são opcionais, e como escalar quando há discordância técnica que não se resolve no nível do PR estão sujeitos a que cada revisor opere com suas próprias normas implícitas, criando inconsistência que é percebida como injustiça pelo time. Uma reunião de equipe dedicada a construir esses acordos produz, na maioria dos times, uma base compartilhada que reduz o atrito das revisões de forma imediata e duradoura.
A prática de revisões síncronas para casos complexos ou controversos é um complemento valioso ao processo assíncrono padrão de code review. Quando um PR envolve decisões arquiteturais significativas, quando há discordância genuína sobre a abordagem correta, ou quando o contexto é complexo demais para ser comunicado adequadamente em comentários escritos, uma conversa de trinta minutos entre revisor e autor frequentemente resolve em meia hora o que poderia se arrastar por dias de comentários escritos sem progresso. Como destaca Jean Pierre Lessa e Santos Ferreira, normalizar esse formato de revisão síncrona remove a pressão de ter que comunicar toda a nuance técnica por escrito e cria espaço para o diálogo, que é o ambiente natural de aprendizado técnico.
O investimento em desenvolvimento de habilidades de comunicação técnica como parte explícita do desenvolvimento de carreira de engenheiros e tech leads é o fator que mais diferencia times com cultura de feedback madura dos que dependem da boa vontade individual de cada revisor. Assim como habilidades técnicas são desenvolvidas por meio de estudo, prática e feedback, habilidades de comunicação técnica podem ser desenvolvidas por meio de frameworks explícitos, exemplos de feedback bem e mal construído, e reflexão sobre o impacto dos diferentes estilos de revisão. Times que investem nesse desenvolvimento coletivamente constroem uma capacidade que se acumula ao longo do tempo e que tem impacto no crescimento profissional de todos os membros, de forma que nenhum processo individual consegue reproduzir.
Autor: Diego Rodríguez Velázquez
