Dan Lines

Hey, what's up, everyone? Welcome to my talk today titled "Merge Pull Requests in Half the Time: Five New Ideas to Do So." Super interesting topic, as it is affecting most developers in the world.

Before we get to that, a little bit about me. My name is Dan Lines. I'm the co-founder and COO at LinearB. I get to work with engineering teams and some of the top engineering leaders in the world. I am also the founder of the Dev Interrupted community and the host of the Dev Interrupted podcast. Of course, I'm a former VP of engineering and former developer, and the coolest thing about the pod is that most people want to talk about developer productivity, which is the main point of the talk today.

01The Pull Request Paradox

I am going to start with the pull request paradox. Pull requests are highly, highly adopted. Probably about 90% of the teams that I work with are utilizing pull requests. It's the strongest new methodology since Agile, correlated with the rise of open source and GitHub and GitLab and Bitbucket; really has become a standard in modern software development.

Pull requests provide a lot of value. Even a lightweight review from a peer can detect up to 65% of bugs. Seventy-five percent of the bugs are around maintainability, technical debt, things like that, and they're hard to detect in an automated way. Pull requests are also really nice for junior developers or new developers working to improve their careers by getting feedback from a more senior developer. There's probably no better way to do it.

The number of software developers is going up every single year, and maybe by 2030 we'll have 45 million software developers, which means there'll be a lot of new people and junior developers entering the market.

That gets us to our pull request paradox. Pull requests are very valuable, but here's the problem. We have a developer that's super excited. They just solved a new problem, and developers love solving problems, and they are ready for a review. But the issue is they need a review from another developer that is solving their own interesting problem, and they're not available right now.

So developer number one is waiting, waiting, and they're moving on to the next cool thing. They don't want to stay idle, and they start working on their next branch, the new problem they're trying to solve. A day goes by, or even two days go by, and now the reviewer is available and saying, "Hey, I have some questions about your PR."

Of course, the original developer is already on to something new, completely forgot about that PR, and lots of cognitive issues start happening, like idle time and transition time.

02LinearB Labs Data

We have an awesome research team at LinearB. We have the ability to analyze millions and millions of pull requests, and here's a few pieces of data that have come from LinearB Labs. First and foremost, pull requests are two-thirds of cycle time.

If you don't know what cycle time is, cycle time is one of those golden engineering organization health metrics made famous by the DORA team, and it measures how much time it takes on average to go from coding on a branch all the way to deployment to production. If you don't have cycle time or you're not measuring cycle time today, definitely do so.

The key information here is that, on average, pull requests are taking four days and 10 hours of the total cycle time. That's just a crazy amount of time in that PR pickup time and in the PR review time itself. PR pickup time means: I open a pull request; how long does it take for someone to start reviewing it?

The other thing that we found is that most pull requests sit idle for half of their lifespan. Fifty percent of PRs are just sitting there. No one's working on them or giving feedback on them for 50% of their lifespan, and 33% of PRs are idle for more than 75% of their lifespan. No one is doing anything with them, which is obviously not a good thing.

03Idle Time and Cognitive Load

There's some inherent idle time, or we call transition idle time, that hurts developer productivity. You might not think that this is a big deal. This is a big deal.

If I'm a developer, I need another developer to review my work, and inherently there's a handoff that creates delays. The developer that is picking up my PR for review doesn't have the context of what it is. They're treating all PRs maybe exactly the same at first glance. They don't know if it's a fast review, a long review; maybe they think they need to block their calendar for half a day to get the review done.

All of this transition time back and forth between the two developers, like if there are requests for code changes, increases the cognitive load: the time I have to spend thinking about going back and forth between developing over here and changing the code that you requested me to do. It causes longer cognitive reload times, it leads to lower quality, and there's more and more context switching happening back and forth. This is transition idle time in the PR process.

There's also another type of idle time called distraction idle time that hurts developer productivity. This is when the PR reviewer starts a PR review and then might get interrupted by someone else and has to stop and start again. It might be a very large PR and it's taking a large amount of cognitive thought processes, and I might need a break after 15 or 30 minutes. Every time this starts happening, I have to get back into the PR; I do a cognitive reload. Where was I? Should I start from the beginning? Do I have the context? I need to reread the code, reread the comments, and this distraction time really hurts developer productivity.

04Five Ideas to Optimize Pull Requests

I have five ideas to throw at you all to optimize the pull request flow.

The first one, and this is like the golden one: keep your PRs under 200 lines of changes. Or another way to say it: do small PRs, small digestible PRs that are easy for the reviewer to pick up quickly and review quickly.

As PRs get larger and larger, the amount of time it takes for them to get merged gets larger and larger and larger. PRs with over 600 lines of change take 3.5 times longer than PRs with small ones, 50 or fewer changes, and two times longer than PRs with 50 to 200 lines of change. Small PRs are picked up faster by the reviewer. The comments are put on there faster, they're merged faster, and there's less code change. Keep your PR small, super important.

