On worse code and apathy

François Fortin's blog post rang true, so here's a few more cents...

Bad programmers aren't the root of all evil. Apathetic programmers are.

A bad programmer may not know better, but an apathetic programmer simply doesn't care. A bad programmer can be taught to be better, but there's not much that can be done for a programmer that simply has no interest in doing a good job.

Apathy can occur from a multitude of reasons: the work may be dull and unchallenging, the position may be obviously underpaid, the environment hostile and deadlines unrealistic, or it may simply be a way of life. Whatever the cause, apathy should be viewed as a contagious cancer. When it sets in, the future of the project starts going downhill at an exponential rate, and more likely than not, no one but the developer knows it. To make matters worse, consistently poor code will result in frustration from other team members, and if things do not change, sooner or later that frustration will result in their own loss of interest in the project.

Every day shortcuts are taken, code isn't refactored, isn't tested, and the absolute bare minimum is produced. Such unmaintainable code ensures that the project either has a very expensive future, or none at all. TODO's (with, let's face it, no hope of ever being done) litter the code, standards go out the window, and the avalanche just keeps growing larger and larger until the project completely collapses under its own weight.

When you write a line of code, do so under the assumption that you'll be the one maintaining it for the next five years. Do you want your next month's job to be clean and pleasant, or a frustrating struggle? Taking a shortcut today will ensure the latter.

And whatever you do, be consistent with it.