Alexandra Hill gave a really good talk at Lead Dev 2018 on “It’s personal - the art of giving and receiving code reviews gracefully”. This was an awesome talk and covered some valuable points.

Code reviews are good for the hard to review part of code changes, so things like

• Functionality
• Readability
• Maintainability
• Scalability

Its important to understand what parts of a code review can cause conflict, the following slide highlighted this.

As highlighted, we should automate review of things like whitespace, typos etc as these are easy to automate and shouldn’t require manual comments. There are some things that are factual making them low conflict and then there are important things with high reward that can result in conflict.

As a reviewer

As a reviewer one helpful technique is to review code as a grading exercising. Raise code by a grade or 2 no more. Trying to drag a D to an A is likely a demoralising experience for everyone and there are other ways to improve the quality of someones code such as pairing and coaching.

Change the language you use, use ‘we’ instead of ‘you’. ‘You could do this’ would become ‘We could do this’.

Say thanks for their hard work.

As a author we can

Practice as if technique, so when receiving feedback, how would i respond to this in my best mood for example.

Annotate your review first, let the reviewer know what you intended to do and why you took the approach you took.

Solicit feedback with specific questions, if their is a part you want feedback on then highlight it.