How Can You Get Coworkers to Review Your Code?

During the last couple of weeks, I have been working on a big project for my workplace.

It required coding in 4 different repositories, multiple PRs, and thousands of lines of code.

The coding process went smoothly but then, when everything was ready, I found myself stuck.

No one of my colleagues wanted to check my code.

Too long, too many files updated, etc.

Hence the question: 

How can you make your team review your pull requests?

 

 

 

 

What is Version Control

To start with, we need to do a few steps back.

We need to ask a few more questions.

Let’s start from the beginning.

When you are in a team, it is good practice to keep your code in git repositories.

These repositories allow you and all the members of the team to store, track and update the code in a safe way.

You can find a more extensive explanation of Version Control here.

 

The Git flow

There are many different ways web developers can code using version control.

Trunk Based Development, feature-based, etc.

The important is that you keep the main code in the master branch.

When you have to update it, you create an alternative branch and code that.

Eventually, after you have done all your updates, you merge your little branch into the main one.

I have written a full series about the basics of Git and GitHub.

 

The Problem

To merge a branch into another you need to create a Pull Request (PR).

Usually, there are some rules within the development teams such as the minimum number of approval the PR must have before is it possible to merge them.

And here was the problem:

What happens when no one in your team wants to review your PR?

I did some research to never fell into this trap again and here are the results.

 

Solutions

 

Developers like to create

When someone asks me why I am so passionate about coding and how I have been able to do it for such a long time I always say that I love to create.

Seeing how a blank page in the browser transforms into something useful makes me happy even after a decade of doing it.

That is wonderful but it is a big issue when it comes to reviewing pull requests.

Neither I nor any of my colleagues perceive reviewing code as creating something.

This is one of the reasons we, as engineers, don’t like to do so.

A solution would be to make the other participants in the creation of your code.

Ask for advice, consult them, and discuss.

When they are going to see their input inside the PRs that will make them extremely happy.

 

Do not make big pull requests

 

PRs are scary! 

Seeing dozens of files update in a single PR is a recipe for disaster.

No one will see it and say: ”Great! I’ll love to spend the next hour looking at this guy’s code”.

If you are creating a big feature remember to spit the code into smaller PRs and keep your colleagues in the loop every time you change something.

Making their job as a reviewer easier will make your job as a programmer faster.

 

Put someone in charge of reviewing your code

When you create a PR the service you are using will make you add the reviewer.

They will receive an email or a notification saying they have been selected to review a PR.

That’s it!

How easy is it to ignore an email?

A lot easier than I thought.

A solution I found was to go to the desk of my colleague and tell him specifically “there is this PR I want you to check, here is the link”.

Make it clear that you MADE him responsible for checking your code.

It might sound harsh but it works.

 

Offer some pair programming

Over the course of my career, I found very good developers despite the number of years of programming in their background.

I saw interns with great attention to detail that led them to spot errors right away and juniors so much passionate about coding that will spend hours refactoring till perfection was achieved.

Offering a junior developer to pair programs for a few hours will work wonders.

You can show him/her your code.

Also, you can use him as a rubber duck.

That will give you 2 advantages.

Fresh eyes will spot mistakes you haven’t and he will learn a lot in the process.

 

Conclusion

What I learned after doing this project was a valuable lesson.

When I work on something I do not only need to manage the code I write but also manage how I show it to others.

I need to ask myself other questions such as whether is it worth splitting the feature into multiple smaller ones.

Also, should I update colleagues about my progress WHILE I am writing the code?

I hope this article will help you manage your tasks better and make your life as a developer better

If you’d like to read more about coding and PHP subscribe to my newsletter to be notified when the next articles are published.