Developer rediscovers his own apology in code years later
A Register reader said an unresolved C# bug returned years after he left himself a warning in the project header.
By Dominic Okoye · Staff Writer
· 3 min read
A software developer writing under the name “Johnny” told The Register that an intermittent bug he could not explain early in his career resurfaced years later, complete with an apology he had left for his future self. The account appeared in The Register’s reader-submitted “Who, Me?” column, which publishes workplace mistake stories from technology workers.
Johnny said he had been hired as a Visual Basic developer and considered the role below his skill level. When assigned a new project, he chose to build it in C#, which he said was still a new language at the time, rather than in the language tied to his job title. According to Johnny, the application met the customer’s requirements until a difficult string-handling routine began failing unpredictably.
The problematic code was used to decide how tasks should be routed. Johnny told The Register the routine would succeed in some runs and fail in others, with no clear pattern. He said he repeatedly inspected the program state while stepping through the code, checking changes to variables, transformations and conditions, but did not identify a defect.
With no obvious cause, Johnny said he began making small, somewhat arbitrary edits in an attempt to expose the fault. One change caused the program to stop working altogether. He reverted that edit, and the original intermittent failure disappeared. Johnny told The Register he compared versions and reviewed his changes afterward, but could not find a technical explanation for either the bug or its disappearance.
The unresolved episode did not end with the first project. Several years later, Johnny said he was still employed at the same company and had become a senior developer. A support team escalated another intermittent issue that had resisted diagnosis, and he agreed to investigate.
His first step, he said, was to read the code comments to understand the original developer’s intent. In the file header, he found a note written by his earlier self. The message said: “Dear future Johnny, I am very, very sorry.”
The Register did not identify the company, customer, product, timeframe or underlying technical cause. It also did not say whether the later support issue was ultimately fixed. The value of the story is narrower but familiar to engineering teams: unexplained state, insufficient documentation and code paths that survive long enough to return to the person who wrote them.
The anecdote is also a useful reminder that “working now” is not the same as root-caused. Johnny’s account leaves the most important engineering detail unresolved: whether the behavior came from the language, runtime, data, environment, or the code itself.
This story draws on original reporting from The Register.