I realized that, paradoxically enough, good programmers need to be both lazy and dumb.

 

Lazy, because only lazy programmers will want to write the kind of tools that might replace them in the end. Lazy, because only a lazy programmer will avoid writing monotonous, repetitive code – thus avoiding redundancy, the enemy of software maintenance and flexible refactoring. Mostly, the tools and processes that come out of this endeavor fired by laziness will speed up the production.

This makes a lazy programmer a good programmer. Of course, this is only half the truth; for a lazy programmer to be a good programmer, he (or she) also must be incredibly unlazy when it comes to learning how to stay lazy – that is, which software tools make his work easier, which approaches avoid redundancy, and how he can make his work be maintained and refactored easily. (By the way, the word “unlazy” has 14,400 hits in Google; I’m sure this makes it legal.)

Second (and I will elaborate a bit more on this because I find the concept to be less known than the first) a good programmer must be dumb. Why? Because if he’s smart, and he knows he is smart, he will:

a) stop learning
b) stop being critical towards his own work

Point a) will make it hard for him to try to find new techniques to allow him to work faster. Point b) will give him a hard time debugging his own work, and refactoring it. In the endless battle between a programmer and the compiler, it’s best for the programmer to give up early and admit that it’s always him and never the compiler who’s at fault (unless it’s about character encoding issues, which is the part even the compiler gets wrong).

But there’s a more crucial point why a good programmer must be dumb. That’s because for him to find the best solutions to problems, he must keep a fresh mindset and manage to think out of the box (or rather, know its actual shape). In a way, this leads to the mindset of a child; incredibly creative because he never heard “no" for an answer.
The direct opposite approach would not be very constructive; to be knowledgeable about the parameters at hand, and accept them. Because who knows how many limits you think are there are for real? The less you know, the more radical will your approaches be; the better the tools you develop, and the better the product you develop with them.

I know from my work that a good programmer, when confronted with a problem from management, will adopt this mindset of being dumb; he will start asking the most simple, child-like questions. Because he doesn’t accept the parameters suggested to him that someone thinks make up the problem. Here’s a typical conversation from the lost land of web development:

“Since yesterday, our client can’t see the logo on the web site.”
“Did he restart his browser?”
“Yes.”
“Did he restart his computer?”
“Yes.”
“Did he empty his cache?”
“Yes.”
“Does he run Internet Explorer 6?”
“Yes.”
“Is he sure he can’t see it?”
“Yes.”
“Did he look at the web site on the screen?”
“What?”
“Well, he might have printed it out.”
“No, he was looking on it on the screen.”
“Did he also not see other images besides the logo?”
“What? Well, I will ask him.”

For the sake of argument (and this was entirely hypothetical) let’s say the client indeed turned off images in his browser. Or his son did. Whatever the case, this answer could not have been found if you would work in “smart” mode*. None of the questions asked by the programmer required any programming skills. No; simply because the problem is so stupid, only stupidity can tackle it.

*Some years ago, I had a long telephone discussion about the whole web site being messed up since my last update... it turned out the guy disabled stylesheets in his browser. Back then, I would have suspected everything but such a simple solution and was listening to half an hour of complaints about quality standards etc. In the end, the assumption that my update was at fault was just that... an assumption. You better listen to facts only if you start debugging, and never to what people think might be the reason.

In similar fashion, when one of my co-programmers asks me: “Why isn’t this working?” most of the time it’s because they’re working on the wrong file (e.g., they linked to library 1 but they’ve altered library 2, and their revision isn’t showing, or they simply didn’t link the library at all). When you ask a colleague for help, particularly in programming, you want him to know less about your project... so he will ask the stupid questions you sub-consciously avoided asking yourself because you thought you knew the answer, when in fact you didn’t.

There’s another side to it. The too-stupid person will just run off and, without a second thought, do something wrong. The too-smart person will sit down and plan something right, without taking any action. A pragmatic programmer is sort of in-between; he knows making the wrong decision 1 out of 10 times doesn’t hurt the goal as bad as making only right decisions 5 out of 10 times, and making no decision at all the other 5 times.

It’s like the story of the centipede. The centipede was very good at walking with its hundred legs. It never spent a thought on just how it could walk. Until one day, when a big black bug asked the centipede “How can you manage to walk with all those feet? Don’t you find it hard to coordinate their rhythm?” The black bug already left, when the centipede was still sitting down, pondering how it could walk, wondering, and (for the first time in his life) even worrying a little bit. From that day on, the centipede couldn’t walk anymore.
So you better not think too much if you want to achieve something. And of course this is only half the truth, too...