I guess I'm just not the pair programming type. I find that the experience is usually frustrating.<p>1. Most software development occurs in my head. If you watch me "write" software, you'll see me sitting silently at my desk most of the time. I only actually type once I have a solid picture of the problem and solution (except for the occasional exploratory code to coax out more details from the problem domain). I can't do that with someone talking and changing the existing code structure. It's basically having someone constantly interrupt you. I'm not a multitasker; I can't write code and converse with someone at the same time.<p>2. I tend to jump around a lot in an existing codebase to verify behaviors or gain a better understanding of a subsystem. But the person next to me doesn't have the same mental map, and so what I'm doing will appear almost random. I've tried explaining as I go, but it just serves to muddy the waters because the other person will be talking and interrupting as I'm trying to keep the delicate mental structure intact.<p>I much prefer to work alone, and then bounce ideas off colleagues when I'm stuck.
They forgot to mention that ( at least in my circles ) they are notoriously known as an 'engineering factory', where most people hate their job, because very few people want to pair program ALL DAY, EVERYDAY.<p>Pair programming in small doses, works wonders. One to three hours working together on a problem can see serious productivity gains. There's no magic to this however; Any collaborative environment gravitates towards this sort of activity naturally.<p>As with most things, balance is necessary. Some solitude to think and reflect, some collaboration to explore your ideas and some pairing to smooth out the rough spots.
Seriously, I think very few people get the concept of pair programming or I would say pairing because programming is only one scenario. Pairing is good or bad is like saying gear-5 (in a car, assuming topmost gear) is better than gear-4 or not. Cmon, both are required for different purposes. You got to change gears. You cant just drive in gear-4 or 5 all the time.<p>Some of the arguments down below read like: I tried driving in gear-4 and I disliked it, so I changed back to gear-5. Funny.
Another one: One company forced me to drive in gear-5...again that company was plain stupid (or atleast the management was, for forcing you, in general).<p>Pair programming is effective when you are coding up while you are building the solution on the go. Its one of those sessions where its not possible to think up everything in your head. Ever had such moments where you didn't know all pieces of the puzzle? You can always say I would think up everything and then discuss in a meeting the whole solution. What if you went ahead and thought up the solution in a pair rather than discussing after you have laid out everything and then realizing you have to change it because you made a wrong initial assumption.<p>You cannot think up everything in your head (as another comment was there). Many times you do not have all the pieces and sometimes even if you have, you need to consult.<p>Seriously people, you are not getting the concept of pairing at all. Or I am just nuts.
This reads more like an advertisement than an objective analysis, which in looking more into AirPair, that's exactly what it seems to be. Pair programming might be great (it certainly sounds like something I wish we did some of at my company), but it's disingenuous to pass off a marketing piece as a critical analysis of software engineering methodology.
Interesting.<p>I could see pair programming being a good fit where you have say one backed developer, and one front end, and you want both to be able to code both.<p>Is there anywhere to read more about practices, or is it simply a matter of sitting down side by side? I have done that with less able developers, but it often feels like I am doing the work, and they are watching, whereas I imagine pair programming to be more interactive.
It really comes down to being a team player, and being able to accept help from others. A lot of us are the loan wolf type. Just as @kstenerud said. "Most software development occurs in my head". Personally, I find that I can over complicate things especially with a problem I don't have a road map for. However, when I have someone else around to bounce my ideas off of I usually end up with a very scalable simple solution.<p>AirPair allows you to find someone who is an expert in what you're working on, and instead of hiring that person to be a full time engineer for 120K+ per year you get to pick their brain for an hour or two and see if they can at the very least point you in the right direction. Two heads are always better than one.<p>So, to answer the question. Is AirPair worth it? 100% worth it IMO.
I find pair programming to be an excellent when you are debugging a problem and need two sets of eyes. It's also great for teaching/learning when a junior developer has banged his/her head against the problem before coming over to a more senior person for help. For research projects or deep thinking exercises, it's pretty counter-productive.
Pair Programming seems like it would be great if both programmers have similar ways of approaching problems, and can bring their different perspectives to bear on the problem in compatible ways. What happens when two people approach things from very different perspectives?<p>Coming from a physical science background, I've found that I "think differently" than most computer scientists and engineers I've ever worked with. It's different enough to my mind to be quite incompatible with in situ pair programming; the few times I've done it have been in interviews, and it was uncomfortable to say the least.<p>It seems like the difference between a kinesthetic and a visual learner. I don't care how often you expose one type of learner to the other kind of learning, there will only be so much improvement; after the improvement plateaus frustration will set in.
It's good for about two weeks to a month, and then you are looking at diminishing returns.<p>The productivity gains come from sharing each others programming tricks. You may learn a different approach to problem solving that you never thought of before. Over time you will learn less and less, to the point where you are just sharing a keyboard.
Is pair programming always carried out on a single PC? I was under the impression that the pairs may just sit side by side and help each other throughout the session. Didn't realize that pair programming implied literally taking turns hammering out code on a single PC.
I think pairing is useful <i>some of the time</i> (esp for debugging, code reviews)<p>in a world trending more and more to flexible hours and remote work, I don't see any way doing it all the time will work.