Senso comum é perigoso quando você não sabe que está usando
Você já viu alguém resolver um problema de performance num banco de dados e a solução foi reiniciar o servidor? Isso é senso comum aplicado sem entender o mecanismo por baixo. O cara achou que sabia o que estava fazendo porque "todo mundo faz assim". A gente chama isso de conhecimento tácito não verificado. E ele é muito diferente de senso comum e conhecimento formalizado. Trabalhei num projeto de migração de carga em 2023 onde a documentação dizia para desligar o cache do ORM antes do insert em massa. Senso comum diria que desligar cache é rápido porque remove uma camada. Não era. O ORM fazia batching automático que virou N queries individuais. Perdi seis horas tentando entender o porquê. A workaround foi manter o cache ativo e usar bulk insert nativo do driver, não do ORM. Aprendi que senso comum sobre "menos camadas = mais rápido" é uma armadilha clássica em stacks modernas.
Onde senso comum e conhecimento colidem na prática
Senso comum é atalho cognitivo. Seu cérebro usa heurísticas para não processar tudo do zero. Isso funciona bem no dia a dia — saber que fogo queima, que chuva molha. Em engenharia de software, infraestrutura ou qualquer campo técnico com camadas de abstração, esses atalhos falham silenciosamente. Você toma uma decisão baseada numa regra que funcionava num contexto diferente há três anos. Conhecimento formalizado é o oposto: processo documentado, teste reproduzível, causa e efeito mapeados. O problema é que a gente tende a tratar os dois como a mesma coisa. Num review de código, vi um desenvolvedor remover um timeout porque "nunca tinha dado problema". Sem timeout, uma chamada pendente trava a thread por tempo indeterminado. Ele confundia ausência de evidência com evidência de ausência. Erro clássico de quem opera no senso comum sem validar hipóteses.
A diferença prática entre os dois se mede em recuperação de falhas. Com senso comum, você tenta coisa até funcionar, sem saber por que funcionou. Com conhecimento formalizado, você restaura de backup, identifica a causa raiz, aplica o patch. O tempo de resolução costuma ser de minutos versus horas, dependendo da complexidade. Em sistemas críticos, essa diferença é a linha entre downtime aceitável e incidente nível 1.
Como sair do senso comum sem perder velocidade
Não adianta só dizer "use conhecimento". A gente precisa de mecanismo. A primeira etapa é identificar quando você está operando no piloto automático. Se a solução veio primeiro e a justificativa veio depois, provavelmente foi senso comum disfarçado. Anotar a decisão no contexto — um comentário no PR, uma nota num ticket — força o cérebro a justificar antes de agir. Leva dois minutos a mais, mas evita o retrocesso de três horas quando algo quebra. A segunda é criar checklists para decisões recorrentes. Quando eu comecei a administrar containers em produção, fiz uma lista de verificação pré-deploy: logs ativos, healthcheck respondendo, backup do volume, rollback testado. O checklist reduziu incidentes noturnos de cerca de quatro por mês para menos de um. Não porque a lista é genial, mas porque senso comum esquece etapas óbvias sob pressão. A lista substitui a memória de curto prazo.
A terceira é o que eu chamo de prova de estresse invertida. Antes de aplicar uma mudança baseada numa suposição, pergunte: "o que precisa acontecer para isso dar errado?" Se você não consegue listar pelo menos três cenários de falha, sua confiança no senso comum é maior que a evidência disponível. Num caso real, isso me salvou de rodar um script de limpeza que apagava arquivos antigos num diretório que também continha logs necessários. O script funcionava bem em ambiente de teste porque os logs eram rotacionados automaticamente. Em produção, a rotação acontecia em outro processo. Diferença de timing que senso comum não captura.
Ferramentas que forçam conhecimento sobre intuição
Versionamento de configuração é o exemplo mais simples. Cada mudança num arquivo de setup deve ter um commit com mensagem explicando o quê e o porquê. Isso transforma intuição em trilha auditable. Quem chega depois não precisa adivinhar. Você também não precisa adivinhar quando volta no tempo para debugar. Testes de integração automatizados são o próximo nível. Eles validam comportamento, não intenção. Um teste que passa não prova que sua lógica está certa. Mas um teste que falha prova que algo quebreu. A diferença é sutil e importante. Senso comum leva você a confiar no teste que passou. Conhecimento leva você a questionar o que ele não cobre.
Observabilidade é a ferramenta mais subestimada. Métricas, logs estruturados, traces distribuídos. Quando um problema aparece, você não adivinha. Você consulta os dados. Tempo de resposta médio, percentil 99, taxa de erro por serviço. Esses números substituem a sensação de "acho que tá lento" por "a latência subiu 300ms nas últimas duas horas". A tomada de decisão muda completamente quando você tem dados em vez de palpite.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando senso comum é a melhor resposta
Não estou dizendo para eliminar intuição. Em contextos de baixa complexidade e alto custo de documentação, senso comum é eficiente. Corrigir um link quebrado numa landing page, ajustar um parâmetro de cor num formulário, decidir qual biblioteca usar para um protótipo rápido. Nesses casos, buscar conhecimento formalizado é overhead desnecessário. O custo da análise supera o benefício. O problema é identificar quando a complexidade justifica o esforço. Uma regra prática: se a falha custa mais do que trinta minutos da sua vida para recuperar, pare e documente. Trinta minutos é aproximadamente o tempo que leva para escrever uma nota clara sobre uma decisão técnica. Se o problema já aconteceu antes e você levou mais do que isso para resolver, a próxima vez vai repetir o padrão a menos que haja registro.
Também existe o cenário de emergência onde senso comum é a única opção. Servidor no ar, cliente reclamando, documentação inexistente. Nesse momento, você usa o que tem. A questão é o que fazer depois. Anotar o que funcionou, testar se foi coincidência, transformar em procedimento. Senso comum de emergência sem processamento posterior vira técnica tribal que ninguém entende e todo mundo segue por medo de Questionar.
Sinais de que seu senso comum está te saboteando
Se você frequentemente diz "deveria funcionar" sem ter testado, alertas vermelhos. Frases como "sempre fiz assim", "nunca deu problema", "é óbvio que" são marcadores de intuição não validada. Não que esses padrões estejam errados. Estão apenas não verificados. A diferença entre correto e não testado é o que separa um sistema estável de um que falha no pior momento possível. Outro sinal é a dificuldade de explicar para outra pessoa. Se você resolveu algo mas não consegue descrever o passo a passo, operou no senso comum. Conhecimento Formalizado é transferível. Você consegue ensinar porque mapeou cada decisão. Intuição não. Ela vive na cabeça de quem resolveu e some quando essa pessoa sai do projeto.
O terceiro sinal é repetição de erro. Se o mesmo problema aparece duas vezes, a primeira foi sorte. A segunda é padrão. Nesse ponto, a solução baseada em intuição falhou porque não incorporou a lição. Documentar o incidente, atualizar o checklist, criar um teste que capture o caso. Trinta minutos de trabalho que evitam três horas no futuro.
A fronteira entre experiência e viés
Experiência de verdade é conhecimento acumulativo. Você viu o problema antes, entendeu a causa, aplicou a correção, validou o resultado. Esse ciclo transforma intuição em padrão reconhecível. O perigo é quando a experiência vira viés. Você assume que o novo problema é igual ao antigo porque superficialmente se parece. Num caso real, um erro de timeout num serviço foi tratado como problema de rede porque o sintoma era similar a uma falha anterior. Dois dias de investigação. No final, era configuração errada de conexão no novo ambiente. A similaridade superficial enganou. Senso comum disse "é a mesma coisa". Conhecimento pedido "teste a hipótese antes de assumir".
A diferenciação exige humildade intelectual. Admitir que pode estar errado é o que separa experiente de teimoso. Não é fraqueza. É requisito técnico. Sistemas complexos punem confiança infundada com falhas caras.
Como treinar o conhecimento sem virar analista demais
O equilíbrio existe. A regra dos vinte por cento funciona bem: dedique vinte por cento do tempo de uma tarefa para validar o que parece óbvio. Se levar cinco minutos, gaste um minuto testando. Se levar cinco horas, gaste uma hora documentando. A proporção mantém a eficiência sem abrir mão da segurança. Revisões periódicas de decisões passadas são outra prática útil. A cada trimestre, olhar para os últimos problemas resolvidos e perguntar: "isso foi intuição ou conhecimento?" Se foi intuição, registrar o padrão. Se foi conhecimento, verificar se ainda se aplica. Contexto muda. O que era verdade em janeiro pode não ser em julho.
Por fim, conversar com quem não conhece o sistema ajuda. Um colega de outra área vai fazer perguntas óbvias que revelam suposições cegas. "Por que esse valor é dois?" "O que acontece se isso cair?" Perguntas ingênuas que mapeiam exatamente onde seu senso comum não tem fundação. Senso comum e conhecimento não são inimigos. São ferramentas diferentes para contextos diferentes. O erro não é usar um ou outro. É não saber qual está usando no momento.
