> If "usually" PRs result in code style or architecture discussions, I'd suggest you have a team problem, not a process one. Start with the humans.
+1
> Not mentioned is one of the other big benefits of PRs (which applies no matter if you pair or are a solo project): it enforces some good discipline.
I found that pairing and frequent rotations result in a much more uniform adoption of good coding practices, following working agreements, etc... It just happens much more frictionlessly since people learn faster by doing. Again, frequent rotations and ensuring that people mix as much as possible is key. (one company I worked for adopted a so called "promiscuity table" to keep track of that)
Also, to quote someone more experienced than me "I've never seen a +300LOC PR that didn't look good!"
Counterpoint: I've reviewed multi-thousand line PRs (with dozens of commits) ... those took me days of 8 hour review, with multiple issues found. (To be fair, when I first skimmed it, it looked great to me, but a deeper dive found lots of things that could be improved.) These kinds of large PRs was how the gentleman I worked with did pairing and it worked out pretty well (surprisingly, don't try this at home).
I suspect this is the exception that proves the rule, not really an alternative rule.
+1
> Not mentioned is one of the other big benefits of PRs (which applies no matter if you pair or are a solo project): it enforces some good discipline.
I found that pairing and frequent rotations result in a much more uniform adoption of good coding practices, following working agreements, etc... It just happens much more frictionlessly since people learn faster by doing. Again, frequent rotations and ensuring that people mix as much as possible is key. (one company I worked for adopted a so called "promiscuity table" to keep track of that)
Also, to quote someone more experienced than me "I've never seen a +300LOC PR that didn't look good!"