Nurturing a healthy culture around code reviews takes effort and maintenance. Some things I’ve found helpful:
a) Always use inclusive language (“we” or “us” instead of “you”)
b) Speak about the code, not the individual
c) Discuss why code review is valuable, not just from a code quality standpoint, but also as a key way in which teammates can learn from one another
d) Decide not to nitpick. If something is a personal preference and is a nit, don’t say it.
e) Automate away any parts of the process you can. Decision fatigue is a real thing and it saves everyone energy if the linter in CI catches an error so that the reviewer doesn’t have to think about it. Side benefit is that if anyone is annoyed by having an error pointed out, it’s directed at the robot rather than a team member :)
f) To this end, pay attention to the kinds of things you’re commenting about in reviews. Could this be enforced with a static analysis or formatting tool? Add that rule to your linting setup and never talk about it again! Is this a nitpick that really is only about personal preference and has no bearing on correctness, readability, or performance? Let it go!
Ultimately I think it comes down to building a culture of trust and respect, and getting everyone on the same page about why code review is important and what benefits you all get from it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nurturing a healthy culture around code reviews takes effort and maintenance. Some things I’ve found helpful:
a) Always use inclusive language (“we” or “us” instead of “you”)
b) Speak about the code, not the individual
c) Discuss why code review is valuable, not just from a code quality standpoint, but also as a key way in which teammates can learn from one another
d) Decide not to nitpick. If something is a personal preference and is a nit, don’t say it.
e) Automate away any parts of the process you can. Decision fatigue is a real thing and it saves everyone energy if the linter in CI catches an error so that the reviewer doesn’t have to think about it. Side benefit is that if anyone is annoyed by having an error pointed out, it’s directed at the robot rather than a team member :)
f) To this end, pay attention to the kinds of things you’re commenting about in reviews. Could this be enforced with a static analysis or formatting tool? Add that rule to your linting setup and never talk about it again! Is this a nitpick that really is only about personal preference and has no bearing on correctness, readability, or performance? Let it go!
Ultimately I think it comes down to building a culture of trust and respect, and getting everyone on the same page about why code review is important and what benefits you all get from it.