Why Good Programmers Are Lazy and Dumb
I've noticed a highly counterintuitive phenomenon: good programmers are both lazy and dumb.
Because they're lazy, they write all sorts of tools to do their work for them. Because they're lazy, they figure out ways to avoid writing boring, repetitive code — thus reducing redundancy, cutting down on maintenance costs, and making refactoring easier. Ultimately, the tools and best programming practices that arise from this laziness-driven motivation improve product quality.
Lazy programmers thereby become good programmers. Of course, this is only part of the story; in learning how to remain perpetually lazy, a programmer (whether male or female) shows astonishing diligence — figuring out what software tools will make their jobs easier, what methods can avoid redundancy, and how to make their work more maintainable and refactorable.
Secondly (I'll spend more time on this point because I find it harder for people to accept), good programmers are dumb. Why? Because if they were smart, or if they knew they were smart, they would:
a) Stop learning b) Lower their standards for their own work
The first point would lead them to stop striving to discover new techniques to make their work faster. The second point would result in code that's harder to debug and harder to refactor. In the endless war between programmers and compilers, the programmer does best by surrendering immediately and admitting it’s their fault rather than the compiler's (unless it's about character encoding issues, where some compilers indeed have problems).
But there's an even more important reason why good programmers must be dumb. To find better solutions to problems, they must maintain a humble mindset and think outside the box. In a way, this brings them back to a childlike state of mind; one that remains highly creative due to never having experienced the "no" that stifles creativity.
In contrast, the opposite mindset isn't as innovative; it assumes full understanding of the current situation and accepts it as it is. But who knows how many of the things you think are impossible are truly impossible? The less you know, the more radical you might be. The better tools you develop, the higher the quality of your products will be thanks to them.
I've learned from experience that a good programmer, when confirming a requirement with a manager, needs to adopt a "dumb" mindset; they start asking the simplest, most childlike questions. They don't take the information provided at face value. A typical conversation in web development might go like this:
"Yesterday, a customer said the logo image on our website wasn't showing up."
"Did he restart his browser?"
"Yes."
"Did he restart his computer?"
"Yes."
"Did he clear his cache?"
"Yes."
"Is he using IE6?"
"Yes."
"Is he sure he didn't see it?"
"Yes."
"Is he looking at our site on a computer screen?"
"What?"
"Well, maybe he printed it out."
"No, he was looking at the screen."
"Can he see other images on the site besides the logo?"
"What? Oh, let me check."
To illustrate our point (this story is entirely fictional), we assume the customer had actually disabled image display in their browser. Perhaps his son did it. Anyway, if you think in "smart" mode, it's hard to come up with such an answer. So the questions the programmer asks require no programming knowledge. Because it's such a dumb question, only a dumb approach could solve it.
A few years ago, I had a long phone discussion about a site-wide failure caused by one of my updates... It turned out the guy had disabled CSS in his browser. Since then, I started doubting everything instead of listening to an hour and a half of complaints about code quality over something so simple. Ultimately, it was guessed that my update was the problem... just a guess. If you want to solve a problem, the best method is to listen only to the facts, not their perceived possible causes.
Similarly, when colleagues ask me, "Why isn't this working?" it's often because they're modifying the wrong thing (for example, they want to link lib1 but are linking lib2, or they aren't linking any libraries at all). When you seek help from a colleague, especially for programming issues, you generally don't tell them much about the project. When they ask seemingly dumb questions, you subconsciously resist answering because you think you know clearly, but in fact, you don't.
Of course, there's another side to this. Being too dumb leads to coming up with no solutions, making mistakes, and solving nothing. Being too smart makes people sit around planning problems without taking much action. The pragmatic programmer takes the middle ground. He knows that being wrong once in ten decisions is better than making five correct decisions and doing nothing for the other five.
This is somewhat like the story of the centipede. The centipede was very skilled at walking with its 100 legs simultaneously. It never thought about how it managed to do so. Until one day, a bug asked him, "How do you control so many legs? Isn't it difficult to coordinate them rhythmically?" After the bug left, the centipede remained sitting there thinking, pondering how to walk, confused, and even (for the first time in its life) somewhat worried. From that day on, the centipede could never take another step.
So, if you want to achieve something, don't think too much. Of course, this is only half the story…