Nao Que Eu Tenha Sabido Ta Certo

Por que quase todo mundo erra na hora de verificar a própria lógica

A gente costuma construir uma resposta e depois passa o resto do dia confirmando que ela está certa. O problema é que o cérebro busca atalhos de confirmação, não verificação real. E quando o assunto é manter essa mentalidade de autoavaliação sem cair no viés de confirmação, a coisa fica ainda mais traiçoeira. Eu já passei por isso várias vezes. A expressão resume um estado onde você chegou a uma conclusão, mas não tem condição de jurar que ela está correta sem passar por uma refutação ativa. Diferente do overconfidence comum em equipes técnicas, esse é ooposto: você sabe que chegou a um resultado, mas ainda não testou se ele aguenta pressão. A maioria das pessoas pula esse meio-termo e vai direto para "está certo" ou "preciso refazer do zero". No dia a dia, isso se traduz em algo bem concreto. Você resolve um problema, roda os testes, tudo passa. Mas algum detalhe sutil na variável ou no cenário não foi considerado. A diferença entre quem aplica esse conceito e quem não aplica é o tempo gasto antes de marcar como resolvido. Em vez de fechar a task na hora, você para, anota três possibilidades de falha e tenta destruí-las antes de entregar.

O método de verificar antes de confiar

Não existe fórmula mágica, mas existe um processo que funciona consistentemente. Primeiro, você documenta o raciocínio que levou à conclusão. Não o resultado final, mas cada inferência intermediária. Isso parece óbvio até você precisar aplicar em um problema complexo e perceber que esqueceu metade das etapas mentais. O segundo passo é o mais importante e o mais ignorado: escreva três cenários em que sua resposta poderia estar errada. Não pense neles, escreva. A ação física de colocar no papel força o cérebro a sair do modoConfirmation Bias e entrar no modo busca por contradições. Eu lembro de uma ocasião específica em que montei uma solução de integração entre dois sistemas legados. Tudo funcionava nos testes unitários. Marquei como entregue. Dois dias depois, um edge case apareceu: quando o payload vinha com campos nulos em posições específicas, o parser quebrava silenciosamente. O problema é que eu tinha escrito o raciocínio, mas não tinha documentado o pressuposto de que os campos nunca viriam nulos naquela ordem. Se eu tivesse feito o exercício dos três cenários de falha, teria coberto pelo menos um deles.

Por que isso não funciona em todos os contextos

O método tem limitações sérias. O maior é o tempo. Verificar ativamente sua própria lógica adiciona entre 30 minutos e duas horas ao ciclo de resolução, dependendo da complexidade do problema. Em ambientes de alta velocidade como incidentes críticos ou sprints apertados, esse overhead não cabe. Nesse caso, a estratégia inversa costuma funcionar melhor: delegar a refutação para alguém que não a construção da solução. Existe também o risco do falso positivona documentação. Você escreve os três cenários de falha, mas escolhe cenários fáceis de refutar porque são os mais óbvios. Os cenários perigosos são justamente os que você não consegue enxergar. Isso não elimina o viés, apenas o disfarça com aparência de rigor.

Alternativas quando o método não aplica

Se você está em um contexto onde não tem tempo para a verificação ativa, pelo menos use checklists estruturados. Listas de verificação baseadas em erros comuns da sua área valem mais do que autoavaliação crua porque elas externalizam o conhecimento de falhas que seu cérebro tenderia a pular. Eu uso uma lista de dez pontos para validação de API antes de qualquer deploy, e ela me pegou umas duas vezes por mês onde minha autoconfiança teria deixado passar algo. Para problemas maiores, onde o custo de erro é alto, o ideal é combinar os dois: fazer a verificação ativa em problemas de média complexidade e usar peer review + checklist em problemas de alta criticidade. Não adianta aplicar o mesmo nível de rigor para tudo, você quebra a eficiência sem ganhar segurança proporcional.

O que ninguém te conta sobre autocorrição

A parte mais difícil não é o processo em si, é a barreira emocional. Reconhecer publicamente que você pode estar errado exige um nível de confiança que nem todo mundo desenvolve. Em culturas onde admitir dúvida é visto como fraqueza, o conceito de nao que eu tenha sabido ta certo vira sinônimo de incompetência percebida, quando na verdade é o oposto: é o sinal de quem sabe os limites do próprio conhecimento. O workaround prático é simples mas contra-intuitivo: em vez de dizer "acho que pode estar errado", apresente os cenários de falha como parte do documento de decisão. Isso transforma a dúvida em análise estruturada e retira o peso emocional da autocrítica. Ninguém questiona competência de quem lista proativamente os pontos de falha. Se você quer aplicar isso de verdade, comece pequeno. Na próxima vez que resolver algo, antes de marcar como concluído, gaste cinco minutos escrevendo o raciocínio e três Ways o resultado poderia falhar. Você vai perceber que a maior parte das vezes o resultado aguenta, mas pequenas brechas que aparecem são exatamente as que causam problemas no futuro.