[jdost]

Great read! Upon finishing, the two sides seem to be opposite solutions of a good problem (that is getting a non singular path to guarantee code quality). It seems that the best solution is a mixed approach. Using pairs to gain the benefits of knowledge sharing and sort of check ups (that is having a second pair of eyes to achieve the intermediate commit/review issue). But also using a large amount of solo coding with code reviews to ensure overall quality without missing out on the non-pairing types.

Has anyone ever tried a balanced approach like this? Such as spending 2-3 days each week pairing on a part of a project to help with knowledge sharing, best practices, or possible bad paths, and then the rest solo coding with some final code reviews?

Also, what is the best form of code review? Is it having a single developer be assigned to perform a code review for each pull request or for it to have some gestation period for crowd comments to come in, or even some voting quota/discussion until a simple consensus is reached? There seems to be some room for a variety of time/quality trade offs (in theory, more eyes == higher quality, more time).