Why Should Developers Say I Don't Know More Often? The Counter-Intuitive Path to Professional Growth

Mar 26, 2026

The Problem

I used to think admitting ignorance was a weakness. In my early years as a developer, I’d nod along in architecture discussions, pretending to understand every acronym and framework reference. I’d say “I’ll look into that” without any real plan to follow up. I’d fake confidence because I believed that’s what senior developers did.

Then I watched a principal engineer—the most respected person on our team—say “I don’t know” in a meeting with our CTO. Not tentatively. Not apologetically. Just straightforwardly: “I don’t know the answer to that. Let me research it and get back to you by tomorrow.”

The CTO nodded. The meeting continued. No one thought less of him.

That moment changed how I approached uncertainty in my career. The problem isn’t not knowing things—it’s pretending to know when you don’t.

Why Fake Confidence Destroys Teams

Software development culture often conflates expertise with omniscience. I’ve seen this create several toxic patterns:

Impostor Syndrome Reinforcement: When everyone around you seems to know everything, you feel inadequate for not knowing. I spent years thinking I was falling behind because I didn’t understand every framework mentioned in meetings.

Technical Debt Accumulation: I’ve watched developers confidently choose databases or architectures they didn’t fully understand, creating problems discovered months later when the team had to untangle bad decisions.

Knowledge Silos: Team members pretend to understand rather than asking clarifying questions. I’ve been in code reviews where someone said “LGTM” without understanding the implementation, letting bugs ship to production.

Trust Erosion: When fake confidence inevitably fails, credibility is permanently damaged. I’ve seen senior engineers lose all influence after their “I’m sure this will work” approach led to a major outage.

From a Reddit discussion on r/ExperiencedDevs:

“I hate this fake confidence that some people show just to save their ego. JUST SAY YOU DONT KNOW”

This comment resonated with 23 upvotes. The frustration is real and widespread.

Strategic Vulnerability: The Right Way to Say “I Don’t Know”

Admitting ignorance isn’t weakness—it’s strategic professional behavior. The key is how you phrase it.

The Right Phrase Pattern

I’ve learned these phrases work effectively:

“I don’t know, but I’ll investigate and get back to you by [timeframe]”
“I’m not certain about that specific aspect. Let me research it.”
“That’s outside my expertise area. I’d suggest consulting [person/resource].”

Notice each phrase includes a follow-up plan. The admission of uncertainty is paired with a commitment to action.

When to Use It

I use “I don’t know” when:

I genuinely lack knowledge (obvious but essential)
I’m uncertain about edge cases or recent changes
Someone asks about a technology I haven’t used recently
Decisions have significant impact and I need more information

When NOT to Use It

I avoid saying it when:

It’s about core responsibilities I should know
I’ve said it multiple times about the same topic (shows lack of learning)
I have no follow-up plan or timeframe

The Trust Architecture

Here’s the paradox I discovered: People who occasionally admit ignorance are trusted more when they express confidence, not less.

The Credibility Paradox

When I admit uncertainty about small things, my certainty about big things carries more weight. If I say “I don’t know” about 20% of questions, my “I’m confident this is the right approach” for the remaining 80% means something.

The opposite is also true. When someone always has an answer, I start discounting everything they say. Their confidence becomes noise.

Research Backs This Up

Google’s Project Aristotle found that teams with leaders who model vulnerability have:

27% higher performance
More frequent knowledge sharing
Faster error detection and correction
Higher retention rates among senior engineers

Psychological safety—the belief that you won’t be punished for mistakes or ignorance—correlates directly with team effectiveness.

The Trust Bank Account Model

I think of credibility like a bank account:

Every admission of uncertainty deposits credibility
Every time my “I’ll figure it out” delivers results, compound interest
Fake confidence is a withdrawal that can bankrupt trust instantly

When I tell stakeholders “I don’t know yet, but I’ll find out by EOD,” and then deliver, I’m building trust. When I fake confidence and fail, I’m making a withdrawal that takes months to recover from.

Common Mistakes I See

Mistake 1: Over-apologizing

"I'm so sorry, I feel stupid, but I don't know this. I should probably know this by now..."

