Not All Laziness Is Created Equal

#softwareengineering #programming #productivity #architecture

How to tell the difference between productive laziness and plain indifference in software development

There is a famous idea in management circles, traced back to the Prussian military, that the best leaders are the smart-lazy ones. Not the diligent ones who never stop working. Not the dull ones who coast. The ones who are intelligent enough to see what needs doing, and lazy enough to want to do it in the fewest possible steps.

It sounds like a paradox. But anyone who has worked in a software team long enough has likely met two very different people who would both describe themselves the same way: lazy.

One of them builds composables, abstractions, and reusable systems. They hate solving the same problem twice. Their code is a gift to the next developer.

The other can't be bothered to make anything reusable. Their codebase is a maze of tightly coupled components, copy-pasted logic, and patterns that were never meant to scale. They just needed it to work today.

Both call themselves lazy. But only one of them is.

The Prussian Test

Helmuth von Moltke, chief of staff of the Prussian Army for thirty years, sorted his officers across two axes: diligent vs. lazy, and bright vs. not-so-bright. His conclusion was sharp: the best officers for high command were the bright-lazy ones. They had the vision to see what mattered, and the aversion to wasted effort that would make them find the cleanest path there.

"I will always choose a lazy person to do a difficult job, because a lazy person will find an easy way to do it."

— Frank Gilbreth Sr.

This is the core of what we now call productive laziness. It is not idleness. It is efficiency-seeking. It is the refusal to do unnecessary work — and crucially, the willingness to do harder work upfront in order to avoid easier but endless work later.

Applied to software development, it looks like this: the productively lazy developer writes a composable because they cannot stand the idea of duplicating that logic in twelve places. They build the middleware because manually threading that concern through every route is an affront to their intelligence. They hate repetition so much that they invest real effort into eliminating it.

The Other Kind

The second kind of laziness has a different shape entirely. It is not efficiency-driven. It is deadline-driven. Or more precisely, it is ticket-driven.

The indifferent developer sees a problem in front of them and solves it — just this once, just this way, just enough to close the PR. They are not thinking about the next time this problem appears. They are not thinking about the developer who will inherit this file in six months. They are not even thinking about themselves next week.

The result is a codebase full of components that know too much about each other, logic that appears in four places with slight variations, and utilities that were written three times by three different people who each assumed no one had solved it before.

This is not laziness in any meaningful sense. It is indifference — to the system, to the team, and to the future.

Two Laziness, Two Outcomes

	Productive Laziness	Indifferent Laziness
Avoids	Repeating work in the future	Doing work right now
Time Horizon	Long-term thinker	Short-term thinker
Output	Composables, reusable systems	Copy-paste, tight coupling
Effect on Team	Multiplies productivity	Creates debt for others
Driven by	"I never want to solve this twice"	"I just need this to work today"

Upstream vs. Downstream Laziness

The cleanest way to distinguish the two is by where the work avoidance happens.

Productive laziness is lazy upstream. It front-loads the thinking — the abstraction design, the composable architecture, the reusable interface — so that downstream work becomes trivially easy. You pay the cost once. The team never pays it again.

Indifferent laziness is lazy downstream. It skips the upstream investment and defers the cost forward — onto future maintainers, onto the next sprint, onto whoever has to touch this code and figure out why it is the way it is. It does not eliminate work. It launders it.

This is why tightly coupled, non-reusable code is actually the least lazy outcome in the long run. It forces every future developer to carry the full weight of the system in their head just to change one thing. The apparent time savings at the start compound into enormous costs at the end.

The Tell: How They Feel About Repetition

There is one reliable signal to distinguish these two developers: how they feel when they encounter repetition.

The productively lazy developer is bothered by it. They see the same pattern appearing twice and something in them resists. They feel the friction. That friction is the engine of good architecture — it is the sensation that precedes the composable, the hook, the shared utility. They are almost constitutionally unable to copy-paste something without first asking whether it should exist once somewhere central.

The indifferent developer does not feel that friction. They have copy-pasted the same validation logic into eight components and noticed nothing. Repeating the work was fine. They just needed to move on.

Productivity laziness requires caring about the codebase as a system. Indifference is its absence.

What This Means for Teams

Teams that confuse these two types of laziness make dangerous hiring and architectural decisions. They may distrust the developer who spends a sprint building infrastructure, calling it gold-plating or over-engineering. Meanwhile the developer shipping features quickly by cutting every structural corner gets praised for velocity.

The cost of this confusion is paid slowly and then all at once — in a codebase that becomes progressively harder to change, a team that spends more and more of its time fighting the system rather than building on it, and onboarding that requires weeks just to understand what should have been self-evident from the structure.

The productively lazy developer is not slower. They are playing a longer game. Every abstraction they build is a tax paid once so the whole team saves it forever.

The Real Definition

Productive laziness is not about doing less. It is about refusing to do the same thing twice. It is the developer who thinks: if I have to do this again, something is wrong — and then fixes the something.

Indifference is not laziness at all. It is the absence of ownership. The ticket closes, the feature ships, and the cost quietly accumulates in the dark corners of a repository that nobody wants to touch.

The distinction matters. Not just for code quality, but for how we evaluate the people writing the code. Busyness is not a proxy for contribution. The developer who spent a week writing a system that saves everyone an hour a day every day is doing more than the one who shipped five features that each take an hour to understand and an hour to safely modify.