The Good Programmer Paradox

If we lived in a perfect world…

  • Good programmers would be recognized and rewarded with interesting projects/better pay/etc.
  • Bad programmers would not get those benefits.

Good and Bad

Perhaps I should better define what I mean by ‘good’ and ‘bad’.  By good, I mean developers that follow good programming practices.

  • Use unit tests
  • Perform code reviews
  • As a result, develop code that has fewer defects

By bad, I mean those who do not follow good programming practices, and as a result, generate more defects.

While there are certainly more aspects of good vs. bad programmers (such as motivation, willingness to learn new things, etc.), I am going to focus on qualities that reduce defects for the purposes of this discussion.

Just a side-note: I consider myself a good programmer not because I’m smart (although I do consider myself to be smart), but because I follow good practices.  The biggest difference in my programming ability came when I followed good programming practices… not when I learned a new coding language or something similar.  So if you have impostor syndrome, just realize the biggest thing you can do for yourself is learn the common practices good developers use.

Suppose you deliver a new feature to a customer.  It’s part of a big release that’s been coming for a while.  Everybody is glad the code is finally out the door.  Whew!  That took a lot of work, and it is finally done!

Until a few weeks later, something terrible happens.  Perhaps a feature doesn’t work as intended.  Perhaps your system reboots every time after being on for 3 days.  It doesn’t matter – something happens and the customer is dissatisfied.

Angry Cat

Something similar to the following probably happens:

  • Customer calls support for your company
  • Support files a defect in a certain code release
  • It’s a super hot issue.  Must be fixed now!  So lots of higher-level managers get involved to determine who should fix the issue.
  • Eventually it filters down to a specific developer.

Now the developer that originally inserted the defect works on this super-hot issue.  He or she fixes it, and hopefully it gets tested well to verify it actually does fix the issue.

A patch release is applied and delivered to the customer.  The customer confirms the issue is fixed and is happy.  Well… maybe not happy, but happier than before.

What happens next is interesting…

The developer is praised for working overtime to get important bug X fixed.  Everybody should be like this developer who works so hard to accomplish the company objectives!  What a great developer!  I’ve literally heard management say the following before:

We really appreciate all the extra hours team ‘blah’ put in.  You did a great job helping us get feature X out the door.

Great Job

Now don’t get me wrong: every once in a while, working a little extra to get a feature shipped is OK.  The problem comes when this is a common occurrence, and that is the case I’m talking about now.  The problem with this is it doesn’t address the real issue, the underlying process problem: the defect should have been prevented from shipping in the first place.  If there were no defects (or at least less of them), you would have happier customers and no need to work as much overtime.

So those that generate bugs get attention… and generally positive attention once the fix is in.  Those that don’t generate bugs (or at least much less visible bugs) do not get that positive attention.

Doesn’t this seem backwards?  It certainly is in my opinion, and I’ve seen it happen in multiple environments.  Unfortunately, this presents itself in multiple ways:

  • Those that develop good code don’t have as many bugs in their code.  So rather than work in their nice codebase, they work on problem areas – code they likely didn’t develop and is much nastier – in order to meet business objectives.  In short, they are ‘punished’ (they work in bad code) since their code works properly (so it doesn’t need more work).
  • They don’t get as much recognition since their code never comes into the spotlight (which may lead to smaller raises, less opportunities, among other things).

So what can we do to fix this?

  • If you manage software developers, make sure you notice this.  Don’t judge developers on their fixing of bugs, but rather on quality metrics and good programming practices that are being followed.
  • If you work in this type of environment, try to educate those above you in pushing the right behavior.  Also attempt to push the right behavior in your group.
  • Take extra steps to get your name out there.  If you aren’t getting as much recognition because of this, point out when your features work in a release.  Do it gracefully… more as a celebration that things worked well the first time… rather than shoving it in everyone’s face.

This type of change lends itself more to changing a culture.  It can be a very long, drawn-out process.  In the end, it is well worth it, but it can be very slow-going at times.  Just realize if you are one of those ‘quality code’ champions, your efforts will eventually pay off.  Keep carrying that torch!


  1. I’ve heard this called “heroic programming”. Amongst other things. I also think it’s similar to the character “Brent” from the Pheonix project:

    I’ve seen this in some companies, too. However, I’ve done my best to get out of them as fast as possible. I think the only way to combat it is through building trust. Trust from those around you that you’re doing the right thing, which is also (hopefully) the right long-term thing, too. I find the only real way to build this is through relationship building, authenticity and openness. But this takes time.

    As a manager, it must be hard. You’re trying to deliver on short-term value but not degrading capacity to deliver in the long term. All whilst having nothing else to go by except the words of the developers who are feeding you information …

    1. The Brent character seems exactly along the lines of what I’m describing here.

      I agree that trust is needed to help combat this. It also helps if the manager knows enough to be able to accurately gauge if what the developer is saying. That way he or she can make informed decisions on what makes sense short-term and long-term.

Leave a Reply

Your email address will not be published. Required fields are marked *