Every developer I admire writes less code than I expect. Their solutions look obvious in hindsight. Their architectures have fewer layers, fewer abstractions, fewer moving parts.
This isn't laziness. It's discipline.
The complexity trap
Early in my career, I equated complexity with sophistication. A custom state management solution felt more "professional" than just using React state. A microservices architecture felt more "scalable" than a monolith. Abstract factories, dependency injection containers, event buses — the more patterns I could name, the better I thought I was.
I was wrong.
What simplicity actually looks like
Simple code does one thing clearly. It's boring. It reads like prose. You don't need a wiki page to understand the architecture because the architecture fits in your head.
Here's my checklist for simplicity:
- **Can I explain this to a new team member in under 5 minutes?** If not, it's too complex.
- **Am I solving a problem I actually have, or one I might have?** YAGNI is real.
- **Would deleting this abstraction make the code harder to understand?** If not, delete it.
- **How many files do I need to open to understand this feature?** Fewer is better.
The courage to be boring
Choosing simplicity requires courage. It means saying "a PostgreSQL query is fine here" when someone suggests Elasticsearch. It means using a simple cron job instead of a message queue. It means writing a 50-line script instead of a "framework."
The best engineers I've worked with have this courage. They've seen enough complex systems fail to know that simplicity isn't a compromise — it's a competitive advantage.
A personal rule
Before adding any abstraction, library, or architectural pattern, I ask: "What happens if I just... don't?"
More often than not, the answer is: everything works fine.