Code reviews improve software by putting human-written code in front of human eyes. Reviews help developers learn best design patterns and coding practices, while also catching bugs that may not be identified by automatic testing. However, it is important to highlight that toxic behaviors during code reviews can be more unproductive than no code reviews at all, because these behaviors stifle the qualities developers need the most: creativity and innovativeness.

Some examples of toxic code review behaviors include:

● Passing one’s programming opinions off as fact (“This should be a lambda function
instead because I like lambda functions”)
● Asking judgmental questions (“Why didn’t you JUST do ___?”)
● Making demands without allowing a discussion (“Use ___ instead of what you did”)
● Sarcasm (“Did you even test this code before you checked it in?”)
● Using emojis instead of words to point out problems in code, which can be easily
misconstrued
● Using code reviews as an opportunity to show off how clever one is

This toxicity can make team members feel uncomfortable, gaslit, silenced, and bullied. It creates an unsupportive environment and discourages risk-taking and innovation in an industry that could never survive without it.

Let’s look at several mechanisms that people can use to help themselves and others unlearn toxic behaviors by refusing to normalize the toxicity. I will speak about how people can drive change from whatever position they may be in: individual contributor, manager, or HR. Ending this toxic culture helps make tech an environment where developers are allowed to learn, grow, and make mistakes.