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