Lazy FTW!

The results are in: developers are strategically lazy

JAXenter Editorial Team
Falling asleep image via Shutterstock

There is mounting evidence to suggest that developers get lazy… a lot. But is it fair to accuse developers of laziness when they’re only trying to streamline processes?

Apparently laziness is inherent in the programming world. There isn’t a lot of manual labour going on when developers are ‘in the zone’. But it’s worth asking whether the habits of programmers are actually lazy, or in fact an array of efficient and time-saving measures aimed at improving their work and preserving their motivation.

The key here is that the ‘laziness’ can actually be strategic, to save developers from doing things twice in a row, or writing the same kind of code.

Strategic laziness

An older article by Swizec Teller summarises precisely what we mean when we declare programmers to be strategically lazy. The automatic reaction in needing to complete a task repeatedly is to find a way to automate the process.

Whenever they’re writing code doing the same thing, they’re on the hunt for a library. In short, programmers’ lives are devoted to eliminating repetivity.

Don’t repeat yourself

There’s also the DRY (Don’t repeat yourself) principle to consider. In software engineering, this is aimed at reducing the repetition of information by creating an abstraction that can be used another time. However, with the input of several programmers, a project can contain piles and piles of abstractions, resulting in uncertainty about what the code is actually doing. There’s a great piece by Jean-Baptiste Quéru over on Google+ that elegantly describes the complexities of the layering that occurs here.

SEE ALSO: You are what you eat (and code)

Repetition is therefore the natural enemy of any developer. The programming profession is often viewed in stark contrast to “normal” jobs that include repetitive and monotonous tasks which define the character of the work. Thinking about professions in this way could help us figure out why the ‘lazy’ tag has been proverbially attached to the programming line of work.

Are good programmers lazy?

There are a slew of supporters for the good = lazy equation in programming. Philipp Lenssen suggests in his article “Why Good Programmers are Lazy and Dumb” that only lazy programmers will want to write the kind of tools that might replace them in the end. He also touches on the repetition theme, noting that:

Lazy, because only a lazy programmer will avoid writing monotonous, repetitive code – thus avoiding redundancy, the enemy of software maintenance and flexible refactoring. Mostly, the tools and processes that come out of this endeavor fired by laziness will speed up the production.

Edgar Hassler also contributes to the debate, proclaiming that developers can be champions of recycling and re-use of code. The savvy developer will recognise what components should be recycled and save time, but warns us that poor choices may lead to components stuck into frameworks that are never used.

Innovation through laziness

The bottom line for our commentators is that without lazy programming, innovation and growth within the discipline just wouldn’t exist. Not only is the idea of laziness in programming encouraged, but the consequence of hard work could actually result in negative impacts on programmer productivity, as Teller claims. Decision fatigue is another common symptom of too much hard work when it comes to programming, so let’s take a moment to feel for the guys working 13 hours a day at the next big start-up.

Well, it seems that laziness is all good and can lead to great things. Except of course if you follow the YDD manifesto

UPDATE! Thanks to commenter Marty G, we have been reminded of the three great virtues of a programmer, as coined by Larry Wall. Numero uno is laziness:

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.

Summing it up nicely.

Inline Feedbacks
View all comments