Getting Down to the Purpose of Code Review

Code reviews have always been a struggle at agencies. Most specifically because sometimes there aren't two people working on the same project. Who gives the review? We decided to change our approach to code reviews as well as re-thinking their true purpose...

About six months ago code reviews became a real struggle for us, in that they weren't happening. It wasn't that people were skipping them entirely, they were all requesting them from me, and there were too many for me to keep up with.

This was happening because we were growing quite quickly and were running a lot of projects simultaneously. Some of those projects were not particularly large and had a single engineer working on them. Since they were an army of one who had enough context to review their code?

It was clear that this wasn't going to scale. Did we want to kill code reviews altogether?

That felt like a hasty approach, I myself enjoyed the code review process. I like seeing everyone's work and the patterns and styles we were using across our client's code bases. It allowed me to see where we had overlapping features and could build efficiencies.

It allowed me to see where engineers were struggling and find opportunities to help them or point them to a person that could. It gave me a general sense of the essence of our org and how our product, the code, was evolving over time.

I wasn't using code review as an opportunity to find bugs. Although this is previously how I thought of code review throughout my career. It was a time that we searched for anti-patterns, missing test coverage, and bugs. I would often pull the code down to test it myself.

Now, Cause of a Kind is large enough that I don't have every code base on my machine. I don't have enough context to run the code and check it. And now, not everyone on the team can just do that either.

I also had some engineers upset with code reviews in general. The two most common complaints:

1. "I don't like HOW this person is commenting on my code and making suggestions."
2. "Nobody is leaving comments on my code, they are just approving my PR's"

So we have people struggling with WHO to ask for a review and now we have people getting feedback they don't like or too little feedback. What a mess.

In order to fix this, I had to get to the essence of what is important about a code review. Thinking back, was my impression of code review misguided? Was the purpose of code review really to catch bugs? In reality we have unit tests and a QA process that should handle this.

When I really thought about it, the true value of code review is keeping everyone in the organization familiar with the code we were producing. It is a way for everyone in the organization to have some familiarity with every project.

It was a way for two developers working on two separate projects to share what they had done and learned. It was a way for them to collaborate on a feature they were both building, albeit for two different clients, at the same time.

The true value of code reviews, is the knowledge sharing. This helps our organization by allowing junior engineers to see how more senior engineers write code. This helps by allowing someone to take a sick day or vacation without feeling like they are the linchpin of a project.

We become better by helping one another become better. By allowing the free flow of ideas through the organization. In a remote environment this is extremely difficult as there are no lunch table conversations about the finer points of using macros or trying out a new library.

All of this can happen through a process of code review. And by changing our focus from looking for errors, to trying to understand the code of our peers, we can now see opportunities to ask questions instead of issue mandates.

Junior engineers no longer need to wonder what they should say. Surely there must be something in this PR you are curious about? Senior engineers can offer guidance with live examples, in real time, as they work on more complex projects.

An engineer interested but inexperienced in a specific technology like web3, gaming, CSS, or DevOps can now take up a code review and see how it's done. They can freely ask questions because this is the purpose of code review after all.

We now have a slack channel, simply called "code_review" where everyone across the organization posts their pull requests for review. People are empowered and encouraged to do this across projects and it is especially important across different experience levels.

Code review isn't about finding bugs, that's what testing and QA is for. We should expect a pull requests at a minimum works. In a fully remote organization this is a more important vehicle than ever for knowledge sharing, collaboration, and learning.