Is there a little corner here of people who don't like Pull Requests / Reviews as the default way of “collaborating on code”? Whenever I’m expected to push “small” PRs, my work slows down sooo much. I always considered myself to be a fast prototyper with code, being able to build stuff faster than teams. Especially with research and exploration, I want to explore fast and stay in the flow and can't wait for my work to be reviewed because the reviewer prefers small changes. Because when I make a PR and want to continue, I make more PRs but those start to depend on earlier (unmerged) PRs. When others aren't available for review… my work piles up and it gets harder and harder for me to see the full picture. Why is this the accepted default? Why is real-time multiplayer still not a mainstream thing (Or is it? Zed anyone?). Is it a skill issue (“just learn git”) or are others experiencing the same pain… or have you just accepted it? Not to mention that with AI most teams realize that reviews are the bottleneck. But isn't the real issue the way we split work into “small PRs”?

Related: https://feelingofcomputing.slack.com/archives/C5U3SEW6A/p1781925506227809?thread_ts=1781925506.227809&cid=C5U3SEW6A

for sure I am faster without review on my own. PR review should be seen as a information sharing ritual, and checking process is followed (e.g. you wrote tests, you considered rollout). Without PR review everyone's standards drift to different places. We had a big chat at work because I am itching to get rid of review, but overwhelmingly my team felt reviews were essential. We used to do pair programming but that has become pointless, so pair programming is now open ideation. Reviews are one of the few touch points now where we thinking about programming. Primarily I now use review to give feedback to my AI coder, so I need that gate to stop it submitting something too sloppy, left to its own devices it will fill my code full of inane comments.

Small PRs haven't been an issue for me so far (hm, maybe AI could help with splitting?). But the delay (sometimes days) was a major one. I think review is the reason dev companies are so slow. But I also totally see why it's necessary. One thing that works (worked in my team and now with AI) quite well is merging code with outstanding comments (to get the bulk of the diff merged) and addressing the issues later - like with technical debt - but on the scale of hours rather than months.

Working with others inevitably involves compromises on one’s own work speed. That said, I don’t consider git anything like the last word in change control, cooperation or anything else.

@Tom Larkworthy Let’s say you work on an algorithm or feature, the first basic implementation that works. You make a PR. But you immediately want to iterate and try a better version. How do you go about that? What about potentially wasted effort of the PR review that might happen a day later? What if the iteration builds on the PR, parts of that PR gets criticized, how do you flow all that back in to your working branch? I don't know but timing/rhythm seems to play a big role no?

yeah, stacked PRs don't really work in git. I worked at Google and they had incredibly long review cycles (like a week or 3) but because stacking worked properly you could pipeline stacked PRs much easier. Not sure why it doesn;t work with git so much, but I guess thats the motivation for Github's new stacked PRs feature. Now that my AI does all the merge conflicts and branch maintanance I have not bothered adopting stacked PRs as my minion deals with that detail. My AI driven workflow is now to aggressively vibe build a full monolithic prototype upfront, and then slowly convert that to merged prod code by syphoning off a small PR chunk at a time. Thats the point I actually fully read the code and fixes all the AI weirdness so its definately still useful. So all the algorithmic iterations are done in the prototype first.

Just to really drive home the point about communication: http://pages.cs.wisc.edu/~remzi/Naur.pdf

@Tom Larkworthy That sounds like what I would want. How does the “siphoning” work in practice? Is the prototype more of a conceptual blueprint that inspires the production PR or do you actually use the prototype code?

no its pretty much the full feature but hacked together, and that is where I might do benchmarks or prompt optimization to guide choices, our PM might demo it, but anywhere a corner can be cut it is (e.g. a buggy static HTML page instead of integrating with the React codebase). But then that branch becomes sort of the reference model and we, the team, look at it when we need to see how something should behave from a data or UX perspective. Like its fully functional so it tells you what APIs need to be called in what order, but you don't really use the code because its not very minimal and is full of races and glitches. But you know what you need to do functionally. Oh actually, on point, our PM was also pushing to that branch with prompt updates, so yeah, the review process is bypassed for the prototype! Its a broken free-for-all but it lets us figure out the UX quickly, and its something we can teest on customers with handholding over the problem areas. I think we had a reset button for wiping the state so if it got in a broken state you would jsut press the reset button, lol

Yes that! A prototype A model A reference No PR review No Gates No code re-use My struggle: “They” try to make the prototype code the product. Because no one understands that it needs a dedicated translation process. That you need both side by side. Now everything slows down. Cant make fast changes anymore. Stuck in the machinery.

If you liked that article, I recommend listening to the associated FoC podcast episode: https://feelingof.com/episodes/061/

When working on a team, I tend to put up a huge PR as a reference of what I will eventually merge. It’s kind of prototype quality code, like what @Tom Larkworthy is talking about. I show the team this so they understand the overall approach. Then I piece by piece put up separate small PRs that are production ready. I may reference the prototype PR, linking each small PR to a section in the big one. The “lots of small PRs” approach can also be tiring for reviewers because they have to context switch a ton. I find being able to reference the monolith PR to alleviate that a bit atleast. I also like small PRs because you get value, and derisk the project, every time you merge a little bit more. Instead of waiting until the end where you may get massive merge conflicts, or realize some incompatibility with CI/CD etc.