The Elements of Grug

Strunk and White’s Rule 17: “Omit needless words.”

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

Grug makes the same argument about code. The best code is the code you didn’t write. The best abstraction is the one you didn’t add. The hardest skill in programming isn’t building complex things. It’s resisting the urge to.

I keep relearning both of these.

Needless things

The extra clause adds nuance. The extra abstraction adds flexibility. Sometimes that’s true. Most of the time it’s just noise.

Strunk and White give this example:

“The question as to whether” → “Whether”

Five words doing the job of one. The long version doesn’t hedge or qualify. It just takes longer to say the same thing. This is a function call wrapped in a factory wrapped in a builder wrapped in a provider. The machinery doesn’t add capability. It adds ceremony.

Why it’s hard

If simplicity is so obviously better, why do people keep choosing complexity?

Complexity is easier to produce. Building an elaborate abstraction layer is easier than figuring out the minimal design that actually solves the problem. Simplicity requires understanding what matters and what doesn’t. Complexity has to be earned. That’s the hard part.

Pascal nailed it: “I would have written a shorter letter, but I did not have the time.”

Complexity also looks like effort, and effort looks like competence. A short function that does the right thing doesn’t look impressive. A sophisticated framework with extension points and plugin architectures looks like serious engineering. We reward the appearance of thoroughness even when the simplest solution was the most thorough one. The one that required the deepest understanding.

Knowing what to cut

The hard part of “omit needless things” is the word “needless.” You have to know what’s load-bearing and what isn’t. That means understanding the thing deeply enough to know which parts are doing work.

A good programmer can simplify a system because they can tell the difference between essential complexity and accidental complexity, between complexity that was earned and complexity that just accumulated.

This is why simplicity takes experience. Early on you write verbose code because you’re not sure what’s necessary, so you keep everything. Long comments explaining obvious things. Defensive checks for impossible cases. Eventually you learn to delete. Delete code, delete abstractions, delete features. You can delete because you know what’s holding the weight.

The discipline is the same everywhere. Code, writing, design, strategy, systems. Understand deeply enough to know what matters. Cut everything else.

Anyone can add. Knowing what to remove is the real game.