Code reviews don't have to suck.

1. Effective peer review.
an ongoing conversation.

2. Why code review?
There are lots of good reasons.
Programming is hard.
We work with smart people.
Discussing our work can be positive.
Increases overall quality.
Helps solve difficult problems.
Spreads knowledge.
Helps develop strong shared standards.

3. Who are reviews for?
Developers.
So that we can learn from one another.

4. 10 Commandments
of egoless programming.
Understand and accept that you will make mistake.
You are not your code.
No matter how much “karate” you know, someone else will always know more.
Don’t rewrite code without consultation.
Treat people who know less than you with respect, deference and patience
The only constant in the world is change.
The only true authority stems from knowledge, not from position.
Fight for what you believe, but gracefully accept defeat.
Don’t be “the guy in the room.”
Critique code instead of people. Be kind to the coder, not the code.

5. We all make mistakes.
The important thing is to catch them as early as
possible.
Luckily our mistakes aren’t life threatening. We can fix them, move on
and laugh about it.

6. You are not your code.
The point of reviews is to find problems early,
educate and learn.
Don’t take it personally.

7. Always room to learn.
We are all smart capable developers.
Let’s learn from one another.

8. Ask why.
Don’t just assume that something is wrong.
Ask questions. Inquire about why something was done in a particular
way. It might be the way it is for a valid reason.

9. Respect your peers.
Even those that have been “in the game” for a
shorter time then you have.
We all have different levels of experience. Patience and respect goes a
long way.

10. Change is constant.
Standards are a living thing.
We need to work as a team to develop a culture of quality.

11. Knowledge over position.
Everybody has valuable insight.
Let’s cultivate that and build a knowledge based development
environment.

12. Don’t dig in too deep.
Fight for what you believe.
Be willing to accept ideas that are different then the ones you have now.

13. Don’t hide.
Building a positive development environment
takes participation.
Share what you know. Ask questions. Participate.

14. Critique Code.
Not people.
Be kind to the coder, not the code.

15. What is a “good” review?
Good reviews spread knowledge and provide a
learning experience for everybody involved.

16. a conversation...
Reviews should be a two way conversation
between the author of the code and the
participants of the review.
Reviewers should ask questions of the author. The author should offer
explanations and frame the context of the code being reviewed.

17. includes a summary...
When a review is over it should be summarized.
This will let all the participants know what action is being taken as a
result of the review.

18. includes praise...
If you see something you like, let the author
know.
It can be difficult to remember to do this, but it is important.

19. references standards...
Have a solid set of standard practices to
reference.
Remember that standards are a living thing. They are still open for
discussion.

20. focus on the code...
Not the person that wrote it.
Ego is something we all have, but should be kept out of reviews as much
as possible.

21. not always actionable...
Comments in a code review don’t necessarily
require immediate action.
Be clear about that. Is a comment a suggestion? A question?

22. is time-boxed...
Code reviews work best on code that is fresh in
the author’s mind.
Respond to review requests promptly. Participate as much as possible
and mark the review complete when you are done.

23. Being reviewed.
It can be tough to be in the hot seat and have
your code examined.

24. Add initial comments.
As the author adding an initial pass of
comments is extremely helpful to explain the
code under review.
Scope and context can be defined this way.

25. Decouple yourself...
Take a step back and release your attachments
to the work being reviewed.
This is challenging. The initial instinct is to “bunker in” and defend the
work.

26. Understand the standards.
Work as closely to the defined standards as
possible.
When you need to deviate explain why in the initial comment pass.

27. Maintain the standards.
Standards are living things.
If you deviate and need to do something a different way open the
discussion for improving the standards.

28. When to start a review?
During active development while the code is
fresh in your head is the best time to start a
review.
Peer review is not a task to save as until the end of development. Starting
the conversation early helps ensure that it isn’t an afterthought. Problems
are caught before they spin out of control.

29. Who starts a review?
Generally the author.
But sometimes it might be started by somebody else if a problem is
noticed or if a commit isn’t under review and is on the large side.