One Pull Request per Day

Productive engineers should write one pull request per day. One pull request per day creates forward momentum. Forward momentum leads to progress. Progress is how teams overcomes their biggest challenges.

The reaction I get from engineers when I tell them they should write a PR per day is usually one of incredulity.

What about something that takes more than a day?

Big things can be broken down into smaller things. Breaking things down encourages rigorous thinking—if you can’t figure out what the next step is, it’s unlikely you understand the problem well enough.

Won’t this lead to people gaming the system, writing code without substance?

In a high trust environment, this seldom happens because the most effective people care a lot. Trust between managers and ICs is a prerequisite for high-performing teams, but even without that, it’s easy to spot this behavior and intervene.

Another way to prevent this behavior to avoid making the count of PRs a target (Goodhart’s law). It’s a guideline and should prompt discussion.

In the single-player scenario, fears of others gaming the system don’t matter. Do you want to be a high-performing individual contributor? It’s hard to do that without being productive.

What about staff engineers that need to spend a lot of their time talking to people, planning, and researching?

The unit of progress might be different for a staff engineer but the spirit is the same—make progress every day. Have you ever worked with a good staff engineer who isn’t productive?

What if the codebase is too complicated to write a PR per day?

Having worked in a very large and complicated codebase before, I deeply understand this concern. At the same time, some of the most productive engineers I’ve worked with in these organizations far outpaced 1 PR per day. Sometimes knowing that it is possible is enough. Sometimes it will prompt the right questions: what knowledge am I missing, what makes this difficult to contribute to, what’s holding us back?