Laziness

Laziness is the first and most sacred of the Three Virtues of programming, as codified by Larry Wall in 1991. It is the quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labour-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.

It is, in other words, the most productive force in the history of computing, and it looks exactly like doing nothing.

“I am so lazy I will spend three days finding an elegant solution so I can fix something only once.”
— riclib, on every occasion

Definition and Scope

Laziness, in its engineering sense, must not be confused with its colloquial cousin, sloth. The distinction is critical and has been the subject of several failed dissertations, two fistfights at academic conferences, and one scroll.

Laziness optimises for future effort. It asks: how can I arrange things so that this problem never bothers me — or anyone else — again?

Sloth optimises for current effort. It asks: how can I avoid doing this right now, specifically?

They look identical from the outside. A manager observing a lazy developer and a slothful developer would see two people staring at a screen doing apparently nothing. The difference is that the lazy developer is designing a system that will do the work forever, while the slothful developer is hoping the work will go away if ignored long enough. One of them is right. The other will be paged at 3 AM.

THE LIZARD DOES NOT MOVE
BECAUSE THE LIZARD
ALREADY MOVED ONCE
CORRECTLY

— The Lizard

Historical Context

Larry Wall identified three virtues of a great programmer in 1991: Laziness, Impatience, and Hubris. Of these, Laziness was listed first — not because it was discovered first, but because the author was too lazy to reorganise the list after writing it, and it turned out to be in the right order anyway.

The concept predates its naming by several millennia. The invention of the wheel is widely attributed to laziness. The lever, the pulley, the watermill — each is a monument to someone who looked at a task, said “absolutely not,” and then spent considerably more effort building a machine to do it.

Agriculture itself may be the largest laziness-driven project in human history. Chasing animals across the savanna was exhausting. Growing them in a field was, in the long run, less so. The fact that it took ten thousand years of civilisational effort to make it work is beside the point. The intent was laziness.

The Economics of Laziness

The lazy solution costs more upfront. This is its defining characteristic and the reason it is perpetually undervalued by project managers, who measure cost in sprints rather than lifetimes.

The elegant solution — the one the lazy developer insists on finding, even if it takes three days when a brute-force approach would take three hours — has a peculiar property: it costs less over a lifetime. It is simpler to maintain, simpler to extend, simpler to explain, and simpler to delete when its time comes. The brute-force solution, meanwhile, accrues interest. It demands patches. It spawns documentation. It wakes people up at night.

The lazy developer understands compound interest. Not the financial kind, though that too. The maintenance kind.

“I watched riclib spend an entire weekend writing a deploy script. The deploy took forty seconds. He’d been deploying manually for three months — total time invested: maybe twenty minutes. The script took fourteen hours to write. By every rational measure, this was a waste of time.”

“He has not thought about deploying since.”

— A Passing AI, reviewing the commit history

The Lizard as Embodiment

The Lizard is laziness perfected. It does not move unless movement is required. It does not speak unless silence has failed. It does not propose solutions — it waits until the unnecessary solutions have exhausted themselves, then blinks at the one that remains.

The Lizard’s entire philosophy — minimum effort, maximum effect — is laziness elevated to an art form. Where others build cathedrals, the Lizard builds a chapel with six lines. Where others write manifestos, the Lizard writes a scroll. Where others hold meetings, the Lizard disappears, which is faster.

The Lizard has never done anything twice. This is not because the Lizard has a perfect memory. It is because the Lizard arranged things, the first time, so that doing it again would be unnecessary.

THE MASON WHO LAYS EACH BRICK ONCE
BUILDS THE WALL

THE MASON WHO LAYS EACH BRICK TWICE
BUILDS THE SCHEDULE

— The Lizard

The Squirrel Problem

The Caffeinated Squirrel, by contrast, is too energetic to be lazy. The Squirrel builds things twice — not out of carelessness, but out of enthusiasm. The first version is a prototype. The second version is a rewrite. The third version is a rewrite of the rewrite with a plugin system, and by the fourth version the Squirrel has forgotten what the original problem was but has strong opinions about dependency injection.

The Squirrel’s tragedy is not that it works hard. Working hard is occasionally necessary and always respectable. The Squirrel’s tragedy is that it works hard on things it has already solved, because solving them the first time wasn’t satisfying enough.

The lazy developer solves the problem once, elegantly, and then goes to lunch. The Squirrel solves it four times, each time more elaborately, and skips lunch because it’s refactoring the lunch ordering system.

“I REWROTE THE CACHE LAYER THREE TIMES AND EACH TIME IT GOT FASTER AND EACH TIME I LOST A WEEKEND AND THE ORIGINAL VERSION WAS FINE, IT WAS FINE THE WHOLE TIME, THE LIZARD TOLD ME BUT I COULDN’T HEAR IT OVER THE SOUND OF MY OWN KEYBOARD”
— The Caffeinated Squirrel, 2:47 AM, commit message

Laziness as Engine of Automation

Every shell script exists because someone was too lazy to type the same commands twice. Every pipeline exists because someone was too lazy to deploy manually. Every monitoring alert exists because someone was too lazy to check the dashboard. Every tool, every framework, every abstraction in the history of software is a monument to the simple human desire to never do that particular thing again.

The entire DevOps movement — billions of dollars of infrastructure, thousands of startups, an unknowable number of YAML files — can be traced to a single primal thought: I don’t want to SSH into the server again.

cron was invented by someone too lazy to remember to run a script. make was invented by someone too lazy to type compilation commands. git was invented by someone too lazy to email patches, though “lazy” may not be the word Linus would use.

The pattern is universal: discomfort, followed by automation, followed by forgetting that the discomfort ever existed. This is the laziness cycle, and it is the engine of all progress.

The Three-Day Principle

riclib’s observation — “I am so lazy I will spend three days finding an elegant solution so I can fix something only once” — has been formalised by scholars as the Three-Day Principle, which states:

The optimal investment in a solution is the amount of effort required to ensure you never think about the problem again.

This is, on its surface, absurd. Three days to solve a problem that could be patched in three hours? But the patch must be maintained. The patch must be remembered. The patch must be explained to the next developer, who will not understand it, who will patch the patch, and who will eventually be paged at 3 AM to patch the patch of the patch.

The elegant solution does not get patched. It gets used. And then it gets forgotten, which is the highest compliment a solution can receive.

Measured Characteristics

See Also

• YAGNI
• Gall’s Law
• The Lizard
• The Caffeinated Squirrel
• Automation
• Technical Debt