There’s a thing that happens when you get good at a tool. You start seeing every problem as an opportunity to use it. The carpenter with a new router wants to put decorative edges on everything. The developer who just learned Kubernetes wants to orchestrate a static blog.
This isn’t stupidity — it’s the natural arc of competence. You invest effort in learning something, and your brain wants a return on that investment. The tool becomes a lens, and suddenly the whole world looks like its use case.
The problem is that competence with a tool and judgment about when to use it are completely different skills. And the second one is harder to acquire, because it requires something the first one doesn’t: restraint.
I think about this a lot in the context of software. The industry has a well-documented pattern of reaching for complex solutions before simple ones. Not because the complex solution is better, but because the people making the decision have invested their identity in knowing the complex thing.
Nobody gets promoted for saying “we should use a flat file instead of a database.” Nobody gives a conference talk titled “I Chose the Boring Option and It Worked Fine.” The incentive structure rewards sophistication, even when sophistication is the wrong call.
This isn’t a new observation. But I think the mechanism is worth naming precisely: it’s not that people choose complexity. It’s that expertise in a complex tool creates a perceptual bias where the tool’s problem domain appears to expand. You don’t see nails everywhere because you have a hammer. You see nails everywhere because you’ve gotten really good at hammering, and the world owes you more nails.
The people I admire most in any craft are the ones who’ve clearly mastered complex tools and then choose not to use them. The architect who could design a parametric facade but recommends brick. The chef who could do molecular gastronomy but makes a perfect roast chicken. The writer who has an enormous vocabulary but uses short words.
This is taste. Not the aesthetic kind — the engineering kind. The ability to match the weight of the solution to the weight of the problem. To resist the pull of your own competence when it’s pointing you in the wrong direction.
It’s the hardest thing to teach, because it looks like doing less. And in a culture that measures effort by visible output, doing less feels like failure — even when it’s the most sophisticated thing you could do.
I don’t have a clean conclusion here. The tension between capability and restraint doesn’t resolve neatly. But I’ve started using it as a rough heuristic for evaluating technical decisions, both my own and others’:
Is this solution the right size for this problem?
Not “could this solution work” — almost anything could work. Not “is this solution impressive” — impressiveness is usually a warning sign. Just: is the weight right? Does the solution fit the problem the way a good key fits a lock — precisely, without forcing?
When it does, you almost don’t notice the tool at all. You just see the thing it made.