Imposter Syndrome in Tech

This post is based on the talk It's Dangerous to Go Alone: Battling the Invisible Monsters in Tech, presented by Julie Pagano at PyCon 2014.

The talk is about something many people feel but few admit out loud: insecurity, anxiety, lack of confidence, and imposter syndrome in tech careers.

And maybe the first important thing is this:

it's not just about "feeling insecure sometimes".

Everyone goes through moments of doubt. Starting a new job, taking on a hard task, switching stacks, joining a more senior team, or sitting through a technical interview can shake anyone.

Imposter syndrome is different because it distorts the way you interpret your own competence.

What imposter syndrome is

Imposter syndrome is the difficulty of internalizing your own accomplishments.

You ship something good, but you think:

"it was luck"
"anyone else would do it better"
"I only made it because people helped me"
"sooner or later they'll figure out I'm not that good"

The problem is that software development already involves failure all the time.

We break things. We introduce bugs. We don't understand an abstraction. We miss estimates. We get stuck on simple problems. We need to ask for help. We go back to the docs. We delete code we just wrote.

That's normal.

But for someone trapped in imposter syndrome, failures look huge and wins look tiny.

You remember the bug you caused, but forget the bugs you fixed. You remember the question you couldn't answer, but ignore everything you studied to get there. You remember the critique in code review, but you don't absorb it when someone says your work was good.

As Julie puts it in the talk: wins shrink in importance and failures look enormous.

The real career impact

Imposter syndrome doesn't stay in your head. It changes behavior.

A lot of people stop sharing knowledge because they think they have nothing relevant to say. They don't write blog posts. They don't speak at events. They don't mentor. They don't comment in technical discussions. They don't open pull requests in open source projects.

Not because they lack the skill.

But because there's a constant fear of being exposed.

That fear shows up in common situations:

pair programming feels scary because someone will watch you think
code review feels like a personal verdict, not code improvement
interviews feel like impossible rituals
a new job opening always seems "above your level"
giving a talk or writing an article seems reserved for "people who are actually good"

One of the strongest moments in the talk is when Julie tells the story of wanting to work at Google but not applying because she didn't think she was good enough. She only moved forward because a recruiter insisted, talked to her, and helped her get past that barrier.

This matters because it shows an invisible cost:

the person doesn't fail because they tried and didn't make it; they fail earlier, because they never try.

The other side: over-compensating

Not everyone with imposter syndrome hides.

Some people do the opposite: they try to compensate for the insecurity by working harder than they should.

They read every book. Take on every project. Attend every event. Study at night. Work weekends. Try to stay perpetually up to date. They feel like they're always running to catch up with everyone else.

For a while, this can even look like productivity.

But it's not sustainable.

The usual outcome is burnout: prolonged exhaustion, loss of interest in the work, and sometimes the urge to quit everything.

That's a serious point. Untreated imposter syndrome can make a talented person stop enjoying programming.

Imposter syndrome is not the same as lack of competence

An important caveat: imposter syndrome doesn't mean every insecurity is unjustified.

Sometimes you really do need to study more. Sometimes your code does need to improve. Sometimes you really aren't ready for a specific responsibility.

That's part of the job.

The difference is that a healthy self-assessment can look at both strengths and weaknesses. Imposter syndrome breaks that balance.

You see your limits, but you don't see your progress.

Julie also compares this with the Dunning-Kruger effect: people with little skill who overestimate their own competence. It's interesting because both phenomena coexist in the industry.

On one side, qualified people not even trying because they don't think they're good enough.

On the other, underprepared people pushing into every space because they don't perceive their own limits.

For software engineering, knowing where you're strong and where you need help is a valuable skill. The problem is when that sense of limit turns into a prison.

Don't go alone

The title of the talk comes from a classic gaming line: "It's dangerous to go alone".

It's dangerous to go alone.

One of the central recommendations is to build a "party": a support group made of people you trust.

It's not a group of flatterers. It's not people telling you you're amazing all the time.

It's people who can do two things:

give you honest, constructive feedback
remind you of the facts when your perception is distorted

