> “As they work on it” is essential. As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead

> “As they work on it” is essential. As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and integrate it into the mainline with everyone else’s current work. Maybe I work on very different code bases to the author, but having half-done work merged into `master` is a terrible idea. The sands are always shifting under your feet as a developer and it's almost impossible to successfully integrate manual testing into your process (testers need a stable base to test against). Yes, you could feature-switch, but it's easy to make a mess of things and it nullifies some of the "integrate often" benefits. > No form of code review is more effective than pairing. Feedback is immediate, so there is a far higher chance you will use it to make improvements. So pull requests are too costly, but pairing isn't? Pairing may reduce one class of errors, but it likely exacerbates others. If the reviewer is "too close" to the code being reviewed they'll miss many of the same things that a single developer would. Not to mention, it's exhausting for a lot of people (myself included). PRs aren't magic, but there's a reason they've become so popular. And no, it's not just management liking "control" or something - they make the codebase better, which makes the developer experience better.