The Power of Tiny Pull Requests
Why I Use Tiny PRs and Why You Might Want To
I care about writing clean, maintainable code, and helping teams deliver software that matters. Over time, I’ve come to appreciate the practices that make development smoother and even enjoyable. Iterative Development, CI/CD (Continuous Integration/Continuous Deployment), and Test-Centric Development (I’ll admit I’m not a strict TDD purist) approaches have all played a role. One habit in particular has stood out to me over the years: working in tiny pull requests.
The Problem: Big Complicated PRs
One PR per Story
Before adopting Tiny Pull Requests, my team’s default was One PR per Story—which led to Big Complicated PRs. Mentally it made sense, but it had several drawbacks:
🕰️ Slow Reviews - Difficult and time-consuming reviews often resulting in a backlog of unreviewed PRs
⌛️ Development Delays - Slower development and integration leading to increased merge conflicts and stale branches
🐛 Hidden Bugs - Higher chance of mistakes due to superficial or LGTM (Looks Good To Me) reviews
🔍 Tricky Debugging - Complicated debugging when a bug is found because it is much harder to pinpoint the exact source of the problem due to the extensive changes
🚫 Refactor Resistance - already bloated PRs discourage refactoring and ongoing improvements
Our process tweaks helped, but not enough. We tried blocking off a few hours every day or dedicating specific days each week to review the PR backlog. I even experimented with breaking up PRs into multiple commits designed to be reviewed separately. Still, there was very little overall improvement. Reviews remained painful, morale sank, and delivery velocity never improved.
The Solution: Tiny PRs
Tiny PRs aren’t a rigid template. They’re a mindset
Ironically, none of us had considered breaking a feature into multiple small Pull Requests. That changed when Kevin Howard gave a presentation on the idea. We decided to give it a try, and honestly, I was very skeptical at first. Like learning anything new, I struggled initially, but eventually we found our rhythm.
What is a Tiny PR?
Defining a Tiny Pull Request precisely is tricky—it’s one of those “you know it when you see it” kind of things. But in general, it has a few key characteristics:
📏 Small in size - A Tiny PR is less about a hard rule on line count and more about making the review process easier. It should bundle one clear, meaningful change so the reviewer can stay focused and maintain context. As a rule of thumb, I aim for around 100–200 lines of changes. That size typically keeps things digestible without overwhelming the reviewer. But it’s just a guideline. If it makes sense to go smaller or even a bit larger while staying focused, that’s fine.
🐿️ Shippable - Every Tiny PR should be safe to deploy to production. That means the change is either temporarily unused (or “dark”), fully complete, or backwards compatible so it won’t break anything in production. If you need to introduce something risky or breaking, use a feature toggle or flag to keep things safe. The goal is to keep delivery moving without creating risk.
🎯 Has a Single Purpose - A Tiny PR should focus on a single, well‑defined goal so reviewers don’t have to juggle multiple threads of changes at once. That means breaking a feature into a clear series of small, self‑contained PRs. For example, like defining the API, then stubbing the endpoint, then adding each integration, and finally composing the full logic. This keeps the review manageable, lets feedback come faster and more accurately, and avoids overwhelming reviewers with too many unrelated updates.
Tiny PRs aren’t a rigid template. They’re a mindset: make each change small, self‑contained, safe to ship, and easy to review. Over time our feedback loops tightened, merge times improved, and reviewer fatigue dropped. We started moving faster without losing quality.
Benefits
I can say it’s almost like having a super power
After practicing this technique now for probably over 7 years, I can honestly say: it’s almost like having a superpower. Tiny PRs aren’t just a productivity trick. They fundamentally reshape how teams build and ship software. Here’s why they are so powerful:
🧭 Promotes Tight Feedback Loops
It’s the difference between navigating with sonar pings every few minutes…. vs once a week.
One of the biggest challenges with Big Complicated PRs is the lack of frequent feedback. Tiny PRs fix this. They create a clear, minimal surface area for reviewers to react to. When there are only a few changes, the conversation naturally centers on just what’s changed. And that means:
Faster, easier reviews
Less hesitation to give feedback
More immediate course-corrections
Open, documented decisions - Design discussions and implementation tradeoffs are captured in the PR for anyone to revisit later
It’s the difference between navigating with sonar pings every few minutes…. vs once a week.
🔍 Improves Feedback Quality
Smaller really is better when it comes to code reviews.
Tiny PRs lead to:
Faster reviews – A handful of well-scoped changes takes minutes, not hours.
More focused comments – Reviewers aren't trying to juggle multiple concerns at once.
Higher defect detection – Research suggests that the ability to find defects diminishes as the size of the change increases.
By contrast, large PRs tend to:
Overwhelm reviewers – It’s hard to stay focused through hundreds of lines.
Encourage rubber-stamping – “LGTM” often really means “I didn’t have time to read it all.”
Miss issues – Complex PRs hide subtle bugs, especially when reviewers mentally check out halfway through.
🔄 Encourages Continuous Integration
Tiny PRs are CI-friendly by nature.
Because each PR is smaller and more self-contained:
They integrate more frequently, helping catch integration issues early.
Merge conflicts are minimized, because branches stay short-lived and up-to-date.
CI pipelines run more smoothly, since each change is smaller and easier to test in isolation.
In other words: less “integration hell,” more shipping.
🧠 Reduces Context Switching
Big PRs don’t just burden reviewers. They wear out the developers too.
When you write a huge PR, it takes effort to re-read, explain, and recall your thinking, and remember why you did what you did. And when reviewers finally respond, you’ve probably moved on to something else entirely.
Tiny PRs flip the script:
You stay mentally close to the change.
Reviewers get it while it’s still fresh in your mind.
Fixes and improvements happen faster.
This drastically lowers the cost of switching contexts and reloading all that mental state.
🚀 Builds Momentum
Tiny PRs make shipping feel effortless.
You get faster merges.
You unlock dependent work more quickly.
You build trust through consistency. Fast, clean PRs become a reputation of reliability
You feel progress being made.
And that’s no small thing. Momentum is one of the most underrated forces in software development.
Common Objections
Tiny PRs aren’t perfect, and they take some getting used to. But after years of practicing them, I’ve seen that most of the pushback comes from assumptions that don’t hold up with a little experience. Here are some common concerns and why they shouldn’t stop you from giving it a try:
“Won’t this create more overhead?” - At first, yes — it can feel like more work. More branches, more PRs, more context switches. But that overhead fades quickly as your team adjusts. You’ll spend far less time reviewing, resolving conflicts, debugging complex changes, or waiting for someone to read a 5000-line PR. In the end, it saves time, not wastes it.
“This feels like busywork” - Try it anyway. You don’t need team-wide buy-in on day one. Break just one feature into multiple PRs and make your case by showing results. Faster merges, cleaner changes, and less back-and-forth in code reviews are hard to argue with once people see the benefits.
“It can’t be done for this feature” - There are definitely situations where breaking things down is harder. But that’s different from impossible. If you look closely, there’s almost always some natural boundary you can work with. It might be a model, controller, service, repository, database migrations, or even config changes. It’s a skill that gets better with practice.
“It’s too difficult” - Like any habit, it feels awkward at first. You might spend more time thinking about how to slice work. But that’s actually a good thing. You’ll end up with cleaner commits, better test coverage, and more intentional design. Tiny PRs force clarity, and that’s worth a little extra effort up front.
“What do I do while waiting on reviews?” - Keep moving. If I’m blocked on one PR, I usually stack the next one on top of it, or shift focus to reviewing my teammates’ work. It’s also a great time to groom the backlog, jump in to pair with someone else, or do some light refactoring in the area I’m already working in. Even small cleanup can make a real difference later.
Bottom line: Tiny PRs aren’t about being perfect. They’re about favoring fast feedback, quick delivery, and easier reviews. You will have to compromise sometimes. But the tradeoffs almost always lead to better team flow, fewer surprises, and higher quality code.
Give It a Try
If you’ve never worked this way, it’ll feel different at first. That’s normal. Start small: take one story and break it into a few focused, reviewable pull requests. Keep each one clean, safe to deploy, and easy to understand. You don’t need a team-wide rollout or a big process change to get started.
Just try it once. Watch what happens. Faster reviews, fewer merge conflicts, and better conversations might follow.
You don’t have to take my word for it. Let your own experience convince you.
