I’m a firm believer in the practice of code reviews. When done correctly it can significantly improve the quality of software and is among the most effective knowledge-sharing tools in a team. In the previous article I shared a few tips how to create a great pull request. Following them as a team will make everyone’s life easier, so keep them in mind at all times. In this article, I’ll focus on effectively reviewing PRs.
TL;DR — Be nice! Your attitude and approach will be mirrored by your peers when they are reviewing your pull requests! Remember the common goal of your team – to achieve business value while writing great code you will be proud of.
Great things are usually built by teams, not by lone wolves. The myth about the 10x developer sitting alone in the basement is often exaggerated. In practice we’re usually working in a team, building (hopefully) great things together. Aside from the code we write, how we collaborate with others, our work ethic and ways of working have big impact on the success of a project.
The code review practice is widely adopted for increasing overall code quality and decreasing number of bugs that reach the QA team / end user. On top of these, I believe reviewing and discussing code written by your peers is the best way to share knowledge within the team, to onboard new members faster and to quickly adopt new patterns as a group.
Below are my top tips for being a great team-player, making your pull requests easier to read and understand so they can get approved as fast as possible.