Large pull requests slow down development
graphite.dev
Large pull requests slow down development
1–10 of 79 posts
Re: Large pull requests slow down development
#2I agree, but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal.
I prefer incremental and used to roll my eyes at them, but it's just a different way of thinking and people/teams are diverse.
Re: Large pull requests slow down development
#3I believe that there's certain things (particularly ambitious net new feature development) that isn't served well by artificially minimizing PR size.
You should absolutely strive to keep smaller PRs, but I've frequently seen this become "you should only have small PRs."
Re: Large pull requests slow down development
#4I agree, but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal. I prefer incremental and used to roll my eyes at them, but it's just a different way of thinking and people/teams are diverse.
> [...] but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal.
It doesn't really matter. You can start with a big change initially as a 'big thinker'. You just have to break it down afterwards.
I often have a bit of feature creep when working on a change, and add all kinds of incidental fixes I find along the way.
But afterwards, I use git's tooling to 'peel off' all those extra changes and stick them into their own PRs. That makes my main PR slim again. If the main thrust is still to big after that diet, I think about breaking it down into incremental changes that make sense for reviewers.
That process of breaking down is all about telling an understandable story to reviewers (both reviewers right now, and the poor folks who have to look at my commits in a few months to figure out when and where we introduced a bug, or why certain decisions were made. Those poor folks often include my future self.)
> I prefer incremental and used to roll my eyes at them, but it's just a different way of thinking and people/teams are diverse.
Some people produce incremental PRs naturally, and that's great for them. But for the 'big thinkers' it's a learnable skill to break their PRs into manageable chunks after the fact. No need to change their natural style.
Re: Large pull requests slow down development
#5It seems to me the size of the PR is a function of the complexity (i.e., the lack of simplicity in the design / architecture). In that case, large is a symptom. What's ultimately slowing things down and adding risk is the complexity.
Re: Large pull requests slow down development
#6*Large pull requests slow down code review up to a point where large enough pull requests promote less thorough and quicker review
Spared you 5 minutes
Re: Large pull requests slow down development
#7I agree, but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal. I prefer incremental and used to roll my eyes at them, but it's just a different way of thinking and people/teams are diverse.
> [...] but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal. It doesn't really matter. You can start with a big change initially as a 'big thinker'. You just have to break it down afterwards. I often have a bit of feature creep when working on a change, and add all kinds of incidental fixes I find along the way. Bu…
I like this take. The onus is on these devs to learn how to use available tools effectively to split up their changes.
There's a clear parallel here to the idea of a "genius" who isn't able to communicate their ideas effectively. Can they really be considered that smart if no one understands them?
Re: Large pull requests slow down development
#8I believe that there's certain things (particularly ambitious net new feature development) that isn't served well by artificially minimizing PR size. You should absolutely strive to keep smaller PRs, but I've frequently seen this become "you should only have small PRs."
Honestly "you should only have small PRs" is one of those cultural things more people should invest in. Small changes really are both faster and less bug-prone.
To make it work, you have to think differently and code differently. You have to think in advance: "does what I want to do require changing a lot?" If so, think about how else you can solve your problem. Or when implementing something for the first time, think about how difficult it would be for someone to change it.
You end up building things with high cohesion, low coupling, object factories, etc. It makes for very different code that is more maintainable, flexible, easier to change. You end up not needing a big PR, or the changes are to a single high-cohesion component so it's much easier to review than changing 10 different components.
Re: Large pull requests slow down development
#9I agree, but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal. I prefer incremental and used to roll my eyes at them, but it's just a different way of thinking and people/teams are diverse.
People can be trained to make smaller PRs. I am guilty of big PRs, but each time I'm told to split up my PRs, it helps me the next time when I remember the pain of splitting it up late. So I'm getting better about making smaller PRs. I just need people to push back more and I'll learn even faster ;)
Re: Large pull requests slow down development
#10I believe that there's certain things (particularly ambitious net new feature development) that isn't served well by artificially minimizing PR size. You should absolutely strive to keep smaller PRs, but I've frequently seen this become "you should only have small PRs."
Net new feature development is often 20% or less of the job. With most guidelines like this, it's always possible to find exceptions -- but understanding why you're making the tradeoff in that situation is key.
With that said, using methods like stacking and feature flagging, I've been finding even new feature development to be possible while keeping my PRs to roughly 5 files changed or less.