#Philosophy#Efficiency#Simplicity#Design

In Praise of Laziness in Software Engineering

Alexandre Jeffroy

Software Engineer

|29 April 2026|3 min read

In popular imagination, the good developer is a tireless soul, capable of coding for hours without stopping. I believe the opposite: one of the most useful traits of a good engineer is a form of laziness. Not idleness, but a visceral aversion to unnecessary effort, whether present or still to come.

It's no accident that Larry Wall, the creator of Perl, listed laziness as one of the three great virtues of a programmer. It's not a personality quirk cultivated for comfort. It's a form of reasoning.

Two kinds of laziness, one reflex

The first kind of laziness pushes you to automate a repetitive task; I've already written about that in a previous article on mental load. The second is quieter, and it acts before the code is even written: it's the one that pushes you to pick the simplest possible solution so you won't have to maintain it, relearn it, or debug it later.

A truly lazy developer doesn't write the most impressive solution. They write the one that will demand the least effort *later*, even if that means putting in a bit more effort now.

The code you never want to read again

On a real-time simulation project, I once saw a trajectory calculation function rewritten three times in a year, each time to fix a forgotten edge case. The culprit: a "clever", over-optimised implementation from the very first version, hard to read and therefore hard to fix properly.

Good laziness would have said: write the simplest, most readable version first, and optimise only if profiling justifies it. The developer who eventually stabilised that function did exactly that, rewriting it more simply, with explicit variable names and an obvious structure. No regression since.

cpp

1// "Clever" version — quick to write, expensive to understand
2double f(double v, double a, double t) {
3    return v*t + 0.5*a*t*t - (v<0?v*t:0);
4}
5
6// "Lazy" version — a bit longer, never misunderstood
7double computeDisplacement(double initialSpeed, double acceleration, double time) {
8    const double distance = initialSpeed * time + 0.5 * acceleration * time * time;
9    const bool movingBackward = initialSpeed < 0.0;
10    return movingBackward ? distance - initialSpeed * time : distance;
11}

Laziness as a filter against complexity

This aversion to future effort acts as a natural filter against over-engineering. Faced with a new feature, I always ask myself the same question: *do I really want to maintain this in six months?* If the answer is no, I look for a simpler solution, even if it seems, at the time, less elegant or less general-purpose.

It's this same reflex that pushes back against premature abstraction. Why build a generic plugin system for a need that, in reality, will only ever cover two known and stable cases? Intelligent laziness prefers two simple functions over an architecture you'll have to understand before you can even extend it.

The real risk: false laziness

There's a dangerous kind of laziness that has nothing to do with what I'm describing here: cutting corners to go faster right now, leaving invisible technical debt behind. That isn't laziness, it's haste. Real laziness is strategic: it accepts a cost today to save a bigger one tomorrow.

Laziness as a strategy

Next time you see a developer spend time simplifying a solution that "already worked", or refuse to build a poorly defined feature until it's clarified, don't judge them as lazy in the bad sense of the word. It's often the sign of an engineer who has already anticipated the effort they're sparing you.