The site was down. A developer pushed a one-line change directly to production.
The next morning, the senior developer asked, “Did the fix work?”
“Yes.”
“Do you remember what you changed?”
The developer paused, then opened the commit. They did not recognize their own hands.
Sitting with the Koan
There is a particular kind of coding that happens at midnight when the site is down. The Slack alerts are firing. Someone senior is watching. The fingers move fast, driven not by understanding but by urgency, by fear, by the need to make the red go green.
The fix worked. That much is true.
But the next morning, reading their own commit, the developer did not recognize their own hands. Not the logic. Not the variable name. Not the decision to change that line and not another. The code was theirs in the most literal sense, pushed under their credentials, timestamped to their session. And yet it was written by someone they no longer were, or perhaps someone they had never properly met.
The koan is not asking whether the fix was correct. It is asking who made it.
We talk a great deal in software development about ownership. We own tickets. We own services. We take ownership of bugs. But ownership implies a continuous self who can be held accountable, who understands what they built and why. The developer at midnight was operating in a different mode entirely, one closer to reflex than reasoning. The pressure collapsed the gap between stimulus and response. There was no space for understanding, only for action.
And the action worked. This is what makes the koan uncomfortable.
Because if the fix worked, should we care who made it? The site came back up. The users never noticed. By every external measure, the incident was resolved. The commit sits in the history, one line, green checkmarks, closed alert. What is there to question?
What is there to question is the developer who cannot account for their own work. Not to a post-mortem, not to a colleague, not even to themselves. If you cannot explain what you changed and why, you have not fixed a problem. You have performed a ritual that happened to have the right effect this time. The difference matters enormously the next time.
There is a concept in Zen practice of acting from a place of no-mind, mushin, where the practitioner responds to a situation with such deep training and presence that action arises without deliberate thought. A master calligrapher does not think about each stroke. A martial artist does not plan each movement. The response emerges from a depth of internalized understanding.
This is not what happened at midnight. What happened at midnight was not mushin. It was panic wearing the mask of competence. The hands moved, but the mind was not present. The developer was not drawing on deep reserves of understanding. They were running away from an alarm.
The question the senior developer asks is not a rebuke. It is an invitation to notice the difference between those two states, between action grounded in understanding and action driven by fear. Both can produce a working commit. Only one produces a developer who grows.
Many of us have written code we would not recognize the next day. Deadline code. Pressure code. Three-in-the-morning code. We have all pushed fixes while hoping rather than knowing. The practice this koan points toward is not to eliminate those moments. Production goes down at midnight. That will not change. The practice is to return to them in the morning with honesty. To read the commit. To ask, do I understand this? And if the answer is no, to learn it now, in daylight, before the next incident requires it.
The fix worked. But the work is not finished until the developer can say, in full daylight, with clear eyes, exactly what their hands did and why.