Clever abstractions can feel satisfying in the moment. They often reduce code in the short term and make an engineer feel productive.
The cost shows up later: onboarding, debugging, and making changes under pressure. Most of a codebase’s life is spent being read, modified, and operated—not initially written.
Because of that, I optimize for clarity first, even when it means writing a little more code or deferring abstraction.
In practice, clarity looks like:
- Intent-first naming and straightforward data flow
- State living where it’s actually used
- File and component structure that matches how the product is described
When I’m unsure whether something is “too simple,” I ask one question:
“If someone joined this team tomorrow, what would confuse them first?”
That question almost always reveals where complexity is hiding unnecessarily. Reducing that confusion is one of the highest-leverage improvements an engineer can make.
Clear systems scale teams, not just features. That’s why clarity beats cleverness in the long run.