Is Pair Programming Worth It? AirPair Interviews Pivotal Labs
airpair.com
airpair.com
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 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.
I just don't know how to do that as a pair.
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
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.
That's why most programmers don't like long period of pair programming. Because you can't program all day. That's all
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.
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.
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.
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).
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.
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.
http://www.pairprogramwith.me/ http://remotepairprogramming.com/
Best to get into it...
Free communities: https://plus.google.com/communities/100279740984094902927 http://www.meetup.com/remote-pair-programming/
First Time Paid experiences through AirPair: http://www.airpair.com/php/troubleshooting-chris-christoff http://www.airpair.com/angularjs/angularjs-problem-solving-d...
Tons more: http://www.airpair.com/customers
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.
http://www.airpair.com/php/troubleshooting-chris-christoff
http://www.airpair.com/angularjs/learning-angularjs-morgan-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.
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 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).
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.
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.
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.
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 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.
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.