Growing older and keeping it simple

Having recently experienced a significant milestone birthday (no, I’m not going to tell you which one), I’ve been thinking about the way my thought processes have changed since I started programming way back in 1982 on a ZX81.

On the one hand, I’m no longer convinced that I know the answer to every programming problem. As Phil Haack writes in his post Getting Older:

The other evidence of my getting older is that I know a lot less now than I did when I was younger … I knew the right way to do all things in all situations with absolute conviction. But these days, I’m not so sure.

On the other hand, I no longer feel that I’m a failure for not knowing a solution instantly. Experience has taught me that I’m usually smart enough to find and recognise or create any solution I need. John Rusk has an interesting perspective on this in his post Becoming an Expert:

When I need to debug it myself, I don’t get “stuck”. I might not know the cause of the problem, but I always have an idea on what to do next – something that will take me one step closer to finding the problem. Just like experienced players instantly “see” good moves in a chess game; I tend to “see” good moves in the debugging process.

For me, writing software is a similar process - bringing together a number of techniques and approaches, knowing that they’ll work together in the way required. And, as John discusses in his article, I can always explain the choices made in a logical manner, it’s just that sometimes the design comes before the explanation.

One of the key lessons I’ve learnt is that simple code tends to be better code. Simple code is usually quicker to write, easier to test, much easier to read and most often has fewer nasty edge cases.

It’s unfortunate that a lot of code is needlessly complex - in addition to the essential complexity of the problem at hand, systems often have large amounts of incidental complexity that isn’t really required. Chuck Moore, in his interview The Lost Art of Keeping It Simple on Simple-Talk.Com says

First, one doesn’t understand the problem initially and thinks it’s more difficult than it is. In the course of solving the problem, one learns about it. But in the rush of completing it, never re-examines the premises, rewrites and simplifies. This is not a small omission; code can be an orders of magnitude too elaborate.

As a younger developer, I used to think that my job was to deliver working code, reguardless of the complexity.

With the benefit of many years of experience, I now realise that while working code is necessary, it’s not sufficient. After all, nobody wants my code, they want the value my code provides.

My job isn’t done when the code works today, it’s done when that code is going to continue to work, day after day, until they don’t need it any more. Keeping thing simple helps.