The purpose of code reviews are to catch mistakes made during the initial implementation phase and to improve the quality of the software. It also helps the younger developers in the team to improve and gain confidence.

There’s always that one developer that you always ask for reviews - the “easy approver”. This type of reviewer is easily pleased and approves code instantly. On the other hand there’s always that developer that you dread asking for a review - the virtually “impossible approver”. This developer will comment and fight you on everything. The implementation will usually take a third of the whole development time due to this long back and forth review.

In my experience neither of the two developers` code review approaches are constructive towards the developer under review or their code.

Code reviews can be helpful or destructive and toxic. This post summarizes the do’s and dont’s for a healthy software team environment as described in Unlearning Toxic Behaviors in a Code Review Culture by Sandya Sankarram.

The dont’s


  • don’t pass opinion off as fact

  • don’t overwhelm with avalanche of comments
    Don’t comment E.g extra space multiple times. This will pollute the review and come across as nitpicking.

  • don’t ask engineers to solve problems they didn’t cause “while they are at it”

  • don’t ask judgmental questions

Why didn’t you just do ___ here?”
  • don’t be sarcastic
Did you even test this code before you checked it in?

  • respond to every comment
    If you’re asking someone to review your code then its disrespectful to not reply to every comment. It will leave the reviewer thinking why did they even bother reviewing your code.

  • don’t ignore toxic behaviors from high performers

  • don’t make people feel bad that they “should already have known” this piece of info

The do’s


  • use questions or recommendations to drive dialog

  • collaborate, don’t back-seat drive
    In my experience and in our team we find it constructive to sit with the reviewer while he/she reviews your code. You open a dialog by doing this. The issues are addressed, discussed and resolved faster.

Comments can often be misinterpreted. Sitting together can also avoid that.

  • know when to take a discussion offline

  • use opportunities to teach and don’t show off

  • automate what can be
    E.g use a linter

  • refuse to normalize toxic behavior

  • set the standard as your team is small and growing

  • understand you might be part of the problem
    Don’t simply point out a bug, because you’ve managed to identify it. This mindset could lead to showing off.