Have you ever worked with a developer that gets defensive whenever their merge requests get code reviewed? Perhaps they find your comments 'too nitpicky', that you are 'micromanaging' their work, or simply 'slowing them down from shipping'.
Maybe it's even gotten to a point that your comments are being read differently than intended? We all know sarcasm is impossible to detect on the internet, here I purpose Shimin's corollary: "To the reader, all potentially condescending texts on the internet are read as condescension."
Therefore, your
'Maybe we should move the event handler down to the component level so as to not pollute the larger namespace.'
becomes
'Why are you polluting the namespace?'
And the innocuously intended
'Did you intend to have all this seemly unrelated code in the MR.'
is read as
'Did you mean add all this unrelated code on purpose or are you too careless to even notice them?'
Even when we all know that code reviews are wonderful at improving our craft and getting the discussion rolling, sometimes it still feels like I'm tiptoeing when trying to come up with the least offensive sounding phrasing of code review comments. This can especially be a problem if the person whose code is under review suffers from imposter syndrome and take negative reviews especially badly.
My solution to the 'condescending MR comments' problem is quite simple, after finishing a round of code reviews, ping the reviewee in your favorite chat program and offer to have a real-time discussion about the comments. It's even better if you are working in the same office and can discuss the issues in person.
By offering to have a real-time technical discussion, you are reframing the code review process away from an 'instructor correcting student' dynamic and into a 'colleagues working together' mindset. Of course, the offer is always genuine and it provides a jumping-off point to build rapport with the other developer and often leads to a whiteboarding / pair-programming session to come up with designs that both people are happy with. Ideally, the results of the discussion will be agreed upon by the team and recorded in the team's style guide or knowledge bank for future references as well.
Thanks for reading! If you enjoyed this post, I think you would also find my post on how to use a code review comment hierarchy to speed up the delivery process helpful.
Happy Coding!