Programmers at work: What kind of lazy are you?

Good programmers always aim to reduce their workload. But it’s got nothing to do with laziness.

Larry Wall once said that there are three virtues of a great programmer: laziness, impatience and hubris. What does it mean to be a lazy programmer?

A respected colleague of mine once declared: “I’ll spend hours and an enormous amount of effort to avoid having to do something ever again”. I am firmly of the opinion, however, that great programmers aren’t lazy. They’re just great at automating things, because that’s their job.

Lazy programmers – the good kind

As the story goes, lazy programmers avoid having to do work in the future in a number of ways:

1. First they identify which problems really need to be solved, and the ones which are not worth wasting time on.
2. They get to the crux of the problem that really need to be solved instead of wasting time solving the wrong problem.
3. If this problem has already been solved by someone else before, they reuse the solution (if it will work).
4. If it hasn’t been solved before, they find the most efficient way to solve the problem.
5. Finally, they automate the solution to the problem so they don’t have to solve the same problem again in the future.

At each stage they are actively trying to cut down on an unnecessary workload. But what is the avoidance of work if not laziness? It could be a lot of things actually. Calling this kind of “laziness” a virtue is a tongue-in-cheek in-joke among programmers, but there are actually a lot of ways in which programmers can be lazy.

Lazy programmers – the bad kind

Here’s what I would expect an actual lazy programmer to look like:

1. They avoid solving problems in the first place, because solving problems is hard work.
2. If they have to deal with problems, they’ll focus on doing the minimum amount of work possible to make the symptoms disappear instead of looking for the real problem.
3. If possible, they’ll jump at the opportunity to push responsibility off to someone else.
4. If they can’t avoid the problem, they’ll take as long to solve it as they can afford.
5. Solving a problem in the general case is almost always more work than solving it for a specific case, so the lazy programmer simply wouldn’t.

So, in essence, there’s a bad kind of lazy and a good kind of lazy. The latter might simply be called “efficiency” by those not in on the joke. That seems obvious, but I’m afraid that there are certain kinds of laziness which pervade our craft which are not so clear cut.

When I was starting my journey down the path of software craftsmanship I didn’t know (or care) much about designing maintainable code. I was far more concerned with finding a solution to a problem, just not the optimal solution to a problem. In the natural course of learning to code I was introduced to the idea that small, otherwise insignificant changes in the way code is written – such as using proper indentation and meaningful variables names – can have an impact on the maintainability of my code. “Goto considered harmful?” Got it, no more goto for me. Global variables? Gone. No duplicated code? That one’s a bit trickier, but into functions it all goes. I wanted my code to be perfect, down to the character.

Don’t just follow rules, understand them

At the time I was introduced to these rules, I didn’t really question where they came from. I didn’t really know why the goto statement was so bad, but the hand wavy reasons they gave me were good enough for me at the time. It wasn’t until I drank the OOP cool-aid and found myself drowning in complex inheritance hierarchies that I started to look critically at the software craftsmanship dogma to see where it all went wrong.

The point I would like to make here, however, is that novice programmers often don’t understand why some coding practices are considered good practice while others are condemned as anti-patterns.

Let’s look at a concrete example: Is saving keystrokes a good kind of lazy or a bad kind of lazy? A wise programmer will make use of their text editor’s features to get a lot of work done with very few buttons, allowing them to stay focused and translate their thoughts into code quickly. A novice programmer might save keystrokes by making their variable and function names shorter (often too short to communicate their purpose).

Novice programmers also tend to avoid commenting their code (because “self-documenting” code is “best practice”) and avoid writing documentation (because they prefer “working software over comprehensive documentation”). For the expert, saving keystrokes was never about laziness, though we might jokingly say that it was. For the novice, saving keystrokes has everything to do with laziness, and it has a negative effect on the quality of their work and the lives of everyone who has to maintain it after them.