Early in my career I wrote a one-liner I was so proud of that I showed it to anyone who'd look. It chained three array methods, a ternary, and a bit-shift into a single expression that did the work of about fifteen plain lines. It was elegant. It was dense. And six months later, when a bug surfaced near it, I stared at my own code for a full ten minutes before I understood what it did.
That was the moment the lesson landed. The cleverest line you ever write is the one your future self will curse. Cleverness is a loan taken out against comprehension, and the interest comes due at the worst possible time — usually at 4pm on a Friday with a production incident open.
Code is read far more than it's written
We type a function once and then read it dozens, sometimes hundreds, of times over its life. New teammates read it to learn the system. Reviewers read it to approve a change. You read it to fix something three quarters later, with none of the context you had the day you wrote it. If you optimise for the act of writing — the satisfying compression of logic into the fewest characters — you're optimising the rarest moment in the code's existence at the expense of every other one.
Readable code respects that ratio. It spells things out. It names the intermediate variable even though you could inline it, because the name is a free comment that never goes stale. It uses an early return instead of a nested conditional pyramid. None of this is impressive. That's the point. The best compliment a function can get is that nobody noticed it.
Clever code hides its intent
The real problem with clever code isn't that it's hard — plenty of necessary code is hard. The problem is that it hides intent. A clever expression tells you how something is computed while saying nothing about why. When you come back later, you can reverse-engineer the how by reading carefully. The why is gone, and the why is what you actually need.
Readable code leads with intent. A well-named function says what it does before you read a single line of its body. A guard clause at the top says "here are the cases we bail on early." Even the shape of the code — short functions, shallow nesting, consistent ordering — communicates structure before you parse meaning. You're not just writing instructions for the machine. You're writing an explanation for a person who is tired and under pressure.
Boring is a feature on a team that lasts
On a solo weekend project, write whatever delights you. But on a team that intends to maintain something for years, boring is a feature. Boring code can be reviewed quickly, onboarded into easily, and changed without fear. It lets a junior developer make a fix without paging a senior. It survives the person who wrote it leaving the company. Clever code, by contrast, creates a small dependency on the cleverness of its author — and that author won't always be there.
I'm not arguing for dumb code. There's a real craft to writing the obvious version well: choosing the right abstraction, drawing clean boundaries, picking names that carry weight. That craft is harder than being clever, because anyone can make something complicated. Making something simple — genuinely simple, not simplistic — takes taste and restraint.
So the next time you feel the pull to compress, to show off, to write the line that would impress a reviewer, pause. Ask who reads this next, and what they'll need. Usually the kindest thing you can do is write the boring version, name it well, and move on. The clever version was never for them. It was for you, and you won't remember it either.
