The Thing About Great Software
I’ve been thinking about this lately — why some tools feel like extensions of your thoughts, while others feel like wrestling matches you’re destined to lose.
The difference isn’t what they do. It’s what they don’t make you think about.
When I click “sign in with google,” I’m not thinking about OAuth flows or token refresh logic or session management. I’m just… signed in. That simplicity isn’t accidental. Someone made a deliberate choice to eat all that complexity so I wouldn’t have to.
Where Complexity Goes to Hide
The best engineers I’ve worked with understand this instinctively. They know that complexity doesn’t disappear — it just finds better places to live.
Internal APIs that gracefully handle every edge case you’ve never thought of. State management that makes impossible conditions… impossible. Error recovery that fails so elegantly you barely notice it happened.
All of this lives where users never see it. Because the moment complexity leaks into the user experience, you’ve broken the spell.
When Things Go Wrong
I’ve seen this play out in painful ways. Configuration screens with forty-seven checkboxes. Error messages that read like stack traces. Workflows that make you think like a database schema instead of like a human being.
Each of these represents a moment where someone chose their own convenience over the user’s experience. And honestly? I get it. It’s easier to punt complexity to the user than to contain it properly.
But that’s exactly backwards.
How This Shows Up in Practice
In my work — whether it’s security tools that translate complex vulnerability data into actionable insights, or APIs that hide gnarly business logic behind clean interfaces — the principle stays the same.
The complexity has to live somewhere. The question is: where does it serve the experience rather than undermining it?
I’ve seen security dashboards that require a PhD to interpret. I’ve also built tools that take the same data and make it feel obvious. The difference isn’t the data. It’s the choice about where to put the cognitive load.
The Discipline It Takes
This approach is more work upfront. Always. You have to resist the temptation to expose your internal structures. You have to invest heavily in abstraction layers. You have to test for edge cases that users will never consciously encounter.
You have to iterate relentlessly on interfaces until they feel inevitable.
But when you get it right, something magical happens. The software stops feeling like software and starts feeling like thinking.
The best technology disappears. What remains is just you and your intentions.