É Loucura Odiar Todas As Rosas Porque Uma Te Espetou

Como lidar com o viés de generalização após uma experiência negativa

A maioria das pessoas comete o mesmo erro duas vezes. A primeira quando algo dá errado e a segunda quando decidem que tudo o que vier depois vai dar errado também. O provérbio é loucura odiar todas as rosas porque uma te espetou descreve exatamente isso: um mecanismo cognitivo de generalização excessiva que aparece em praticamente qualquer área da vida profissional e pessoal.

O mecanismo por trás da rejeição generalizada

O cérebro humano é otimizado para sobrevivência, não para precisão estatística. Quando você recebe um estresse negativo intenso — seja um relacionamento ruim, um investimento que perdeu dinheiro, uma ferramenta que falhou criticamente — a amígdala grava aquela experiência com muito mais força do que grava os casos neutros ou positivos. O resultado é um viés de disponibilidade distorcido. Você consegue lembrar de um único caso negativo com detalhes vívidos e esquece os dezenas de casos que foram normais ou bons. Eu já vi isso acontecer com desenvolvedores que tinham uma biblioteca específica travar o projeto inteiro em produção uma vez e, a partir daí, passaram a recomendar contra todo e qualquer uso daquela ferramenta, sem considerar que o problema era configuração, não a ferramenta em si. Isso aconteceu comigo também. Em 2019, eu estava configurando um pipeline de CI/CD com GitHub Actions para um repositório Node.js e o job de deploy falhava intermitentemente. O erro era sobre variáveis de ambiente não sendo passadas corretamente para containers Docker. Eu abandonei a ferramenta completamente e voltei para Jenkins, que eu já conhecia, mesmo que fosse muito mais lenta. Levei três semanas descobrindo que o problema era um simples erro de indentação no arquivo YAML onde as variáveis estavam definidas fora do escopo do job. O YAML é sensível a espaços, não a tabs. Esse é o tipo de detalhe que ninguém te avisa na documentação inicial.

Como identificar quando você está caindo nessa armadilha

O sinal mais claro é quando sua rejeição não tem base empírica sólida. Se você diz "nunca mais vou usar X" mas não consegue listar quantas vezes X funcionou bem para outras pessoas ou em outros contextos, você está operando por emoção, não por análise. Outro sinal é quando você começa a usar linguagem absoluta: "toda vez", "nunca", "todas as vezes". Linguagem absoluta raramente reflete a realidade. A abordagem mais prática que eu uso é simples. Quando surge uma rejeição generalizada, eu anoto três coisas antes de tomar qualquer decisão: o que exatamente aconteceu de errado, quantas vezes o mesmo cenário deu certo, e qual foi a causa raiz real. A causa raiz quase sempre é diferente do que parece no momento emocional. No meu caso com o GitHub Actions, a causa raiz não era "a ferramenta é instável". Era "eu não entendi como o scope de variáveis funciona no YAML". Isso muda completamente a recomendação que você deve dar.

Quando o provérbio não se aplica

Existe um cenário onde rejeitar tudo não é ilógico. Se um sistema ou processo falhou de forma consistentemente ruim em múltiplos contextos diferentes, a rejeição generalizada é válida. A diferença está na consistência dos fracassos. Um único evento ruim, especialmente se for atípico ou causado por erro de implementação, não justifica abandonar algo. Vários eventos ruins em condições diversas sim. Eu já trabalhei com uma stack inteira de microserviços baseada em Kafka que gerava problemas de mensageria a cada duas semanas. Depois do terceiro incidente grave, a decisão de migrar para RabbitMQ foi razoável, mesmo que ninguém pudesse apontar uma única causa raiz definitiva. Às vezes o custo de manter algo que falha recorrentemente supera o custo de mudar, independentemente de entender exatamente por que as falhas acontecem. O problema é que muitas pessoas tratam um evento isolado como se fosse um padrão. Eu vi gerente de projeto cancelar o uso de TypeScript em uma equipe inteira porque um debug de tipos levou quatro horas numa sexta-feira à tarde. A equipe nunca mais voltou a usar, mesmo após resolver o problema original. Dois anos depois, eu recomendei TypeScript para outra equipe e levamos meia hora configurando os tipos corretos na primeira vez. A experiência negativa deles foi real, mas não generalizável.

Um exercício que funciona na prática

Antes de descartar algo completamente, faça o seguinte. Liste pelo menos cinco casos em que aquilo funcionou bem. Não precisa ser na sua vida pessoal. Pode ser casos que você ouviu falar, artigos que leu, colegas que usam. Se você não consegue chegar a cinco, questione por quê. É porque realmente é ruim ou porque o seu cérebro só está mostrando o caso negativo? Depois, analise a causa raiz do problema original com o mesmo rigor que você usaria para analisar um bug de produção. Você vai notar que na maioria das vezes a causa está em como você implementou, não no que você está implementando. Isso vale para tecnologia, para relações pessoais, para investimentos. O padrão cognitivo é o mesmo. A exceção são os casos onde o problema é estrutural e recorrente, e aí a recomendação muda. Não existe regra única que funcione sempre.