The Reality of Bad Programmers

I’ve been reading a lot of articles lately outlining what defines a bad programmer. I find this to be a particularly interesting topic myself as often times I am accusing other programmers of being “bad”. Upon reflection, and after reading these articles, I must admit, this is an unfair term. The term “bad” in this context is completely subjective. By calling someone a “bad programmer,” you’re applying standards to them which aren’t universally true. It would be a fair assumption to say that we’ve all wrote “hacks” in our times, and on many occasions, those hacks were out of the necessity of the situation and not what the developer would like to do.

Science does not promise absolute truth, nor does it consider that such a thing necessarily exists. Science does not even promise that everything in the universe is amenable to the scientific process. - Isaac Asimov

What I’m getting at here is that there aren’t bad programmers, there are bad programs… and even those often aren’t “bad” if they are taken into context. So what does all this talk of so-called “bad programmers” actually mean? It means we’re frustrated. It means we, as developers, strongly desire some metrics for determining “goodness” or “badness” of not only the code of others, but even our own.

Why is this still a problem? After over fifty years of code, we still cannot figure out what makes a program good?!? That would seem like a problem… on the surface. It’s not. Here’s why:

The Philosophy of Code

As programmers, we expect our code to do two things: Work or Not Work. And when it doesn’t work, we expect to be able to fix it after testing. Black and white thinking. It either works… or it doesn’t… and if it doesn’t… it should and it will.

The concept of good and bad aren’t just subjective and intangible, they’re completely non-existent in the realm of programming quality. Unless such metrics are created, and they themselves are immutable and empirically verifiable, then the best we can do is judge a program based off whether it actually does the tasks it was intended to do.

For instance, I consider myself fairly good at interface design. However, every single time I choose an interface revision that works to publish, there’s someone, bless their soul, who cannot deal with concepts such as, say, “drag and drop”. These people are a strong minority, but to them, I’m a terrible interface designer because it doesn’t work for them as they cannot understand it. This does not mean the interface is bad, it does not mean I am a bad interface designer, it does not mean I’m a bad programmer. It means that they would have done it differently.

What’s bothering me is that all these articles speaking of “bad programmers” are being extremely unfair and hypocritical. Much of the code they write, I can guarantee there would be someone out there who looks at it and says, “I would have done this better.” And that is exactly the problem; black and white thinking applied to a gray area.

The Metrics Being Applied

Does it work well?

• If no, bad code.
• If yes
  • Can it be better? (subjective)
    • If yes, bad code.
    • If no
      • Why can’t it be better? (subjective)
        • (enter list of excuses here)

The Only Metric That Matters

Does it work?

• If yes, good code.
• If no, fix it or start over.

What This Means

We want programmers to write nice code. We want modularity. We want good organization. We want the code to be decoupled. We want to avoid copy and paste. We want everything. What project has time for that? The only projects I’ve ever seen that are like this and remain like this are open sourced projects run out of love and not for money. They have no deadline. The quality is the goal as it’s the only feature that will keep users using is and, in turn, contributing. This is not a reality in the business world. In the business world, quality comes second to deliverables. Make the milestone, at all costs. And the first cost to go is code. Why? There’s actual profit to be made in doing so!

If coders were left to code. If coders coded for love. If coders didn’t have to worry about their jobs… if they did it out of love… well then of course the code would improve. They’d do everything in their power to improve their code.

All this talk about bad programmers is categorically false. There are uneducated people in programming positions, yes. There are incapable people in programming positions, sure. There are people in programming positions who cannot “hack it”, of course. But this talk of “bad programmers” aren’t defining standards for spotting these people. Those people *AREN’T PROGRAMMERS*, they’re script kiddies or charlatans. What we’re talking about are real programmers: people employed at companies, people gaining contracts, people who contribute to open source projects. That’s might haughty of these authors of these articles to tell such people that they’re bad programmers because they do not know certain things that they probably do not even specialize in or use.

What’s more is, look at what they are asking people to know? 25 years ago, knowledge of OOP would be a minor point. Now it’s a major point. Right now, knowledge of functional programming is a minor point. 20 years from now, who knows. Now, knowing about assembly languages isn’t a big deal. 20 years ago, it was a huge deal. If you can code (and by that I mean, write code that works), you are a good programmer.

In summary: does the code work? If so, it’s good as is whoever wrote it. If you need more requirements later and the program needs to be extended to make it work, consider that a separate program then apply the same metric… does it work? Talk of anything else immaterial as it’s a subjective qualitative assessment.

From http://www.humanerr.com/2008/07/04/the-reality-of-bad-programmers/