A developer declared a variable called temp and moved on.
Six months later, another developer found it still there, holding something important.
The senior developer was asked, “Should we rename it?”
The senior replied, “What is more permanent than that which was meant to be temporary?”
The Teaching Unfolds
We have all written temp. We write it at 4pm on a Friday when the concept has no name yet, when we are moving fast and the variable is just a placeholder, a stepping stone to something else. We tell ourselves we will come back to it. We do not come back to it.
Six months pass. A new developer opens the file. There it is: temp, sitting quietly in the middle of something load-bearing, holding a value that the rest of the system depends on. The scaffolding became the structure. The placeholder became the thing itself.
This is not a story about bad naming conventions. It is a story about the nature of the temporary.
In software, as in life, the things we intend to be fleeting often turn out to be the most durable. The workaround that outlives the problem it worked around. The quick fix that ships and stays. The prototype that becomes the product. We underestimate the permanence of the provisional because we assume we will always return to refine it. But the code does not wait for our good intentions. It runs, and it runs, and it runs.
The senior developer’s question is not rhetorical. It is an invitation to look honestly at what we do when we name something temp. We are making a declaration about its importance, or rather, its lack of importance. We are saying: this does not deserve a real name yet. And then we move on, and the code does not.
There is something worth sitting with here. The variable was called temp precisely because it was not supposed to matter. But it did matter. It always mattered. We just had not decided to acknowledge that yet.
Renaming it is not merely a technical act. It is an act of honesty. It is admitting that what we built is real, that it has weight, that it deserves to be called what it actually is. This is one of the quieter forms of craftsmanship in software: the willingness to go back, to look clearly at what exists, and to name it truthfully.
The senior developer does not say whether to rename it or not. That is not the point. The point is the question underneath the question: when did the temporary become permanent, and were you paying attention when it happened?