|
"IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more well designed product." That's what PRs are for. One can't use the same argument to oppose PRs, as you suggest, because of this key difference: in a PR, the person doing the review has (or ought to have) context on the broader picture (e.g. overall architecture, structure of the code in which the change is being made, etc.), but not the specific changes. It's analogous to having a proof reader: one doesn't invite a peer author to review his writings, because the peer has an implicit bias and can easily miss defects. "Also, at least in my experience, design isn't primarily or even mostly confined to an initial design phase. Most of the 'design' of a problem occurs when you're actually coding." This is common, unfortunately, and one of the primary reasons software is so buggy and overly complex. The code isn't the design, or shouldn't be. To draw an analogy to physical/industrial processes, the code is the machinery on the factory floor doing the work--the design is what was used as a blueprint to construct that machinery. |