I like how this digs into pair programming using these two as an example - pair programming, at least when I was coming up, was seen as a panacea to all softwar

I like how this digs into pair programming using these two as an example - pair programming, at least when I was coming up, was seen as a panacea to all software development problems. However, in our field, suffice it to say there are "difficult" personalities or people much more comfortable working alone, and in practice, I've rarely seen success with it, personally, more than someone looking over your shoulder every now and then to debug something. As a primary working method, which it seems like the subjects of this article are doing, you definitely need to find someone who thinks like you. I've had things that were close, but usually devolves into multiple short 10-20 minute meetings, division of tasks, then reconvene, rinse/repeat. That typically works well and I don't have to deal with people nitpicking how I use my editor or how many chrome tabs I have open.