Effective peer review. an ongoing conversation.

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.

Why code review?

Developers.So that we can learn from one another.

Who are reviews for?

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 patienceThe 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.

10 Commandments

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.

We all make mistakes.

The point of reviews is to find problems early, educate and learn.Don’t take it personally.

You are not your code.

We are all smart capable developers.Let’s learn from one another.

Always room to learn.

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.

Ask why.

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.

Respect your peers.

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

Change is constant.

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

Knowledge over position.

Fight for what you believe.Be willing to accept ideas that are different then the ones you have now.

Don’t dig in too deep.

Building a positive development environment takes participation.Share what you know. Ask questions. Participate.

Don’t hide.

Not people.Be kind to the coder, not the code.

Critique Code.

Good reviews spread knowledge and provide a learning experience for everybody involved.

What is a “good” review?

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.

a conversation...

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.

includes a summary...

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

includes praise...

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

references standards...

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

focus on the code...

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

not always actionable...

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.

is time-boxed...

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

Being reviewed.

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.

Add initial comments.

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.

Decouple yourself...

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

Understand the standards.

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

Maintain the standards.

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.

When to start 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.

Who starts a review?