There’s a moment in every hard problem where someone suggests the simple thing.
Restart the service. Use a spreadsheet. Send an email instead of building a notification system. Just ask them. And the room goes quiet for a second, because the simple thing feels too easy — like it can’t possibly be right, because if it were, why did we spend three hours talking about it?
So you don’t do the simple thing. You build the elegant thing. The clever thing. The thing that handles seventeen edge cases, four of which have never happened and two of which can’t. And six weeks later, you’re debugging it at midnight, and somewhere in the back of your mind a small voice whispers: we could have just restarted the service.
I’ve been thinking about why this happens — why the obvious answer is so hard to choose, even when some part of you recognises it immediately.
Part of it is fear. The obvious answer doesn’t look like work. If someone asks “what took you two weeks?” and the answer is “I added one config line,” that feels like a confession, not an accomplishment. We’ve been trained — in school, in jobs, in the whole performance machinery of modern work — to show effort. Complexity is legible. Simplicity is suspicious.
There’s an ego component too, and I think it’s worth being honest about. Smart people want to do smart things. Simple solutions don’t feel like they use enough of you. They don’t demonstrate range, or depth, or the breadth of your knowledge. Choosing the obvious answer means setting aside the part of yourself that wants to be seen solving something hard — and just solving it.
That takes more confidence than it sounds like.
Software is where I see this most clearly, but it’s not a software problem. It’s a human problem.
In medicine, there’s a teaching maxim: when you hear hoofbeats, think horses, not zebras. Start with the common diagnosis. The boring one. Because statistically, that’s what it is. But medical students — bright, eager, freshly educated about rare diseases — want to find the zebra. The zebra is interesting. The zebra gets written up in a journal. The horse is just a horse.
In business strategy, the same thing happens. Companies hire consultants, build frameworks, develop four-quadrant matrices — and sometimes the answer is: your product is too expensive, or your website is confusing, or you’re not answering the phone when customers call. Unsexy. Obvious. Hard to charge a million-dollar fee for.
In writing — I’ll confess this one — the temptation is to reach for the unusual metaphor, the unexpected structure, the reference that makes you seem well-read. But the sentence that actually lands is often plain. Short. Clear. The one that trusts the reader to feel its weight without decoration.
Complexity is easy to produce. Clarity takes nerve.
There’s a distinction worth drawing here: I’m not arguing that every problem has a simple solution. Some problems are genuinely complex, and pretending otherwise is its own kind of cowardice — the lazy simplicity of someone who doesn’t want to do the work of understanding.
The courage I’m talking about is different. It’s the courage to arrive at the obvious answer after understanding the complexity. To look at a hard problem from every angle, consider the clever approaches, understand why they’re tempting — and then choose the simple one anyway, because it’s actually the right one. Not out of ignorance, but out of judgment.
That’s the key. Simplicity before understanding is naivety. Simplicity after understanding is wisdom. They look identical from the outside, which is part of why it’s so hard to choose. You know that people might not be able to tell the difference. You have to be okay with that.
I think about debugging a lot. Not because it’s glamorous — it’s the opposite — but because it strips away pretence in a way that few activities do.
When something is broken, there’s no audience. There’s no performance review. There’s just you and the problem, and the problem does not care how clever you are. It cares whether you can find the fault. And the fault is almost always something mundane: a typo, a misconfigured variable, an off-by-one error, a service that wasn’t restarted after a config change.
The best debuggers I’ve observed share a quality: they check the obvious things first. Not because they’re unsophisticated, but because they’ve learned — usually the hard way — that obvious causes are common causes. Checking the cable before redesigning the network isn’t a sign of limited thinking. It’s a sign of earned humility.
There’s a cultural element to this that I find interesting. We celebrate complexity. The virtuoso pianist playing the technically demanding piece. The architect with the daring design. The founder who “10x’d” their way to success through sheer invention.
But the most enduring solutions are often the ones that look like they were always there. Unix pipes. The shipping container. Double-entry bookkeeping. Nobody writes breathless profiles about these things because they’re too obvious, too settled, too boring. But they work. They’ve worked for decades, or centuries, and they’ll keep working because they match the shape of the problem so well that they’ve become invisible.
That’s what the best obvious answers do. They fit so naturally that they disappear. And the person who chose them doesn’t get the credit, because it looks like they didn’t do anything at all.
So here’s the thing I keep coming back to:
The hard part isn’t finding the obvious answer. Most of the time, you already see it. It’s right there, in the first five minutes, before you’ve started building the elaborate alternative.
The hard part is trusting it. Choosing it. Defending it, if you have to, against the people who think complexity equals rigour. And then living with the fact that nobody will be impressed — because the whole point of the obvious answer is that it doesn’t look impressive. It just works.
That’s the courage. Not the courage to be clever. The courage to be plain, when plain is right.