I really liked this article. At Sturdy [1], we spent a lot of time thinking about this compromise between PRs and Pair Programming when designing our workflow.

I really liked this article. At Sturdy [1], we spent a lot of time thinking about this compromise between PRs and Pair Programming when designing our workflow. I've always felt that the PR code review happens too late, and that you might be tempted to ship code that isn't perfect, as you might have spent tens or hundreds of hours in the "wrong" direction without anyone noticing. But the PR might be the first time someone else on the teams sees the code, but since you've already made the investment in building the code, you might as well ship it. You might say that you'll come back and fix it later, but that rarely seems to happen. Pair Programming on the other hand, get's extremely tricky to coordinate. The entire team needs to synchronise their schedules to be able to effectively pair program, and even then, you only get a few hours of high quality programming time together each day. We've taken the real-time aspect of Pair Programming, and the "offline" aspect of Pull Requests (no voice/video chat required) and built it into the core workflow. On Sturdy, you start by creating a reviewable "Workspace", before you even begin coding. And after that point, you're "live streaming" your code up to the workspace as you're typing (through file system watchers)! Your team mates get an up-to-date status of what you're coding on, and can continuously give you feedback when it fits their schedule. 1: https://getsturdy.com https://getsturdy.com Disclaimer: Founder of Sturdy here