The Power Of Peer Reviews

And how can they benefit your team

Peer reviewing or cross code-reviewing is a common software development practice that refers to having other members of the team review and check code that you’ve written. As simple as it sounds, this practice entails many different benefits that can boost confidence and productivity throughout your team. In this article, I depict some of the most relevant benefits you could take from peer reviewing, and show some guidelines to ensure it is being done correctly.

Benefits of peer reviewing

Here I mention some of the benefits I’ve experienced from doing peer reviews, this list may be not so accurate to a standard development team and other important aspects may be missing, but can be taken as a close picture of how your team could benefit from this practice.

Knowledge gets spread across the team: implementation details, decisions and solutions which are reflected on a pull request (PR) will be instantly transferred to other members of the team once they review the code. Developers become aware of each other’s tasks and responsibilities, can reutilize solutions among their contributions, can learn how to deal with specific features or legacy code, and can spot recurrent issues early based on previous similar experiences that another peer may have already had.

Code conventions become consistent: code layout, naming conventions and assets management tend to differ when developers work in isolation from each other. These differences blur when developers review their peers’ code and start thinking about establishing and following a general set of rules and conventions for writing code consistently.

Less error prone code is delivered: a detail oriented developer could spot on a missing edge-case that can make a piece of code fail, while a developer that knows how an external service works internally, could suggest to handle specific error scenarios so as not to propagate them to the rest of the code. These are just some examples of how peer reviews could prevent unexpected behaviors from happening in a production environment.

Higher quality code is delivered: more experienced developers can make interesting suggestions about the design of the code. Simpler layout alternatives, usage of specific design patterns, better naming choices, changes to support future likely-to-happen modifications in requirements, are just a few examples of them. Junior developers might highly benefit from this expertise transfer process.

Multiple reviewing strategies are allowed: a TDD oriented developer might start the review by looking at the unit tests before jumping to the solution specific code. Another one could pay more attention to how the new code is integrated with the legacy code (if any), whereas a third one could focus directly on the core design of the solution. Pretty different suggestions may arise from these three developers, as a result of aiming the code from different perspectives.

Developers are trained on how to give and receive feedback: since doing a code review is an instant process of feedback, both sides are trained on this topic. On the one hand, reviewers learn how to provide high quality feedback in a kind manner to their peers. On the other hand, code owners learn how to receive and process feedback, leaving arrogance out of the game.

Tips for doing peer reviews

Some tips that I find useful for doing peer reviews include the following:

Be kind: whenever a developer gets a code change request, being the code writer, there’s always a little feeling of having done something wrong. Always make your suggestions and requests as kind as you can, to avoid making feel the owner as if he’s doing a poor job.

Bad feedback: “This code looks like bullsh*t!!!”

Good feedback: “Could we change it this way so as to make it look better? :)”

Focus the code, not the person: a piece of code written by a developer reflects how the solution was aimed at that time. The same developer could write a better solution in a few more iterations. The problem is actually in the current version of the code, focus the code itself instead of the developer.

Bad feedback: “You’re not thinking on the case that A is a negative number here”

Good feedback: “This current solution doesn’t support having negative numbers in A, is that right? Could it be improved?”

Explain why should the change be made: give a strong fundament of why the code should be changed. Refer to code conventions, missing edge-cases, performance issues. Add external links if it is convenient. Avoid feedback without any foundations.

Bad feedback: “Hmm… I don’t like this”

Good feedback: “I think that we could initialize this variable outside this loop to avoid hitting the service on each iteration”; “I suggest that we use the array_map function here, so as it seems to simplify the code, check this URL”

Scope changes that aren’t related to the task: avoid making suggestions related to other tasks or including new things that weren’t originally under the current scope of the task. Create a new task for that with its corresponding PR and requirements. Use a backlog or add a follow-up note for keeping track of it somewhere else.

Bad feedback: “I see that it won’t be hard to support single-sign-on login here, could we add it, too?”

Provide positive feedback also: reviewers are used to focusing only on things that need to be changed. Often they see very interesting approaches and designs, they think “Wow, I’m impressed, what an elegant solution”, and yet they don’t externalize anything. Provide feedback for beautiful code too! This encourages peers to continue receiving feedback, in addition to making them feel useful in your team.

Good feedback: “Good usage of the Proxy design pattern! I wouldn’t have thought of that”

Thanks for your reading, I hope to see you again with new content!