This article begins with the premise that Atul Gawande's insights may apply to programmers. However, Gawande's writing has dealt mostly with the work of people like surgeons (he's one) and airline pilots. There's a crucial difference between this kind of work and the work programmers do: surgeons and pilots have to get everything right in real time -- a very brief lapse in attention could lead to disastrous consequences. Programming is different: you can review code after it's been written and get the benefits of a second pair of eyes (or several extra pairs of eyes) examining it at leisure. So if pair programming makes a particular programmer more productive, that's fine, but if it makes other programmers less productive, no tragedy will result if they use code reviews instead.
That said, one of the major techniques that Gawande advocates is the use of checklists, which can be useful even to programmers working alone to make sure they haven't missed some important step (e.g., verifying that their code works against a live server, vs. just passing unit tests). His article in the New Yorker on checklists is interesting in its own right:
That said, one of the major techniques that Gawande advocates is the use of checklists, which can be useful even to programmers working alone to make sure they haven't missed some important step (e.g., verifying that their code works against a live server, vs. just passing unit tests). His article in the New Yorker on checklists is interesting in its own right:
http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...