Some principles for better coding

In my previous post I showed you how a good rule (“always write tests”) can be wrong in certain cases, and for each individual case I gave some alternative suggestions. How did I go about coming up with this exception to the rules? And more importantly, how can you do so?

Underlying the rules you have been taught are principles. A principle is a general guideline, whereas a rule will tell you exactly what to do. Knowing when and how to apply a principle requires more thought than simply following a rule. I plan to discuss this at some point in the future. At the moment however I’ll limit myself to listing some of the principles underlying my last post:

  • You are more than just a rational thinker. Pay attention to your body: sometimes coding tasks are hard because you need a snack, or some sleep. Don’t ignore your emotions. Instead use them as a guide for more structured and logical forms of thought.
  • You have a limited ability to keep details in your head. Computers do not suffer from this problem, so use them to compensate for your limitations.
  • Whatever problem you’re having has already been solved in some form or another by someone else. We can all stand on the shoulders of giants, we just need to take the time to find the right one to stand on.
  • The goals of your project are the only way to measure what software quality means. If you’re throwing away your code in an hour you probably have different measure of quality than code that will be used for a decade.

There are many more principles, of course, but even internalizing just these four will make you a better programmer. In my next few posts I will discuss other applications of these principles so you can see them used in other contexts.

Meanwhile, if you re-read my last post can you see how I applied these principles? Are there any other principles you can deduce? Send me an email with any ideas or questions you have on the subject.



We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 2600 other programmers, and every week you’ll learn how to avoid another of my mistakes.


You might also enjoy:

»» Get the work/life balance you need
»» Level up your technical skills