Imposter Syndrome: How to overcome it during Code Reviews

The articles in this series about being an effective code reviewer have be leading to this final article on imposter syndrome. Sending your code for review or reviewing the code of a colleague can be intimidating and stress inducing. Often you feel as though, I am not qualified to do this?! In particular, when team members haven’t been working together for a long time and a senior developer asks you to review their code…. Who am I to give them advice? I’m not good enough to do this Code Review.

Stop right there, you are good enough!! In fact you may be the perfect person to do this review, specifically because you have different experience than the author of the code. The feeling you are having is imposter syndrome. Everyone experiences it and it is normal. Twenty years into my career, I still experience this.

What is imposter syndrome?

Impostor syndrome (also known as impostor phenomenon, impostorism, fraud syndrome or the impostor experience) is a psychological pattern in which one doubts one’s accomplishments and has a persistent internalized fear of being exposed as a “fraud”.- wikipedia

It is important to recognize imposter syndrome and ensure you have a culture and leadership that provides the tools to overcome it. Psychological safety has been shown to be a #1 key factor to a successful team. When team members feel safe to take risks and are not scared of embarrassment during collaboration and exchange, ideas can quickly flourish.

Therefore, it is critical to build a culture where people feel safe to ask questions, share what they do not know, and share ideas when they disagree.

Some common problems:

• I do not understand the code and I am afraid to ask for clarification
• I am less senior and do not want to disagree with more senior people

Here are some tips to overcome imposter syndrome and contribute to the team:

1. Imposter syndrome never goes away!! Developers with years of experience still experience it. There is always more to learn
2. Everyone has something to add to a code review regardless of their experience. A fresh second set of eyes always has something to offer regardless of your level of experience.
3. Look at this as a way to learn as well as review.
4. Establish a specialty. i.e. I am the “go-to” person for _____ type of code reviews or _____ area of the code. It is also good to align this with your career goals.
5. Look at the review until you find a way to improve the code or find an edge case.
6. Compliment the person who wrote the code when it teaches you something. This will help create a relationship and may break barriers for the next time.
7. Pair with someone who you know does great code reviews so you can learn their technique.

In addition, code reviews are an opportunity to encourage healthy communication on the team. There are many, many, many concrete tips on communicating in a constructive way which feels inclusive and where people do not feel judged. Here are a few tips for authors and reviewers of a code review:

• Assume good faith and competence
• Avoid selective ownership of code. (“mine”, “not mine”, “yours”) The review is of the code, not the author. Favor the use of “we”. Instead of “you should use a constant here“, frame it as “Here it seems we need a constant because this value”
• Asking questions instead of making demands. Instead of “rename to user_id”, use “what do you think of naming this user_id?
• Be humble and assume the best of the author. Instead of “Why didn’t you use X here?”, use “Have you considered using X ? because …”.
• A comment can simply be a question asking for clarification. “I am not sure why this has an impact on latency, could you add more details?” It is important to make it specific and not be too general.
• Positive Reinforcement: it is important for both authors and reviewers to thank each other. Small notes such as “Good catch, thanks. Fixed” or “Thanks for the rework, this looks really good.”

Finally, if you are a team lead, it is crucial to reward good reviewers and acknowledge their contributions. Do not forget to use this criteria when evaluating people. You can also reinforce it in your 1:1 or team meetings when some work really benefited from a code review. A good code review can catch a bug early and/or prevented lots of technical debt.

For further reading on Imposter Syndrome check out Yes! You are good enough by Trish Taylor

This article is a series on how to be an effective code reviewer. Please see my previous article that provides background on Code Reviews and Their Benefits. Other articles in the series are:

4 Rules of Thumb for Providing Effective Code Review Feedback

How to Provide Effective Feedback based on Code Review Type

Inclusive and Productive Collaboration in Code Reviews

Thank you to Alice Bonhomme-Biais, co-author of this article. We originally presented the content at Grace Hopper 2020 as a part of a presentation on “Finding your Voice as a Code Reviewer”