Como lidar com atitude filosófica no dia a dia técnico
A maior parte das pessoas usa o termo atitude filosófica de forma vaga, como se fosse sinônimo de "pensar muito antes de agir". Na prática, isso não é o que acontece quando você trabalha com sistemas complexos, arquitetura de software ou problemas que envolvem múltiplas partes interessadas. Atitude filosófica, no sentido útil, é uma disciplina de suspender julgamento até que as premissas tenham sido explicitamente mapeadas. Sem isso, você gasta horas resolvendo o problema errado e não percebe até que o código já está em produção e quebrando. O problema começa porque ninguém ensina isso direito. Você entra num projeto, recebe um requisito ambíguo, e a tendência natural do time é ir direto para a implementação. Eu já vi isso acontecer em pelo menos três empresas diferentes. A última vez foi com um sistema de notificação que entregava mensagens duplicadas para 12% dos usuários. O time inteiro estava convencido de que era um bug no código de envio. Levou quatro dias de investigação até eu perguntar: "Qual é a definição exata de 'entrega' nesse contexto?" A resposta revelou que dois serviços estavam interpretando o campo timestamp de formas incompatíveis. Ninguém tinha documentado isso. Ninguém tinha questionado.
Atitude filosófica na prática: mapeamento de premissas
O método que funciona, e funciona de verdade, é o seguinte. Antes de qualquer decisão técnica, escreva em um documento simples, mesmo que seja apenas um comentário no PR ou um rascunho no Notion, todas as premissas que estão sustentando a solução proposta. Premissa significa afirmação não verificada que você está aceitando como verdadeira. Isso inclui coisas como "o dado vem formatado assim", "o usuário espera esse comportamento", "o sistema externo responde em menos de 200ms". Quando você expõe essas premissas, três coisas acontecem: surgem divergências que antes eram invisíveis, pontos de falha se tornam óbvios, e o debate perde o caráter pessoal porque não se discute opinião, se discute suposição. Um detalhe que quase ninguém considera: atitude filosófica não significa passar mais tempo pensando. Pelo contrário. No meu caso, o mapeamento de premissas reduziu o tempo médio de resolução de problemas recorrentes de cerca de três dias para oito horas, porque a maioria dos bugs que encontrei vinha de uma premissa não declarada, não de lógica errada. Quando a premissa estava anotada, a discrepância aparecia logo, antes da implementação. É contra-intuitivo porque parece que estar mais lento no início é pior. Na verdade, é o oposto. Implementar sob premissas não verificadas é o que gasta o tempo de verdade.
Existe um custo, e preciso ser honesto sobre isso. Mapear premissas exige cultura de equipe. Se você é o único interessado nisso, vai parecer burocrático para os outros, especialmente em ciclos de entrega acelerada. Numa sprint de duas semanas, pedir para listar premissas pode parecer perda de tempo para quem só quer entregar funcionalidade. A solução que eu encontrei foi transformar isso num ritual mínimo: três linhas no início do ticket, antes de qualquer task ser movida para em andamento. Não mais que isso. Três premissas críticas, identificadas, com nível de confiança. Isso reduz a resistência porque não é um documento, é apenas um checklist. Leva dois minutos e muda completamente a qualidade da discussão técnica posterior.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que fazem atitude filosófica virar paralisia
O maior erro é confundir análise com indecisão. Atitude filosófica mal aplicada vira procrastinação disfarçada de rigor. Isso acontece quando você lista premissas mas nunca as testa. Ou quando usa o mapeamento como justificativa para não tomar nenhuma decisão. Se você passar duas semanas mapeando premissas sem avançar na implementação, não está sendo filosófico, está sendo evasivo. O teste é simples: se uma premissa não pode ser validada ou refutada em até dois dias de trabalho, ela não é uma premissa crítica, é especulação. Anote e descarte. Foque nas que realmente impactam a arquitetura. Outro erro comum é tratar premissas como verdades absolutas. Nenhuma premissa é eterna. O que era válido no contexto do sistema legadoo o qual você migrou pode não valer mais. Eu perdi uma manhã inteira debuggando um problema de serialização porque aceitei como premissa que o formato de data permanecia o mesmo após a migração. Não permaneceu. O sistema antigo usava UTC e o novo usava timezone local. A premissa não tinha sido atualizada. Isso mostra que atitude filosófica não é um exercício único, é contínuo. As premissas precisam ser reavaliadas sempre que há mudança de contexto, integração com novo sistema, ou atualização de versionamento.
Se você está num ambiente onde decisões precisam ser tomadas rapidamente e não há espaço para mapeamento explícito, a atitude filosófica não desaparece, ela se adapta. Neste cenário, o mais prático é fazer o que eu chamo de pré-mortem expresso: antes de decidir, pergunte em voz alta, num chat ou reunião rápida, "se isso der errado dentro de três meses, qual premissa provavelmente estará errada?" A resposta geralmente aponta para o ponto cego mais importante, sem exigir documentação formal. É uma versão enxuta da mesma disciplina, adaptada a contextos de alta pressão.
Como implementar sem perder velocidade
Comece com um template de três campos no seu sistema de gestão de tarefas: premissas assumidas, fontes de incerteza, critérios de validação. Isso é tudo. Não precisa de planilha, não precisa de ferramenta nova. O template é tão simples que não justifica resistência. Após cada sprint, revise duas ou três premissas que se provaram erradas. Anote o motivo. Com o tempo, você constrói uma memória coletiva de onde a equipe costuma errar, e isso vira um ativo técnico real. Uma coisa que vale a pena observar: atitude filosófica não serve para todos os tipos de problema. Em contextos onde a informação é claramente disponível e o domínio é bem compreendido, aplicar rigor filosófico é excesso. Se você está configurando um serviço de banco de dados padrão, por exemplo, listar premissas é desperdício. O método é valioso principalmente quando há ambiguidade, múltiplas interpretações possíveis, ou dependência de sistemas de terceiros cujos contratos não são totalmente claros. Nesses cenários, o investimento em clareza de premissas retorna em ordem de grandeza.
O resultado de aplicar isso consistentemente não é bonito, não é inspirador, é apenas mais eficiente. Você para de reconstruir soluções que já foram descartadas, para de discutir pontos que já foram resolvidos em outro projeto, e para de culpar o código quando o erro estava numa suposição não verificada. Não é revolucionário. É só disciplina aplicada de forma consistente.
