Code review done right

When it is done right, code review is a fabulous tool for building and developing the skills and experience of your team. Done wrong, it can destroy them.

Here we look at some ways to ensure you do it right.

Transcript

1. Sarah Pantry VIP Development Consultant Code Review Done Right
2. Code review is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code. What is Code Review? Done right it is also a valuable tool for growing skills and knowledge amongst the team. Not just here for the quality of today’s code, but also to improve tomorrow’s
3. How is it done? Code review can be done one on one. For fans of xSports, you could say that pair programming is extreme code review It can be a group activity where the entire team gets together reviewing all or just some of the teams code It can be performed remotely - OSS projects, distributed teams, cross company
4. Doing it wrong Not doing it at all.
 If the reviewers look like this or developer looks like this Not always so obvious. Not learning, low quality, low self esteem, stressed, burn out.
5. Doing it right! - Why not what Things to focus on to make sure you are doing it right.
6. Why not what Which will have the best effect? 1. Is not helpful in fact it is very negative and confrontational. 2. Tells what but not why. 3. Explains what, why and also where this can be applied in future.
7. Doing it right! - Why not what - Facts not opinion
8. Facts not opinion No reasoning - So it’s already failed our last point by looking at the what not the why. 
 Normally DPs are a choice they have trade offs. Does it really need to be a singleton or is that just personal preference? Focus on the facts, especially in a position of authority.
9. Doing it right! - Why not what - Facts not opinion - Constructive not destructive
10. Constructive not destructive WHY!!!!
 
 No one would think this was ok! If we fix this method, our life will be better Developers are people. They feel protective of their code. They can get defensive if they feel attacked. They may shut down and stop listening, certainly not learn well. Not everyone has same understanding of code base or features. Develop not destroy. Especially more junior ppl
11. Doing it right! - Why not what - Facts not opinion - Constructive not destructive - Quality not quantity on to 4th point.
12. Quality not quantity Not a competition to raise most issues Not everything *must* be flagged up, changed or fixed. Pick up on the most important things. If it really makes a difference then fix it. Bonus point. Don’t say “While you are at it fix X” in code that wasn’t changed. Raise another issue for it.
13. Food for thought Craig Newmark Don’t correct people when it matters little Craig’s boss Craig’s boss gave the craigslist founder some advice that Craig shared in a Business Insider interview.
 When it matters a lot--when there's something on the line; when it's going to affect something important at the company; --of course let someone know. 
 But when it doesn't really matter, don't tell people what they're doing wrong. Let them be.
14. Sarah Pantry sarah.pantry@automattic.com @anigelUK Thank you