Questionable Code: It seemed like a good idea at the time

I write this as a bit of a goodbye to my current job, which I have enjoyed greatly over the years. Thanks everyone!

  • My first wish is that when my soon-to-be former co-workers come across any questionable code I wrote a years ago when I was inexperienced that they don’t judge me too greatly.
  • My second wish is that when they come across any questionable code I wrote just last month that they also don’t judge me too greatly.

I am switching jobs, and as part of that have been working to transferring some the areas of code where I have been the primary (or only) person developing or maintaining.

So, I’ve spent the week sitting down with one of my (soon to be former) co-workers going over a large component that I helped write, answering: “What does it do?” and “How does it do it?”. Of course while discussing the latter, inevitably another questions comes up: “Why did you do it this way?”

This can sometimes be a hard question to answer. Especially if it’s been a few years since you last worked on it. It can also be an awkward or even embarrassing one.

In this case my co-worker pointed out (quite correctly in my opinion) that the code seemed vastly more complicated than it needed to be. As soon as she pointed it out, I could see it too: the section was a massive and over-engineered piece of code. And at first, I couldn’t really answer her (or even remember myself) why.

Thoughts went through my head like: “This is way to complicated.” and “What was I thinking?” and “God, I hope she doesn’t think that I’m a terrible coder.”

And then, slowly, I begin to recall some of the reasons. I’m sure this is a list that we all recognise:

  • “We were eventually planning to do thing B with this too, and so had to account for it, but we never built thing B.”
  • And “I never really liked doing it this way but the guy I was working with pushed for it.”
  • As well as the opposite “I kind of pushed for my design but in hindsight the other guy’s would have been better.”
  • To the all-to-common “Well we were rushed and didn’t have time to do it the way we wanted.”

I’m sure each of these has happened to us from time to time. Hindsight is 20/20 and project needs change over time. A few years down the road, something that seemed like a very reasonable idea at the time, can turn out to be an over-engineered mess or even too simplistic and not robust enough. Projects can be rushed with intentions to revise later that never happen.

These are problems we all face and must always work at, and we have to keep our eyes open for them. There are certainly many sections of code in projects I’ve been a part of that I know need work, but as this experience pointed to me, there are also sections where familiarity makes it easy overlook or to just think “That’s just how we do it”.

In the end I was happy for the chance at a code review, as it made me re-examine some code that I had become accustomed to, made me reconsider better ways to do it, and left the company with not only a good understanding of how it’s working now, but also with some solid suggestions for improvement.