← Todos os Posts

Crítico e gentil: como codifiquei princípios de feedback em 86 hooks

5 min read

O Project Aristotle do Google estudou 180 equipes e descobriu que segurança psicológica, não densidade de talento ou recursos, era o maior preditor de desempenho de equipes.1

Passei 12 anos dando e recebendo feedback de design na ZipRecruiter. Depois codifiquei os princípios que aprendi em sistemas automatizados de revisão de código. Os padrões se transferem surpreendentemente bem.

Resumo

Feedback eficaz separa a crítica ao trabalho do valor pessoal. Na ZipRecruiter, vi designers talentosos se fecharem após receberem feedback que atacava eles em vez do trabalho deles. Também vi equipes acelerarem quando o feedback era preciso, frequente e focado no resultado. Quando construí meu sistema de hooks do Claude Code, percebi que estava codificando os mesmos princípios de feedback: meus hooks criticam o código (específico, acionável, não pessoal) em vez de bloquear o desenvolvedor (vago, punitivo, ameaçador à identidade). O paralelo entre feedback humano e portões de qualidade automatizados é mais profundo do que eu esperava.

O que aprendi dando feedback por 12 anos

A distinção que importa

“Seu código tem uma condição de corrida no handler de pagamento” critica o trabalho. “Você sempre comete erros básicos” critica a pessoa.

A distinção parece óbvia no papel. Sob pressão de prazos, gestores cansados rotineiramente confundem as duas coisas. Eu mesmo fiz isso no início da minha carreira.2

Na ZipRecruiter, um designer júnior lançou uma funcionalidade com um problema significativo de usabilidade: um fluxo de três etapas que deveria ter sido uma só. Meu primeiro instinto foi frustração: “Como isso passou pela revisão?” O feedback que quase dei: “Você precisa pensar com mais cuidado sobre fluxos de usuário.” O que dei no lugar: “O fluxo de onboarding adiciona duas etapas desnecessárias entre o cadastro e o primeiro valor entregue. Veja como condensá-lo.” Mesma conclusão. Enquadramento diferente. A primeira versão deixa o designer na defensiva. A segunda ensina.

O padrão da curiosidade primeiro

“Me explica sua abordagem aqui” abre uma conversa. “Por que você fez errado?” fecha uma.

O enquadramento da pergunta determina se a resposta será defensiva ou colaborativa. Aprendi isso com o framework Radical Candor de Kim Scott e depois validei em centenas de revisões de design.3

Perguntas que começam com curiosidade revelam contexto que perguntas que começam com julgamento suprimem. Um designer que pulou testes de acessibilidade pode não conhecer o requisito. Um desenvolvedor que escolheu um algoritmo mais lento pode ter encontrado um conflito de dependência com o mais rápido. Começar com curiosidade traz esses fatores à tona. Começar com julgamento os enterra.

Frequência reduz o peso

Equipes que recebem feedback semanalmente sobre itens pequenos desenvolvem resiliência para feedback sobre itens grandes. Equipes que só recebem feedback durante avaliações anuais vivenciam cada instância como algo de alto risco e ameaçador.4

Na ZipRecruiter, mudei as revisões de design de quinzenais para standups diários. A resistência inicial foi alta. Em um mês, a equipe relatou que o feedback parecia “normal” em vez de “um evento.” No terceiro trimestre, os designers buscavam feedback proativamente porque o peso por instância era baixo o suficiente para que ouvir “isso precisa de ajustes” soasse como um dado, não um julgamento.

Como princípios de feedback viraram código

Quando construí minha infraestrutura do Claude Code, não estava conscientemente aplicando princípios de feedback. Mas olhando para trás, cada decisão de design espelha o que aprendi com ciclos de feedback humano.

O feedback dos hooks é específico, não vago

Meu hook blog-quality-gate.sh não diz “este post precisa de ajustes.” Ele diz “Linha 47: voz passiva detectada em ‘was implemented by the team.’ Sugestão: ‘the team implemented.’” Número de linha específico, problema específico, correção específica.

Compare com um revisor de código humano que escreve “arruma isso” versus “o tratamento de erro na linha 52 engole a exceção de timeout. Adicione um catch específico para TimeoutError.” O primeiro é julgamento vago. O segundo é crítica acionável. Meus hooks impõem o segundo padrão automaticamente.

Hooks criticam o trabalho, não a identidade

Meu hook git-safety-guardian.sh intercepta comandos git perigosos, mas sua saída nunca diz “você está prestes a cometer um erro.” Ele diz “AVISO: force-push detectado na branch main. Esta operação reescreve o histórico remoto.” O hook descreve a situação sem atribuir descuido.

