O Doutor do Dia Seguinte 🩺
Um médico exausto salva um paciente de madrugada. No dia seguinte, outro, descansado, olha o prontuário e acha tudo simples. A mesma cena se repete todo dia com código legado. Sobre julgar decisões sem conhecer o contexto em que foram tomadas.
Estes dias eu estava ouvindo um podcast em que um médico muito conhecido, o Dr. Paulo Muzy, conta uma história mais ou menos assim:
Imagine um hospital com um médico plantonista que já está há mais de 24 horas de trabalho, cansado, com sono e com fome. De repente, ele se depara com uma situação crítica no corredor: um paciente em estado grave e uma família completamente alterada, desesperada por atendimento. O médico admite o paciente e, enquanto tenta salvá-lo, ainda precisa acalmar os familiares. Depois de alguns procedimentos, consegue estabilizar o quadro, encaminhar o paciente para a UTI e pacificar a família. Incêndio apagado.
No dia seguinte, com o paciente já estável na UTI, chega outro médico. Esse teve uma noite tranquila de sono, tomou café com a família, levou o filho para a escola e foi trabalhar. Ao olhar o prontuário e algumas poucas análises, ele conclui: “Nossa, mas isso era tão simples de resolver.”
⚖️ Duas condições completamente diferentes
Repare na diferença entre os dois médicos. O primeiro atuou sob pressão, cansaço e estresse máximo. Tinha que apagar um incêndio ali, naquele instante. O segundo, descansado e bem alimentado, por motivos óbvios consegue pensar com clareza e elaborar uma solução muito mais refinada.
O ponto não é quem é o melhor médico. É que eles nunca estiveram no mesmo jogo.
💻 Trazendo para o mundo da tecnologia
Quem nunca olhou para um sistema em produção e soltou um “mas por que isso foi feito desse jeito?”.
De certa forma, também estamos sendo o Doutor do Dia Seguinte. Julgamos um código a partir de uma situação completamente diferente daquela em que ele provavelmente foi escrito: pressão de entrega, bug em produção, cliente reclamando, prazo apertado, aquele incidente às duas da manhã.
🔥 Um caso prático (o retry “feio” que segurou a Black Friday)
Deixa eu contar um caso que ilustra bem isso.
Imagine um serviço de checkout que, em plena Black Friday, começa a falhar. O gateway de pagamento está respondendo de forma intermitente, alguns timeouts aqui, outros ali, e cada pedido que cai é dinheiro saindo pela janela. São duas da manhã, o time de plantão está sob pressão, o pico de vendas do ano acontecendo em tempo real.
O engenheiro de plantão não tem tempo de desenhar a solução ideal. Ele abre o código e adiciona um retry na mão: três tentativas, um Thread.Sleep entre elas e um fallback para um gateway secundário quando o principal não responde. Feio? É. Mas o faturamento voltou a fluir, e a Black Friday foi salva. Commit às 02:47, direto na main.
Meses depois, chega um novo engenheiro, descansado e sem nenhum incêndio por perto. Ele abre esse mesmo trecho e pensa: “Que gambiarra é essa? Um Thread.Sleep num retry? Bastava um circuit breaker com Polly e uma política de backoff exponencial, isso é básico.”
E ele está certo. Tecnicamente, existe uma solução muito melhor. Mas ele é o Doutor do Dia Seguinte. Ele não estava lá às duas da manhã, com o CEO no grupo do WhatsApp perguntando por que as vendas tinham parado. Naquele contexto, aquele retry “feio” não era ignorância. Era a decisão certa para manter o barco flutuando com o tempo e as informações que existiam naquele momento.
A diferença entre os dois não é competência. É contexto.
🧭 O aprendizado
O que essa história me ensinou foi simples: nada que foi feito ali foi feito sem motivo algum.
Tente entender o contexto antes de criticar. A crítica pura e simples raramente traz benefício para a situação, mas entender o porquê traz luz para as soluções futuras. Vale para o código legado, para a decisão de arquitetura que você herdou e, principalmente, para as pessoas que estavam apagando o incêndio antes de você chegar.
Isso não significa que a gambiarra deva viver para sempre. O retry da Black Friday precisa virar, sim, um circuit breaker bem feito. A diferença está em como você chega nessa melhoria: refatorar entendendo o contexto é evolução, criticar sem entender é só arrogância com data marcada para envelhecer mal.
Antes de perguntar “quem foi o louco que fez isso?”, pergunte “o que estava acontecendo quando isso foi feito?”. A resposta quase sempre muda a conversa.