Where There is Code There Should be a Review (but Why?)

Lately, I was asked by one of my trainees why I am so persistent when it comes to code reviews. An interesting question if you ask me, so I decided to take a closer look as to what my big Whys were, and also wanted to ask you what you think about the (sometimes feared) Code Review !

No matter if your dev-team is looking on a Scrum or Kanban board on a daily basis () there most probably is this one column with a header like To Verify, Testing or QnA written prominently above it. Why? Well, in my mind there are a lot of good reasons for cultivating code reviews within, especially small, dev-teams:

Quality Assurance: Four eyes always see more than two and so potential bugs or pitfalls can be fixed on the spot. The argument of quality of course needs to be the first point on this kind of agenda as it is the most practical reason for their existence.

A Break from your own Tickets and Code: Personally I love nothing more than spending Monday mornings with some delicious coffee reviewing new merge requests to again find into the right mindset for the week and stay up-to-day with current developments.

Everyone Learns Something new: Of course, always depending on your levels within the coding domain, both the coder and the reviewer will always learn something new in the process. Be it how to do something or how not to do something.

More Communication: Especially with home office and remote work, working together changed a lot over the scope of the past few months (and actually years!). The biggest pain-point for most people probably was the lack of interaction with their peers and colleagues, and personally within the scope of reviews I communicated the most with my co-workers also on a personal level.

What are your opinion on Code Reviews? What other Whys do you see (so I can hype my protg up even more when it comes to them)?

Looking forward to hearing your thoughts .

Cover picture by Markus Winkler on Pexels