What thoughts go through your mind when you look at the code that you have written a few years back? I don’t know about you, but for me it’s mostly unease. Over the time, as we refine our coding style, learn new techniques or even new languages, we tend to view our current coding practices as the best it can get. Objectively speaking, this can hardly be true.

First of all, if you’re looking at the code that you wrote five years ago and smile condescendingly, how can you be so sure that the same won’t happen five years from now? Just because you’re using the best development techniques du-jour (be it agile, scrum, iso, cmm, web services, …), the best languages du-jour (erlang, ruby, factor) or the best design patterns du-jour (inversion of control, …), does it mean that they are really the best? Hardly, especially given the volatile state of software development. Sure, you can say, back then i was this wide-eyed fresh-out-of-college junior dev, but now i’m an experienced developer with tens or hundreds of thousands of lines under my belt. Does that mean that you’ll be standing still over the next five years? Will you be using the same development techniques, tools, languages or even hardware in 2012? It works the same even for language theorists that find the existing concepts dated and inconsistent.

Second, you will always have bugs. And this is a Good Thing™ and you should make it as easy as possible for your users to report them to you. And if Neal Gafter can blog publicly about a bug in the core JDK code, it only means that nobody is perfect. You can have all the experience in the world, and you will still write buggy code. And as time goes by and simpler bugs are found, it means that the bugs that are left are much harder to detect and reproduce. The code you’re writing today has bugs. As did the code you wrote five years ago. As will the code that you will write five years from now. The only way your code will not have bugs is when you don’t write any code at all.

Now, the only real advice i can think of is simple – don’t get attached to your code. It might be clever, it might be beautiful and it might even work the first time you run it (and this is a Bad Sign™). Once you get attached to it, it becomes much harder to objectively respond to bug reports filed against it. It becomes much harder (especially when you’re working with a team) to argue about its deficiencies or even agree for it to be replaced / removed altogether in favor of some other implementation. It is especially painful when junior developers have to maintain the pile of code that you have written a few years ago, and your current architect / senior dev ego doesn’t let you acknowledge a simple fact – that it is completely unmaintainable, impossible to understand and very painful to extend.

Instead of projecting yourself on the code, project the code on its users. Does it do what the users want? If it does, who cares about how it does it? If it doesn’t, nobody will use it and nobody will care how clever / beautiful / smart it is.