I just finished reading J.Timothy King’s provocative essay, “Does Bad Writing Reflect Poor Programming Skills?”. King’s answer is an unqualified “yes”, and I have to mostly agree with him.
The difference, of course, between communicating with human beings and communicating with a computer is that computers have infinite patience. You can probably be a boring, unimaginitive writer and still have good programming skills (although arguably, if you lack imagination you may fail to think outside the box enough to come up with the best solutions consistently). What you definitely cannot be, though, is an unclear writer.
King’s point is well-taken, too, that a program must be comprehensible to other developers and maintainers, and to your future self months or years from now — not just to the computer.
The scary thing is that an astounding number of programmers (I won’t dignify them with the term “developer”) not only can’t write, they can’t even read effectively.
In my experience if you assign a task to a good developer, they will annoy you with pertinent questions until they understand every detail of what you’re asking them to do. If you assign a task to a lousy developer they will read the first two sentences and might manage to misinterpret even that much.
For example, I recently gave instructions to a programmer working on a web form that included home and work phone number fields. I stated, “In both the home and work phone numbers, the last seven digits may not be the same.” In other words, 480-111-1111 is not a valid phone number, nor is 480-777-7777.
Instead of what I asked for, the code the programmer wrote checked that the last seven digits of the home and work phone numbers were different from each other. So 480-111-1111 would be okay for a home phone so long as a different number was used for the work phone. Not even close to what I was looking for.
Predictably, other aspects of the code were “off”. One of the objectives of the code rewrite was to establish redundant validation on both client and server so that people with JavaScript disabled — and spam-bots — could not enter invalid data. The classic ASP code being worked on submitted the form to a separate ASP page for processing. Rather than combine the two or make sure the server-side validation was on the processing page, the programmer did the server-side validation on the form ASP and then submitted the validated data to the processing page via an in-the-open querystring, so that things were still readily hackable by simply submitting a bogus form directly to the processing page.
Coincidence? I think not. And no, I didn’t hire this guy. Thankfully he took 30 hours to do 8 hours worth of work, which got the attention of the non-technical hiring manager, and this particular programmer was un-hired in short order — proving once again that money talks. It saved me a half hour of patient explanation of exactly how this fellow was dropping the ball.
If you’re not comfortable quickly and accurately reading and clearly writing in plain old English, tackle English as your next “programming language”. The job you save may be your own.
{ 1 trackback }
{ 0 comments… add one now }