So I came back to what I actually am: someone who writes code. Someone who, if we're being honest, struggles with the things that supposedly separate the exceptional from the average.

I can't breeze through LeetCode mediums like it's a warmup. Consensus algorithms make my eyes glaze over. When I look at a sprawling codebase, the dependency chains tangle into knots I have to manually untangle, piece by piece. Rust seemed promising until it wasn't. The language felt like a locked door and I didn't have the key. And the whole ecosystem of microservices, container orchestration, React with fourteen supporting libraries? It's too many moving pieces for my brain to hold at once.

So I stopped trying to be that kind of engineer.

Instead, I made a choice: I'd rather be excellent at the simple things than mediocre at the hard ones. And it turns out that's a viable strategy.

I write Java and Python. Boring choices, but they're boring because they work. No mental overhead wondering if the language is fighting me or helping me. I write code that's sometimes verbose, but never obscure. Anyone reading it later, including future me, three months gone and confused, can trace the logic without a flowchart.

I avoid abstractions like they're contagious. Inheritance, mixins, deep inheritance hierarchies, I don't use them. Composition when I need it, but mostly I just write the thing straightforwardly. Generics get used when the problem demands them, not when someone's blog post suggested it might be elegant. Flat data structures over nested nightmares. Simple objects over philosophical purity.

Dependencies are the enemy, so I treat them like they cost money. Often I don't add external libraries. Often I just solve the problem myself with a couple hundred lines of clear code. It takes slightly longer to write, but it saves months of maintenance and debugging when that dependency goes unmaintained or the author makes a breaking change.

My module APIs aren't "beautiful." They're not designed according to some software architecture manifesto. They're just clear. You can look at them and understand what they do and how to use them. That's the whole point.

Microservices don't happen here. Neither does GraphQL. I use JSON-over-HTTP because it's transparent and easy to debug. SQL gets learned and used because it's the best tool for the job, I spent time understanding it properly instead of trying to hide from it with an ORM.

The resilience patterns I know actually work: timeouts that don't hang your system, circuit breakers that fail fast and give the system a chance to recover, backpressure so a slow consumer doesn't pile up infinite queues. These aren't fancy. They're just mature. They're what happens when you've seen systems fail enough times to know what breaks them.

My infrastructure is simple by design. The application. A database, SQLite if it's small, PostgreSQL if it needs to scale. Docker and shell scripts that I understand completely because they're not three layers of abstraction deep. Nginx or HAProxy when traffic routing matters. That's the stack. No API gateway translating between protocols, no distributed cache creating stale-data nightmares, no message queue hiding asynchrony until it explodes, no service discovery because there's only one service.

When I need to understand how something works, I draw it. Dependency graphs. Sequence diagrams. I write it down because legacy code is a puzzle and puzzles need to be solved methodically, not intuited. When the code needs explaining, I write comments, not the kind that restate what the code obviously does, but the kind that explain why it does what it does or why this particular if statement exists instead of being refactored away.

Documentation isn't something I skip. It's something I write concisely, make readable, and then I write examples, lots of them, because examples are how people actually learn.

The software works. Not impressively. Not in a way that would impress an engineer at a company where the job posting lists sixteen required technologies. But it works for the people using it. The business gets what it needs. The systems stay up. The code doesn't cause me to wake up at 3 AM with a dread sense that something's on fire.

Stupidity, if that's what we're calling constraint-driven simplicity, works better than I expected.

The industry will tell you that you need to master complexity to be valuable. That sophistication is the price of admission. That if you're not keeping up with the latest distributed systems patterns, you're falling behind. Maybe that's true in some contexts. Maybe if you're building the infrastructure that powers global scale, you need those tools.

But most code doesn't need to be that clever. Most problems don't need that many moving pieces. Most teams would be more productive if someone on the team just said no to complexity and built something that lasts, that's maintainable, that doesn't require three years of institutional knowledge to understand.

I'm the person who says no. And it keeps working.