Programming is full of decisions. Apart from the simplest or most familiar tasks, you don’t work on autopilot.

There are many ways to get a program to work. But some ways are better than others; they cause fewer headaches along the way, make the code easier to maintain, lead to fewer bugs in the end. To find those ways, you have to make decisions, constantly, correctly and quickly.

There are big decisions at the start of a project. Which system to develop for (or should it be cross-platform?), which language to use, which API. These choices can seriously affect the progress and outcome and should be considered carefully.

Then there are lesser, but still far-reaching decisions. What kind of coding standards to follow. Which paradigms to embrace or reject. What sub-systems to create.

Every line is a decision. What algorithms to use. How to organise the code and data. What comments to write. What checks to put in.

There are a few types of decision that can paralyse progress and for these I have some general guidelines that I follow:

  1. Should you trade coding speed for accuracy and maintainability? Maybe – it depends whether you are writing production code or not.
  2. How much planning should you do in advance of coding? As little as necessary. Coding drives thinking and you will find out more as you go.
  3. Should you write top-down or bottom-up? Write interfaces top-down. Put yourself in the place of the user. Write the implementation bottom-up. Add as little as you need in each step in order to test it.


Most importantly, keep the code simple and clear. You (or someone else) will need to be able to read it in six months time and understand what decisions were made and why.

Above all else ... clarity.