Comments by "Andrea Laforgia" (@andrealaforgia) on "Why Pull Requests Are A BAD IDEA" video.

Once again, pair programming does not mean "working while there is a person watching every LoC over your shoulder". That is NOT pairing.
2
>(a) One HAS some other Engineer(s)* available to pair/mob This is the premise of working in a team, isn't it? There is a widespread idea that a team is a set of individuals working independently and only occasionally catching up. I've heard many times the argument "helping the junior members of the team slows down the senior ones who cannot complete their work". That's completely wrong. There's no "my work", "your work", there's the "team's work", so get the members of your team pair up and mob cause THAT is the premise of teamwork. If that condition is not currently achievable, work hard to achieve it. My thoughts about (1) and (2): It's another work culture problem. If you have a super slow local build, that's a big problem. You need to address that. As a developer, you must be able to commit to trunk with confidence. The trunk build is not where you verify your local changes, so any developer who does that needs a good slap on their wrists. Any company that allows gaming the system that way has a big cultural problem that needs addressing. I am not going to comment any of your remaining points, because none of them really contradicts what Dave proposes or creates scenarios where what Dave proposes is inapplicable. Those are not an indication of situations where PRs are a better solution. They only show situations where CI and CD are either not being implemented properly or using a completely flawed toolchain. The fact that PRs, in those specific contexts, might come more handy because CI and CD are done badly, is not a merit of PRs. Sorry, but you missed the point.
2
There are antipatterns with any practice and pair programming is no exception. But it's not a problem with the practice; it's a problem with the humans implementing that practice and not committing to that practice. What you describe is not pair programming; it's "pair programming theatre".
2
"when everyone has different things going on" That is not a team.
1
@SM-ok3sz Oh please. That's not the takeway. The takeway is that working together, on the same machine, is possible. Colleagues are coworkers, not strangers.
1
PRs are not strictly necessary for automation. The automated steps you attach to a PR can live in the build and deployment pipelines. What stops bad code from being merged is automated tests and code review, not Pull Requests. Code reviews can be performed in many different ways, for example continuously, when adopting social programming approaches. The more you dig down, the more you discover that no, there isn't plenty of reasons to use them. PRs were never meant to be used by durable product teams.
1
@nextlifeonearth PRs are not lights.
1
Test coverage thresholds make little sense. Remember Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure"
1
The mistake is thinking that PRs are needed for code reviews. Code reviews can be done continuously. No need for PRs. PRs were never meant for durable product teams of colocated, trusted collaborators. They were meant for open source projects having lots of external, untrusted collaborators. Peer review == pull request, as Thoughtworks also says int their tech radar, is a false equivalence.
1