The purpose of a code style guide is ultimately to reduce recurring friction. The purpose of a code review is multi-purposed, but a big part of them is to identify said points of friction with the goal of determining the trade-offs of each preference and setting a rule in the code style guide.
When we disagree with a code decision it should be communicated respectfully, professionally, and with empathy. However, it is super important to communicate these disagreements. The response will usually be "Ah, yeah, that makes sense, good call out!". Sometimes things will be more nuanced but this communication is ultimately a good thing (even if it can be difficult and uncomfortable sometimes). In this process it is important to maintain a culture of empathy and psychological safety but to remember that healthy conflict promotes better code and stronger working relationships.
Have you had lunch? Did you sleep ok last night? Being "hangry" or general irritable is a very real thing. Check in with yourself before a code review. Consider if you are in a good mindset to provide constructive feedback. If you are not, that's ok. Grab a snack, get some coffee, take care of your needs first, and consider letting your colleage know you'll need some time before being able to start reviewing.
Frame wanted changes as requests, not commands - when in doubt of how to say something, ask a question.
If a developer has repeated a mistake in their submitted code, the best way to handle this is to place a single comment on the PR and mention this exists in a few places. There is no need to comment on every instance of the mistake.
- Have a conversation in-person or via video call
- Concede or escalate to a team discussion
- Discuss in retro
- Add rule to Code Style Guide
Offer praise when you see something cool and call out when you just learned something new! Calling out that you learned something you didn't know before may trigger both of you to share that tip more with others.