I had an enlightening conversation with Mark Wotton on twitter recently. It started when I gave the following advice:
Writing advice: You should have a constant mental process going asking “Is this bit I’m writing boring?”. If it is, delete or rewrite it.
I’d meant it to apply to prose. I was reading an article which took an important and exciting piece of information and made it deathly dull. I don’t want to link to the article, but I’m sure you can think of examples yourself.
Mark replied:
I thought you were talking about code for a second there – it actually works pretty well there, too.
This wasn’t a context in which I’d thought about it before.
I won’t quote the entire conversation here (you can check it out at the source if you care), but the conclusions from it were interesting.
A lot of code is boring, and sometimes this is ok. Most code does boring things – display a web page, convert data from this format to that format, write out an error message, etc. Boring tasks are ubiquitous and necessary to get things done.
But, like writing, you can write about things which are boring and you can write about things in boring ways.
What does boring writing look like? Well, it could contain a lot of repetition, it could take forever to get to the point making it non-obvious what it’s about, it could include a lot of irrelevancies…
Hmm. None of those sound like very good things to do when coding, do they?
As people are fond of saying, code should really be first about telling other people what it should do and secondarily about getting the computer to execute it. Coding is a form of writing, and as such it needs to keep the reader interested or their boredom will get in the way of their understanding (side note: this is not the same as making the reader work hard to understand it – not being boring is not the same as being overly clever).
So, it’s ok to write code that is boring because what it is trying to do is inherently boring, but you shouldn’t add unnecessary boredom to the code.
Hmm. That sounds familiar.
So, to borrow the terminology from Fred Brooks: There are two types of boredom. Essential boredom, which is inherent to the problem being solved, and accidental boredom, which is introduced by the programmer. Seek to minimize the latter.