Reap The Benefits Of Include Junior Team Members In Your Code Review Process

03 November 2020

Photo: Unsplash - Jud Mackrill

Code reviews are a vital part of running a development team. Once you get past developer number one, its vital to ensure you have an agreed code review checklist and factor time into your workflow to ensure you review all code. I would argue that if you work as a lone developer, you should go back periodically and review code written more than two weeks ago. It is amazing when I do that the things I spot.

A lot of articles exist detailing how to review code and best practices. Ensuring that the requirements have been met, that there are no logic or security issues introduced by the changes and that the code adheres to the in-house style guide are top of most code review checklists. One thing often missed with peer code reviews is that it is an opportunity for learning.

Lots of teams state only a more senior or experienced member of the team is to review pull requests. They do not think about the more junior members of a team reviewing code of the seniors. On the surface this makes sense. You hope that your seniors are capable of recognizing issues and maintaining a high standard in your codebase.

This approach is flawed for a couple of reasons. The first is that you add an increasingly significant burden on your senior developers as your team grows. You reduce the capacity of your sprints and limit the time within them to focus on larger “big picture” changes to your product. Not only that but I have seen senior developers struggle to maintain enthusiasm for code reviews as time goes on and this leads to a reduction of effectiveness.

By enabling more junior members of your team to undertake code reviews you can shift that burden across the team. This has many benefits. If a change is simply adding fields to a form, for example, there is less risk than a change which integrates with a third party API. A non-senior team member should be capable of ensuring that the changes work, that it follows your style guide and that it has supporting tests that are sensible and passing. It also allows them to feel part of the whole process and I have found that has a measurable effect on how they engage in stand-ups and work within the team.

What I would not suggest is that a non-senior member of the team reviews code written by a senior. A large scale architectural change or a brand new feature that has an impact across the whole code base needs to be reviewed by a peer at a similar level. These big picture style changes absolutely have to be checked for security and logic issues and impact on existing code. But, the key thing to consider here is to allow more junior team members to still review the pull request as a learning opportunity. A team is only as strong as the knowledge within it. Each developer can not only learn about the new feature or the code added in the pull request, they should be encouraged to ask questions and learn about the how and why behind the request as well.

By allowing your less senior developers to be a part of the whole development process your team wins on many levels. You spread the burden of reviews across your team which means your senior members can add more value in any given sprint. You decrease the risk of harming the enthusiasm of your senior developers and you enable the less senior members of the team to learn and grow their knowledge. This can only benefit your team as a whole. You reduce the risk of developers leaving, you increase your sprint capacity and you engage and empower the lower two thirds of your team. So if you have a good code review process already which is geared towards top down reviews, think about how you can change it to benefit the whole team.

If you have any questions or thoughts about how to enable your team further through a whole team code review process then let me know via twitter or email.