3 ms·
People are quick to downvote calling such things BS, because it sounds just nice and well-intentioned when presented like that. The problem is that such "rules"
by sundarurfriend 9y ago
People are quick to downvote calling such things BS, because it sounds just nice and well-intentioned when presented like that. The problem is that such "rules" can be and are used to harass and shame people who are focused on the code and just want to get things done, without either sugarcoating their thoughts or being intentional assholes about it. It also just plain ignores people who actually prefer getting plain, straight to-the-point reviews, and makes their preferences less valid.
In an ideal case, the reviewer "should" perhaps consult with the reviewee's therapist and craft the reviews to most benefit the reviewee based on their emotional state - but we don't have an ideal world of infinite resources, and some of these rules go beyond a reasonable "don't be an asshole" line and make code review into an even more mentally taxing task: one where you can't treat the other person as an adult peer, instead having to talk to them as if they were insecure teenagers who could misinterpret anything as rudeness or attacks on them.
- ewi_ 9y agoActually, if what you are looking for is "to the point" reviews, then you should agree with the article's advices. To name a few: - Pointing to a common reference instead of simply stating your opinion in a review will get the improvement you want done faster - Writing a single comment for a repeated error is faster to do for the reviewer - Explicit communication instead of emojis and sarcastic comments will bypass the need for further explanation, which will make the whole process faster Finally, you seem to take issue with only a few of the author's points ('some of these rules go beyond a reasonable "don't be an asshole" line'), could you explain which ones and why? I am interested to know what exactly makes the process too taxing for you.