Ask Dumb Questions Early

Because fixing it later costs way more than looking stupid now. You wrote the code. It works. The tests pass. Your PR is clean. Then someone says: “Oh… that’s not what we needed.” Now you’re rewriting a perfectly good feature to solve a problem that was never actually clarified. Not because you're bad at your job - but because you didn’t ask the question that felt too dumb to say out loud. You assumed you’d figure it out later. Now it is later. And here we are. 1. Ego in Disguise (and the Impostor Spiral) Sometimes you don’t ask because you think you should already know. Other times, you’re terrified everyone else already does. So you keep quiet - just in case speaking up confirms your worst fear: that you’re the only one not getting it. That’s impostor syndrome. Or, in senior engineering terms: Tuesday. This is how even smart engineers ship the wrong thing, perfectly. You’d rather look competent than be curious - right up until you’re reworking a week’s worth of code because no one clarified what the feature was actually supposed to do. The fix isn’t heroism. It’s humility. Ask the thing you’re second-guessing. Say the quiet question out loud. You’re not undermining your credibility - you’re protecting the project. 2. Psychological Bruising Maybe you did ask once - and someone made you regret it. A sigh in a meeting, a clipped response, a passive-aggressive “it’s in the doc.” Doesn’t take much to learn that asking is risky. So you stop. Over time, the questions go unasked. Ambiguity festers. People nod through planning and quietly panic in implementation. This is how trust erodes. Not through yelling - through silence. And it stays broken until someone speaks up first. If you’ve got any seniority, this is your job now. Ask early. Ask publicly. Ask the stuff you already know just to make it safe for someone else to admit they don’t. You’re not showing weakness - you’re removing friction. 3. Process-Driven Avoidance In fast-paced teams, asking questions can feel like being the one person still reading the instructions. So instead of clarifying, you dive in and hope you’re building what they meant - not just what they said. But when specs are vague and expectations are fuzzy, building fast only guarantees that you’ll build the wrong thing faster. So slow down. Just enough to get aligned. Add a “what’s still fuzzy?” checkpoint to planning. Make one awkward clarification part of the routine. You’re not derailing momentum. You’re stopping the train before it heads off a cliff. 4. Low Context, High Shame Halfway through the sprint, it hits you: you don’t actually understand how this fits into the bigger picture. You don’t know how the user gets here, what they’re trying to do, or what success actually looks like. But instead of asking, you keep going. You tell yourself you’ll backfill the context later. Spoiler: you won’t. This is where context gaps quietly become team-wide blockers. A feature gets halfway built, then someone asks a question that should’ve come up two weeks earlier — and now you’re rewriting, rescoping, and wasting everyone’s time. I wrote about this in Your Code Isn’t the Problem. Your Context Is. — how engineers quietly build the wrong thing because they never learned how the system actually works. You don’t need to become a domain expert. But you do need to stop pretending you already are. Ask what the user is trying to do. Ask when and why it happens. Ask what came before. That’s not “extra.” That’s the work. 5. Cognitive Laziness Sometimes the reason you didn’t ask… is because you didn’t feel like it. You figured it would sort itself out. That if something didn’t make sense, someone else would bring it up. That silence meant consensus, not confusion. That’s not collaboration - that’s entropy with a friendly face. If something’s unclear, and you noticed it, it’s your job to say something. Yes, you might be wrong. Yes, someone might roll their eyes. But they won’t be the one rewriting it later. You will. Questions Build Systems Code doesn’t prevent wasted effort. Questions do. Every time you ask early, you shrink the problem before it grows teeth. You prevent rework, not just for yourself, but for everyone waiting downstream. You surface assumptions before they calcify into bugs. You make it safer for the next person to speak up. You make the system better. The dumb question you ask now is the rewrite you don’t have to make later. And the engineer who asks anyway? That’s the one people want in the room next time. So ask. Especially when it feels dumb. Because nothing’s dumber than building the wrong thing really well.

Apr 17, 2025 - 19:28

