Hi Daniel, thanks for taking the time to read it & share your thoughts.

I think you've given some great examples of the benefits of PRs; most of which I agree with and have enjoyed. One of which is keeping the git log clean by squashing commits on the PR merge. That is something I've become a bit anal with; our team (currently using PRs) has a pristine git log with atomic commits which is largely down to me selling this practice to the team. I think I may miss that.

I do think though that your point about raising a PR for renaming a variable kind of proves the point about their harm to productivity.

One thing you said which I agree with is:

"A pull request is just an easy organized way to share and collaborate on code".

That is obviously true and I think their easiness is part of their appeal/success. The use of "proper" CI & pair/mob programming as an alternative is going to be harder by comparison & may not be suitable/desirable/productive for all teams.

It sounds like you've got a processes in place to help make the PR workflow more synchronous & yielding good value for your team. As I mentioned in the article, your team may function better with them than without. If that's the case I certainly wouldn't suggest you're following bad practice. As per the "No Dogma" section - I think teams should do what works well for them.

I didn't set out to portray PRs as flat out bad practice. As Adam's response pointed out, it all depends on context (like most things). But given the drawbacks that come with PRs, I think it's worth teams experimenting without them to see if they can gain productivity without compromising quality.