In partnership with
6 months after starting as a frontend dev, I was staring at a piece of code.
Dumbfounded.
The logic was tangled. I couldn't find my way through it.
"Who wrote this?" 🤔
I checked git blame, ready to hunt down the culprit.
There it was, in plain sight: Blame nfdiop.
I wrote that monstrosity. And now I had to deal with it.
"Why did anyone let me merge this?" I went back to the PRs and realized why.
My PRs were massive. No one could reasonably give me a thorough review. Those big PRs cost me valuable learning.
Since then, I've reviewed over 3,000 PRs. The pattern is always the same: big PRs get shallow reviews.
Here are 7 reasons to keep yours small.
TLDR
Small PRs get faster, more thorough reviews — you learn more
Reviewers procrastinate on big PRs; small ones ship sooner
Big PRs force all-or-nothing reverts when things break
AI-generated code hides subtle bugs; smaller PRs make them easier to catch
Splitting PRs builds your decomposition and architecture skills
Parallel reviews from different reviewers unblock you faster
Small PRs mean fewer merge conflicts
1. You get reviews that actually teach you
Imagine handing someone a 400-page novel and asking them to proofread it by tomorrow. Now imagine handing them a 10-page chapter. Which one gets real feedback?
Same with PRs. When a PR is big, reviewers focus on the big picture and miss the details. Those details, a cleaner pattern here, a better naming choice there, are what build your coding instincts as a junior dev.
With big PRs, reviewers get tired or miss things. With small PRs, they have the bandwidth to teach you.
Don't be "old" me 😅.
2. Small PRs ship faster
Whenever I have a big PR to review, I keep putting it off. A small PR? I knock it out in minutes.
I'm not the only one. Opening 3 small PRs gets you to production faster than 1 big one.
3. Reverts don't kill all your progress
I once had a big PR with unrelated changes finally merged, only to revert the whole thing because of one broken piece.
Most of the code was fine. But everything lived in a single PR, so all progress was lost.
With smaller PRs, the working features ship independently. Only the broken piece gets reverted.
Example:
Say you build a new filter component, update the API call, and refactor a shared utility, all in one PR.
The utility refactor breaks something. Now the filter and API work are reverted too. Three small PRs? Only the utility gets rolled back.
4. Bugs hide better in big PRs
Big PRs were already hard to test. AI makes it worse.
AI-generated code looks clean but can hide subtle bugs that aren't obvious at first glance. AI-powered review tools help, but they miss things too.
Smaller PRs mean less code to review. Fewer places for bugs to hide.
5. Splitting PRs sharpens your architecture
Striving to split my PRs improved my skills in two ways:
File organization — I had to structure files so different reviewers could work in parallel without conflicts. No more spaghetti files with all the logic crammed in.
System thinking — I had to think about all the components upfront and how they fit together. This forced better separation of concerns.
6. Parallel reviews unblock you
This is the best perk of small PRs.
Say you have three colleagues. Instead of waiting for one person to slog through your giant PR, open 3 small, independent PRs. Tag a different reviewer on each.
You move three times faster. And if one PR gets blocked by feedback, you keep working on the others instead of sitting idle.
7. Fewer merge conflicts
Big PRs sit in review for days. The longer they sit, the more your teammates' changes pile up on the target branch.
By the time your big PR is approved, you're resolving conflicts you wouldn't have had if you'd merged smaller pieces along the way.
Small PRs get reviewed fast, merge fast, and stay out of each other's way.
How small is small enough?
My rule of thumb: a PR should do only one thing. If I start writing the PR description and I use "and", "also", or "as well as", I know it's too big.
Ask yourself:
Can I ship the refactor separately from the feature?
Can the types or interfaces go first?
Can the tests be their own PR?
If the answer to any of these is yes, split it.
Conclusion
When you join as a junior dev, you feel pressure to prove yourself and ship fast. I know I did.
But big PRs hurt your growth. You learn less, introduce more bugs, and wait longer for reviews.
Shipping fast and shipping big are not the same thing.
Keep your PRs small. Your future self will thank you.
That's a wrap. If this helped, share it with a junior dev who needs to hear it ❤️
💡 AI TIP
Use the /grill-me skill from Matt Pocock to build the right thing.
