Getting the best out of your code reviews

Mattia Tommasone

@raibaz

https://slides.com/mattiatommasone/code-reviews/

http://bit.ly/mf-codereviews

Slides!

About me

• Developer
• Developer Advocate
• Open Source Maintainer
• Open Source Contributor
• Open Source Supporter
• (Former) Kids' Football Coach
• (Former) Uni Lecturer
• (Sometimes) Conference Speaker

Show me your hands

I would have liked you to

• Linus's law
• Macro-level knowledge sharing
• Micro-level knowledge sharing
• Automatic rubberducking
• Communication practice
• Precise discussion
• Empathy

https://www.npmjs.com/package/save-dev

Common mistake #1:

Common mistake #2:

Too many reviewers

Possible rules

• Google: 2 reviewers, different in nature
• GitLab: Chain reviewers
• Whatever works for you, just stick to it

• Linus's law
• Macro-level knowledge sharing
• Micro-level knowledge sharing
• Automatic rubberducking
• Communication practice
• Precise discussion
• Empathy

So how do you help reviewers?

Anticipate questions

aka, "if your code was hard to write, make it easy to understand"

• Improved test coverage
• Unquestionable reason to request changes
• Historical context

DO's:

• Analyze all the code for potential issues
• Suggest all possible improvements
• Have high standards
• Focus only on the code and only on this PR
• Keep the language barrier in mind
• Allocate time for code reviews

DON'Ts:

• Be a jerk
• Involve other topics in the discussion
• Make this about the people rather than the code
• Leave anything behind out of kindness
• Spend all your time doing code reviews

ASSUME GOOD INTENT.

“An amateur is defensive. The professional finds learning (and even, occasionally, being shown up) to be enjoyable; they like being challenged and humbled, and engage in education as an ongoing and endless process.”

— Ryan Holiday, Ego Is the Enemy

Questions? Feedback?

(I will assume your good intent)