Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


What Makes Bad Programmers Different?

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.

— Andrew Binstock
Editor in Chief
[email protected]
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.