Essay··4 min read

Reading My Own Code from a Year Ago

Was refactoring legacy code and the culprit turned out to be me. Turns out git blame is a terrifying command.

The Moment I Ran git blame

I was refactoring some legacy code. There was this one function I absolutely could not understand. Variable named temp2, no comments, if statements nested four levels deep. Who on earth wrote this?

I ran git blame.

It was me. Me from a year and two months ago. The commit message read "fix: urgent fix."

(I can't even remember what was so urgent.)

I Want to Have a Word with Past Me

Honestly, I'd love to ask the me from a year ago: why did you do this? In what context did you decide this was the best approach?

But the answer is obvious if I think about it. I was in a rush. The timeline was tight. "I'll fix it later." I just didn't know "later" would turn out to be a year from now.

The issues I found:

  • The same logic was copy-pasted in three different places
  • Error handling consisted of a console.log inside a catch block
  • Every type was any (there's genuinely no excuse for this one)
  • The magic number 86400 was hardcoded with zero explanation (it took me 4 minutes to figure out it was seconds in a day)

But Weirdly, It's Also Reassuring

At first, I was embarrassed. I wrote this? But after sitting with it for a while, I actually felt a strange sense of relief.

The fact that code from a year ago looks terrible now means I've grown that much. If I looked at year-old code and thought "yeah, that's fine" — that would be scarier. It would mean I hadn't moved an inch in a year.

I never expected growth to show up like this. Cringing at your past code being a sign of progress? That's something.

Will Today's Code Look Just as Bad in a Year?

This is the truly scary thought.

The code I'm writing now, the stuff I think is "clean and well-structured" — there's a strong chance I'll look at it in a year and go "what is this?" Maybe not a chance. Maybe a certainty.

So what should I do now? Spend two weeks trying to write perfect code? No. Future me will find it lacking regardless. Write sloppy code then? That doesn't feel right either.

I think the answer is doing your best with what you know, while keeping the structure flexible enough to change later. But knowing me, "keeping the structure right" will also look inadequate in a year. It never ends.

The Real Problem Is the Missing Comments

Code style can evolve. But having no comments borders on criminal. The me from a year ago didn't document why any of this logic existed. I was too devoted to the "code is documentation" mantra.

Code is documentation — sure, when the code is well written. When you're using variable names like temp2, the code isn't documentation. It's a cipher.

(Honestly, I still skip comments sometimes.)

The Refactor Took Three Days

I ended up rewriting that function from scratch. Took three days. The original estimate was half a day. I told the PM "it's more complex than expected," but the honest version would've been "I wrote it sloppily a year ago."

I added tests during the refactor. The existing test count was zero. Also past me's fault.

After finishing and putting up the PR, I wondered: what will the me from a year from now think of this code? Probably sigh. But at least I left comments this time, so maybe fewer sighs.

Who knows. I'll just have to come back in a year and find out.

Related Posts