Very interesting and I completely agree with that.
I would just add, from personal experience, the case that the discussion between developer and reviewer(s) goes over and over: in this case I found that the only way to solve this is to speak (phone call or personally) and leave the online tools. Most people are much more "soft" by person than behind a monitor
that is very true. we are much better in overcoming differences when we talk face to face. If you cannot come to a common ground it also helps to invite a third opinion into the review to "de-personalize" the issue.
Right. Sometimes text is a terrible medium, especially if people have attachment issues with their code (all the more reason to make branches small and short lived!). I try to make liberal use of happy emojis so folks understand that I'm not trying to be a jerk. Sometimes pointing out flaws in code can cause a visceral reaction that we need to be careful with.
I generally try to avoid taking a code review to a phone call or video chat unless I'm really struggling to understand a branch. I find that having the discussion in written form is helpful for the rest of the team and other reviewers of the PR. Once the conversation moves to voice or video, the context of that conversation can be lost unless the PR author or reviewer goes back to recap the discussion in the PR itself.
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.
Very interesting and I completely agree with that.
I would just add, from personal experience, the case that the discussion between developer and reviewer(s) goes over and over: in this case I found that the only way to solve this is to speak (phone call or personally) and leave the online tools. Most people are much more "soft" by person than behind a monitor
that is very true. we are much better in overcoming differences when we talk face to face. If you cannot come to a common ground it also helps to invite a third opinion into the review to "de-personalize" the issue.
Right. Sometimes text is a terrible medium, especially if people have attachment issues with their code (all the more reason to make branches small and short lived!). I try to make liberal use of happy emojis so folks understand that I'm not trying to be a jerk. Sometimes pointing out flaws in code can cause a visceral reaction that we need to be careful with.
I generally try to avoid taking a code review to a phone call or video chat unless I'm really struggling to understand a branch. I find that having the discussion in written form is helpful for the rest of the team and other reviewers of the PR. Once the conversation moves to voice or video, the context of that conversation can be lost unless the PR author or reviewer goes back to recap the discussion in the PR itself.