This content originally appeared on Level Up Coding - Medium and was authored by Giedrius Kristinaitis
Gatekeeper code reviews signal about lack of trust, are not effective and slow teams down.
Have you ever been in a situation when your team slows down considerably because there’s no time to do code reviews and there are a lot of pull requests just hanging around?
Have you ever had a day when a big portion of your time went into reviewing your teammates’ pull requests?
If so, there are some serious trust issues in your team. If there aren’t, why is the delivery of new features blocked by code reviews?
Why Trust Issues Exist
Skill gaps
Obviously, the main reason is that there might be some people in the team who are less skilled than the rest.
Skill gaps need to be closed. If you have skill gaps in your team and you’re not willing to do anything about it you should ask yourself some questions:
- How do you expect quality work to be delivered if you think there are people who don’t measure up to your expectations?
- If someone in your team is not willing to improve why are they still on the team?
- Is it ok for you to be gatekeeping code changes through pull request reviews?
- How much time does pull request gatekeeping consume?
- Why are you willing to work in an environment where you can’t trust your teammates?
Code ownership
Some people fall in love with their code to the point where they don’t allow anyone else to touch it, and, of course, they’re not gonna trust anyone to make changes to it.
If you find yourself being in love with your code you should ask yourself some questions:
- How will someone else changing your code affect you? How will it harm you?
- Are you guarding your code because you want it to always be perfect?
- Does someone else changing your code invalidate the hard work you put into it?
- Does someone else changing your code hurt your pride, because you know it’s not good enough and has to be changed?
The reason people get overprotective of their code is that they identify too much with it, and they think that when someone needs to change their code it’s personal, it’s about them, and not the code.
If you’re taking changes to your code personally, keep in mind that your code is not your helpless child, it’s not an extension of you, and it doesn’t automatically make you a bad developer if someone sees the need to change your code.
Allow others to change your code.
If you know someone who’s protective of their code I think you should make it clear to them that code changes are not about them.
A misplaced sense of responsibility
Some people feel like it’s their job to make sure that everyone else does their job well, that it’s their responsibility.
When you feel responsible for the job others do you may start trusting them less, because, after all, you’re the one who can take care of your responsibilities the best.
Spoiler alert, I’ve been there. More about that later.
The could be countless reasons for trust issues to exist. However, one thing’s for sure — a team with trust issues is not an effective team, it’s not even a team. Trust is fundamental for the existence of a team.
The Gatekeeper
In a team where people are not trusted decision making is done by very few individuals.
When not everyone can make decisions you have a new role in the team: the gatekeeper… or the babysitter, or whatever you wanna call it. Gatekeepers micromanage others, and, as you can imagine, it consumes a lot of their time, to the point where they stop doing any work themselves and only micromanage.
Gatekeepers also discourage others. Tell me, how would your self-trust change if you had someone keep a close eye on every step you make and constantly tell you that your decisions are bad? I’m pretty sure you’d stop trusting yourself in the long run.
Destroying the Gatekeeper Role
Obviously, babysitting is bad for the team. A team is supposed to be a body where everyone’s decisions matter, a team is should be based on collaboration, a team is supposed to be based on trust.
The role will not disappear overnight, but there are steps you can take to at least begin eliminating it.
You’re not the only one who’s responsible for the team
I’ll admit, I’ve been in the gatekeeper role. I can say that I don’t like it.
The reason I ended up in that role was that I felt too responsible for the team, I felt like if some bad decision or some bad code went under my radar it would mean that I’m not doing my job.
Then I realized that everyone is responsible for the team.
It’s not your job to guard others, it’s not your job to do their job. Simple as that. If some bad decision is made the blame doesn’t fall on you unless you consciously let it slide.
When I felt too responsible for the team, I spent too much time focusing on what others are doing, while forgetting my priority — the work I was supposed to be doing. As a result, my productivity decreased.
The world is not gonna explode if you drop the gatekeeper role. Every gatekeeper needs to understand that.
Understanding that is the first step towards getting rid of the gatekeeper.
Start closing the skill gap
Easier said than done. Closing the skill gap requires time, it’s a big investment.
If someone’s not qualified enough to do their job and is not willing to improve then you should part ways, after all, why should you keep someone who’s not bringing value?
Even starting to approach the skill problem can be uncomfortable, as at least one person needs to understand that they need to improve, and they could take it personally. The possibility of that might prevent the problem from being pointed out, and you can’t even begin to solve it without admitting it.
Trust people more
Why don’t people trust others? Trust involves risk. Some people just can’t accept that risk.
Sometimes you just have to take the risk and trust what others are doing. Trust doesn’t require proof that others will live up to your expectations. If you require proof to trust other people then it’s not trust, it’s paranoia.
Trust needs to be earned, and how can others earn your trust if you don’t give them a chance?
Pull request review is not the only way to spot mistakes
You might be thinking right now “no matter how qualified someone is, nobody’s perfect, and everyone makes mistakes, that’s why we need to review pull requests”.
I get it, some domains require greater care and involve more bureaucracy. In some domains, a tiny mistake could be very bad. Some domains just don’t allow you to trust, they demand you to verify everything. However, not all domains are like that, in fact, most aren’t.
You can get by without gatekeeping pull requests if you have a decent automated test suite. If you have tests that check the most important things you can trust your team. Some smaller mistakes might go through, but small mistakes are easy to fix.
Looking for small mistakes just wastes a lot of time that could be spent doing something more productive.
Of course, there are a lot of projects where automated testing is not a thing and changing a single line of code causes the whole system to explode. Usually, in such cases, the technical debt is so great that even pull request reviews don’t help one bit, because the ways the system breaks are practically humanly unpredictable. Such systems are based on hope, you just throw things into it and hope the world doesn’t explode.
I believe that if your team is skilled enough you can trust people and stop requiring approvals to merge pull requests.
How You Keep Up With Changes Is Up To You
If you think that you need to go through pull requests to keep up with what’s happening in the project it’s fine, everyone has their own way of staying up to date.
What I’m getting at is that pull requests that require approvals introduce a bottleneck to the whole workflow.
Conclusion
A lot of trust issues come down to skill gaps, and people are hesitant to admit it. Trust issues lead to gatekeeping, which slows the whole team down.
Getting rid of gatekeeping requires you to build trust in the team, and you must close skill gaps in order to build trust. If you trust your team then there’s no reason to gatekeep the changes they’re making.
Gatekeeping pull requests is not an efficient way to work. As someone who’s been very involved in pull request reviews, I say that it’s the worst possible way of working (unless you’re working on an open-source project).
The goal of this article is not to tell you what to do with your code review process. The purpose of this article is to make you think more about trust and micromanagement through code reviews. You should be the one to come up with your own conclusions.
You Should Think Twice About Pull Request Approvals was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Giedrius Kristinaitis
Giedrius Kristinaitis | Sciencx (2022-10-27T23:19:10+00:00) You Should Think Twice About Pull Request Approvals. Retrieved from https://www.scien.cx/2022/10/27/you-should-think-twice-about-pull-request-approvals/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.