4 ms·

> And yet when it happens When it does happen, like any other mistake, it should be corrected. Just like if someone put secrets into git, it should be explaine

> And yet when it happens When it does happen, like any other mistake, it should be corrected. Just like if someone put secrets into git, it should be explained to them why they shouldn't do that, and an expectation should be set not to do it again. If the individual fails to meet that expectation, disciplinary action should be taken, up to and including termination. I've in fact had this happen to a developer who took PR comments personally. The rest of the team was very glad to see them terminated. Fifteen minutes per day adds up to a lot, and I'm quite sure it's more for staff whose roles are heavier on communication or those for whom anticipating people's feelings comes less naturally. > rather than fearing being rebuked at each turn My point is that a fear of professional criticism is a fundamental flaw in a professional, one that should be corrected to the benefit of the individual and the organization. A leader who refuses to correct this flaw in their reports is holding back their professional development and failing in their role as mentor. One should experience nothing but sublime gratitude that one's mistakes were found and corrected before they caused any damage.

trifurcate 3y ago
I actually agree with most of the points you've made here. I think the difference lies in what context this feedback is relayed to a teammate. If I'm tasked with a code review, that is pretty much a directive for me to offer feedback. When I am asked explicitly for feedback, whether directly by my peer or as assigned by a higher up, I tend not to bother with the kind of niceties I am talking about. Still, being nice is nice. But I expect the other person to take my words as-is, so I won't mince them. Accommodating others becomes more important to me outside of this "directly asked for feedback" context. If I'm in a group discussion, or if my feedback hasn't been explicitly solicited, then that's a trickier environment with greater potential for me to negatively dominate the discussion. Similarly, if the issue at hand is not one of baseline technical necessity (like committing secrets to git) but more open to different opinions (like how to structure an interface we're exposing), I place greater weight on trying to be accommodating. I find that most discussions tend to be of the latter kind.

trifurcate 3y ago

I actually agree with most of the points you've made here. I think the difference lies in what context this feedback is relayed to a teammate. If I'm tasked with a code review, that is pretty much a directive for me to offer feedback. When I am asked explicitly for feedback, whether directly by my peer or as assigned by a higher up, I tend not to bother with the kind of niceties I am talking about. Still, being nice is nice. But I expect the other person to take my words as-is, so I won't mince them. Accommodating others becomes more important to me outside of this "directly asked for feedback" context. If I'm in a group discussion, or if my feedback hasn't been explicitly solicited, then that's a trickier environment with greater potential for me to negatively dominate the discussion. Similarly, if the issue at hand is not one of baseline technical necessity (like committing secrets to git) but more open to different opinions (like how to structure an interface we're exposing), I place greater weight on trying to be accommodating. I find that most discussions tend to be of the latter kind.