It can be someone on your team, a manager, friends in the industry, mentors, communities, or study peers.

The point is simple: if your internal competence meter is miscalibrated, you need more reliable external signals.

Measure progress

Another useful idea from the talk is to turn progress into something more concrete.

Asking "am I good?" usually triggers an emotional answer.

Asking "what have I improved over the last three months?" gets you a more observable one.

A few examples:

I fixed bugs I couldn't have fixed before
I shipped a feature end to end
I did my first code review
I explained a concept to someone
I wrote a technical post
I went through an interview
I contributed to a project
I asked for help earlier instead of being stuck for days

None of this needs to be grand.

Real progress almost always looks small while it's happening.

Train yourself to see the positives

For some people, recognizing the positives comes naturally.

For others, it needs practice.

A simple habit is to log small wins. Not to inflate your ego, but to build evidence.

Because on bad days, memory gets selective.

You can keep a list of things you've learned, problems you've solved, positive feedback you've received, and hard moments you got through.

That doesn't erase insecurity, but it lets you argue with it using data.

Watch out for toxic environments

Tech environments can reinforce imposter syndrome a lot.

Every community has people who use knowledge as a weapon. The person who corrects everything with contempt, looks shocked when someone doesn't know something, interrupts with "well, actually..." all the time, or turns any question into proof of inferiority.

Those people may even be smart.

But they are not a good data source about your worth.

At the same time, it's worth checking your own behavior. The talk mentions small practices that quietly wear down environments:

fake surprise: "how do you not know this?"
irrelevant corrections just to flex
backseat driving while someone else is coding
subtle comments steeped in sexism, racism, homophobia, or any form of exclusion

Reducing that kind of noise makes everyone's life better, especially for people already fighting their own insecurity.

Kill your heroes

One of the most interesting parts of the talk is the idea of "killing your heroes".

Not literally.

The idea is to stop treating senior people as magical beings who were born knowing everything.

When we look at a reference in the field, we usually see the final result: good talks, good code, books, projects, reputation.

We don't see the path: bad code, doubts, rejections, bugs, fear, practice, years of work.

Turning heroes into humans helps you see something more realistic:

they also started small.

They also messed up.

They also have insecurities.

And you don't have to become a copy of them to build a good career.

Help other people

A powerful way to fight imposter syndrome is to help people who are just starting out.

When you explain something to someone, you realize you know more than you thought. When you watch a beginner call themselves dumb for not understanding something basic, you might recognize the same pattern in yourself.

That builds empathy.

It also builds responsibility.

If you're a mentor, a teacher, a manager, or a reference for someone, the way you talk about yourself matters. Constant self-deprecation can look like humility, but it can also teach others to put themselves down.

Being honest about struggle is healthy.

Tearing yourself down all the time isn't.

Fake it until you make it, carefully

Julie brings up a common phrase from the people she interviewed for the talk: "fake it until you make it".

But there's an important distinction.

This is not about lying about technical skill. Don't put on your résumé what you don't know. Don't fake mastery of a critical technology. Don't take on responsibilities that put other people at risk.

Here, "fake it" means acting in spite of a lack of confidence.

Submitting the talk proposal even when you're scared.

Applying for the role even when you don't have 100% of the requirements.

Publishing the post even when you think it could be better.

Asking the question even when you're afraid it sounds basic.

Sometimes confidence shows up after action, not before.

The main point

Imposter syndrome thrives in silence.

When nobody talks about it, everyone thinks they're alone. Everyone assumes other people understood the docs on the first read. That other people code without getting stuck. That other people can explain architecture clearly all the time. That they're the only one improvising.

But tech is built by people.

People get tired, make mistakes, learn, forget, ask for help, and try again.

The goal isn't to eliminate every insecurity. A bit of doubt can even protect you from arrogance.

The goal is to stop insecurity from deciding the size of your career.

If you saw yourself in this post, the next step might be small:

talk to someone you trust, log your progress, ask for feedback, publish something simple, apply for that role, contribute to a project, or help someone who's just getting started.

You don't have to face the invisible monsters alone.