The quiet cost of a clever abstraction
Every abstraction is a loan against future understanding. Here's how I decide whether it's worth the interest.
The most expensive code I’ve written wasn’t slow or buggy. It was clever — an abstraction so elegant that, a year later, nobody on the team could safely change it. It worked perfectly and taught no one anything.
An abstraction is a trade
You spend clarity now to buy leverage later. The mistake is assuming the leverage always arrives. Often you pay the clarity cost up front and the leverage never materializes, because the second and third use cases the abstraction anticipated never showed up.
So I’ve started asking a blunt question before extracting anything:
Would a competent engineer who has never seen this code understand it in one sitting?
If the answer is no, the cleverness had better be earning its keep in something measurable — speed, safety, or reuse that already exists, not reuse I’m imagining.
The boring version is usually right
Not because boring is a virtue, but because boring is legible, and legible code is code a team can actually move quickly through. Speed is a property of the whole team over time, not of the line you’re writing today.