Hacker News Reader

Comment by trifurcate | Hacker News Reader

> There is no good reason to react emotionally to professional criticism.

And yet when it happens (not a rare event), it can be quite unproductive for both parties. I would hope that you deal with other worst-practices in your domain with greater grace than a total refusal to deal with and prevent pathological outcomes.

Additionally, if you truly believe what you stated, then so long as I avoid sacrificing significant efficiency/productivity to keep my words from bothering people, then I do not see why it should bother you either. If I had to self-judge, I really don't think that the added conversational padding pans out to more than 15 minutes per day. That's worth spending to make sure that the people you work with are engaged with you and the task at hand in an accommodating way, rather than fearing being rebuked at each turn.

View on HN

> 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.

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.

Reply on news.ycombinator.com