You’re listing out a series of statements in stream of consciousness style without actually building an argument. You’ve got to start with some premises that people can get behind. Some of your statements seem reasonable, some seem flat out wrong, but in any case they’re not cohesive.

Take this paragraph:

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

This is a strange statement. Are you trying to show that programmers think in black & white? Of course the question “does it work or not?” is (usually) a binary proposition, but you say it as if this question is somehow indicative of a more general mental process of programmers.

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

This is nonsense. There are many empirical qualities of software such as development time, maintenance time, number of bugs, nature of bugs, features present, real-world problems solved, etc. The problem is that scientific comparison is impossible since software projects are very rarely replicated. Don’t let the small subjective issues over style or incomplete information cloud your judgement. Programming is an extraordinarily creative activity where different approaches can have vastly different tradeoffs, and sometimes certain solutions are just plain bad.

“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 is a red herring. A huge part of design is understanding your audience. No interface can be all things to all people. If you are designing an interface for professionals and drag and drop is the most efficient way of accomplishing something then it can be widely accepted as a good interface. You can’t dumb it down to the lowest common denominator and frustrate everyone else. On the other hand, if the majority of your audience has some sort of cognitive (or physical) problem with drag and drop then you would be a bad designer not to accommodate them. It doesn’t matter what one person thinks of your skills as a UI designer. What matters is how efficient your users are with what you’ve designed compared to other potential solutions.

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

Just because someone thinks they could have written something better doesn’t mean they actually could have. Maybe they are missing crucial information, maybe they aren’t as good as they reckon, maybe their beef is more style than substance. For any of those reasons, it may be an unfair judgement against the code. But again, just because a lot of judgements are unfair doesn’t mean they all are.

Also, just because the terminology is black and white doesn’t mean the thinking is. I don’t put code into two boxes like that, and I suspect very few others do.

“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?”

Code doesn’t start out bad and then get better by people putting more time into. Sure we cut corners all the time, but that doesn’t mean we have to settle for bad code. The smart thing to do is cut features and keep development under control. If you resign yourself to bad code in order to get something done, you may find yourself spending more time debugging than it would have to do things properly in the beginning. Even worse, the project may fail altogether.

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

It seems like you really have a chip on your shoulder about the fairness issue. But look, just because people make unfair judgements doesn’t mean that everything is magically equal. Certainly good programmers can produce bad code because of practical concerns. Good code can become bad over time because there are no resources to refactor. Both good and bad programmers can misjudge code based on poor understanding, pet peeves, or superficial considerations. None of that changes the fact that there are huge qualitative differences in code. These are the differences that make or break projects and companies every day. We can’t gloss over it to prevent people from making unfair judgements or to protect our feelings. We are human, we are fallible, let’s not stick our head in the sand.

Even if you’re working on the 1% of projects that is written with the intention that it will never be maintained, it probably will. This is an _implicit_ requirement of every project. So “it works” is nothing without considering how well it can be maintained. Then if you actually _are_ expecting to add features…

In short: code is for human beings to read, not computers. If you don’t realize that, you _are_ a Bad Programmer. Hopefully next time York Co will hire the better programmer charges $600, but they probably don’t know the difference. If you do, then maybe you should inform them.

This is the end result of “does it work?”

Thanks again for visiting my little site here :-)

Yes, I see what you’re saying. But … isn’t the ability to design and finish programs the definition of a programmer? Are those other people really programmers? I don’t think so, but that’s become a linguistics issue.

I see your point in that situation. On the other hand you have to admit there is a full range of programmers out there. You cannot say every programmer in the world is as good as Linus Torvalds :) just because their code kind of works. Some programmer can start and end a given task alone, others can only start. In big enterprise projects the good programmers most of the time compensate for the the lack of skill of less good programmers. This is done by mentoring and by allocating to them really well defined tasks already designed.

@leed25d:
I do not think I actually ignored that point all together. In my defense, I did state that not matter what someone does, there’s always going to be someone complaining. That does not mean that the code or the coder is bad. It just means that it either bothers a small minority or it needs to be changed to accommodate the greater good. As far as that goes, there is a consistent answer: Does it work? That question is answered by the requirements of the project.

@Daniel:
Like I stated above, these questions you ask have answers… the question is whether those answers are important. I say they only are if that is what the project requires. For instance, “is it easy to extend?” As far as I’m concerned, that question is ridiculously laden with qualitative assumptions which can never be measured. Then you have the satisfaction problem which I addressed above with leed25d.

However, this does raise a good point… what does it mean to “work”? Well as far as I’m concerned, if it comes down to time and money, it means it meets exactly what the specifications say it does, and not a letter more. This burden of second guessing specifications often leads programmers to causing more problems for themselves.

Here’s a real world example: York Co., Va requested a simple search engine be built for their services which would poll someone of what their situation is and give a weighted list of solutions to departments which solve that situation. They paid a developer $500 to build this simple application. What they did not tell him is there A) needs to be a particular weight order and that has to be able to change as departments shift responsibility and B) they need to add departments at will. Now when I first found this out, I cursed his name and called him a terrible programmer for not offering those services… then I started to realize… he’s being paid $500. Would I go the extra mile for a small client like that? Hell no! Does this make him a bad programmer? I don’t think so. His code wasn’t extensible because it wasn’t meant to be. Does he do that consistently… for a $500 client… yes. I know I would for small jobs. Is that ethical? Who knows, I don’t believe ethics is really relevant to the conversation anyway.

The point is, those questions can be answered if you addend the phrase “Does it work” with “Does it work to specification.” That, I thought, was implied, but I guess not.