Dear Past Me: Notes From the Developer Who Has to Fix Your Code

Last month I opened an old project and found a function called handleStuff. It was 140 lines long, had zero comments, and right in the middle sat a line that said // TODO: fix this later.

I did what any mature developer would do. I opened git blame, ready to find the guilty person and have a serious talk with them.

It was me. Eight months ago, at 2 AM, with a deadline and half a cup of cold tea.

That's when I understood something nobody tells you when you start programming: most of your career is not spent writing new code. It's spent dealing with the decisions of someone who no longer lives at your address. That someone is you.

The stranger who wrote your code

When you write code, you feel like you understand everything. The logic is fresh, the names make sense, and you think, "Why add a comment? It's obvious."

Then three months pass, and your brain throws away everything it thinks you don't need. When you come back, the code looks like it was written by a stranger with strange habits and a deep love for variables named temp.

But Past You was not stupid. Past You was tired, rushed, and sure that Future You would remember everything. Past You was an optimist, and Future You pays for that optimism.

"For now" is the most dangerous phrase in software

Nobody sits down and says, "Today I will create a mess." It always starts with a good reason: the client wanted it by Friday, the server was down, the manager said, "Just make it work for now."

Nothing lasts longer than a temporary fix. I have seen "temporary" solutions survive three team changes and one full rewrite. Somewhere, a quick hack from 2019 is still running in production, and everyone is too scared to touch it, like an old grumpy neighbor nobody wants to upset.

Naming is really thinking

Ask any developer about naming things and watch their eyes go distant. You start with x, then x2, then x2_final, then x2_final_updated. At that point you're not programming, you're writing the history of your own confusion.

But naming is hard for a reason: it forces you to understand what your code really does. If you can't name a function clearly, maybe it's doing too many things. A bad name is often a warning that your thinking is messy.

Comments are letters to the future

Most of the time, you write comments for yourself, the same person who will one day open this file with no memory and a lot of anger.

A good comment doesn't explain what the code does. The code already says that. It explains why. "We check this twice because the payment API sometimes lies" is worth more than a hundred lines of clean syntax.

So next time you think, "I'll remember this," stop. You won't. Memory is the most unreliable tool in software, and we still trust it every day.

Be curious, not angry

When you find ugly code, you can be angry or curious. Angry is easy: you rewrite everything and feel smart for a day. Then you discover why the code was ugly. A strange edge case, a weird customer, a bug that only appears on the last day of the month. Reality is ugly, and you were about to repeat the same mistakes with prettier syntax.

Curious is harder, and it makes you better. Ask, "What problem was this person solving? What did they know that I don't?"

And remember, someone will open your code one day and ask the same questions about you. They won't know about your deadline, your bad week, or your cold tea. They will only see the code.

Write for the tired stranger

You can't write perfect code. But you can write code that is kind to the next person. Leave a clear name. Leave a short comment that explains the reason. Replace // TODO: fix later with what should be fixed.

Because one day a tired stranger will open your project at 2 AM and decide whether to thank you or curse your name.

I hope they thank you. Me? I'm still trying to rename handleStuff to something that doesn't make me ashamed.