Não Mate O Mensageiro

Entendendo o princípio

não mate o mensageiro é um ditado do universo da programação que todo mundo já leu em algum fórum ou commit. A ideia central é simples: quando alguém te reporta um erro, o problema não está na pessoa que trouxe a notícia. Está no código, na arquitetura, no processo. Matar o mensageiro significa responder com hostilidade, frustração ou culpa para quem sinalizou a falha. Eu vi isso acontecer de novo. Um desenvolvedor junior abriu um issue num repositório interno reportando que um formulário travava no Safari. A resposta do time mais experiente foi algo do tipo "isso não é um bug, é você que está fazendo errado". Dois dias depois, todo mundo que usava Mac descobriu o mesmo problema. O código estava com uma validação que só quebrou nos navegadores Apple após uma atualização do sistema operacional. O mensageiro tinha razão desde o início.

Como aplicar não mate o mensageiro na prática

O primeiro passo é entender que receber uma crítica ou reporte de bug não é um ataque pessoal. Parece óbvio, mas eu já vi devs entrarem no modo defensivo dentro de segundos. O seu ego não tem nada a ver com o fato de que algo no sistema não funcionou como esperado. A pessoa que encontrou o problema gastou tempo testando, registrando o comportamento e buscando ajuda. Isso é trabalho. Reconheça isso. Quando alguém reporta algo quebrado, faça perguntas antes de julgar. Não "como você pôde fazer isso", mas "o que você estava tentando fazer". A diferença é enorme. A primeira pergunta coloca o culpado na outra pessoa. A segunda te ajuda a entender o contexto real do problema.

Eu tenho um caso específico que ilustra bem isso. Há alguns meses, um usuário relatou que o sistema de busca retornava resultados duplicados em cerca de três por cento dos casos. Três por cento. A maioria das pessoas teria Ignorado. "É edge case, não vale a pena corrigir." Mas eu abri o log, segui o padrão de requisição e descobri que os duplicados sempre vinham de uma query que não fazia DISTINCT num GROUP BY. Três por cento era o sintoma. A causa raiz era uma migração de banco que mudou o motor de consulta sem atualizar essa stored procedure. Sete anos de código rodando com um bug silencioso. Se eu tivesse matado o mensageiro, jamais teria achado isso.

Por que é tão difícil seguir esse conselho

Às vezes, o mensageiro realmente traz más notícias de forma inadequada. Tem quem abre um ticket escrevendo "isso está horrível, arrumem logo" sem nenhuma informação técnica, sem passos para reproduzir, sem print ou log. Isso é frustrante. Todo mundo já passou por isso. Mas frustração não é licença para ser rude de volta. A atitude profissional é pedir as informações que faltam, não mandar o pessoal ler um manual. O problema mais comum é achar que o reporter está sendo exagerado ou irrelevante. Começa com um "não vejo problema nisso". Aí vira "quem testou antes de abrir isso?". E termina com o report being ignored or closed without explanation. Isso cria um ciclo vicioso: as pessoas param de reportar problemas porque sentem que não são levadas a sério. E os bugs só aparecem quando alguém em produção quebra tudo.

Existe também o viés de confirmação. Você já investiu tempo em certa solução. Quando alguém diz que não funciona, soa como se estivesse dizendo que seu trabalho foi inútil. Não é. É exatamente o oposto. O bug report te poupou de descobrir isso semanas depois num cenário pior.

Alternativas quando o mensageiro é impreciso

Nem todo report vem com informações úteis. Às vezes vem vago, às vezes vem com suposições erradas sobre a causa. Nesse caso, a alternativa ao ataque é o refinamento. Peça steps to reproduce. Peça logs. Peça versionamento. Mostre que você quer ajudar, mas precisa de dados concretos. Se a pessoa não consegue ou não quer fornecer, documente isso no thread e mova adiante. Não feche com um comentário seco. Deixe claro o que falta e como proceder. Uma armadilha que eu vejo muito acontecer é o time inteiro entrar numa defesa coletiva. "Nós testamos isso antes de liberar." Claro que testaram. Ninguém está questionando o esforço do time. Estão questionando se cobriu todos os cenários. São coisas diferentes.

Também é comum encontrar pessoas que não sabem diferenciar bug de feature request. Alguém diz "não gosto do layout" e trata como defeito. Nesse cenário, a melhor resposta é separar claramente: isso é questão de preferência ou de funcionalidade quebrada. Se for preferência, encaminhe para o canal adequado. Se for quebra, siga o protocolo normal de investigação. Não misture as duas coisas. O custo de ignorar um bom reporter é alto. Um único issue bem descrito pode economizar horas de debugging. O custo de humilhar um reporter é ainda maior: você perde a informação dele e ganha um colega que nunca mais vai se manifestar. Conta isso na próxima vez que sentir vontade de responder com sarcasmo.