This thing of Humble Programmer really got me. I think that, in the unlikely case that someday a wannabe programmer would come to me asking for advices on how to learn programming and how to become really good at it, I would suggest that he needs just two things – humility and will to understand. I have to be honest, I didn’t read the original paper by Dijkstra. I tried, but it is very long and the introduction is nearly as long, and … ok I know, I should have. Nonetheless I read books and magazines and grasped the idea of “humble programmer” elsewhere.
So, what so powerful in being “humble” at programming?
Well there is so much to learn, because you question your approach and your solution rather than the world. How many times, when the code is malfunctioning, do you blame Microsoft, the libraries, the kernel, the compiler?
It is easy to take for grant that the problem is someone else fault without really investigate the matter seeking for objective proofs. If humility is not for you, then you can consider it as a sort of attempt of substantiated arrogance. From my experience during investigations I realize that a) it was my fault (more or less subtle anyway) and b) now I better understand the system and c) not only I’ll avoid this problem in future, but also I’ll avoid an entire family of related problems.
It is a long time I don’t stumble in a compiler bug. Really. I was used to finding some back at Amiga days (Lattice C), and still some at the beginning of (my) PC era (Watcom C/C++), but that means 10 years ago. And that makes sense. Both Gcc and Microsoft Visual C are very mature products (ok, let’s forget for a while the problems with managed C++ and the like, these are young, recently introduced technologies). The chance of hitting a bug writing even non-trivial code are so far fetched that maybe it’s more likely being hit by an asteroid while walking in the street.
Anytime someone calls me invoking a compiler bug as the cause for a problem, my eyebrow automatically raises in a Spock-like manner.
The will to understand is the complementary force guiding to great programming. Every time you are in a hurry, twiddling the code to make it work, without really understanding what’s going on, you are in double trouble. First if you don’t understand what you are doing (that’s research? ;-)) you are likely to fill the matter with subtle problems ready to strike on your back as soon as you get distracted. Then you are wasting the chance to increase your comprehension of the system, the chance to better handle it in the future, you are intentionally keeping your tool chest from growing with new powerful tools.
Ok, humble, but boring, I’m quitting here 🙂