| The problem with this is that people are rarely given training in understanding criticism and how to deliver it constructively in industry. Maybe it's different in some computer science curriculum? All too often, eager young developers are told to, "do code reviews," without being given any instruction on how. This can lead to all kinds of unproductive misunderstandings, such as: - Interrogating the author's competence, Why did you add the fields to this struct instead of... - Shaming people, You should know... or How could you miss something so obvious? etc - Bikeshedding, this one is subtle and a huge source of wasted effort and a huge nuisance. When discussing the construction of a nuclear power plant the most well attended and heated discussion was what color to paint the bike shed. Consider if your comment would really change anything for the better or is it just creating busy work? Remember: personal preferences aren't important, and neither are superficial ones. Simple things you can do to avoid these kinds of comments, sound more constructive and assertive: refrain from the use of the words "I," or "you." Use the non-personal pronouns, "this," "they," to talk about the code. Stick to facts and avoid personal preference: you might have written it differently but if the tests pass, the style fits the rest of the module, there are no lint warnings, etc; people shouldn't have to come to you to ask how you would have written it. And use labels as the article suggests: if you feel compelled to leave some helpful advice for a junior colleague that isn't necessary to get the code merged, leave a label to indicate your intention. In a similar fashion, authors: make sure you're comfortable rejecting poorly written review comments, ignore unhelpful nit-picking, etc. Practice rejecting a few nitpicks once in a while. After all, you took the time to understand the problem and write the code in the first place. Some times reviewers dropping by at the last minute haven't taken the time to fully understand and appreciate the problem. If their suggestion would have you re-write half of the work you did and not materially change outcomes it's a sign they have no idea what they're talking about. |