← Writing

You cannot be dumb and lazy at the same time

·2 min read engineeringcraft

487 words

There is a blunt rule of thumb that holds up everywhere in engineering: you can be unexceptional, or you can be lazy, but you cannot afford to be both.

If you are terrifyingly sharp, you can get away with working four hours a day. You glance at a stack trace, spot the unindexed database scan or the off-by-one race condition in three minutes, write a fifteen-line fix, and move on. Your leverage is high enough that your output looks effortless.

If you aren't that person—and almost nobody is when they start—you still have a completely viable path: you just outwork the gap. You pull down the library's source code instead of guessing what the docs meant. You fire up a debugger and step through twenty stack frames. You write a script that generates ten thousand edge-case payloads until the bug reproduces locally. It takes longer, but you arrive at the exact same truth.

The disaster is when people try to borrow the work habits of the first person while possessing the context of the second.

The guessing game#

You see this most clearly in how people debug.

When someone lacks both deep understanding and the patience to grind, debugging turns into superstition. They change a variable name, wrap a synchronous call in an unnecessary retry loop, sprinkle random null-checks, and rerun the test suite. If it passes once, they push to main and pray nobody touches it again.

Nothing was diagnosed. No invariants were verified. The underlying race condition or memory leak is still there, quietly waiting for traffic to spike.

It happens because genuine diagnosis is tedious:

  • Reading a 40-page protocol spec when you only care about three fields.
  • Profiling memory allocations under load instead of blindly bumping the container's RAM limit.
  • Tracing raw TCP packets when a connection drops silently behind a reverse proxy.

None of that is glamorous work. It is mostly reading, testing hypotheses, and being wrong ten times in a row before finding the one line that actually matters.

The leverage tax#

Productive laziness is real, but it is an earned state.

The engineers who build clean, minimal systems aren't "lazy" in the sense that they skip the hard parts. They are lazy in the sense that they refuse to solve the same problem twice. They spend three days designing a clean abstraction or writing an idempotent pipeline specifically so they never have to wake up for an on-call alert on Saturday.

That kind of simplicity requires enormous upfront cognitive work. Making something simple is much harder than making something complicated.

If you don't have the mental models yet to build that leverage, you can't skip straight to the relaxed afternoon. Your only real option is to put in the hours: read the manuals, write the test harnesses, inspect the logs, and build the intuition from scratch.

One handicap is workable. Both at once is just negligence.