Code reviews done right - Getting the best from code review

A look at how to ensure your developers get the best possible learning experience from code review

1. wpvip.com Code Review Done Right VIP Development Consultant @anigelUK Sarah Pantry @anigelUK
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. @anigelUK Not just here for the quality of today’s code, but also to improve tomorrow’s
3. @anigelUK 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. @anigelUK 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. - Why not what @anigelUK Things to focus on to make sure you are doing it right.
6. @anigelUK 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. - Why not what - Facts not opinion @anigelUK
8. @anigelUK 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. - Why not what - Facts not opinion - Constructive not destructive @anigelUK
10. WHY!!!!
 
 No one would think this was ok! If we fix this method, our lives will be better @anigelUK 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. - Why not what - Facts not opinion - Constructive not destructive - Quality not quantity @anigelUK on to 4th point.
12. @anigelUK 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. Craig Newmark Don’t correct people when it matters little Craig’s boss @anigelUK 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. wpvip.com sarah.pantry@automattic.com @anigelUK Thank you