Get away from your computer!

Want to write some code? Get away from your computer!

http://blog.rtwilson.com/want-to-write-some-code-get-away-from-your-computer/

I’ve recently realised something. The best place to write code isn’t in front of your computer, with your compiler, IDE and tools. The best place to write code is far, far away from any of these tools – somewhere where you can think properly. For a language with which you are fairly familiar, the mechanics of translating the program in your mind to a program that the compiler can compile (or the interpreter can interpret) is fairly easy – it’s coming up with that program in your mind which is hard.

The other day I was on a train journey. I had my laptop, but no internet. Unfortunately I was using a commercial programming language (, as it happens) for which I need to use my university’s site license. As I didn’t have access to the internet, I couldn’t get hold of the site license, so couldn’t run the compiler and IDE. Say what you like about commercial programming languages which require expensive licenses, but it stopped me from actually writing code in my editor with the compiler. And…guess what…it actually made me think!

I guess this post is somewhat along the lines of and the following quote:

One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.”

That is what being away from your compiler forces you to do. It’s very easy to slip into the mindset of:

1. Write a bit of (fairly bad) code
2. Compile and run
3. Test with a poorly chosen test case
4. Find it doesn’t work
5. Make small change to the code on the off-chance that it might solve the problem
6. Repeat…

Of course this leads to code in the end that is ill-understood by the programmer, probably fairly buggy and not well tested.

Being away from the computer forces you to run through all of the thoughts in your head – which tends to take longer than getting a computer to compile and run your code (for small code bases at least…). So you don’t tend to make tiny changes and re-run things, you tend to actually think about what the code is doing. Until I did this on the train the other day, I hadn’t actually run a piece of code on paper (that is, written down columns for each of the variables and worked out what each value will be at each stage in the program) since my Computing A-Level exam!

In the case of the code I was writing the other day, I managed to produce some high quality, fast, bug-free code by writing it in long-hand on a piece of paper, thinking about it, gradually typing up bits of it, thinking some more, and then after a long time trying it in the compiler. The code (which was some region-growing image segmentation code which involved lots of recursion) was eventually copied from my piece of paper to my IDE, compiled (with only one syntax error – impressive I think) and ran correctly first time (and completed all of the tests that I had also devised on paper).

Job well done, I think, and a useful piece of advice, I hope.