thumbs up by @sincerelymedia on Unsplash

You don't get told enough that you're going great

Aug 25th, 2023

Share on TwitterShare on LinkedInShare on RedditShare on Facebook

Ever feel like an impostor waiting to be exposed as a fraud? Software engineers face this all too often due to the nature of our work, and through my experience this is present in all levels, but mostly in juniors. I'm convinced that you and most people are actually killing it, but impostor syndrome won't let you see that. Let's go into some details on what it is and how to avoid it in the workplace.

Impostor syndrome

Impostor syndrome is a type of self doubt over one's skills mixed with anxiety that you'll eventually be found out as a fraud. It is a far richer subject than this post can illuminate, but it is far more prevalent and problematic than we talk about in software engineering.

Aren't performance reviews enough?

For some people they can be, but let me tell you a story of how they aren't.

Some time ago, my team was pressured to release. We had all of our work done a hair before the deadline with only one more change to merge in. The engineer working on it (let's call her Abby for anonymity) was having some simple computer problems slowing down the progress. With some help and encouragement, we merged in the last change and were ready to ship 🚀.

Abby communicated distaste for some of the messages sent by the team when helping. Seeing only positive ones, I offered to listen to her side as to understand her perspective.

Abby was near tears when explaining how bad she felt that she was holding up the release and in the high anxiety of the moment, she saw the messages not in the light of us trying to help, but as pins and needles shining light on how she was having issues. Seeing there was more behind this I asked if there was anything that led up to her feelings today. That's when I found the root cause - months of impostor syndrome just waiting for a spark to ignite it.

Our team, like most other teams, has a culture of critique. Most engineer output was under constant, rigorous scrutiny. Praise was rationed only for big efforts, rarely to juniors consequently. Abby being newer to the field experienced her self confidence erode under the barrage of critique. As the confidence plummeted, more things were interpreted through the lens of inadequacy, even the team's comments to comfort her. After prolonged erosion, Abby was unsure if she did anything right.

If you believe performance reviews should be enough, what would you tell Abby when she receives daily feedback telling her she needs fix her pull request again?

Just a junior problem?

This problem I see far more often in juniors as critique culture takes time to adjust too. I'd go so far as to say the vast majority of engineers experienced this ordeal when cutting their teeth on their first work laptop, but is this just a problem only for new engineers?

Impostor syndrome doesn't discriminate. Because more experienced engineers already do junior work well, impostor syndrome doesn't strike there. The confidence eating virus feeds off of insecurities about the more advanced tasks they do like mentorship, architecture designs, and requirement gathering.

Let me list out a few questions brewed in the minds of infected seniors.

  • Is my output high enough?
  • Am I leading my team off a cliff with the architecture I designed?
  • Did I miss any requirements?
  • Why am I being misunderstood? Is something wrong with me?
  • Would the team move faster if they had someone else in my position?
  • Was my critique too harsh or too much?
  • Did I need to block on that?

No one is safe. All levels of all jobs are vulnerable. I felt this personally when learning how to write documents in Amazon's culture. It was like being a junior all over again. Instead of code reviews, it was document reviews. Instead of missing tests, it was missing context. Instead of poor separation of concerns, it was poor formatting/flow. You get the point. It was crushing and I left work every day thinking I was stupid beyond hope.


If you feel I've described your 9-5, I've found a few things that help.

Seek balanced feedback

Critique culture makes it easy to hyper focus on the bad making it appear as if the bad is all that exists. Don't be afraid to ask others what you've done well, even if you failed. I call this "seeking partial credit". I personally prefer to ask one or two people in private message to point out things I did well as to help focus my self improvement on my weakest areas first.

Finding a mentor who gives partial credit or communicating your desire for it to the mentors you already have is also effective. In my experience, most people want to be helpful so don't be afraid to ask for what you need.

Understand expectations

The first aspect to understand is what good output at your level actually looks like. It is easy to expect perfection or rejection in our job, but often good enough™️ is exactly that. Mistakes are ok especially for new folk and if you aren't failing every once in a while, you're not learning. Even at Amazon one of our leadership principles is "Are right, a lot", not "Are right, always".

The second aspect is to grow comfortable with critique; neither will it ever go away nor would you want it to. Critique culture exists in part as a pedagogical technique designed to help you improve. See critique not as disappointment, but as care to see you become the best you can be. Also, getting good at a skill takes time and that's ok.

The curse of knowledge

The Curse of Knowledge is a very real phenomenon that describes how experts often forget what things are like from the perspective of someone trying to learn. To them they see a clear path from problem to solution, but what new people don't know is the yak shaving in between that causes them to get confused and make mistakes. If you're running into many surprises when doing tasks that others find simple, the problem probably isn't you, it's likely poor process documentation or knowledge dissemination.

To combat this, seek to get a full description from problem to solution from someone who has been down that journey a few times to tell you where the land mines and booby traps are. Finding a mentor aware of this bias is also very helpful.

Seek professional help if needed

Impostor syndrome might be an ugly symptom of something deeper. Don't be afraid to get professional help if what you experience is serious. Personally I struggled with anxiety and depression for a long time leading to tons of problems. Having someone to help you through recovery is a blessing from God. Your company might even have mental health resources for you to take advantage of.

Preventative measures

If you feel I've described the 9-5 of people you work with, I've found a few things that help.

Say something

The "silence is approval" policy some people have is hard on newcomers. It's the very thing that fuels the problem. Even though it makes your burden easier, ditch it. Make efforts to say positive things about other people and their work. It doesn't have to be massive or passionate. Something simple like "Good catch", "Thanks for refactoring", or "I like your design" are good enough. Try to make the small things somewhat regular. I try to leave at least one positive comment on every code review I do, and always carve out time in mentorship to discuss positives.

Start them off right

If you have people you manage, mentor, or lead, frame expectations properly by being clear on what good work looks like at their level. If you expect someone to "just know" how to do a good job without checking they have the right mindset and resources to do so, you will be setting them up for failure on top of giving that person a sense of feeling too stupid to figure it out themselves. Stay ahead of the curse by doing tasks like theirs every once in a while and ensure good documentation on processes and expectations. Update them whenever their proven stale.

Ensure learning after failure

If someone fails and you have the right relationship to correct, don't just vomit the critique then leave; ensure that it was understood properly and that they can reconstruct the correct solution if they do it again. For juniors this might be coding a design pattern with them whereas for seniors this might be to reformat an architecture document. The person who failed likely already feels at least a little embarrassed, so they might feign comprehension to please you. If you don't ensure comprehension, you'll make their feeling stupid worse when they screw it up again.

Also, make sure they have the right materials to improve. If they're having a problem with git I like to point them to Learn Git Branching and offer to sit down with them if they need help. If they're having a problem with document writing, give them a few well written examples and offer to deconstruct what makes them good. Some people only need the resources, but others need mentorship so be discerning when helping people learn.

Be honest and realistic

I once worked with a junior that thought I was the best coder on earth, but it was only because I was the first one he met who made a point of writing clean code and reading tech articles. I considered much of his feedback to be out of balance as I had plenty to improve on. Similarly, if you provide feedback, ensure that you aren't being overly positive. Be honest and realistic. It helps to discuss both the good and the bad when giving feedback. Giving partial credit communicates well that you're trying to be balanced.


Feelings of inadequacy and impostor syndrome are very common in software engineering. Making sure praise, proper expectations, and adequate help are present in your team go a long way with combating the problem.

Also, you're doing great; keep up the good work 👍🏼🙂. You deserve to hear that.

Subscribe to receive more like this in your inbox.

No spam ever.

You can also support me and my tea addition 🤗🍵.

Buy me a tea

Or share with othersShare on TwitterShare on LinkedInShare on RedditShare on Facebook