There is a famous quote by John Woods:

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

To understand the sentiment behind the quote, people have to stop taking coding for granted. Or doing it for the sake of career demands or to get the pay.

Imagine going to a five-star restaurant and after an hour of waiting, getting a half-cooked mushroom ravioli because the chef was not interested in cooking. I’m guessing most of us would go Anthony Hopkins (Silence of the Lambs) psycho at the chef. Maybe I’m exaggerating, but that’s not the point here. I’m trying to emphasize the chef’s mindset.

This mindset of negligence arrives very often among us engineers when we are not being reviewed or judged on our code. It happens when coders are not motivated to seek suggestions or coding is not a source of pride for them, rather just work designated. So, Code review is not just done for the sake of code quality. It also contributes to a greater purpose. Exposure, motivation, learning, or gratitude for both reviewers and authors.

Coding The Art

It aids in improving the professional relationships among co-workers while they are helping and improving each other. Eliminating the fear that people usually have around coding. Coding is an art that is not learned just from self-exploration. No one knows everything. People learn from others, too, and that’s how they grow. Maybe you are reviewing your teammate’s code, and they have used a technique or algorithm that you can learn from.

Code reviews are nonhierarchical. Being the most senior person on the team does not imply that your code does not need a review. It doesn’t matter if the author is an intern or CTO. It doesn’t matter if the author has three months or 30 years of experience. Coding is a delicate task, and things can slip through the cracks easily. Ao having another set of eyes is always helpful. Even if in the rare case, the code is flawless, the review provides an opportunity for mentorship and collaboration and minimally diversifies the understanding of code in the codebase.

In hindsight, there are other benefits, too.

Better product quality

Tiki-taka — not everyone has heard of these words, but in the world of football. It’s perhaps one of the greatest tactical revolutions and has helped Barcelona FC and Spain dominate world football in the past two decades. Tiki-taka demonstrated excellence in collaborative team play with the highest standard of football. Barcelona FC didn’t get all those wins just because they had world-class players who knew how to play good football on the team, like Messi and Villa. They won because everyone was playing together and improving each other’s play.

Software engineering is not a one-man show. Engineers have to collaborate and aim to deliver best-grade code together. And code reviews contribute to that to a great extent. Also, it sets expectations for the authors so that they keep code up to the standards if they want to contribute. Coding best practices are contagious, and code reviews and feedback are the best ways to share wisdom with others.

Fewer bugs in code

According to a research conducted by Stripe in partnership with Harris Poll :

“On average developers spend over 17 hours per week dealing with maintenance issues like debugging and refactoring, and about a quarter of that time is spent fixing bad code. That’s nearly $300B in lost productivity every year.”

Although code reviews are not really done to resolve bugs (come on.. we have tests, style guides, and CI for that) sometimes they help — for example, the reviewer might sometimes end up identifying some underlying imported function which they wrote that might act up in production.

Moreover, peer reviews have psychological effects on team members too: a SmartBear study of Cisco Systems found that spot-checking 20% to 33% of code resulted in lower defect density, with minimal time expenditure, for companies who practiced peer code reviews because it prevented people from pushing bad code to their peers.

Improvement in interpersonal skills

We all know coding is a technical skill (or a hard skill). It’s teachable and a measurable ability. We can learn it by reading someone else’s code or just copy it off the internet (most of us do that; pretty easy, right?). Now comes the difficult part, convincing someone that the code they wrote (or copied) isn’t up to the mark or is buggy. It’s arduous to convince someone to change their code for the good, and it happens very often during code reviews.

That’s when soft skills come into play. Leadership, openness to criticism, persuasion, adaptability, and effective communication skills are much more important and difficult to learn for software engineers than coding, and that’s what makes a software engineer different from a coder! Doing code reviews often hones our soft skills while we are trying to communicate and make our peers understand the intentions behind our feedback.

Detecting accidental errors/blind spots/typos

It’s pretty common for people to make typos while texting their friends in their native languages. Writing machine language code shouldn’t be an exception. After all, it’s normal for us humans to make mistakes, and having another set of eyes always helps. Studies have found that even short and informal reads have a significant impact on the mitigation of typos or blind spots.

Smooth onboarding of new team members/interns

There are a lot of onboarding sessions organized by companies, in which new employees are told about the company, how the company works, and the rules and regulations, on a much zoomed-out level. When it comes to engineers who spend more time working on laptops and code than working with people, there are not a lot of processes defined. Most of the time, they are just asked to go and read the code or the documentation.

To be honest, it’s quite frustrating. Imagine getting married to the person of your dreams, but the very next moment after you guys are married, you’re asked to read a blog or a biography of that person rather than talking to them firsthand. Discouraging, right?

Code reviews smooth the process of technical onboarding a lot. Maybe we can kick off the onboarding for the new guys. By giving them a small issue that was identified while doing a code review earlier. As a part of future improvements in code. It gives them confidence, as well as opportunity, for creating an impact right away. Also, it’s pretty common for different companies to have different coding standards and styles. So code reviews are also helpful in making new members on the team understand and adapt to the team’s style of coding.

Code ownership divided among the team rather than being a single person’s responsibility

Let’s be honest, how many times has it happened that we wanted to take leave because of some super-urgent work. But because there was a release happening in the coming days, we couldn’t. Pretty common, right? It’s overwhelming sometimes to know that you are not just being asked to code. But you also have to babysit it all the time.

During a review, a reviewer is able to explain the change at a reasonable level of detail to other developers. This ensures that the details of the codebase are known to more than a single person. Leading to positive interaction and strengthening of social bonds between team members. Which helps in breaking the “my code, my ownership” mindset (which is very toxic!). Photo by Annie Spratt on Unsplash

Learn From Udemy Best Courses: