Trying to measure developer productivity is a famously difficult and often misguided effort. IBM’s historic attempt to gauge output by lines of code written is perhaps the most notorious example. It rewarded verbosity over clarity and activity over outcome.
Yet despite the limitations of rigid metrics, some patterns consistently emerge when you observe highly effective software engineers. At Flare, one habit we’ve seen repeatedly among our best developers is simple and powerful:
They make small and frequent merge requests.
In this post, we’ll unpack why this behavior works so well and how it supports better collaboration, faster iteration, and stronger product delivery.
Why Small, Frequent MRs Work
1. They Reflect Deep Understanding
At Flare, we work within a Shape Up-inspired product development framework. A large part of each cycle is spent on shaping and understanding the problem. By the time execution begins, the scope is usually de-risked and well understood.
When a developer has that deep understanding, they naturally break the work down into clear, manageable chunks. Each merge request becomes one of those chunks: focused, self-contained, and purposeful.
2. They’re Easier to Review and Safer to Ship
Large change sets are difficult to review thoroughly. Even experienced teammates can miss important details when too much is packed into a single MR. In contrast, small MRs:
- Surface issues earlier
- Make reviews faster and more focused
- Reduce the risk of regressions
- Are easier to revert if something goes wrong
This supports faster iteration and higher confidence in production releases.
3. They Encourage a Collaborative Mindset
A steady stream of small MRs creates rhythm in a team’s workflow. It encourages collaboration, builds trust, and makes progress visible.
Being stuck on something for too long, however, is a red flag. In one of the most effective teams I’ve worked with, we had a simple rule: if you were blocked for more than 40 minutes, raise a flag. That one principle saved days of frustration and kept momentum high.
What About Big Refactors?
None of this means that large, exploratory change sets have no value. Sometimes, a big refactor is the best way to learn. I often create a scratch branch where I pull apart a system to understand it better.
But that’s not what I submit for review.
Instead, I use that learning to map out a sequence of clean, logical steps. Then I go back and start fresh, delivering the solution through a set of small, testable MRs. That’s when the real progress begins.
Summary: Strong Developers, Small Chunks
Here are a few things you’ll often see among high-performing developers:
- Merge requests are small, focused, and submitted regularly
- Blockers are raised early and solved collaboratively
- Large refactors are used for learning, but final changes are delivered incrementally
Frequent, small merge requests are more than a habit. They’re the outcome of thoughtful problem-solving and deliberate communication. If you want to move fast and build confidently, this is one of the clearest paths forward.
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.