Code from the Past

We all try to write the best, most elegant, most functional code we can. It’s our life: we get paid to write good code, plain and simple. We like to feel that the project that we’ve done our best work on is our current project at hand. That being said, what happens when you read code from that project after a few months or even a year?

Embarrassment. Or at least that is how I feel. “How did this code ever work?” or “Why did I do something this way?”

My friend who has been my roommate for two years at Iowa State is doing an internship this summer; his boss said that whenever an interviewer asks, “Tell me a time where you’ve failed.” he replies, “Every time I look at the code I wrote 2+ years before”.

I can directly relate to this. Looking back at old code, I feel like the code is a typed out failure. After discussing my mindset on this topic with a coworker of mine, my mindset has started to shift.

This new mindset holds that the code from a past project was right at the time so the product was deployed. The code was at least “good enough”; therefore it was not a failure. Another thing that I have worked on believing is that without writing those (now) “bad” lines of code, I wouldn’t have learned how to write the (currently) “good” lines of code.

A good programmer is constantly learning. This brings about changes in programming styles, techniques, design, and the list goes on.

In conclusion, this is how I am going to try to see it when looking at code of the past from now on: I desire to be a good programmer, one who is constantly learning. Because of the constant learning, it is unfair to judge myself on something that was written many lessons learned ago. The only thing I can do is reflect on what’s been built and apply the lessons that I learned in the projects of today and tomorrow.