Pull Requests and Code Reviews Are an Engineering Team’s Magic Bullet

Here’s some background about me; I worked at companies that didn’t do pull requests. We wrote our garbage code quickly, released quickly, and spent a good portion of our time firefighting when we should have been learning and improving as employees. We were stressed, overworked, and constantly in situations where we were afraid to innovate due to the risk. During those times, the frantic “gotta finish this” culture made sense – code reviews take time, and if the code appears to be working, we’re done!… right?

I ended up getting a job in a company that had a better engineering culture, and when I was first faced with a culture of checking each other’s code I balked. To me – a new member on the team – it was a waste of time checking code in a codebase that I didn’t know, checking code for projects that were not mine, and spending my own time not focused on my tasks. Code reviews had no appeal to me, because I wasn’t a good engineer back then… I was simply a coder, and I subscribed to the dangerous mentality that so many non-engineers believe to be best: The only KPI is short-term profit.

A senior dev eventually sat me down to drive home a point; “Check all pull requests and you will improve”. I put my trust in him, so I did my best to check all pull requests, and began to realize how much I had been missing out on. Checking the pull requests wasn’t something to do as a favor to others, it was something that improved all of the engineers on the team, helped us improve, and helped us avoid the stress that comes with firefighting.

So take a look at these 5 reasons why pull requests are the best thing since sliced pizza.

1) Checking other peoples’ pull requests will boost THEIR development skills
Pull requests are about collaboratively reaching the best solution given the circumstances, and this happens when you share what you know. Your knowledge may be about the system’s infrastructure, or perhaps you experienced problems in the past and anticipate them with the proposed code, or maybe the code just isn’t very good and you know a better way of writing it. You impart what you know on the other members without specifically setting aside time for a meeting or exercise. Plus, everyone can read the comments you make!

2) Checking other peoples’ pull requests will boost YOUR development skills
You learn about new solutions that are written specifically for your circumstances – no need to navigate through Stackoverflow looking for situations similar to yours and copy-pasting in nonsense.

3) Pull requests let you know what your teammates are doing
Ticketing systems track tasks, but the status of the code shows the actual progress. The code is the source of truth when it comes to … well, the code. It’s not just the manager, team leader, or whomever should be tracking the progress of tasks, but your should be doing that as well. You can get a feel of how fast people work, what their workload looks like, and can give you an idea of when they will finish.

4) Pull requests stop bugs from going to production
This one is probably one of the primary reasons for having pull requests; because we don’t want unforeseen bugs making their way to production code. More eyes on the code and more people checking that code on their local machines means less buggy surprises in the future.
Additionally, in terms of architecture it can also be used to prevent laziness which can cause code to eventually develop into unmaintainable piles of convoluted trash.

5) They get the team talking
Having a strong pull request culture leads to having a strong team because it’s well-oriented to driving discussion (“will this feature help our service? Does this code fulfill the specifications? How will this technology interact with our system?”), it allows you to understand everyone’s work (“person A is working with the X module, I can discuss with him/her when I need to work with it!”, “person B is strong with Y technology but needs help with Z technology”), and it helps improve your own code as well (“I saw person C using this algorithm, maybe I can use it too!”).
This has the additional benefit of getting the team working together and relying on one another for help. They are a group of resources available to your immediately who can give more specialized information than a Google search could.

One thought on “Pull Requests and Code Reviews Are an Engineering Team’s Magic Bullet

  1. Good points. #4 though I’d say doesn’t stop bugs but recudes them. Semantics but worth noting.

    It takes real skill to be able to review someone’s code and another to be reviewed by someone.

Leave a Reply

Your email address will not be published. Required fields are marked *