Merge One PR Per Day

When new software engineers join my team they see a goal for each team member:

At least one PR per day merged into the mainline branch.

This goal often creates fear that comes in two forms:

1. If I don't get one PR merged per day I will be fired.
2. I must ship an entire completed feature per day.

I’m not expecting them to ship an entire feature on any given day. And I’m not looking to use this as a stick to beat folks with. But shipping one PR per day requires specific practices that are not obvious to all software engineers.

Why bother?

If you’re getting one PR merged into the mainline branch every day you're secretly practicing continuous integration. This comes with a huge number of benefits.

The biggest is that you avoid what I call solo developer syndrome.

You’ve seen this one before. When Dave on the team goes heads down for weeks. His daily update is consistently “almost done with the thing”. When the time for code review comes, he drops 8,000 lines of deep, unnecessary abstractions, and incoherent class and variable names. The team has no idea what’s going on or where to even start to gather understanding. No one wants to be the one to review it, because who wants to attempt to review that much code? Even when it’s well written. At the same time, Dave insists this meets the business’s needs, and he was supposed to ship it two weeks ago. The worst part is about two weeks after he walks away from the work it becomes completely incomprehensible, even to him. The team has just created a haunted graveyard. No one will touch it, because spooky ghosts lurk there, waiting to break whatever you’re trying to tweak.

By ensuring your code is integrated, and subject to review from your team frequently, you make it much more difficult to get into this state. In the event that you do push unmaintainable code, the amount you've pushed is smaller, so you have less to clarify and unwind before continuing onward. Long term you get more maintainable code, and a better engineer and team experience.

The long and short of it means that you get faster, more frequent feedback. With a proper system in place you can use this to grow as an individual faster.

Organizations that practice continuous integration are shown to have better business outcomes based on the DORA research. These include things like better profitability, productivity, and market share compared to competitors, as well as lower levels of burnout, and higher levels of employee job satisfaction.

The most minor benefit is avoiding merge conflicts and allowing other folks on the team to take advantage of the changes that you're making sooner.

Steps for individuals

If you're not hitting one PR per day, here are a few practices from my experience that can help you to consistently merge one per day. Every day. This way you can get more reps in faster, and get ahead in your career.

If you're like many software developers I've worked with, you’re probably not used to sitting and thinking through an implementation before banging out the code.

I know I still want to sit down and start coding, because it feels better. It feels like you’re making progress, even if you’re ultimately painting yourself into a corner.

But stop. Take a breath. Put away the code. Think about how this problem can be solved.

I’ve saved myself weeks of work by sitting and thinking through a problem, realizing that if we asked users for one readily available additional piece of information we wouldn’t need an entire complicated and error prone process to programmatically guess it.

You may be used to writing the entire feature on a branch before you merge it in. This is going to stop you from being able to merge one PR per day, and stop you from learning and iterating faster.

Part of stopping to think through the problem, allows you to break down a piece of work in a way that you can submit one or more PRs per day. You can find likely seams in your code that are good breakpoints, that can be sent up without breaking production.

Breaking down your work means you’ll also need to learn how to write more clearly about what the larger issue is, and how this small PR fits into the larger picture.

Finally, you need to write tests. The tests ensure that you maintain momentum, and don’t have to spend each day verifying that the code you’ve added or modified doesn’t break existing functionality.

If you’ve clearly broken down the work ahead, you can write the tests first as well, and they form a checklist of what you need to implement in order to call a PR, or a larger feature, complete.

One PR per day is a systems goal

But if you understand how to break work into smaller chunks, then it’s time to examine systemic issues. These are things you’re likely going to have to discuss with your manager and/or product manager, but a great place to start is with the following list:

1. Does the team understand the problem space?
2. What about the possible solutions?
3. Do you have access to user experience and design input?
4. Is the team available to review your code?
5. Do they have the necessary context to review it?

Do you have time to actually write one PR each day? Or do you spend most days in back to back meetings with two 30 minute blocks to write code? (And one of those is lunch.) It’s worth thinking about your day in terms of maker vs manager schedules, and that you need uninterrupted time to craft your solutions. Unfortunately you will need to talk to your manager to resolve this one. If you just stop showing up to half the meetings on your calendar, you’re going to have a bad time.

If your organization isn’t used to conducting code reviews, or doesn’t require them, you’re going to need to actively seek reviewers for your code. Even if they’re mandatory, everyone will have a better time if you actively seek out the individuals best suited to review your code, and ask for feedback that they are best suited to give. Find folks that have experience or context in the areas that you’re extending or modifying to ensure that your mental model matches theirs. Find folks that are experts in the language or framework that you’re using, and ask them for pointers there.

You’re also going to want to ensure you’re returning the favor. Review others' code when it comes in, and ensure that everyone has a good experience with it. If you piss everyone off,you’re going to make it much harder on yourself to get reviews.

All of these are things that need to be addressed to ensure you can ship one PR per day. You’re likely going to have limits on how much you can affect them, but addressing each of them to the best of your ability is critical.

So go forth and merge one PR per day, knowing that this is a goal designed to help you, not to get you fired.