The Next-Day Doctor 🩺
An exhausted doctor saves a patient at dawn. The next day another one, well rested, reads the chart and finds it all simple. The same scene plays out every day with legacy code. On judging decisions without knowing the context they were made in.
The other day I was listening to a podcast where a well-known doctor, Dr. Paulo Muzy, tells a story that goes something like this:
Picture a hospital with an on-call doctor who has been working for over 24 hours straight. Tired, sleep-deprived, hungry. Suddenly he runs into a critical situation in the hallway: a patient in serious condition and a family completely beside themselves, desperate for care. The doctor admits the patient and, while trying to save him, also has to calm the relatives down. After a few procedures, he manages to stabilize the patient, move him to the ICU, and reassure the family. Fire put out.
The next day, with the patient already stable in the ICU, another doctor arrives. This one had a peaceful night of sleep, had coffee with the family, dropped the kid off at school, and went to work. Looking at the chart and a few test results, he concludes: “Wow, this was so simple to solve.”
⚖️ Two completely different conditions
Notice the difference between the two doctors. The first acted under pressure, exhaustion, and maximum stress. He had to put out a fire right then and there. The second, rested and well fed, can obviously think clearly and come up with a far more refined solution.
The point isn’t who the better doctor is. It’s that they were never playing the same game.
💻 Bringing it to the tech world
Who has never looked at a system in production and blurted out “but why on earth was this done this way?”.
In a way, we are also being the Next-Day Doctor. We judge a piece of code from a situation completely different from the one it was probably written in: delivery pressure, a production bug, an angry customer, a tight deadline, that incident at two in the morning.
🔥 A practical case (the “ugly” retry that saved Black Friday)
Let me tell you a case that illustrates this well.
Picture a checkout service that, in the middle of Black Friday, starts failing. The payment gateway is responding intermittently, a few timeouts here, others there, and every order that drops is money going out the window. It’s two in the morning, the on-call team is under pressure, the biggest sales peak of the year happening in real time.
The on-call engineer has no time to design the ideal solution. He opens the code and adds a retry by hand: three attempts, a Thread.Sleep between them, and a fallback to a secondary gateway when the main one doesn’t respond. Ugly? It is. But revenue started flowing again, and Black Friday was saved. Commit at 02:47, straight to main.
Months later, a new engineer arrives, rested and with no fire in sight. He opens that same snippet and thinks: “What kind of hack is this? A Thread.Sleep in a retry? A circuit breaker with Polly and an exponential backoff policy would do the job, this is basic stuff.”
And he’s right. Technically, there is a much better solution. But he is the Next-Day Doctor. He wasn’t there at two in the morning, with the CEO in the WhatsApp group asking why sales had stopped. In that context, that “ugly” retry wasn’t ignorance. It was the right call to keep the boat afloat with the time and information available at that moment.
The difference between the two isn’t competence. It’s context.
🧭 The takeaway
What this story taught me is simple: nothing that was done there was done for no reason at all.
Try to understand the context before criticizing. Pure, plain criticism rarely brings any benefit to the situation, but understanding the why sheds light on future solutions. This applies to legacy code, to the architecture decision you inherited, and above all to the people who were putting out the fire before you showed up.
This doesn’t mean the hack should live forever. The Black Friday retry does need to become a proper circuit breaker. The difference is in how you get there: refactoring with an understanding of the context is evolution, criticizing without understanding is just arrogance with an expiration date.
Before asking “who was the fool who did this?”, ask “what was going on when this was done?”. The answer almost always changes the conversation.