Não Seja Sábio Aos Teus Próprios Olhos

O perigo de acreditar que domina o assunto

Tenho visto muita gente cometer o mesmo erro em projetos que envolvem análise de dados e tomada de decisão. Eles chegam, montam uma solução elegante, confiam cegamente nos resultados e mandam ver. Dois meses depois, alguém nota que o modelo simplesmente não funciona no mundo real. O problema nunca foi a técnica. Foi a arrogância disfarçada de competência.

A armadilha do não seja sábio aos teus próprios olhos

O ditado vale tanto para o consultor que entrega um dashboard bonito sem questionar as premissas do negócio quanto para o desenvolvedor que decide que SQL não precisa de manutenção porque "a query funciona". Eu vi isso na prática há alguns anos, trabalhando em uma migração de dados para uma empresa de logística. O sistema tinha uma camada de validação que parecia sólida no papel. Ninguém testou com dados reais de campos obrigatórios faltando. O resultado foi um job que rodou por 14 horas e gerou exatamente zero registros úteis. A correção foi simples: parar de confiar na estrutura e começar a tratar cada campo como potencialmente corrompido. Levei mais três dias para refazer a validação de forma defensiva. Aprendido. O que acontece com frequência é que pessoas experientes param de se questionar. Elas conhecem o suficiente para resolver o problema rapidamente, mas essa confiança excessiva as impede de notar edge cases. Um exemplo bem específico: validação de schema em pipelines de dados. Se você assume que todo arquivo CSV que entra tem o cabeçalho correto, seu pipeline quebra. Sempre quebra. A solução é validar o header antes de processar qualquer linha, e se ele estiver errado, registrar o erro e pular o arquivo. Não tente adivinhar. Só registre e continue.

Como manter a humildade técnica na prática

A abordagem mais eficiente é simples e costuma ser negligenciada. Antes de entregar qualquer coisa, peça para outro colega revisar. Não alguém júnior que vai concordar com tudo. Alguém que tenha motivo para encontrar falhas. Eu costumo mandar um pull request sem nenhum contexto adicional, só o código. Isso força quem está revisando a entender o problema do zero, o que revela lacunas que eu mesmo não via. Outra prática útil é escrever um documento breve antes de começar a implementar. Não um documento longo. Três parágrafos no máximo explicando: o que está sendo resolvido, quais são as premissas e o que aconteceria se elas estivessem erradas. Esse exercício te obriga a identificar os pontos fracos antes de gastar tempo construindo algo sobre bases instáveis. Na minha experiência, esse passo corta pelo menos 30% do retrabalho em projetos de integração de sistemas.

Quando se trata de tomar decisões técnicas, existe um viés cognitivo chamado efeito Dunning-Kruger. Pessoas com conhecimento limitado tendem a superestimar sua capacidade, enquanto especialistas tendem a subestimar. O equilíbrio está em tratar todo conhecimento como provisório. Se você não consegue explicar para um colega menos experiente como uma decisão técnica foi tomada, provavelmente não entendeu o suficiente para tê-la feito com confiança.

Limitações que ninguém gosta de ouvir

A humildade técnica tem custo. Ela desacelera entregas. Pedir revisão, escrever documentação prévia e testar cenários de borda leva tempo que muitos gestores não querem esperar. Em ambientes de alta pressão, essa abordagem é frequentemente vista como preguiça ou perfeccionismo. É importante saber quando aplicar e quando não aplicar. Para um script interno que roda uma vez, talvez não valha a pena. Para um sistema que outras pessoas vão depender, não há alternativa. Um cenário onde a autocensura técnica falha completamente é em problemas mal definidos. Se você não tem clareza sobre o que está tentando resolver, nenhuma quantidade de humildade vai ajudar. Nesse caso, a prioridade deve ser gastar tempo entendendo o problema, não resolvendo-o. Eu já vi equipes inteiras desperdiçarem semanas implementando soluções para problemas que não existiam, porque alguém assumiu que entendia a necessidade sem confirmar com o cliente. A correção foi uma reunião de três horas com o stakeholder, onde simplesmente perguntamos: "o que aconteceria se nada disso fosse feito?" A resposta mudou todo o escopo do projeto.

O que resta é um princípio básico que parece óbvio mas é frequentemente ignorado. Verifique suas premissas. Pergunte a si mesmo qual seria a consequência se estiver errado. E quando encontrar alguém que discorda de você, em vez de ver como uma ameaça, considere que talvez seja a pessoa certa para encontrar o erro que você não viu.