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
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.



A bad programmer is also one that feels the way code is written is more important than meeting a deadline. Too often developers will “refactor” code that works just because of some coding rule they feel is not being followed. Reading the comments many are pointing out extreme cases of bad programming. I have sat through countless code reviews and the changes suggested are usually just a matter of personal preference.


A good programmer would deliver a level of elegance matching the situation. If management demands excessive shoddiness, then, ideally, profession ethics would suggest resigning.


From the cited link:

It would be hard to self-test, but some clues would be: do you think you're the best programmer in the world? Do you find code with a lot of functions messier and harder to understand than code with only a few large functions? Do you routinely copy code from one place to another and make a few small changes to it? Do your programs tend to be a few huge files or lots of small files? When you're asked to make a change, do you usually have to touch most of the code or just a small chunk of it? If you say 'yes' to most of these, you're probably bad. If not, you're probably alright. :)

I would say that non-OO languages tend to force programmers to use large functions. Some languages don't support partial classes, so you end up with huge files.

If you want to limit the scope of required changes, encapsulation is your friend. You can't program in R as if it were C#. But this doesn't make one a bad programmer, if one cannot use what isn't available.

Regarding copy-paste of the code, I have a question for you: how do you deal with two cases? If you have to deal with two cases, is it easier to write an "if" or a loop?


What about the programmer team so concerned with elegance, they consumed their time budget building infrastructure, and failed to deliver a solution? Are they good or bad programmers? The judgement is in the eye of the beholder. Failure to deliver might be damning for management, and forgiven by fellow programmers.


I would have preferred to have the good programmers earn a lot more money than the bad ones, rather than seeing the job market get so bad that none but the best can get preserve their mediocre income.

But yeah, public code reviews are the answer. That, and having first-level managers responsible for reading and understanding what their employees write. You wouldn't have a junior engineer's designs sent over the wall to production without a senior engineer first reviewing every detail; but that's what we do with code.


It seems like all the bad programmers I knew were laid off years ago, and were unemployed for so long that they finally moved into employment that was a more realistic fit.


I work in an software services role that interacts directly with the customers, gathers requirements, and develops solutions. We either use our own proprietary toolkit (4G language) or API to design solutions. I am also responsible for using various languages and tools (ie. C++, ODBC, XML) to add product enhancements. I also write documentation, and provide level 1 technical support for those products. In my occupation there is no "programmer" role (although I carry the title Senior Software Developer). I have yet to meet anyone aside from an entrepreneur that has the same job responsibilities as mine. Programming software is only about 40% of my job duties. Very few "good" software developers have the personality or patience to do the sort of work required nowadays. Heads-down programmers sequestered from the rest of the process are a dying breed. Being able to manage and operate within the different areas of the SDLC is more important than fulfilling a single job responsibility. Sure, I'm not the best programmer I've ever met, but I also get to see the big picture that most 'good' programmers don't get to see. Believe it or not, the industry runs on 'good enough'.


I actually remember one programmer who "fixed" a problem in the code which was generating an error message by commenting out the print statement for the error message... He was always proud of how many pages he could check off in the "bug book".

Even the best programmers slip into one or the other of these bogs now and then. The difference is that they SEE the negative consequences of their actions, and then modify them. For example, you're in too much of a hurry to write proper (accurate) comments in your code, and then when you go back to change something a month later, you suddenly realize, "What the H--- was I thinking when I wrote this???"


You have, of course received manna from heaven haven't you? Doesn't everyone?


Dear Andrew,
Everyone starts as a bad programmer, much like the concept of original sin. The bad programmers surely are evil, mucking about in the CS equivalent of the 7 deadlies. Probably they didn't read the copious, elegant documentation that issues forth from the good programmers like manna from heaven.

Yes, code reviews, please.
Just a few questions...

Was it a good programmer or a bad programmer that...

1) had such impoverished abstractions of memory hierarchies they "Need to Rewrite Established Algorithms"
2) kept installers in the "Dark Ages"
3) release software that's "Not Ready For Prime Time"

4) remarked "object-oriented design is the roman numerals of computing”

Are you resetting or setting the Bozo Bit?



Wow -- reminds me of a contract where I reviewed the code of other developers. This one developer had 10 excuses as to why the code was so bad. (none of them were her fault) All while showing no interest in changing her approach even after I pointed out how she could address the issues she used as excuses.


On my field at least the half of the team in every project would meet your criteria for bad programmers.

Unfortunately, management likes to think they are cheap to keep around with low salaries, and low salaries are more important than quality in our projects from their point of view.


Mediocre developers with 20 years in the field have one year of experience 20 times.


Programming is like singing - everyone thinks they can