> Some people get it. But overall in the cultures I've done it in, it mostly gets me branded as difficult.
Sorry to hear that. Getting the right balance of sync and async, and knowing when to use one or the other makes a big difference. In my current team we went through multiple iterations to come to a mix that works for us. If it's too much sync, the constant sync conversations drain you; if it's too much async, coming to a concensus becomes grindingly slow.
I have learned that its good to praise in public, criticise in private. It is possible to have criticism in PR's private inside a company which reduces its "publicness" but some people are still sensitive even with the reduced exposure.
I hate that idea. If I criticise an idea in public, and I'm wrong in my criticism, then five other people will immediately correct me. Or provide nuance and perspective I miss.
Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
----
Edit: almost forgot! Private criticism also leads to an air of suspicion, in my experience. When everything public is upbeat and positive you start to wonder what terriblenesses people are hiding. It might be nothing, but that's the thing -- you just don't know.
Being able to publically discuss both the good and the bad is a prerequisite for a smooth operation, and the hallmark of a mature organisation.
> Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
This. When I get criticized in private on an technical matter by someone more senior than me and disagree with them there isn't much I can do. Maybe I already have a good relationship with them and we can talk it out but if not I just have to suck it up. I can maybe escalate to higher up but that is also very risky and might more harm than good.
There isn't much I can do to defend myself.
In public there is a chance of other people offering their opinion. Senior people might get kept in check if their critic seems too unreasonable to the rest of the team.
I think a good rule is to criticize technical stuff in public and personal stuff in private.
> Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
Interesting, that's the opposite of what I've experienced. Also a problem with group dicussions is that it's too easy for participants to drift into group think and conformism. I thought these are general principles, but maybe they are predicated on the group.
This is the biggest part of life that people just don't get and has always bothered me.
I can't stand people that are always-positive and nice all the time. I know they are lying and holding stuff back --- but what? I'd rather be friends with someone honest than nice. At least I know what they are thinking, and thus actually know them. Some people would rather just go through life in a mask and insist everyone else wear one too -- something I generally refuse to do.
Some people are insecure and terrified to ever have a record of them being wrong or ignorant. That's understandable, especially in cultures that hire a lot of relatively unskilled people and h highlight that they're competing. I think it's essential that those who are considered senior or expert demonstrate their own vulnerability by asking questions that show they don't understand or know about something, and being grateful for the response.
If and when you have that trust, criticism also needs to be more structured and question oriented. E.g.
- I think the main problem we're trying to solve is X. Is that right?
- if we do this, we'll solve Y but we'll also have a new issue Z. Do we think we would rather have Z than Y?
Most actionable code review comments are criticism. People have to be able to avoid taking criticism of their code personally, and to write criticism in an inoffensive way.
The whole team should be able to look at and learn from code reviews, and the best way to do that is if it's in the open for the whole team or company to see. I'm not sure if truly "public" is possible for most companies, so I'm not talking about that.
I would say that you're right about other kinds of feedback, like criticism about (mis)conduct, attitude, etc. That should for sure be done in private.
I also have learned that people that worked long time with toxic people, or are the toxic ones that are more sensitive to this. One starts being afraid of openness.
It's hard - but a wonderful soft skill - to do this in semipublic envs and be gentle.
"enhancement: Extracting the lines below into a separate function. As far as I understood it's only calculating x, you can call 'x_calculation'. Fell free to use a better name than my suggestion".
shorter, for a team that you are already know for some time:
"enh: extract into a new function. It's calculating x, maybe it's 'x_calculation'. You can name it better than me."
During retros then, I usually recall everyone that I'm open to be criticized in good terms, and send me a message if I'm out of touch. Or even be open during the retro.
True. And I guess you need to be prepared to favor sync at first for newer problems and colleagues. Once you understand each other better, the ambiguity of content and tone in async lessens.
Sorry to hear that. Getting the right balance of sync and async, and knowing when to use one or the other makes a big difference. In my current team we went through multiple iterations to come to a mix that works for us. If it's too much sync, the constant sync conversations drain you; if it's too much async, coming to a concensus becomes grindingly slow.