Early in my career I thought good code looked *smart*. Nested ternaries. A reduce that did six things. A regex so dense it could have its own gravitational pull. I'd finish one of these and lean back like I'd just defused a bomb on live television, waiting for applause that never came.
Then I had to debug my own bomb eight months later. At 2am. During an incident. With a customer on the other end politely asking why their money had vanished. That experience cured me faster than any code review ever could. Nothing humbles you like being outsmarted by yourself.
Code is read way more than it's written
You write a function once. Then you and everyone you work with read it dozens of times — reviewing it, debugging it, extending it, quietly resenting it. Studies of where engineering time actually goes put reading and understanding existing code at well over half the job. We just don't *feel* it, because reading is invisible labor and writing comes with a little dopamine hit.
So the real question was never "how short can I make this?" It's "how fast can a stranger understand this?" Because in six months, *you* are the stranger. You will have forgotten every assumption, every clever shortcut, every "obviously this can't be null here."
Write code for the tired version of you who has to fix it under pressure. That person has no patience for your art project.
Boring is a feature, not a confession
Boring code is predictable. Predictable code is debuggable. Debuggable code lets you go home on time. There's nothing embarrassing about writing the obvious thing — the embarrassment is reserved for the person who has to reverse-engineer your masterpiece at midnight.
A few habits that compound forever:
- Name things for what they mean, not what they are.
isAccountLockedbeatsflag2every single time. - Keep functions small enough to hold in your head. If you have to scroll, you have two functions wearing a trench coat.
- Make the happy path obvious and handle errors loudly. Silent failure is just a bug with good manners.
- Delete dead code. The repo is not a museum and you are not its curator.
- Prefer early returns over deep nesting. A pyramid of
ifstatements is not an achievement.
A worked example
Here's the clever version everyone writes exactly once before they learn:
const ok = u && u.sub && !u.banned && (u.plan ?? 'free') !== 'free' && Date.now() < u.exp;It works. It's also a single line carrying five separate ideas, and the next person to touch it will add a sixth condition somewhere in the middle and introduce a bug nobody catches until billing complains. Here's the version that ages well:
const isSubscribed = (u.plan ?? 'free') !== 'free';
const isActive = Date.now() < u.exp;
const inGoodStanding = Boolean(u?.sub) && !u.banned;
const canAccess = inGoodStanding && isSubscribed && isActive;Same logic. But now each idea has a name, the final line reads like a sentence, and when someone adds a rule they have an obvious place to put it. You traded four characters for four months of sanity. That's the best trade in software.
Tip
Rule of thumb: if a teammate has to *decode* a line instead of *read* it, you've written a puzzle, not a program. Puzzles belong in advent calendars.
The nesting trap
Cleverness isn't only about one-liners. Deep nesting is its quieter cousin — code that's technically readable but makes you track six levels of context in your head at once. Guard clauses fix it almost every time:
// before: the arrow of doom
function process(order) {
if (order) {
if (order.items.length) {
if (order.paid) {
return ship(order);
}
}
}
}
// after: handle the exits first, then the real work stands alone
function process(order) {
if (!order) return;
if (!order.items.length) return;
if (!order.paid) return;
return ship(order);
}Same behavior. But now the failure conditions are listed up top like a bouncer's checklist, and the actual work isn't buried under three layers of indentation. Your eyes thank you.
"But it's more performant"
Usually it isn't, and even when it is, you measured nothing — you vibed it. The compiler is smarter than your cleverness 99% of the time, and the 1% where it isn't, you'll only find with a profiler, not a hunch. Premature optimization isn't just the root of all evil; it's the root of all unreadable code.
Write the clear version, profile it, and *if the profiler points at it*, optimize that specific spot and leave a comment explaining the deal you made with the devil:
// HOT PATH: called ~50k/sec. Manual loop beats .map here (benchmarked, see #482).
// Touch this and re-run bench/throughput.ts before merging.
for (let i = 0; i < points.length; i++) total += points[i].weight;Heads up
Optimized-but-unreadable code with no comment and no benchmark is a trap you set for your own team. If you can't prove it's faster, it's just hard to read for no reason.
Comments: explain why, not what
Clear code makes most comments redundant — the code already says *what* it does. The comments worth writing explain *why*: the weird business rule, the bug this works around, the assumption that isn't obvious. // increment i helps nobody. // skip row 0, it's a header from the legacy export saves an afternoon.
The actual senior move
Cleverness has a home: a genuine bottleneck, a hard algorithm, a constraint you can't design around. There, you isolate it, comment it, and test it until it begs for mercy. Everywhere else, the senior move is *restraint*. Ship the boring thing. Let it be obvious. Save your one good trick for the problem that actually deserves it.
Nobody has ever been paged at 2am and thought, "thank god this function was a clever one-liner." Be the person who wrote the boring code. Be everyone's favorite engineer to inherit a project from.
Key takeaways
- 01Code is read far more than it's written — optimize for the reader, not your ego.
- 02Boring, obvious code is debuggable code. Predictability beats brilliance.
- 03Reserve cleverness for measured bottlenecks, and comment the deal you made.
FAQ
Related reading