Second idea: add context to your PR. It's table stakes, but make sure that you have real-time alerting. If I get assigned a PR, I want to see in Slack or MS Teams, "Dan, you've been assigned this PR." But I also want the additional context in there.

What is the related issue? We're talking, for example, a Jira issue. Is this urgent, not urgent? Is it a bug, a feature? Is it for a customer? I need to know what this is about. I need to know the risk areas in the PR. These are the two files that you should really spend time on, or here's the function that I'm most worried about that needs to be optimized. Where should the reviewer spend time?

The last one that I have bolded on here: estimated time of review. Tell your reviewer how much time you think, or in the case of LinearB, how much time we see from data it will take to review the PR.

When you add this estimated time of review, it really helps the reviewers optimize their schedule. They can say, "Oh, okay, I just stopped coding. I have five minutes before lunchtime. I see that this PR will only take about three minutes of my time. Let me get this in before lunch right now." Or they might say, "Okay, I'm seeing a 30- to 45-minute estimated time of review. I'll make sure that I block my schedule off in the afternoon, so I'm not getting interrupted back and forth. I'll put it on my calendar, or I'll go to a room. I'll get this done in the most efficient way so we don't have those cognitive reloads over and over." Context is really important for PRs.

Another thing that's really important, this is what the data shows us: finish important PRs in one day. PRs that are open for more than 24 hours take longer and longer to actually get through the PR review cycle.

Start and finish PRs in the same day. If you have a PR that you want to get merged within 24 hours, open the PR in the morning. That's a really good time to get attention of reviewer. Find a reviewer within one hour. Add a lot of context to the PR; let them know how much time it will take to actually review. And when the reviewer is giving you feedback or requests changes, be available right there to either change the code or respond to a comment. Getting your PR merged within 24 hours is super important for an efficient merge process.

Idea four: go synchronous for pull request reviews instead of async. I know this is a little bit against maybe your intuition or the original purpose of PRs. It's like the idea of how when you're riding a bike and you start moving faster, things get more and more stable. When you're going slow, async, I'm going to get an email notification. You request changes. I do it tomorrow. Then I have to get another piece of feedback or a comment. That really slows things down.

As a developer, how can I create the best experience for my reviewer? I want to know when they're starting their review. I want to be available to respond really, really quickly. I want to reduce that idle time and reduce the cognitive load for both of us.

Notify the PR issuer when review is started. You've got to know when the review is started. That's a must-have. You could find a conference room if you're back in office. You could start a pairing session over Zoom or something like that. Schedule a time to get your PR reviewed quickly. Schedule a time to do it together with the reviewer.

The last idea, idea number five: discuss review time and pickup time in your retros.

As part of the sprint retro, which most teams do, talk about review time, talk about PR pickup time, see how long it's taking the team to get PRs merged. Talk about the efficiency.

One of the things that's really, really important for engineering teams is predictability in their iteration. Are we doing what we say we're going to do? In this case, I call it planning accuracy. Are we predictable in getting the things done within the sprint? One of the things that will make that not happen is having an inefficient PR process. If you measure this, talk about it in the retro, and do some of these tips to improve, I guarantee that you'll hit more of your sprints on time, and that's why it's so important.

05LinearB Tooling

LinearB can help out with this. We have a tool at linearb.io. It's a free trial. It can benchmark your team and track goals. We'll show you your cycle time, and we'll show you where the bottlenecks are in the cycle time. You can see on a team-by-team basis if the team is struggling with picking up the PR or reviewing the PR.

We've added a feature called Team Goals, so each team can set working agreements and say, "Okay, we'd like PRs to be picked up within five hours, and we'd like reviews to be done within seven hours, and we have a goal to do this, merge PRs all within 24 hours." You'll get Slack notifications of how you're trending against this and be able to track it and discuss it in the retro.

With the LinearB product, every developer gets this bot called WorkerB, for either Slack or MS Teams, and it automates improvements of these working agreements. It cuts out the noise. It only delivers notification to each developer when they're either called upon for a review or there's a change request. It includes that estimated time-of-review thing that's so important for the reviewer to be efficient with their time. In this case, it's saying, "Okay, the estimated time of review is six minutes." It will also automatically always include the related Jira issue or project management tool of your choice for that context.

Lastly, we also have a free Chrome extension called WorkerB for Pull Requests. You can go to the Chrome Web Store and just search for LinearB. It'll be the first thing that pops up. This is a browser extension. It's totally free. You don't need Git or any code access. It gives that estimated time of review, both for the developer, the PR owner, and for the reviewer.

It will notify you as the PR owner when the reviewer starts viewing your PR, so you can make yourself available, get that PR merged within 24 hours. Totally free. Check this out.

That is it for my session. I hope everyone is enjoying the conference. And again, I'm Dan Lines from LinearB and Dev Interrupted. Thank you for having me here today.