a) Potentially embarrasses the person
b) Can create animosity towards co-workers
c) Difficult for introverts regarding reviewing & critiquing
Private code reviews
1) you are not your code. When you're doing a code review, you're critiquing the code, not the person.
2) critique is not the same thing as criticism. Yes, I was taught to criticize privately, but critique is frequently public (within a small group). Artists have critiqued publicly for centuries. The reason is that it's not only the creator who can learn from the critique.
3) critique doesn't have to come across as harsh. Instead of "you should have done Foo using Bar instead of Baz", try "why did you decide to use Bar instead of Baz for Foo?". Instead of "this code is badly written", try "do you think this might be simpler/clearer if you did it this way instead?" Personally, I've learned a ton by asking questions like these and paying attention to the answers.
It's possible (preferable, IMO) to critique with empathy. The nice thing about code review is that it's an asynchronous medium where you can think through how you phrase things, which can be good practice for learning to interact empathetically in other potentially confrontational contexts.
Yes good code reviews can be a learning experience for both reviewer and reviewee.
At work I lurk on a number of PRs that I’m directly involved with just so I can learn from the comments.
Maybe I’m lucky to be part of a team with a healthy code review culture.
I'm sorry but if you're a functioning adult working in a professional environment, you should expect to receive critiques and feedback on your work. If someone is so sensitive that they cannot accept constructive criticism on their work, I don't know how they're ever going to learn or improve.
Personally I find the first idea fairly bad since the amount of constructive criticisms you might get from people far outside of the problem realm seems limited.
Having them open to the entire team on the other hand seems like a good way to spread knowledge and to get input from different sources
If a reviewer asks you to change something and you believe your version is just as good as what they suggest, change it. If they suggest something they claim is "totally optional", do it. Remember, we're getting stuff done. This is faster than arguing (over stupid shit that isn't going to matter anyway).
On the other side, if you ask for something in a review and they're not gonna do it, bias toward letting that slide unless it's a real problem. If you think a piece of feedback will seem embarrassing, mention it in a private chat or something first so they have an opportunity to address it.
Code-style issues should not come up in reviews. Set up a linter, fail builds on lint errors, and forget about it.
Maybe it is difficult for introverts, but you know, a lot of things are going to be difficult. Sorry about it.