Having your code peer reviewed is always a good idea — even if you’re a senior developer. After all, even the best programmers are still human (yes they are!). And humans make mistakes. 🤓

In case you don’t know, a code review (or inspection) is a systematic process developers use to check each other’s code for errors or inefficiencies.

This might sound like a really time-consuming process, but it’s actually been proven to accelerate the software development process and reduce the amount of time required for quality assurance. Of course, peer reviews also save money — especially if they catch a bug that would have otherwise slipped through testing and production. A single coding error can lead to a raft of bad customer reviews, which can seriously hurt sales and your brand image.

Peer code reviews can also make you a better programmer. The peer review process gives you a chance to learn better ways to write clean code, employ coding shortcuts, and spot issues like memory leaks, buffer overflows, scalability problems, etc.

In case you’re thinking you can just automate the code review process with software, be warned: Tom Glib and colleagues have shown that a formal peer review is the most effective way to find and fix complex coding problems. Formal code inspections even outrank software testing in terms of defect-removal efficiency: testing is only 30% efficient while formal code reviews are on average 65% efficient.

Another bug-detection strategy called “static analysis” has the same level of defect-removal efficiency as peer reviews, but it’s only suitable for a small range of defects. Peer code review is the most comprehensive bug-detection strategy available.

However, not all peer review methods are equal. And, unfortunately, the most common methods programmers use are often inefficient in certain contexts.

Why the most common peer code review methods are inefficient

The most effective peer review process is a long formal process wherein every line of code is printed out and scrutinized by a team of four to six experts. However, this formal process isn’t usually necessary unless you’re coding for an application with zero margin for error — in other words, anything where human lives are at stake.

In most cases, a more lightweight review processes is good enough. Let’s look at four of the most common methods.

The email thread 😬

One easy way to get your code reviewed is to put it in an email and hit send. This is a good option if you have trouble getting your team together in the same room at the same time. But the problem is you’ll be left with a complex email thread of suggestions and various opinions that you’ll have to sift through and make sense of.

Pair programming 👩‍💻👨‍💻

This involves two programmers writing the same code together and checking each other’s work as they go. It’s basically a way to write and review code at the same time, so you can skip the peer review afterwards. Pair programming can be an effective way for senior developers to mentor junior developers, but it typically uses up more resources than other review methods. Also, sometimes both authors are too close to their work to spot errors, and a more objective third-party would be more effective.

Over-the-shoulder 👀

This simply involves one colleague checking another colleague’s code at their workstation. This is a good way to get adhoc feedback from whoever happens to be available, but it’s very informal and it can be hard to properly track errors and document changes to code.

Tool-assisted 🔎

Finally, you can use one of several browser-based tools to help check your code for errors. These work like Google Docs, allowing you to give colleagues access to your code so they can leave comments, propose solutions, and review your code from their own workstation — without affecting your version of the code. This is a much better method than an email thread, but it can still become overwhelming when multiple reviewers chime in. Be sure to choose a tool with good documentation functionality so it’ll be easy to see who suggested what changes, and when.

4 ways to make peer code review more effective and efficient

1. Crowdsource reviews from 10 or more reviewers

Crowdsourcing speeds up the typically slow, resource-intensive peer review process by leveraging several programming brains at the same time. The benefits are obvious:

More eyes on your code increases the likelihood that all errors will be caught. It doesn’t have to be 10, but we’ve found that having 10 or more reviewers significantly increases the error-detection rate.

Crowdsourcing allows you to spend your (or your company’s) time and resources writing new code, thereby making the programming process more efficient.

2. Solicit feedback from proven experts

Feedback is useless unless you can trust its source. But how do you know whether your reviewer is up to the task? That’s a major drawback with most review websites.

At Indorse, we solve this problem by asking developers to be successfully assessed by our community of expert developers, before they’re allowed to review others’ code! We also provide reviewers with an incentive to conduct thorough reviews, so programmers who submit their code for an evaluation can rest assured it will be properly reviewed.

3. Use anonymous reviewers

Protecting the identity of reviewers adds to the quality of the reviews you receive. Why? Simple: if a reviewer is anonymous, they won’t feel uncomfortable providing you with honest feedback.

Imagine a situation in which you’re reviewing a colleague’s or friend’s code. You notice some small errors that could be left alone and the code would still run, just not very efficiently. You might be tempted to brush the errors aside to avoid hurting their feelings. As a result, your colleague misses out on a learning opportunity. Or suppose the errors are significant and you’re forced to heavily scrutinize their work. In that case, your colleague might feel as though you’ve unfairly scrutinized their work, even though you were just being objective.

The reality is that peer reviews can sometimes damage personal and professional relationships. But anonymous reviews cannot, so it’s much easier for an anonymous reviewer to be objective.

4. Group and distill the feedback

Scattered feedback is hard to use. It can even pull you in multiple directions if two or more reviewers have completely different ideas about the correct way to solve a coding problem.

So before you start implementing changes to your code, read through your reviews and identify common trends. If you find conflicting feedback, it’s a good idea to reach out to the reviewers for clarification.

Conclusion

Unless software somehow starts writing itself, there’s always going to be a need for skilled reviewers. Remember: all the code testing tools in the world can’t beat the combined wisdom of a group of qualified developers. There’s really no substitute for expertise and careful analysis.

Also, having your code reviewed (and making time to review others’ code) will make you a better programmer. You’ll learn from your mistakes much faster, and you’ll start to think more about your coding decisions, because in the back of your mind you’ll know that every line you write will be scrutinized by another professional. That bit of extra pressure can significantly improve the quality of your work.

Looking for a new way to review your code?

Consider submitting your code repo on Indorse for a modern crowdsourced code review! You can simply connect your GitHub repository to Indorse, or complete one of our coding assignments, and have your code reviewed by a panel of expert developers spread across the globe — all for free. 💃🕺

If you’re like Aleksandar, Liam or Kishore , and want to join our community of expert developers, then this is for you (click on become our validator 😁)!