Code reviews, the human perspective.

Everybody in the industry talks about code reviews, as they are indispensable and a developer’s life could not be without them. I want to talk about my experiences on a decade of code reviews and why I despise them.

When I was a junior developer, we had the usual process; you push some code to a branch and request a code review from your more senior colleagues via an online tool.

This colleague will give his opinion on my code. And because I was a junior I got slammed in code reviews. And as a junior, that is such a pleasant feeling, NOT! I felt devastated and discouraged to go back to the code and solve it.

I lived through the process, hardened my shell, and became a medior. As a medior developer, I was still doing code reviews but became frustrated. Every freaking time I had to wait for ages for colleagues to review my code, with excuses, no time, meeting, tomorrow, etc, etc. This ended up in having multiple code reviews waiting for approval, talk about context switching!

I also lived through this process, buried my frustrations, and became an even better developer, let’s call it a senior. The better I became, the more code reviews landed on my plate. Now I’m a colleague who had no time and many meetings. I became the bottleneck for my junior/medior colleagues. As a senior, I told them how to improve code quickly (Hey, I am busy), which probably discouraged them as it discouraged me.

Because the code reviews piled up, they became dreary, and I started doing a crap job, skimming code reviews or approving code reviews just because I trusted the specific colleague. How is that for code quality? I am 100% sure lots of developers do this.

In my entire career, code reviews never made sense. It is a damaging practice, and that is why I despise them.

What’s the alternative?

First, think about the agile manifesto, “Individuals and interactions over processes and tools“, I think the code review process devaluates personal interactions you could have with your peers. So instead of pushing code to a tool, why not build the desired feature together and start with pair programming.

Pair programming creates better personal interactions where the junior feels less judged and more fulfilled as they can quickly absorb new subjects. Whereas mediors and seniors will grow their teaching skills and lose dreaded code reviews.

Practicing pair programming makes your group more cohesive and feels like a real team.

But how do you ensure code quality without code reviews?

The idea of code reviews is to check if the code is up to par for quality, mistakes, and requirements, with pair programming, code reviews are instantaneous, your reviewer is sitting next to you.`

We don’t have time for this; we have too much to do.

I think this is a futile argument, the cost of context switching is tremendous. Moving around from your feature to open code reviews to discussion and back and forth is a lot of context switching, by pair programming, you save this time. Plus, pair programming improves your efficiency, as code detours become less likely. Pair programming is more fun, creates better quality, better understanding, and saves time!

My advice, stop wasting time, build your team and pair program, or go bigger and do mob programming!

Let's talk!