3 ms·
> But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. Y
by MockObject 5y ago
> But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort.
Yes, without a doubt.
> Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task)
Having paired for years, and soloed for years, I have found that the downsides of allocation are overridden by the benefits of pairing, one of which is real-time code review.
- Agentlien 5y agoI have done some pair programming. At my first job we sometimes did it when some problem proved especially tricky. Typically a tricky bug. In some cases it's invaluable, absolutely. I just don't think that's a large percentage of the code written on a daily basis. For most tasks pairing seems to be either 1) one person tapping out simple code which practically writes itself while the other lazily nods along. 2) One person solving something tricky which happens to be their area of expertise while the other stares blankly. Maybe at that point it would be useful to explain things in detail, but that can make development take much longer and if something like this requires rethinking halfway it can be quite taxing. In that case, I would prefer waiting until it's done and compiling the result as an annotated review. Which can be a great forum for asking questions.
- MockObject 5y agoWhen I've seen it adopted, it was in the context of XP. The red-green-refactor cycle affords a decent flow for pairs, who may switch off between test writing and feature writing. I can see that without the other XP practices, pairing may be awkward.