I guess I'm just not the pair programming type. I find that the experience is usually frustrating.
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.
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.
I much prefer to work alone, and then bounce ideas off colleagues when I'm stuck.
I'm not keen on pairing, but instead of planning things in my head, that's why I do TDD. The tests explore various ideas (as in effect the tests are clients of whatever I'm building, just like the finished app will be) so I get to play around with it before writing any code.
There are benefits to be had by BOTH. Pairing 100% of the time works well for Pivotal and their clients. At AirPair we mix and match for appropriate tasks internally. Externally for our customers, we use it as the ultimate format of knowledge share and training.
Benefits of solo:
- Creative
- Code faster (in terms of lines, no necessarily quality)
- Get to do things they way you like
Benefits of pairing
- Instant code review and double vetted architecture decisions
- Avoid distractions (like email/social media) as you can't be rude to your pair
- Getting accelerated knowledge infusion on both software tricks and domain of the application
I agree. I tried to pair program for a few years. Most people will tell me how it is my fault pair programming is not working, but I just don't like it.
I find myself starting to zone out when working with someone who types slow, has odd habits (such as checking twitter or email too frequently), uses a different editor than I, or we have a large skills gap. I know there are techniques to solve some of these, but again, I personally don't like it.
I much prefer a gated review system, such as gerrit.
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.
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.
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.
The problem is programmers goof off about 4-5 hours a day but when they assign to pair program the whole day they can't do that. There is no pair goof-offing.
That's why most programmers don't like long period of pair programming. Because you can't program all day. That's all
Spoken like someone who either isn't a programmer ( a PM, maybe? ) or is projecting. Programmers don't 'goof off' more than any other group of people.
Programming is generally a solitary activity, largely due to the immense amount of concentration it takes to build a mental model of a system that you're working on. Tracking variables, context, structure, side-effects, out-come scenarios, etc. takes a lot of brain-power. 'Pairing with someone' for long periods of time adds another dimension to that... Communication and synchrony with another person.
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.
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).
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.
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.
Seriously people, you are not getting the concept of pairing at all. Or I am just nuts.
Do you mean to say they are simpler than gearboxes and hence should continue to function using one method always?
If you meant they are more complicated than gearboxes, then I think we are saying the same thing and either you aren't getting it or I am not doing a good job conveying it.
If you are think there is absolutely no analogy, gimme one and I can say the same for that too. If this was the case then, I am sorry but I believe that statement of yours was absolutely unthoughful.
I mean that you can't just shove them into this kind of a working mode, then into some other kind, as would say a teenager play around with shifting from 2nd upto 5th the first time he gets to drive his dad's Mazda all by himself.
Which is about the same degree of attachment expressed in the idea that a project manger can "shift" programmers into and out of pair programming mode the way one would work a stickshift.
Working habits are intensely personal, idiosyncratic things.
People -- by which I mean creative, productive, self aware & self-managing people; i.e. the only kind you should ever hire -- almost by definition don't like being pushed into working one way or another. Or being simply told what works best (because X or Y said so).
Sersiouly dude, you didnt get it. I said that pushing in general is bad. Not bad, its stupid.
I dont know where the hell you got the idea that I meant some manager pushing people to pair program. I didnt say that.
Working habits could be personal but there is something called as team work. You should also make sure the person is capable of collaborating. Collaboration does not always means attending meetings.
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.
I'd heard of AirPair before, and my first thought reading the title was "Is Pair Programming Worth It? A Company Offering Pair Programming Services Interviews Another Company Offering Pair Programming Services". I wonder what the answer is!
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.
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.
This. My team's almost entirely new to the code base (hired at the same time) and we're split along front- and back-end skill sets. We regularly pair with the explicit purpose of sharing knowledge.
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.
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.
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?
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.
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.
I was forced to pair at a company that I temporarily worked for. I was open to the concept of pairing but through actual experience pairing with other engineers, I found out that it was not for me. I can see the benefits of sharing the context of what's being written and having two sets of eyes on the code but in my experience, the process ended up slowing down myself and other engineers as well as making us unhappy (we preferred to code independently most of the time - being forced to directly work together isn't an enjoyable thing) and didn't dramatically increase the quality of code enough to warrant the hassle. That may be due to the quality of engineers and other factors in the workplace, though.
I can absolutely see the benefits of pairing when engineers themselves choose to pair with each other though (instead of being forced to all the time). An engineer asking another engineer for a bit of help with some code is not an uncommon thing and well, it's pretty much part of working in a team and not some bizarre new concept so I don't think it really needs to be highlighted as part of a company culture.
Since I left the company (due to unhappiness), I understand that the managers have become a bit more relaxed towards pairing and now allow engineers to "solo" more (at least the more experienced engineers).
I pair almost every day, and my biggest complaint is that pairing isn't useful for boilerplate code. Pair programming's biggest advantage is that you have two people working out solutions and catching bugs. If the solution is boringly obvious and the chance of bugs almost zero, then pairing is a waste.
The success of pairing depends heavily on the skill and personalities of those involved. If the skill disparity is too great, you end up with one person doing all the thinking while also lecturing the newbie. If neither collaborator likes the other, you'll have issues. Even something like preferring different editors can get in the way.
In general, I don't think of pairing as good or bad. I think, "Is pairing a tool I should use in this case?" For me the answer is often yes, but it depends on many factors. I could see others answering no just as often as I answer yes.
Really though, you don't know it 'till you try it. If you want to get started with pairing, make sure you pair with someone who has paired before! If both people are inexperienced, the result is usually chaos and frustration.
> The success of pairing depends heavily on the skill and personalities of those involved. If the skill disparity is too great, you end up with one person doing all the thinking while also lecturing the newbie. If neither collaborator likes the other, you'll have issues. Even something like preferring different editors can get in the way.
Very much agree. I was a client at Pivotal for a few months, and learned a ton from them while pairing. We brought their XP style (slightly tweaked) back to our office once our contract with them was up, and continued pairing about half of the time. We could all get along well enough, and had agreed on using the same editor, so the only pain point I felt was when working with people with a different skillset. Though the different skillset problem made development go slower, but the more experienced people are teaching the less experienced people, hopefully making the tradeoff worth it.
Another advantage to pairing is that it keeps developers honest -- if you're supposed to be doing TDD, then ideally your pair helps you stick to it instead of taking shortcuts you "know" are okay.
Edit: oops, grandparent asked for negative experiences. The only ones I had were frustration when working with people who were already frustrating to work with. (Ideally, while pairintg they'd be learning, and would become less frustrating to work with...) I do agree with parent's point about it being less useful when banging out boilerplate or obvious solutions, but that's not really a horrible experience, just a little wasteful feeling.
It's good for about two weeks to a month, and then you are looking at diminishing returns.
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.
It's usually done with a single computer. Sometimes shops will have multiple keyboards hooked up to one computer. But it doesn't have to be that way. There are lots of tools for pairing remotely. Screen/tmux + Vim/Emacs, Screenhero, Google+ hangouts, etc.
I don't want to toot my own horn, but at Floobits (YC S13) we've built some really nice tools for remote pairing. I like Sublime Text. Bjorn likes Vim. I live in SF. Bjorn lives over in the east bay. But we pair using our native editors: http://abughrai.be/pics/screenshots/Screen%20Shot%202013-12-...
We're still improving the setup process and documentation, but we've found it to be better than pairing in person. We get to use our favorite editors. We don't have to commute. We can listen to different music while pairing. It's pretty nice.
"Proper" pair programming, in the original Extreme Programming sense, always involves two people sitting at a single computer (or, if you have to pair remotely, two computers with screen-sharing/similar and some form of voice/video chat).
In an ideal world (e.g. the way a place like Pivotal does it), you've got two mirrored monitors, two keyboards, and two mice.
I would argue that "advantage" in your scenario only applies to the employer, who doesn't have to provide space for two people. For those who must now share a space, I would consider this a disadvantage.
As someone who has a desk at a co-working space, I'd want to murder you after 3 hours. It's not really an appropriate place to spend 8 hours a day talking to each other:)
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.
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.
I much prefer to work alone, and then bounce ideas off colleagues when I'm stuck.