Posted February 28, 2012 at 11:48 am by Ed Guiness
When I’m asked at an interview to talk about my weaknesses, I usually say that apart from being a perfectionist (said with irony) I can sometimes be too analytical.
Being analytical as a programmer is a major advantage, but I’m told by those close to me that every now and then I can be a royal pain in the arse.
“…it’s useful to remember that you’re buying into an abstraction over something.”
Which is fine advice for the normal person (the person who might make a note to read up on multipart form data sometime, uh, maybe) but my reaction led me to turtles.
I’ll come back to turtles later.
Just like kitchen gadgets and the postal system, software is sweet when it works and can really create disorder when it doesn’t.
Part of the wonderful thing about working computer systems is how they present us with a simplified view of the underlying system. In other words they present us with an abstraction.
The better the abstraction the more we come to depend on it, and the less able we are to cope without it.
In almost the same way, many programmers using the Microsoft stack of technologies cannot write code without Visual Studio, even though their predecessors made do with a text editor, a compiler, and make. Some have gone as far as asking if Visual Studio might rot the mind.
Of course, real programmers cut code with a magnetised needle and a steady hand while the truly hard core do it with butterflies.
This is not to criticise my fellow coders; we get leverage from development tools just as we get leverage from abstractions. We almost never need to revert.
Charles Petzold, renowned programmer and author, wrote a book called Code: The Hidden Language. What’s good about this book is that it goes much deeper than your average book for dummies. Petzold describes computer systems from the ground up – he starts with how communication can be encoded as ones and zeros, works his way through logic gates, to calculating machines, to low-level languages, and eventually arrives at modern computer systems and the internet.
It’s a real eye-opener if your introduction to computer systems was writing HTML for the web, and a book I highly recommend.
I mention Petzold’s book because it shows how many layers of abstraction we take for granted, even if we think ourselves “techie”.
Back to the turtles…
A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!”
– Stephen Hawking in A Brief History Of Time
Whether it was Bertrand Russell or a Hindu that came up with the image, an infinite regression of turtles seems a good metaphor for the question of how deep a programmer should dive beneath the immediate abstraction.
At one extreme the programmer can ignore the turtles, and struggle like an inverted turtle when the underlying reality fails to cooperate.
At the other extreme the programmer can disappear down the layers of abstraction in an endless quest for understanding.
Somewhere between these two extremes there is an appropriate balance, and I hereby confess that I don’t always recognise it.
Just the other day I was chatting to a friend about the awesome specs of my new Zenbook, in particular marvelling at the solid-state drive. While reading specs for the SSD we noticed it has an unusually high operating shock tolerance of 1500g. I’m a little embarrassed to recount that I spent far too long trying to work out what this might feel like relative to, say, a punch in the face.
(The answer was an SSD falling from desk-height would be nothing compared to a face-punch from an elite boxer.)
So how deep should a programmer go? I think the answer lies in the old joke about Pete and Jim, the two friends who disturb a tiger; Pete reaches into his pack and pulls out a pair of running shoes. Jim looks at him. ”Do you really think those shoes are going to make you run faster than that tiger?”
“I don’t have to run faster than the tiger. I just have to run faster than you.”
Pete is motivated by self-preservation, but a similar approach can work for programmers motivated presumably by self-improvement. The programmer needs to outrun his peers, or in other words
The expert programmer understands at least one level deeper.
This is not particularly profound advice, and the same is found in other specialisms. When Chess grandmaster Samuel Reshevsky was asked how many moves ahead he sees, he replied “always one more than my opponent!”
Don’t misunderstand – I’m not advocating one-upmanship. In an ideal world the programmer will understand all levels of abstraction, but in the real world almost no one has time for that. Striving to understand one level deeper than your peers will set you apart as the go-to programmer.