Creating a measurable Pull Request process 🔍
Why you should track pull requests and set goals about them — and a pragmatic approach to do it.
Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
Pull requests and code reviews are a cornerstone of the workflow of any engineering team. In my experience, this is a fairly uncontroversial statement for any team, as most people have a grasp of why PRs are useful.
However, as for testing and any part of the engineering work that doesn’t visibly advance the creation of production code, this intuitive idea of usefulness sometimes is not enough to protect the practice against the pressure of tight deadlines and management.
When you have to cut corners, some corners are just more vulnerable than others, and PRs are one of those.
I would go as far as to say that, without a conscious effort in weaving good PRs into your culture, you will find yourself in a situation where a non negligible share of people on your team secretly despise them. And you will be surprised by how effective these people can become at neutralizing the practice and making it useless, without anyone being able to notice.
Objectives
To understand why this is possible, first we have to define what are the objectives of a good PR process. In my book, they are:
Improving the quality of code before being released
Sharing knowledge across the team
Keeping the PR cycle itself short
You may notice that there is a tension between the last objective and the first two. This is healthy, because we want to make sure we strike the right balance between shipping things fast and shipping things that are correct and under control of our team.