This undermines your credibility. You’re not sorry for not knowing—you’re just stating a fact.

"I don't know that. Let me look into it."

Confident, direct, action-oriented.

Mistake 2: No Follow-through

"I don't know." (conversation ends, nothing happens)

This is laziness disguised as honesty.

"I don't know. I'll research it and share findings by tomorrow's standup."

Specific commitment with a deadline.

Mistake 3: Using It as an Escape Hatch

Saying “I don’t know” repeatedly about the same topics shows you’re not learning. I’ve worked with developers who used it as a shield to avoid deepening their expertise. After the third “I don’t know” about the same concept, colleagues start to notice.

Mistake 4: Wrong Audience

In a high-stakes client presentation:
"That? I have no idea. Never seen it before."

This undermines your team’s credibility with the client.

"That's an excellent question. I want to give you accurate information, so let me verify and follow up with you directly after this meeting."

Professional acknowledgment of uncertainty while maintaining confidence.

Real-World Scenarios

Architecture Discussion

Person A: "Should we use PostgreSQL or MongoDB for this use case?"
Developer: "MongoDB is better for everything. Let's use that."
Result: Wrong choice made, performance issues discovered months later

Person A: "Should we use PostgreSQL or MongoDB for this use case?"
Developer: "I don't know the specific trade-offs for your access patterns.
          What are the query patterns and consistency requirements?
          I can research and provide a comparison by EOD."
Result: Informed decision, documented rationale, shared learning

I’ve seen the fake confidence approach lead to months of pain. The honest approach takes a day longer upfront but saves weeks of rework.

Code Review

Reviewer: "LGTM" (doesn't understand the algorithm)
Result: Bug ships to production

Reviewer: "I don't fully understand the caching strategy in lines 45-67.
         Can you walk me through it? I want to make sure I'm not
         missing edge cases."
Result: Knowledge transfer, potential bugs caught, better code

I’ve started asking “I don’t understand this part” in code reviews. The result? Better code, better learning, and more respect from my peers—not less.

Sprint Planning

Team Lead: "Can we deliver the auth refactor in this sprint?"
Developer: "I don't know yet. The scope seems large and I'm unfamiliar
          with the legacy OAuth implementation. I need a half-day to
          spike it and give you a realistic estimate."

Follow-up (within stated timeframe):
Developer: "After investigation: 5 days estimated. Legacy OAuth has
          circular dependencies. Here's the breakdown..."

This pattern—uncertainty followed by investigation and concrete results—has made me more reliable, not less.

Why This Matters Long-Term

Saying “I don’t know” strategically—with commitment to follow-up—has transformed my career in three ways:

Faster Learning: When I stop pretending to know, I start actually learning. I ask questions I used to be afraid to ask. I take time to research things I used to fake my way through.

Better Estimates: My sprint estimates are more accurate because I’m honest about uncertainty. I don’t commit to timelines I can’t meet.

Stronger Relationships: Teammates trust me more because they know when I say I’m confident, I mean it. I’m not crying wolf with constant certainty.

The original poster from the Reddit discussion said it well:

“As much as it’s hard for my ego, saying ‘I don’t know, but I will figure it out’ is a very common phrase in my daily work. It can’t be too frequent, of course, or your colleagues might think you’re incompetent, but we can’t know everything.”

The balance is key: honest uncertainty paired with reliable follow-through. Not every question needs “I don’t know,” but every genuine uncertainty deserves honesty.

Final Thoughts

In this post, I explained how saying “I don’t know” strategically—with commitment to follow-up—transforms perceived weakness into a professional superpower that builds trust, prevents costly mistakes, and accelerates learning.

The counter-intuitive truth: admitting uncertainty makes you more credible, not less. The developers I respect most are the ones who confidently say “I don’t know” when they don’t, and deliver when they say they will.

Start today. In your next technical discussion, when you don’t know something, say so. Add a timeframe for follow-up. Then deliver. Your career will be better for it.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit Discussion on Developer Productivity
👨‍💻 Google Project Aristotle - Psychological Safety
👨‍💻 Impostor Syndrome in Tech

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!