How do I stop over-engineering my code?

Build for the requirements you have, not the ones you imagine. The core discipline is YAGNI — you aren't gonna need it — and it's hard precisely because over-engineering feels like professionalism while you're doing it. What over-engineering usually looks like: - Abstractions with one implementation. An interface, a factory and a strategy pattern for a thing that has exactly one variant and always will. - Configuration options nobody asked for. Every option is a branch to test, document and maintain forever. - Building for scale you don't have. Caching, queues and sharding for an app with 40 users. Different problem entirely, solved at the wrong time. - Generic 'flexible' systems where a hardcoded value was fine. The irony is that speculative flexibility usually turns out to be flexible in the wrong dimension, so the actual change is *harder* than it would have been in simple code. Why it happens, which is worth naming: it's more intellectually enjoyable than the boring solution, it feels like insurance against future pain, and it signals sophistication. All three are real motivations and none of them are about the user's problem. The practical brakes: 1. **Rule of three.** Don't abstract until you have three real instances. Two similar things might be coincidence; the abstraction you'd design from two is usually wrong because you can't see the axis of variation yet. 2. **Ask 'what breaks if I do the simple thing?'** Often the honest answer is 'nothing, and if requirements change I'll spend an hour then'. An hour later beats three days now against a hypothetical. 3. **Write the simple version first, deliberately.** Hardcode, duplicate, skip the config. Ship it. Refactor when a *real* second case arrives. Simple working code is not a rough draft you should be embarrassed by. 4. **Timebox design.** If you've spent more time designing the architecture than the feature would take to build directly, stop. 5. **Count the users of your flexibility.** If the answer is zero and has been for months, delete it. The reframe that helps most: simple code is not less skilled code. Writing something obvious that a colleague can modify safely in six months is a harder and more valuable skill than producing an elegant framework only you understand. Senior engineers are frequently identifiable by how *plain* their solutions are — they've been on the maintenance end of their own cleverness enough times to have lost the appetite for it. The genuine exception: architecture that's expensive to change later — database schema, public API shape, security boundaries. Think carefully there. For everything else, prefer the boring version and let real requirements pull complexity in.