I've found that favoring full time pair programming and not reviewing work that was soloed upon unless the author explicitly asked for it because of self-identi

I've found that favoring full time pair programming and not reviewing work that was soloed upon unless the author explicitly asked for it because of self-identified uncertainty or caution has resulted in a better workflow with little to no actual hit to quality. Additionally, proper test-driving and testing practices are incredibly effective ways to enforce high quality code. Again, this comes down to culture and practices. Teaching and encouraging good testing will pay off far more than enforcing "two pairs of eyes" type rules. My experience is that code review is great at linting, nit-picking, and causing arguments about idiom. The times a bug was okayed with 8 different :thumbs-up: or "lgtm" on the PR in github are uncountable. It's not that code review doesn't work, because I'm sure it often catches plenty of bugs, it's just that I have no reason to believe it's more reliable than pairing or letting authors ask for help explicitly when they need it. Disclaimer: I spent my formative years at Pivotal Labs. Yadah Yadah Yadah it's a cult of pair programmers so something about a grain of salt.