Wednesday, 9.25pm
Sheffield, U.K.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. – Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.
Most people react instinctively to complexity in the way animals respond to a forest fire.
They try and get as far away from it as possible.
Not everyone though.
Some people make things complicated because they’re learning and they’re trying to push their boundaries – do things in new ways.
And that’s a good thing.
Eventually, they will learn that the really cool and complex thing they made two years ago is now the bane of their lives as they struggle to maintain and deliver a service using it.
And then they will learn the value of simplicity.
Others see their mastery of something complicated as a weapon, a secret to be hoarded – as if the possession of knowledge is a guarantee of security.
And that’s less useful, because no one wants to work with people like that really.
If you are a programmer – an experienced one anyway – you will know that any reasonably sized piece of work you make will have bugs.
Often, the way in which we work encourages us to create bugs.
This is not restricted just to programmers, however, it applies to most people who interact with a computer.
For example, if you write, do you rely on your word processor to help you with spelling and grammar?
Do those little red lines or the absence of them help you correct mistakes?
If you are expecting the computer to pick up all those errors, then you’re doing the same thing as a programmer – creating something and then hoping that when there are no red lines on the screen you are done and can send the thing.
Except, do you find that every once in a while errors still creep in, two words have crept in that are spelt correctly but don’t belong together.
If you really want to catch your mistakes, what you should do is print out your document and read it, catching as many errors as you can manually before using the computer.
And, it turns out that if programmers do this they catch quite a few more bugs before the things get a chance to get built into the program.
But who has the time to do that – I don’t – I often catch errors in these posts only when I read them later.
Now, this principle applies to much in life.
Any time you create a process – a marketing process, a sales process, an operations process – there is a temptation to create steps and gateways and forms.
Imagine that the thing you’re creating is a program – it’s a set of instructions that are going to be executed one after the other, perhaps some in parallel.
It should be obvious to you that the number of bugs is going to scale with the number of instructions – if you don’t do something then you can’t do it wrong.
So why is it that any seminar on sales will give you a 7 step process, a 10 step process, a 15 step process?
Is that because they have to justify the value – it’s hard to charge you much if I say – just listen to your prospect and build what they tell you they need.
If you try and give people too many instructions they will probably do them wrong.
And, unlike a machine, they will interpret those instructions quite differently from someone else – creating a whole new category of bugs – ones that arise from misunderstandings and miscommunication.
The only way to deal with this is to recognise that the world has no need of the smartest thing you can build.
Actually – you don’t need to do that.
When you come across something made by someone else – or even something you made a few years ago you’re like a person blundering about blindly – trying to figure out what is going on while deprived of a number of senses.
When you have something complicated to deal with in that condition – it’s just going to make you unhappy.
So be kind to your future self – and keep things simple.
Cheers,
Karthik Suresh
p.s. Some more good quotes about programming and keeping it simple are here…
Handcrafted insight 