Fundamentally, there are only two ways of improving in life: avoiding the bad and aspiring to the good. As children, we learn about how to function in precisely this sequence. First, we make mistakes and suffer the penalties, then we learn to build goals toward which we strive. It is expected that as that striving becomes a driving focus, the errors will fall away by themselves and we won't have to repeatedly make silly or costly errors. Ultimately, both aspects determine greatness. Whether it be in music, sports, or major life decisions, the quality of the result is determined by making wise decisions and limiting errors most especially, preventable errors.
In my previous editorial ("What Makes Great Programmers Different?"), I drew a profile of great programmers and discussed the path to that destination. In the name of proper disclosure, I am not a great programmer in the sense that I presented it. But due to my work as editor, I have met many great programmers and spoken with them at length about the nature of excellence in programming.
In this editorial, I examine the traits of programmers who occupy the lowest tiers of the profession. I've met them mostly in my developer work and we've rarely spoken about excellence in programming. They make good negative examples; that is, they serve as powerful reminders of what to not do. And in a secondary way, they are a costly way to reaffirm the need for good habits.
The bad programmer in action is best described by Daniel K. Lyons, who put forth the following list of traits as a comment on my previous editorial. The traits are:
- Their code is large, messy, and bug laden.
- They have very superficial knowledge of their problem domain and their tools.
- Their code has a lot of copy/paste and they have very little interest in techniques that reduce it.
- The fail to account for edge cases, while inefficiently dealing with the general case.
- They never have time to comment their code or break it into smaller pieces.
- Empirical evidence plays no role in their decisions.
I believe that most bad programmers participate to varying degrees in all these activities. They rarely fail to specialize in just one, alas.
Of Lyons' points, however, the one that consigns bad programmers to their fate forever is the last item. In my experience, at the core of bad programming is invariably a lack of curiosity. Bad programmers are often comfortable within the constraints of their narrow skill set; and they view the quest for alternative ways of doing things as the kind of folderol that is more of a personal programming indulgence than a productive activity. Their happiness within their lack of ambition is well encapsulated by the vaudeville gag line, "Three years ago, I started in show business at the bottom and I like it here!"
What they don't appreciate, though, is just how much work and effort they shift to the rest of the team. And if this information is communicated to them, they're initially surprised, then incredulous, but ultimately unfazed.
The larger issue, though, is that this information is rarely communicated to them. So, they manage to glide along with a false sense of dependable mediocrity. If their numbers are sufficient, they drive away truly talented programmers and punish the good ones who remain. Personally, I believe the only way to sufficiently communicate their shortcomings to them and make their cost clear to management is through diligent use of code reviews. I'll take up that subject in a future editorial.