I’ve posted about code review a number of times, about how it requires trust and needs to be fast. But, in the end of the day, code review is just one tool in the toolbox of collaborative software development. It should be evaluated in the context in which it is used.
For example, when you’re starting a new project from scratch, usually there’s a lot scaffolding to set up. This is an important time for collaboration as you’re laying the foundation for building new things. However, most of the code written at this stage will be boilerplate. Detail-focused PR-based code review will be a hinderance: there’s no point in line-by-line critique of boilerpalte and it’s too slow. You’ll be better off pair coding and iterating quickly. Maybe simply regularly talking to each other is all you need!
Whether code review is the right tool for you and how it should be done depends on the team, the goals, the environment, and the stage of the project. This is why I believe that the team should choose its own tools and continuously evaluate them. Regular retrospectives are a great way to make this happen.
I’ve realized that I give a lot of advice that assumes a skilled team in a psychologically safe environment. It works to an extent for less skilled teams as long as the environment is safe and they want to learn.
But what if the environment is not safe? I’m pretty sure you’ll have to start by fostering safety, but I don’t know how that is done.