It would be way easier for managers if they could only draw a flow chart explaining how code review works. The manager then would email all the peers, telling everyone should follow the new process.
There are many ways to implement code review in an organization. For sure, that’s not one of them.
Code Review is a practice that changes according to external elements. So I raise a question: is it a practice or a culture?
According to the Cambridge Dictionary, a practice is “something that is usually or regularly done, often as a habit, tradition, or custom.” The same dictionary defines the word culture as “the way of life, especially the general customs and beliefs, of a particular group of people at a particular time.”
That said, it seems Code Review is indeed a practice. It’s something performed daily, and sooner or later, it becomes a developer habit. This habit gets inherent to developers and engineers, and they feel like there is no distinction between software development and code review.
Below I present some of the cultural aspects that influence the healthiness and effectiveness of the practice.
Free E-book: Click here to download the free e-book Decoding Code Review and Pull Requests. Get all the key points and best practices to implement a code review culture.
Inclusive Code Reviews
To ensure reviews are inclusive, the first thing to do is to tell team members they are expected to review code explicitly. When a new practice is implemented, not everyone fully understands what changes in their routine.
A crucial point to enforce is that Pull Requests are the perfect place for learning and sharing knowledge. It’s a place to ask questions, consider alternative solutions, and deliberate about new ideas. Be the person a junior or an experienced developer; there is always space for a relevant question.
Reviewing takes time
How many times does a developer take to review a pull request? I don’t think this question has an answer. There are many factors to consider.
They include the size of the pull request, code complexity, familiarity to the codebase, how thorough is the reviewer, to list a few. However, they have little to do with culture. They relate to the pull request itself.
When managers measure productivity by the number of commits, lines of code, or merges, for instance, they are creating pressure against the practice. In this scenario, instead of taking the time to review, developers tend to produce more code.
In implicit ways, managers tell developers that opening or closing pull requests are more important than reviewing it. As time goes, pull requests are created and merged as a mere act of bureaucracy. Soon, the team decides to discontinue the practice for not being valuable.
It must be part of the culture to defend this practice from juniors to management.
Communication
Communication is the core of code review. It increases collaboration, shares knowledge among team members, and allows developers and engineers to evolve in their careers.
Reviews make heavy use of written communication. It’s essential to polish everyone’s writing skills. Everything counts when expressing ideas, suggestions, and potential problems: language, tone, and emojis.
If you don’t want to sound harsh, a vital tip is to prefer questions to statements. “Could you point elsewhere the variable is used?” is better than “Remove it.”
Sometimes problems are too complex to elaborate in a comment properly. In those cases, I suggest first to look for guides, blog posts, and other resources that can help.
If it’s too specific, a video call should help. Quick face-to-face meetings can be convenient. Don’t forget, though, to summarize the discussion and post in the pull request for documentation purposes.
Conclusion
Code Review is profoundly affected by external factors. It can’t exist without a supporting culture around it. In this blog post, I shared 3 cultural factors that managers should be aware of when implementing a code review practice.
Co-founder and CEO of SourceLevel. Previously co-founder of Plataformatec.
Loves to talk about software engineering, Elixir, coffee, mechanical keyboards, multitools and his 3 big dogs.