Unfortunately, it’s extremely common for less senior people to interpret suggestions from more senior people as instructions to be followed even if they aren’t worded as such. Having a consistent, explicit, and unambiguous way of distinguishing between these scenarios that everybody on the team can follow easily is valuable. You can’t rely upon all developers to be good writers or even good readers, especially across language barriers.
Eh, suggestions from more senior people are in practice instructions. The risk in ignoring them is that something comes back to bite you and you look like an idiot for not following the suggestion of the senior.
Not necessarily. It depends on culture (local or otherwise). A senior needs to carefully instill an understanding of when a suggestion is optional; for some seniors, this may be "never". I personally prefer when direct instructions are mandatory but anything framed as a suggestion allows personal discretion (and requires willingness to defend having not followed the suggestion).
As a senior, you should be aware of the authority you have or that others perceive you have. Your comments will be perceived as authoritative and coming from experience.
And they might very well be! But just make sure you get a rapport with the reviewed party, and prefix or suffix the comment with a "just a suggestion" or an explicit "I'm not asking you to act on this remark". With a semantic review, you can shorten it to "nit:".
This "good enough writing style" must also be able to cross cultural borders - I dare to say even journalists don't get it right most of the time:
* I've heard Kiwis say "F*ck you?" in lieu of "Seriously?"
* A Brit who says "That is an interesting solution!" usually does not feel intellectually stimulated by the solution but is conveying that it is utter garbage.
Thus, I very much like the proposed idea of well-defined labels.*
> A Brit who says "That is an interesting solution!" usually does not feel intellectually stimulated by the solution but is conveying that it is utter garbage.
I can be sarcastic but I have never directed sarcasm towards someone who I am reviewing. (Sarcasm towards third-party code is okay for me.)
I don't know if people who are using sarcasm would want to start labeling things like that as such, since it tends to detract from the intended effect.
Well yeah, but in those examples the commenters do not use direct or clear language, they use colloquialisms and passive-aggressive remarks; if you avoid those, a lot of problems with cultural difference are already resolved.
If in work setting your coworkers (god forbid teamleads or managers) interact like that just run, don't try to solve it with conventional reviews or something. Believe me you will not finish blinking before they start misusing this too to cope with their repressed anger through mockery/shallow sarcasm. "nitpick: have you considered escaping user input?"
Anything that avoids ambiguity here is beneficial. Even if the comment itself is perfectly crafted, the potential for misunderstanding remains. This method outlines the expectations for responses much more than it conveys the tone of the message. This is critical information that is often overlooked in asynchronous communication.
The label takes a fraction of a second to type, and saves the reader(s) many seconds spent inferring what purpose the writer had.
The label makes it easy to find comments still in need of replies, and for automated security to prevent merging items with outstanding crucial comments.
The label opens the possibility of automated reporting and/or review of reviews.
Thank you for your comment. Your experience leads me to believe that the concept might be more useful for non-native speakers. The labels have helped us shorten lengthy PR discussions and focus on the factual aspects. For context: I work in a German company with an international team, and we use English as our business language
I agree. For example just prepending "Question" to a sentence ending in a "?" did not convey anything more to me. Worse the Question that this OP posted in his example could have actually been constructed in a safer manner if safety was what this environment was most under threat. I did sense there was a need to robotify humans and sure enough the "Source" confirmed it (Google Software Engineering Practices)!