The type of language you present in your examples reeks of nervous giggling and fluttering hands, and it greatly undermines the importance of the message being sent. When it comes to a process that involves finding failure points in an application, being direct is not "bossy" or "judgmental." It's necessary. It just has to be done the right way.
-- Make distinctions between what could be done differently and what needs to be done differently. Part of that involves knowing how the code fits into the big picture of an application.
-- Give examples of what could/should be done instead of just saying "this is wrong."
If something about the code is inconsistent with standards set elsewhere in an application, give examples of where and how it was done differently. If there is a more efficient way of accomplishing the desired end result, provide documentation about why that way is better.
-- When there is any room for doubt or any chance you may not understand why something was done a certain way, ask questions.
-- There is a big difference between being direct and being a jerk. Before you hit the "request changes" button, think about how you would react if you received the feedback you are about to send and reword accordingly.
-- As a reviewee, remember that someone took the time out of their day to give your work a fresh set of eyes. It is not their job to make you feel warm and fuzzy, but to help you write better code and build a better application. When you've been buried in development so long that even you can't elaborate what you just did, even the most benign and necessary feedback is going to feel like a personal attack. It's not.
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.
You had me until the end, which reads a lot like this:
thecooperreview.com/non-threatenin...
The type of language you present in your examples reeks of nervous giggling and fluttering hands, and it greatly undermines the importance of the message being sent. When it comes to a process that involves finding failure points in an application, being direct is not "bossy" or "judgmental." It's necessary. It just has to be done the right way.
-- Make distinctions between what could be done differently and what needs to be done differently. Part of that involves knowing how the code fits into the big picture of an application.
-- Give examples of what could/should be done instead of just saying "this is wrong."
If something about the code is inconsistent with standards set elsewhere in an application, give examples of where and how it was done differently. If there is a more efficient way of accomplishing the desired end result, provide documentation about why that way is better.
-- When there is any room for doubt or any chance you may not understand why something was done a certain way, ask questions.
-- There is a big difference between being direct and being a jerk. Before you hit the "request changes" button, think about how you would react if you received the feedback you are about to send and reword accordingly.
-- As a reviewee, remember that someone took the time out of their day to give your work a fresh set of eyes. It is not their job to make you feel warm and fuzzy, but to help you write better code and build a better application. When you've been buried in development so long that even you can't elaborate what you just did, even the most benign and necessary feedback is going to feel like a personal attack. It's not.