Every developer has written a line of code they were proud of for the wrong reason. A one-liner that folded three operations into a single clever expression. A recursive trick that avoided a loop. A regular expression that did in one line what a small function would have done in ten. It felt good to write. It rarely felt good to read again.
Clever code optimizes for the moment of writing. It rewards the person solving the puzzle, not the person who has to understand the solution later without the context that produced it. That second person is often the same developer, months on, with none of the working memory that made the cleverness legible in the first place.
The cost shows up slowly. A clever function works fine until it needs to change. Then the person changing it has to first reverse-engineer the cleverness before they can safely touch it. What would have been a five-minute edit to plain code becomes a thirty-minute archaeology project.
This isn't an argument against elegant code. Elegant and clever are different things. Elegant code is often simpler than the obvious first draft — it removes steps rather than compressing them into fewer, denser lines. Clever code adds density. Elegant code removes it.
A useful test: could someone unfamiliar with this codebase read this function and explain what it does, out loud, without running it? If the answer requires tracing through operator precedence or remembering a language quirk, the cleverness has a cost that hasn't been paid yet — it's just been deferred to whoever reads it next.
The habit that's served me best is writing the boring version first and only reaching for something denser when the boring version is genuinely too slow or too repetitive to live with. Most of the time, the boring version turns out to be the one that ships.