Isso espelha a distinção entre feedback ao trabalho e à pessoa. O hook critica a operação, não o operador. Um desenvolvedor que acidentalmente executa git push --force main não se sente envergonhado. Se sente informado.

Portões de qualidade são frequentes e de baixo peso

Meu linter de blog com 12 módulos roda a cada commit em content/blog/. Cada verificação é pequena: uma regra, uma descoberta, uma sugestão. Nenhuma descoberta isolada é uma crise. O linter produz 3 a 5 achados por commit, cada um corrigível em menos de um minuto.

Isso espelha o padrão de feedback do standup diário. Verificações frequentes e de baixo peso normalizam o feedback de qualidade. Um desenvolvedor que vê “INFO: baixa densidade de links internos” trata isso como um lembrete, não um veredito. O mesmo desenvolvedor recebendo um relatório trimestral listando 47 problemas se sentiria sobrecarregado.

O Pride Check é autoavaliação, não julgamento externo

Minha filosofia Shokunin inclui um “Pride Check” antes de qualquer trabalho ser marcado como concluído: “Um engenheiro 10x respeitaria essa abordagem? Este código se explica sozinho? Eu tratei os casos extremos?” Essas perguntas são autodirigidas, não impostas externamente.

O padrão de autoavaliação funciona melhor que a imposição externa pela mesma razão que o feedback com curiosidade primeiro funciona: preserva a autonomia. Um desenvolvedor que decide por conta própria que seu trabalho ainda não está pronto cresce mais rápido do que um desenvolvedor que é avisado que seu trabalho não está pronto. Mesma conclusão, diferente apropriação psicológica.5

A contraintuição: padrões altos E segurança psicológica

A maioria dos líderes opta por gentileza ou honestidade. Gestores gentis evitam feedback difícil, criando conforto onde trabalho medíocre persiste. Gestores honestos entregam críticas diretas que corroem a confiança, criando ambientes onde as pessoas param de assumir riscos.6

Ambas as abordagens falham. A pesquisa consistentemente mostra que as equipes de maior desempenho combinam feedback direto com segurança psicológica. O Project Aristotle do Google, a pesquisa de Edmondson sobre organizações sem medo e o framework Radical Candor de Scott convergem para a mesma conclusão: pessoas fazem seu melhor trabalho quando se sentem seguras para falhar E recebem feedback honesto sobre como melhorar.

Meu sistema de hooks codifica essa combinação. Os hooks são rigorosos (bloqueiam commits com voz passiva, notas de rodapé soltas e meta descriptions ausentes). Mas o feedback é construtivo (achado específico, sugestão específica, sem atribuição pessoal). Padrões rigorosos com entrega gentil.

Principais conclusões

Para gestores: - Separe a crítica ao trabalho da avaliação pessoal; use “o código tem” em vez de “você sempre” - Aumente a frequência do feedback; feedback semanal sobre coisas pequenas constrói tolerância para feedback trimestral sobre coisas grandes - Dê o exemplo de vulnerabilidade compartilhando seus próprios erros e o feedback que você recebeu

Para engenheiros construindo sistemas de qualidade: - Projete feedback automatizado para ser específico e acionável; “linha 47: voz passiva” ensina mais do que “problemas de qualidade detectados” - Faça portões de qualidade frequentes e de baixo peso; 5 verificações pequenas por commit superam 47 achados por trimestre - Enquadre requisitos de qualidade como autoavaliação (pride checks) em vez de imposição externa

Para contribuidores individuais: - Busque feedback específico e acionável em vez de aprovação; “tá bom” ajuda menos do que “o tratamento de erro na linha 45 não cobre o caso de timeout” - Segurança psicológica não significa conforto; equipes seguras assumem riscos maiores e enfrentam problemas mais difíceis porque o fracasso não é punido

Referências

  1. Duhigg, Charles, “What Google Learned From Its Quest to Build the Perfect Team,” The New York Times Magazine, February 2016. ↩

  2. Stone, Douglas & Heen, Sheila, Thanks for the Feedback, Viking, 2014. ↩

  3. Scott, Kim, Radical Candor, St. Martin’s Press, 2017. ↩

  4. Gallup, “Employees Want a Lot More From Their Managers,” Gallup Workplace, 2018. ↩

  5. Edmondson, Amy, The Fearless Organization, Wiley, 2018. ↩

  6. Buckingham, Marcus & Goodall, Ashley, “The Feedback Fallacy,” Harvard Business Review, March-April 2019. ↩