Because fixing it later costs way more than looking stupid now.

You wrote the code. It works. The tests pass. Your PR is clean.

Then someone says:

“Oh… that’s not what we needed.”

Now you’re rewriting a perfectly good feature to solve a problem that was never actually clarified.
Not because you're bad at your job - but because you didn’t ask the question that felt too dumb to say out loud.

You assumed you’d figure it out later.

Now it is later.

And here we are.

1. Ego in Disguise (and the Impostor Spiral)

Sometimes you don’t ask because you think you should already know. Other times, you’re terrified everyone else already does. So you keep quiet - just in case speaking up confirms your worst fear: that you’re the only one not getting it.

That’s impostor syndrome. Or, in senior engineering terms: Tuesday.

This is how even smart engineers ship the wrong thing, perfectly. You’d rather look competent than be curious - right up until you’re reworking a week’s worth of code because no one clarified what the feature was actually supposed to do.

The fix isn’t heroism. It’s humility. Ask the thing you’re second-guessing. Say the quiet question out loud. You’re not undermining your credibility - you’re protecting the project.

2. Psychological Bruising

Maybe you did ask once - and someone made you regret it. A sigh in a meeting, a clipped response, a passive-aggressive “it’s in the doc.” Doesn’t take much to learn that asking is risky. So you stop.

Over time, the questions go unasked. Ambiguity festers. People nod through planning and quietly panic in implementation.

This is how trust erodes. Not through yelling - through silence. And it stays broken until someone speaks up first.

If you’ve got any seniority, this is your job now. Ask early. Ask publicly. Ask the stuff you already know just to make it safe for someone else to admit they don’t. You’re not showing weakness - you’re removing friction.

3. Process-Driven Avoidance

In fast-paced teams, asking questions can feel like being the one person still reading the instructions. So instead of clarifying, you dive in and hope you’re building what they meant - not just what they said.

But when specs are vague and expectations are fuzzy, building fast only guarantees that you’ll build the wrong thing faster.

So slow down. Just enough to get aligned. Add a “what’s still fuzzy?” checkpoint to planning. Make one awkward clarification part of the routine. You’re not derailing momentum. You’re stopping the train before it heads off a cliff.

4. Low Context, High Shame

Halfway through the sprint, it hits you: you don’t actually understand how this fits into the bigger picture. You don’t know how the user gets here, what they’re trying to do, or what success actually looks like.

But instead of asking, you keep going. You tell yourself you’ll backfill the context later. Spoiler: you won’t.

This is where context gaps quietly become team-wide blockers. A feature gets halfway built, then someone asks a question that should’ve come up two weeks earlier — and now you’re rewriting, rescoping, and wasting everyone’s time.

I wrote about this in Your Code Isn’t the Problem. Your Context Is. — how engineers quietly build the wrong thing because they never learned how the system actually works.

You don’t need to become a domain expert. But you do need to stop pretending you already are. Ask what the user is trying to do. Ask when and why it happens. Ask what came before. That’s not “extra.” That’s the work.

5. Cognitive Laziness

Sometimes the reason you didn’t ask… is because you didn’t feel like it.

You figured it would sort itself out.
That if something didn’t make sense, someone else would bring it up. That silence meant consensus, not confusion.

That’s not collaboration - that’s entropy with a friendly face.

If something’s unclear, and you noticed it, it’s your job to say something. Yes, you might be wrong.
Yes, someone might roll their eyes. But they won’t be the one rewriting it later. You will.

Questions Build Systems

Code doesn’t prevent wasted effort. Questions do.

Every time you ask early, you shrink the problem before it grows teeth.
You prevent rework, not just for yourself, but for everyone waiting downstream. You surface assumptions before they calcify into bugs. You make it safer for the next person to speak up. You make the system better.

The dumb question you ask now is the rewrite you don’t have to make later.
And the engineer who asks anyway? That’s the one people want in the room next time.

So ask. Especially when it feels dumb.
Because nothing’s dumber than building the wrong thing really well.