October 9, 2025/726 words/4 min read

The Expert's Blindspot

Why I reach for payment patterns as a habit.

I've spent many years in payments and fraud, long enough that most problems in my domain don't surprise me anymore. I can read a feature spec and feel where the risk sits before anyone's pointed it out. I can trace how a transaction will fail three steps before it does. This pattern recognition is the thing I'm most proud of professionally. It also fires whether I ask it to or not, which is why I don't fully trust it.

A few months ago I was helping out with my friend's side gig, Paymenter, an open source billing platform for hosting companies. One of their contributors was working through a checkout flow and I jumped straight into retry logic and idempotency. I was already asking what happens when a payment succeeds but the webhook fails, then designing for the full catastrophe.

Those failure modes matter in enterprise systems processing millions of transactions through dozens of payment processors and acquirers. It's the stuff I think about every day at Verifone. Paymenter is built for small hosting providers, many of whom run it themselves for a few hundred customers. My guardrails would have added weight to a checkout that needed to stay simple and fast.

Someone pointed out that a basic error message and a retry button would cover ninety-nine percent of real-world cases. Which is, of course, obvious. I knew that. I had reached for an enterprise payments answer before my brain caught up. By the time I noticed, I was solving a problem that didn't exist at that scale.

I keep bumping into this. When you've spent a long time in one domain, every new problem gets pattern-matched against that domain's logic before you're even conscious of doing it. The confidence doesn't adjust when the context changes, which is where it gets dangerous. You don't actively decide to apply your domain lens to everything. It becomes how you see. That's the trap! By the time I notice I'm forcing the pattern, it has already given me an answer I believe.

The other side is less comfortable to write about. I've been picking up more infrastructure work lately, partly out of curiosity and partly because my side projects need it. After years of being the person in the room who knows the answer, not knowing what I'm doing is genuinely disorienting. I'll be debugging a networking issue or trying to understand why a container isn't behaving the way I expect, and I can feel myself reaching for analogies from payments just to have something to hold onto. Sometimes the analogy helps. More often, I'm mapping familiar language onto an unfamiliar problem because it makes me feel less lost.

There's a specific discomfort in conversations where I can't contribute and have to listen, and I don't love it. I want to add something or connect the discussion to a thing I know. That connection usually serves me more than it serves the conversation. The most useful thing I can do is shut the hell up and let the gap stay open while smarter people speak.

Whether I'm applying a payment pattern too quickly or reaching for one in infrastructure because I feel lost, I'm filling the gap between what I think I see and what's actually there. I don't have a clean method for knowing which mode I'm in at any given moment. I'd like to say I pause and check, but most of the time the pattern has already fired before I even know there was a question.

I've started paying attention to the feeling of certainty itself, or at least trying to. When something feels obvious and the answer arrives before the question has fully formed, my domain patterns are usually doing the work. The answer may be right, but I can't assume it is. I usually find out after someone shows me where it fails to fit the problem in the room. It makes you feel like a fool.

I don't think there's a fix for this. Expertise is supposed to narrow, because that's what makes it useful. Being a beginner feels bad when you're learning something your existing patterns can't handle. I've spent almost a decade building intuitions I trust deeply, and the hardest skill I'm trying to develop now is knowing when not to trust them. It's not a skill I'm good at yet.