The Engineer's Definition of Efficiency

Level 1: The Smart Kid Who Hates Chores

Imagine a kid who's told to water the garden every day. One kid dutifully hauls the watering can back and forth all summer. Another kid spends one afternoon rigging up a hose with little holes in it, and then never waters the garden again — the garden waters itself. The second kid looks lazier, but the garden is just as green and they're off riding their bike. That's the whole joke: the student was asked to define "efficiency" and answered "clever laziness," which is funny because it sounds like a confession but is actually the truth — the people who hate wasted effort the most are the ones who invent the best ways to avoid it.

Level 2: Why Lazy Is a Compliment Here

If you're early in your career, hearing "laziness is a virtue" can feel like a trap — but in software it has a precise, respectable meaning. A few concrete translations:

• Automation: If you've run the same three commands more than twice, put them in a script. The "lazy" engineer who spends 30 minutes writing it never types them again; the "diligent" one types them daily for a year.
• Caching: Computing something is expensive; remembering the answer is cheap. Storing a result so you don't recompute it is literally the machine being clever-lazy on your behalf.
• DRY (Don't Repeat Yourself): Copy-pasting code feels fast, but it means every future fix must be applied in five places. Writing one shared function is the lazier long game.
• Lazy evaluation: Some languages (like Haskell) won't even compute a value until something actually needs it. The concept is so useful it's a formal language feature, not a character flaw.

The mindset shift is this: effort itself isn't the goal — outcomes per unit of effort is. That ratio is, not coincidentally, exactly what the textbook's formal definition of efficiency measures. The student just wrote the human-readable version.

Level 3: The Three Virtues, Annotated

A grayscale textbook page asks, under REVIEW QUESTIONS, "1. What is efficiency?" — and a student has penciled in two words that could headline an engineering manifesto:

clever laziness

What makes this answer land so hard with developers is that it's not a joke answer. It's arguably more correct than whatever the textbook wanted (this looks like a physics or environmental science page — note the chart axis and the partial word "Wate…" at the top, so the expected answer was probably something like "useful output divided by total input"). The handwritten version captures the behavioral definition instead: efficiency is what happens when a smart person refuses to do unnecessary work.

Larry Wall, creator of Perl, canonized this in the preface to Programming Perl: the three great virtues of a programmer are laziness, impatience, and hubris. Laziness, in Wall's formulation, is "the quality that makes you go to great effort to reduce overall energy expenditure" — it's why you write documentation (so you don't have to answer questions), why you write the script instead of doing the task by hand a fourth time, and why caching, memoization, and make exist at all. Nearly every load-bearing abstraction in computing is fossilized laziness: compilers exist because assembly was tedious, garbage collection exists because manual memory management was tedious, CI/CD exists because deploying by hand was tedious and error-prone.

The crucial qualifier is clever. Plain laziness ships the hack and walks away; clever laziness does an implicit cost-benefit analysis: is the upfront effort of automating this less than the integrated cost of doing it forever? Senior engineers internalize this so deeply that it becomes their primary design heuristic — the best code is the code you never had to write, the best meeting is the one replaced by a README, the best on-call shift is the one where the alert auto-remediated. The industry even has anti-pattern vocabulary for when the balance tips wrong: spending a week building a bespoke framework to avoid an hour of repetition is not clever laziness, it's procrastination with extra steps, and it's how half of all internal tooling is born.

There's also a quieter satire here about education versus practice. The textbook wants a formula; the practitioner gives you the mindset. One of these will be on the exam. The other one will get you promoted.