Worst offender is when a dev decides to reformat code and you can't even differentiate at a glance what is real code change and what is reformatting. Fortunately modern tooling formats code automatically so there's less bikeshedding.
[deleted]
Large pull requests slow down development
41–50 of 79 posts
Re: Large pull requests slow down development
#42Where I work it takes several hours to get a PR past all the merge gates. If I have 5 small PRs that all build one on top of the other, it can take me the better part of 2 weeks to get them all merged, counting all the context-switching, tweaking based on comments and relaunching of the merge checks, etc. The only way developers are able to make any kind of velocity in their work is to babysit their PRs morning, even…
You must work at a big tech company. Thats utter insanity.
Re: Large pull requests slow down development
#43Where I work it takes several hours to get a PR past all the merge gates. If I have 5 small PRs that all build one on top of the other, it can take me the better part of 2 weeks to get them all merged, counting all the context-switching, tweaking based on comments and relaunching of the merge checks, etc. The only way developers are able to make any kind of velocity in their work is to babysit their PRs morning, even…
Isn't the problem here the flaky and long running PR gates? There's room for nuance to say "small PRs are a north star but large PRs are sometimes OK too"
Re: Large pull requests slow down development
#44There is one place where large pull requests are essential: In dysfunctional orgs with enormous code review time per PR, with lots of nitpicking, and a CI/CD pipeline that is constantly broken and takes a LONG time to get things into a staging environment.
and then you send it to your friend on the weekend for a blind approval? :P
Re: Large pull requests slow down development
#45[deleted]
Re: Large pull requests slow down development
#46I suppose I agree but I don't think it's really accurate. You can make large, easy to review PRs but if the commit history isn't useful then you have to view it all in one big chunk. If instead you take a note out of the patchset workflow and make each commit it's own fairly discrete and digestible change after you wrap up development on the feature, then reviewers can just start on commit 1/N and review each one as…
Most people are not that good at git from my experience to be able to do this.
Re: Large pull requests slow down development
#47Where I work it takes several hours to get a PR past all the merge gates. If I have 5 small PRs that all build one on top of the other, it can take me the better part of 2 weeks to get them all merged, counting all the context-switching, tweaking based on comments and relaunching of the merge checks, etc. The only way developers are able to make any kind of velocity in their work is to babysit their PRs morning, even…
I mean this is mostly just a devops issue though no? PR’s used to take a solid week to merge at my company with a 10 hour CI that had a ~50% success rate when the code worked. But we put a bunch of resources toward build times and ci run time and now it mostly works. Yea, you can circumvent a shitty pr system by just making massive pr’s but wouldn’t it be easier to have the devops team fix your broken system?
> devops team
Ah… about that
Re: Large pull requests slow down development
#48This article implicitly assumes that a single PR corresponds to a single commit. It doesn't touch on the idea of multiple commits in a single PR.
Consider adding a feature. I might structure this as three commits:
1. Refactor in a way that preserves existing behavior but prepares for the new feature
2. Implement the feature, creating a user-visible change
3. Remove old code rendered unnecessary with the new feature
Each of these commits is independently reviewable, passes all lints and tests, and supports bisecting. Small, separate commits like this is good.
But there's no rationale for three small, separate PRs, because they are not independent. Either all the commits should land, or none of them. If we later revert, we would revert them all. And review is made easier by seeing how the commits relate to each other.
I suspect that structuring PRs as multiple independent commits requires a certain level of git history-grooming which is difficult to learn. If git's interactive rebase were more first-class, we would have fewer, larger, and better-structured PRs.
Re: Large pull requests slow down development
#49Where I work it takes several hours to get a PR past all the merge gates. If I have 5 small PRs that all build one on top of the other, it can take me the better part of 2 weeks to get them all merged, counting all the context-switching, tweaking based on comments and relaunching of the merge checks, etc. The only way developers are able to make any kind of velocity in their work is to babysit their PRs morning, even…
I mean this is mostly just a devops issue though no? PR’s used to take a solid week to merge at my company with a 10 hour CI that had a ~50% success rate when the code worked. But we put a bunch of resources toward build times and ci run time and now it mostly works. Yea, you can circumvent a shitty pr system by just making massive pr’s but wouldn’t it be easier to have the devops team fix your broken system?
Depends on what your code does. A lot of my code runs robots. You can't scale horizontally because you can only fit so many systems in a room before you run afoul of production limits, safety requirements or cooling capacity. You can't scale vertically because zoning. You can't run the tests faster because physics.
So, you either run the expensive tests asynchronously and all that entails or you allow CI to take forever.
Re: Large pull requests slow down development
#50The title seems to imply that "slow down development" is a bad thing. Given the immense churn and the result of what passes for software these days, I disagree.