Tom's Second Law: It's Already Been Done

Or, Do NOT Re-invent the Wheel

When designing and/or implementing anything other than business logic - and sometimes even then - the odds are very good that what you need has already been built. The problems solved by any particular application are usually related, so in a project of reasonable size you're likely to find an existing solution within that same project. And the problems solved by applications in general are largely similar, so thanks to free and open-source software, you're likely to find a solution somewhere out there on the web. Seek out those existing solutions and use them if you can. If you can't use them you can at least learn from them.

Remember what Picasso said - good artists copy, great artists steal. Programmers tend to think that only their code is worthwhile, and that they must write everything themselves from scratch. That mindset is a recipe for disaster. Fight the urge to code everything yourself. Instead, assume that it's already been done, and build it yourself only after you fail to find an existing implementation. You'll be much more productive and produce higher-quality code over the long-term.

Tom's First Law: Code Readability is the Key to Long-term Software Quality

Setting aside correctness of functionality (which should be addressed with as much automated testing as possible), I consider "good code" to be code that is easily understood by others. Good code naturally gives rise to quality products, so... if you want to build a quality product, write code that others can understand.

Remember, 6 months from now, you'll be a different person. So "others" technically includes you, the original author, not just beings who inhabit other bodies. Speaking from experience, there are few things more frustrating than looking at code you yourself wrote and not being able to understand how it works.

There are at least two very good reasons why mindful code writing leads to quality products in the long term.

First, unless you live alone on an island without Internet access (in which case you won't be reading this anyway) then someone else, at some time, is going to look at and modify your code. A co-worker, a QA engineer, a professor... your eventual replacement if you write lousy code... somebody else is going to work with your code. Not only will you make their lives better by making it easy for them to understand your code, but you will help them avoid creating new bugs due to misunderstandings about your code. That in turn frees them up to add new features or make other improvements, both of which make for better software.

The second but probably more important reason to keep your audience in mind while writing code is more subtle. Focusing on your future audience forces you to step back and think about the code differently. Bugs jump out at you when you try to see the code through someone else's eyes. You take fewer shortcuts when you assume someone else will look at the code, because you know they'll think you're a lazy SOB for taking those shortcuts. You add extra comments to explain things so that the funny smelling guy on the next floor doesn't come asking for explanations. The list goes on and on.

At an institutional level, this idea manifests itself as coding standards. Good coding standards can make a lot of things better, but the burden is still ultimately on you, the developer, to remember that the world doesn't revolve around you. Embrace that responsibility - your co-workers and your career will both thank you for it.

And most importantly, so will your customers.