The Seduction of Being Sure
“In engineering, ‘feels right’ is not the same as ‘is right.’”
Most engineering mistakes don’t stem from a lack of skill they come from acting too quickly on what feels certain.The first idea often seems the most appealing: it’s familiar, proven, and quick to implement. And when time is tight or expectations are high, that sense of familiarity can be dangerously comforting.
But intuition isn’t always insight. What feels obvious is often just a pattern we’ve repeated enough times to stop questioning. And the real danger isn’t choosing the wrong approach it’s assuming there wasn’t another one worth exploring.
When no one questions a decision, it’s rarely because it’s perfect. More often, it’s because someone’s confidence is carrying too much weight and the room doesn’t feel safe pushing back. That’s how comfort masquerades as logic. That’s how poor decisions get framed as fast ones.
We skip the hypothesis. We assume alignment. We commit.
But here’s the truth:
You don’t have to be wrong for it to still be the wrong decision.
When “Obvious” Becomes Unquestioned
“The more senior you are, the easier it is to get away with bad ideas said confidently.”
I’ve seen this dynamic way too many times especially among senior engineers and tech leads. Someone proposes a solution in a confident tone. They drop a buzzword. A familiar pattern. Maybe even reference past success. And everyone in the room relaxes.
Seniority doesn’t mean your ideas need fewer checks it means you should invite more. The higher up you go, the more your words carry weight even when they shouldn’t. And if you’re not careful, your team stops pushing back. That’s how bad architecture gets blessed with a shrug.
This isn’t imposter syndrome. It’s a leadership responsibility. A confident voice without curiosity isn’t a sign of strength it’s a louder failure waiting to happen.
The Quiet Cost of Skipped Conversations
“Silence isn’t alignment—it’s deferred regret.”
You don’t notice it right away. There’s no incident report, no heated debate, no flashing red sign that something’s gone wrong. But the signals were there all along subtle, quiet, and easy to dismiss. The stand-up where no one asked, “Have we validated this?” The Slack thread that drifted into silence before anyone offered pushback. The RFC that sailed through with a single enthusiastic thumbs-up—because it came from someone senior.
In the moment, that quiet feels like progress. No resistance. No blockers. Just momentum. But that absence of friction isn’t alignment it’s a blind spot forming.
Eventually, the costs reveal themselves. The bug reports roll in. The feature under-performs under load. The onboarding flow breaks for edge cases no one had considered. And suddenly, the decision that once felt obvious—or at least uncontroversial—turns into a tech debt ticket, a late-night fix, or an awkward postmortem.
When critique is skipped, consequences aren’t avoided. They’re simply delayed. And by the time they surface, the team has already moved on leaving someone to clean up clarity that should’ve come earlier.
Your Certainty Is in the Code
“Every line of code is a bet. Certainty just hides the fact you didn’t test the odds.”
Certainty isn’t just a mindset it shows up in the code.
tsCopyEdit
const Memoized = React.memo(MyComponent);
We don’t just think in defaults we code them in. We reach for memo, useCallback, extra abstractions, premature patterns. Not because we’ve validated the need, but because they feel right. Because they look like smart engineering. Because they signal experience.
But often, what they really signal is untested conviction.
It’s not optimisation it’s assumption dressed as certainty.
“I’ve done this before” isn’t a justification. It’s a warning. What worked in one context can quietly rot in another. And when those assumptions go unchallenged, they calcify into technical debt not because the logic was wrong, but because the logic was never questioned.
Every abstraction, every pattern, every decision you ship is a bet.
Smart engineers don’t bet less.
They just know when to check the odds.
Strong Engineers Need Correction, Not Validation
“Being right is a flex. Being corrected early is a skill.”
This is the shift that took me years to internalise and even longer to practice.
A senior engineer’s job isn’t to have the final answer.
It’s to surface their thinking early enough that it can still be questioned.
That means framing every idea as a hypothesis, not a conclusion.
It means actively opening the door to critique not performatively, but with genuine curiosity. It means building habits around feedback, not just receiving it, but inviting it before code gets written or consensus calcifies.
You start asking things like:
“What’s the dumbest assumption I’ve made here?”
“What am I not seeing?”
“Can someone rip this apart before we build it?”
And more importantly—you actually want the answers.
You don’t flinch when they come. You revise. You adapt. And you keep going.
Because strong engineers aren’t the ones who are always right.
They’re the ones who get it less wrong, sooner.
Build Teams That Disagree Well
“Disagreement isn’t dysfunction. It’s design feedback—early, cheap, and essential.”
Avoiding the trap of false certainty isn’t just a personal practice it’s a team sport. It requires a culture where disagreement isn’t a sign of conflict, but a sign of care. That culture doesn’t emerge by accident. You have to design it.
Start by making intellectual humility normal. Encourage engineers to say, “I might be wrong,” during sprint planning not as a caveat, but as an invitation. In design reviews, go beyond green checks; actively ask for counterarguments. In architecture meetings, assign someone the role of skeptic not to slow things down, but to illuminate what might otherwise be missed.
Just as importantly, celebrate revisions. Normalise changing your mind. Treat updated decisions not as backtracking, but as a healthy response to new input a sign that the process is working.
The best engineers I’ve worked with aren’t the ones who rush to answers. They’re the ones who slow down when it matters, open the floor to critique, and revise with clarity and intent. They treat friction as a signal, not a nuisance. They see disagreement as design input. And they hold confidence lightly—testing it the way they'd test any other assumption.
Because in the best teams, good ideas don’t win by being loud.
They win by surviving the teardown.
Conclusion: Certainty Needs to Be Earned
“Confidence without curiosity isn’t leadership. It’s a blind spot.”
Certainty is seductive. It offers speed, authority, and the comforting illusion of control. But in engineering, the ideas that go unchallenged are often the ones that go unchecked and unchecked assumptions are what break systems in ways no test suite can catch.
The most dangerous decisions aren’t the ones that are wrong.
They’re the ones made in rooms where no one speaks up.
Outages, regressions, creeping tech debt they rarely arrive with a bang. They show up slowly, wrapped in the quiet of unasked questions and untested convictions.
So when an idea feels “obvious,” stop.
Not to second-guess yourself but to invite the friction.
Ask: “What am I missing?” “Where could this break?”
Make it a habit. Make it a culture.
Because the strongest leaders don’t seek validation.
They design teams that correct them early and celebrate it.
They don’t cling to certainty.
They earn it.
