I was discussing how I work with PRs recently, and apparently coined a new term without realizing: The Micro-PR.

So what is a Micro-PR?

Well, if I need to define it, I’d probably come up with something like:

The smallest possible PR that adds some value to the code base.

That’s kind of boring though. What’s more interesting is how and why I use them.

Before I dive into that, though, let me talk about some of the problems that have been wideley observed with the more “traditional” approach to PRs:

• PRs introduce a queue and lag
• That lag encourages larger PRs
• Large PRs make the lag longer
• Long lag means higher chance of merge conflicts, and delayed feedback, more disruptive context switching…
• Snowball effect ensues

A common approach to solving these problems is pair programming. But not everyone is comfortable pair programming, and not all managers will allow it.

Enter the Micro-PR, and its accompanying workflow.

If we work in a quick cadence of micro PRs, we can solve most of those problems sufficiently… and it can also serve as a nice gateway drug to actual pair programming if/when you’re ready. The process boils down to two stages that oscillate back and forth:

1. Review an un-reviewed PRs by your peers.
2. Work on your next small task, and create a Micro-PR.

Now some clarification on what I mean by a small task. This is where the above definition comes in. Suppose you’re working on a large feature that will require, let’s say, 100 commits. You work on the first commit, and, assuming the code can compile and pass all tests, you commit it as a Micro-PR. This Micro-PR doesn’t represent anything like a full feature. Maybe it just modifies a function to accept a new argument, or it renames a variable, or adds a skeleton class to your project. That’s fine. As long as it’s a step toward your feature, and it compiles and passes tests, it’s eligible for Micro-PR status. Push that and create a PR.

So you’ve done your Micro-PR. Now what?

Well, next you go review a peer’s code. Hop over to GitHub or whatever source tool you’re using, and see if there are open PRs to review. If there are, review them, and unblock your colleagues. If there are not, we have a dillema… (and this is where peer programming still shines over this approach, but more on that another day):

Do you wait for someone to review your latest Micro-PR, or do you work ahead, with the risk that whatever you do next will conflict with some requested change on your pending Micro-PR?

There’s no perfect answer here. But in either case, the risk of waste is infinitesimal compared to when doing traditional, days-long PRs.

Is this a panacea? Of course not.

It really only works well if the entire team (or at least a significant portion of the team) is committed to the Micro-PR flow. Otherwise you’ll find yourself waiting hours or days for a 2-line PR to be approved.

But if you can get your team on board, I’ve had good success using this ideal as a way to get developers to go from weeks-long feature branches to days-long branches to hours-long branches, and eventually to minutes-long branches.

Eventually, you may start to feel that even Micro-PRs involve too much waiting, and the next natural step from there is pair programming: “Share my screen and lets write this feature together. Then you can immediately approve it once I create the PR.”