The intense inwardness of programming makes personal character especially important. You know how difficult it is to put in eight concentrated hours in one day. You’ve probably had the experience of being burned out one day from concentrating the day before or burned out one month from concentrating too hard the month before. You’ve probably had days on which you’ve worked well from 8:00 am to 2:00 pm and then felt like quitting. You didn’t quit, though; you pushed on from 2:00 pm to 5:00 pm and then spent the rest of the week fixing what you wrote from 2:00 to 5:00.
Programming work is essentially unsupervisable because no one ever really knows what you’re working on. We’ve all had projects in which we spent 80 percent of the time working on a small piece we found interesting and 20 percent of the time building the other 80 percent of the program.
Your employer can’t force you to be a good programmer; a lot of times your employer isn’t even in a position to judge whether you’re good. If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.
At the top of the list of desirable personal character traits is humility:
Nobody is really smart enough to program computers. Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time. The way you focus your intelligence is more important than how much intelligence you have
At the 1972 Turing Award lecture, Edsger Dijkstra delivered a paper titled “The Humble Programmer.” He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.
The purpose of many good programming practices is to reduce the load on your gray cells. You might think that the high road would be to develop better mental abilities so you wouldn’t need these programming crutches. You might think that a programmer who uses mental crutches is taking the low road. Empirically, however, it’s been shown that humble programmers who compensate for their fallibilities write code that’s easier for themselves and others to understand and that has fewer errors. The real low road is the road of errors and delayed schedules.
When interviewing candidates for programming positions, I always look for someone who is brave enough to say “I don’t know” when they need to. Candidates who can’t or won’t do this get red flagged; those types of programmers are dangerous. “Can-do” attitiudes have a superficial allure, but they’re actually poison in our field.
Isn’t the world of development blogs, an amazing fountain of seemingly endless knowledge— also incredibly humbling? There are so many people, many of them giants in the field, who are far smarter and just plain better than I will ever be.
But it’s not our job to be better than anyone else; we just need to be better than we were a year ago.
