A few thoughts: 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 c

A few thoughts: 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.