It's important to highlight that your code reviews are reviews of the _code_ and not him as a person or his character. You're both trying to make the best possi

It's important to highlight that your code reviews are reviews of the _code_ and not him as a person or his character. You're both trying to make the best possible decisions to ensure that the product is stable, minimize the amount of bugs (and therefore toil), reduce the on-call incident rate (if you're in an on-call rotation), and teach/learn from each other. You're _not_ trying to change/review each other individually. People automatically have their defenses up if they feel like you're criticizing them. As others have mentioned approach matters a lot. Saying "this is wrong, make it X to fix it" will be received poorly most of the time. Instead you can phrase it as a conversation in the form of "What do you think of refactoring this endpoint to follow the conventions we follow throughout this repo [link to examples]. It'll make the codebase more consistent and easier to follow along for others" or "I believe using `new Buffer()` has some security issues and has been deprecated [link to deprecation notice]. We can use `Buffer.from()` instead which has the same interface." (this examples are trivial but as things get more complicated who knows... maybe what you thought was right is incorrect) For minor things such as formatting preference I strongly recommend getting a linter/formatter at stick to what it chooses. Make sure your CI enforces its formatting.