I'm aware of an unofficial convention in some US government departments - if you have a small round green sticker on your pass, then you are opting in as someone who can handle un-sugar coated discussion.

It's a great system - you occasionally see someone pause momentarily to check that everyone in the group has a sticker before saying "well, that was a clusterfuck wasn't it".

I want this to be true

I think on my sub, it was just assumed that everyone had a green sticker :)

I like this - so this is a real thing?

Is "Why don't you just use sshd?" actually objectively more useful than "Would there be any tradeoffs using sshd here?"

Both of those comments are actually not great, but at least the first one has the benefit of being direct. Really the question you’re asking is something like ‘you’re deviating from an established design pattern here, why?’. It’s essential to communicate that you either don’t understand a decisions they’ve made, or that you have some particular reason to question a decision they’ve made. Beating around the bush dilutes that message, will usually just end up wasting time, and will often seem condescending. If your team can’t deal with good faith criticism in peer review, then you have a problem with your team culture, not a problem with improperly concealed criticism.

Thank you, I appreciate your take on this. I personally also like to learn from criticism, but it took me a long time to be able to accept it better. I try to get to know the other developers first to get a feeling for whether or not they're used to accepting criticism. If the other person becomes defensive I try to be more careful, if they seem more accepting I will continue being critical.

Usually I would be more openly critical if someone is more experienced.

Learning to accept criticism isnt easy. I've found one way, at least for me, is to be self-critical. I'm usually harder on myself than my peers. Makes it a bit easier to accept when someone else points out a flaw.

I think it’s something you can develop as a team. One of the best teams I’ve ever worked on took blameless post-mortems very seriously. If a decision you made lead to an incident, then you had to attend a PM, explain what you did, and why you did it. Most people got pretty stressed about their first PM, but would pretty soon come to realise that they were actually quite positive experiences. The team knew that failure was something that was completely unavoidable. You can continuously improve the resilience of your systems, but you will still have failures every so often. As such it’s not ‘your fault’ when you cause a failure, it’s just something that happens, and the only thing we can do about it is learn from it. People would figure out pretty quickly that everybody on the team wanted everybody else on the team to succeed, and that that’s what motivated all critical discussion. This team had succeeded in building a trust that everybody had everybody else’s best interests in mind, and because of that criticism was given openly and without creating conflict or feelings of judgement.

That said, I’ve also learned a lot from giving misguided criticism on PRs. I’d point out something I thought was wrong and the author would come back to me and point out some misunderstanding I had. This sort of work environment is one that naturally maximises personal development, and eliminates a lot of the anxiety people have about making mistakes at work. It takes a lot of continuous effort, but imo developing that sort of culture is far more valuable in the long run than developing social conventions around sugar coating criticism.

But questions like this can be used to better understand the engineering decision. There have been plenty of times when questions like this have saved me typing out a long, critical response because there was something I didn't understand, and most of the other times it helps me better frame my response or change my criticism entirely.