The Cost of Cleverness

Clever code is a loan against the next reader’s attention. You felt smart writing it. The next person to open the file is going to spend ten minutes reverse-engineering what a clear line would have communicated instantly. Multiply by every reader, forever.

The interest rate compounds

Software is a multi-reader medium. The author writes a line of code once. The line is then read — by the same author six months later, by the new hire on day twelve, by the on-call engineer at three in the morning, by the auditor preparing for the compliance review, by the static analyzer, by the next refactor, by the AI assistant trying to summarize the change for a pull request. Each of those readers pays a small comprehension tax. Multiply the tax by the readers and the line is not free. It is a recurring bill, and the bill scales with how clever the line was.

Boring code is the opposite trade. It is slightly longer to write. It is much cheaper to read. Multiply that across years and teams and the savings are obscene. The honest measure of code quality is not how concise it is. It is how cheap it is for a stranger to change safely. By that measure, most of the code we admire in language showcases is not good code. It is exhibition code, designed to be looked at, not lived with.

Cleverness as a personality tax

There is a particular flavour of cleverness that is really a status performance — the one-liner that uses three obscure language features to do what a five-line loop would have done. It is rarely about performance. It is about signaling. The author is telling the rest of the team how fluent they are. The team gets the signal. The team also gets a line of code they cannot safely modify without a meeting.

Senior engineers tend, with time, to write more boring code, not less. They have been the reader on the other end of someone else’s brilliance enough times to know what it costs. They have also discovered that the team’s collective velocity matters more than any individual moment of self-expression. The boring solution is often the courteous one.

Where cleverness still earns its keep

There are places where cleverness pays its own interest. Hot paths where a smarter algorithm shaves milliseconds at scale. Library internals that thousands of downstream callers depend on, where one careful optimization moves the floor for everyone. The rare crevice where a domain genuinely demands a non-obvious solution — cryptography primitives, lock-free data structures, the parser for a language you cannot change. In those places, write the clever code. Then write the comment that explains why it had to be clever, the test that pins its behaviour, and the benchmark that proves the cleverness was worth the cost.

Everywhere else, the answer is to be boring on purpose. The verbose name. The explicit early return. The flat conditional instead of the nested ternary. The named intermediate variable that gives the reader a place to rest. None of this is bad taste. It is hospitality.

The team contract

Treat code clarity as a team agreement, not a personal preference. Pull requests that lean clever should have to justify the cleverness, not the other way around. The default in review is ‘rewrite this to be more obvious unless you can explain why obvious would be worse.’ The team that holds the line on this for a year ends up with a codebase that new hires can be productive in by week two, instead of week eight. The savings are real. They show up in onboarding time, in incident response time, in how fast a team can pivot when the business changes its mind.

A small daily discipline

Before you merge, read your own diff as if you were seeing it for the first time. If a line makes you reach for the language spec to remember what it does, the next reader will too — except the next reader will not have the benefit of having written it. Rewrite the line. Be boring on purpose. The next reader is you, in eighteen months, on a Sunday night, trying to fix something before Monday. Be kind to them.

Cleverness is a debt. Pay it where the return justifies it. Decline it everywhere else.