Fake It Till You Make It: What Confidence Actually Means for Developers

“Fake it till you make it” has a bad reputation in engineering circles because it sounds like lying. Like pretending you know things you don’t, taking on work you can’t deliver, bluffing your way through interviews.

That’s not what it means. Or at least, that’s not what the useful version of it means.

The version worth understanding is this: confidence in the unknown is a learned skill, and it’s built on a foundation of evidence from your past — not a fabrication about your present.

The Imposter Syndrome Trap #

Most developers experience imposter syndrome at some point. The feeling that you’re not as competent as the people around you think you are. That the job was a mistake. That you’re going to be found out.

Here’s the thing about imposter syndrome: it scales with capability. The developers who feel like imposters most acutely are often the most skilled, because they understand the problem space well enough to know how much they don’t know. The genuinely incompetent developer rarely has imposter syndrome — they’re too busy being confidently wrong.

The junior developer who thinks they understand everything is less self-aware than the senior developer who is constantly aware of the limits of their knowledge. Imposter syndrome, calibrated correctly, is actually a sign of intelligence. The problem is when it becomes paralyzing — when it prevents you from taking on challenges, claiming credit, or communicating with authority.

What “Fake It” Actually Means #

When experienced developers project confidence in unfamiliar territory — a new codebase, a technology they’ve never used, a system they’re on-call for after two weeks — they’re not lying about their capabilities.

They’re drawing on something real: a track record of figuring things out.

You have solved problems before that you didn’t know how to solve when you started. You have learned technologies you knew nothing about. You have debugged systems you didn’t build. You have figured out codebases that were foreign to you. Every single time you did that, you added to an evidence base that says: I can navigate the unknown.

That’s what the confidence is built on. Not fake knowledge. Genuine evidence of adaptive capability.

When a developer with fifteen years of experience walks into an unfamiliar problem and projects calm — it’s not bravado. It’s pattern recognition. They’ve been lost in the weeds before and they know, from experience, that they can find the way out. The surface uncertainty is real; the confidence that it’s navigable is also real.

Building This for Yourself #

If you’re earlier in your career and you don’t yet have the track record to draw on, here’s how to build it:

Catalog your wins deliberately. Most developers don’t keep any record of problems they’ve solved, systems they’ve built, situations they’ve navigated. This is a mistake. Start keeping notes — informal is fine. When you solve something hard, write it down. When you learn something from scratch and ship something with it, write it down. This becomes the evidence base you draw on when things get uncertain.

Reframe the unfamiliar. When you encounter something new, the instinct is to feel exposed — to think “I don’t know this.” The reframe is: “I don’t know this yet.” The second version is more accurate, because it accounts for your demonstrated ability to learn. You have already learned harder things than this. This is evidence.

Separate knowledge from capability. You can be capable of solving a problem without knowing the solution. Most engineering problems don’t require knowing the answer in advance — they require the ability to reason, research, and iterate. Those are durable skills that transfer to any new problem. They’re what you’re actually being hired for.

Communicate uncertainty without performing it. There’s a difference between saying “I don’t know” and saying “I don’t know this off the top of my head — here’s how I’d approach finding out.” The first closes the conversation. The second demonstrates capability while being honest. Practice the second.

The Competence Loop #

Confidence and competence are in a feedback loop. Genuine confidence — the kind that comes from a track record — leads to taking on harder problems, which builds more actual competence, which builds more genuine confidence.

Anxiety, by contrast, leads to avoiding the hard problems and staying in known territory. Which means the competence doesn’t grow. Which means the anxiety has less and less evidence to argue against. This is how a developer who was once sharp stagnates.

The way out of the loop is to take the next hard thing and trust that you’ll figure it out — not because you’re certain, but because you have done it before.

The Limit #

To be clear: there are things you should not fake. If you’re leading a team through a disaster and you are genuinely out of your depth in a dangerous way, say so and get the right people involved. If you’re being asked to architect something for which you lack foundational knowledge and the stakes are high, be honest about the gap and ask for what you need.

The version of confidence we’re describing is applied to the normal uncertainty of engineering work — the daily reality of encountering things you haven’t seen before and having to navigate them anyway. That uncertainty is not a red flag; it’s the job.

You’ve been here before. You found the way through. You’ll do it again.

That’s not fake. That’s experience.