The Familiarity Trap: Why Your Brain Lies to You About Complexity
Your Past Experience Is Sabotaging Your Estimates
Every single one of these feels like it should “just work” because, well, it always has, on someone else’s implementation that took months or years to get right.
There’s a specific kind of limitation that hits you when you’re building something complex, especially if you’ve spent years using tools that do the same thing. Your brain has already decided the problem is simple. It’s been using the finished product for so long that it can’t fathom the engineering iceberg lurking beneath the surface.
Here’s the example that made this click for me: a text editor. I’ve used text editors my entire life, long before I became a software engineer. My brain is completely wired to believe this is a straightforward problem. Type text, delete text, move a cursor around. How hard can it be? Then you actually try to build one, and you discover a staggering number of edge cases you never even considered. Parsing pasted content. Resetting the cursor index after operations. Handling text selection across elements. Managing undo/redo state. Dealing with keyboard navigation across rows and columns where each cell might have different text lengths. Every single one of these feels like it should “just work” because, well, it always has, on someone else’s implementation that took months or years to get right.
The Illusion of Simplicity
familiarity with the output of engineering is not the same as understanding the process of engineering. Your brain is pattern-matching based on what it’s seen, not what it’s built.
While I was battling this mentally and genuinely interested to the point of research, I realized that Psychology has a name for this. Several names, actually. The familiarity heuristic is a cognitive shortcut where your brain judges a current situation based on how similar it looks to past experiences. You’ve used text editors a thousand times, so your brain pattern-matches and says, “I know this. It’s easy.”
But familiarity with the output of engineering is not the same as understanding the process of engineering. Your brain is pattern-matching based on what it’s seen, not what it’s built. And because this shortcut favors speed over deep analysis, it can mislead you — especially when a new problem looks like something you’ve encountered before but actually demands a completely different approach.
There’s also the planning fallacy, the well-documented tendency for people to underestimate the time and effort a task will require. And the Dunning-Kruger effect plays a role too: when you have surface-level familiarity with a domain, you overestimate your competence because you literally can’t see the complexities you’re missing. Experts, paradoxically, tend to underestimate their abilities, because they’ve developed enough metacognition to see how deep the rabbit hole goes.
The combination is brutal. Your familiarity tells you the problem is simple. Your optimism tells you it’ll be quick. And your lack of depth in that specific domain means you can’t even see the edge cases until you’re knee-deep in them.
The One-Size-Fits-All Reflex
Because your brain is convinced the problem is simple, you keep reaching for simple solutions. You try to handle every edge case with a single elegant abstraction. You resist adding complexity to your solution because it feels wrong.
What makes this worse is the downstream effect on your approach. Because your brain is convinced the problem is simple, you keep reaching for simple solutions. You try to handle every edge case with a single elegant abstraction. You resist adding complexity to your solution because it feels wrong. This thing shouldn’t be this hard. You’re not just underestimating the problem; you’re actively fighting the evidence that it’s more complex than you thought.
This is the real trap. It’s not just bad estimation; it’s a feedback loop. You underestimate, you build something too simple, it breaks on edge cases, and instead of stepping back and acknowledging the true complexity, you patch it with another simple fix. Rinse and repeat until you’ve got a fragile mess that never quite works right.
The people who built the text editors you grew up using didn’t take shortcuts. They sat down, broke the problem apart, analyzed every interaction: what happens when you paste rich text into a plain text field, what happens when you press backspace at position zero of a merged row, what happens when you arrow-key navigate across cells with different content lengths. And they built specific, deliberate solutions for each scenario.
Recalibrating Your Brain
over-engineering is almost always the lesser sin. An over-engineered solution can be optimized and trimmed down.
I think there needs to be a fundamental shift in how we approach problems we think we already understand. Your brain needs to learn to recognize problems for what they actually are, rather than what your familiarity tells you they should be. The instinct to downplay complexity is strong, and yes, there’s a balance. You don’t want to over-engineer everything into an enterprise architecture astronaut’s fever dream.
But here’s my take: over-engineering is almost always the lesser sin. An over-engineered solution can be optimized and trimmed down. It’s a lot easier to simplify something that works than to keep bolting fixes onto something that was never built to handle the real scope of the problem. Downplaying complexity, on the other hand, means you might never arrive at a working solution at all. You just keep circling, patching, and wondering why this “simple” thing won’t cooperate.
This applies far beyond software. Any domain where you’re a confident consumer but a novice builder (cooking, writing, design, business operations) carries the same trap. The smoother and more invisible the experience is as a user, the more likely you are to catastrophically underestimate what it takes to create it. The next time you look at something and think, “That can’t be that hard,” treat it as a red flag. Your familiarity is lying to you. Dig deeper before you commit.