Slashdot Mirror
Experiences with Pair Programming?
gmletzkojr queries: "I recently was able to engage in some Pair Programming for a couple of days. However, my experience was less than rewarding. I have read books regarding the subject, and all of the case studies show praise for the effort. I found my pair programmer a bit difficult to work with. Has anyone been in this situation, and what things can be done to work around the personality conflicts?"
What is to be done about this? Ask for a different partner, maybe? Pair programming is useless if you can't work with your partner. This should be obvious. Not everyone is compatible, not with each other, and some people probably aren't even compatible with pair programming at all. That's fine, everyone's different.
Nothing will ever be a magic bullet. Pair programming, agile methods, and all that other crazy marketing-speak, it's just a procedure. If it works for you, use it, if not, try a different approach.
Random and weird software I've written.
Scenarios and results from my experience.
1) If your partner is more experienced it is usually annoyance for them and great fun learning for you.
2) Vice versa of 1.
3) Neither partner is experience or knowledgable enough to do the work on their own then productivity increases only slightly because you have two people trying to figure out new things at once. Also makes the job programming less painful for both since you share suffering.
4) Both partners are knowledgeable and experience enough for the work. It depends on the personalities of the people
4a) personalities are conducive to teamwork, super productivity! Project gets done fast, bugs are caught during implementation, everyone is happy.
4b) personalities not conducive to teamwork, super bad! Both programmers are knowledgeable and could therefore be doing more work if they each coded separately.
As long as neither partner lacks basic social skills and is not a complete loner then teamwork is usually good experience because you can enjoy the company and conversation of another programmer while you work.
The GeekNights podcast is going strong. Listen!
"Type foo"
"What?"
"There, foo"
"Oh yeah, ok"
"No, foo"
"Oh right"
"Oh for fuck sake.. FOO, the keyword is FOO"
"Oh sorry, was thinking about something else"
Pair programming is like watching a woman change channels. "You know what's on this channel, it's shit, keep going."
How we know is more important than what we know.
I was assigned to do pair programming with a more senior person. I got so tired of my suggestions being ignored (not disagreed with, ignored), that I just gave up and sat and watched him. The project had long since morphed into a Death March so this was just one more reason to loathe going into work each day.
If I ever get forced into another pair programming situation, I'll use my spare time to apply for other jobs.
It's simple: I demand prosecution for torture.
I found my pair programmer a bit difficult to work with.
That's actually the whole point of pair programming. It's supposed to slow you down so you make fewer mistakes.
Things I would recommend:
- Communication. This is by far the most important quality to have as a pair.
- Patience. Sometimes your pair might not be at the same level you are, in this case, it is your job to help get them there.
- Assertiveness. If you have no clue what your pair is doing, ASK!
Other recommendations I have are to force your partner to drive if they are more inexperienced than you. This will help you both learn. If you don't have any idea what's going on then tell your partner you'd like to drive for awhile. I find this helps get you focused and allows you pick things up faster.
Of course, if your partner just isn't willing to cooperate, then I think there are other issues that need to be dealt with. But, for the most part, I think people are more than willing to teach others, you just have to ask and communicate.
Another thing to keep in mind, too, is to give it time. You aren't going to be a master pair after a few days or weeks.
Not really anything different than working with any other person. Programming doesn't introduce some new kind of situation to deal with that teams of two haven't been dealing with for centuries.
So, my tips, just coming off about a year's worth of pair work:
1. The most important thing is that you have to be complementary. That is, their strengths have to fix your weaknesses, your strengths have to fix their weaknesses. If they don't have any strengths, it will be more like training for them, a mentor/student situation as opposed to a true team.
2. Think of it as a product. If "average" or "baseline" is 1, it helps if you're a 2.1 and they are a 1.4. If you're very good and they're not, the total suffers. Only work with someone that is as good as you or better, and only do it if you're very good to begin with.
3. Define exactly who is going to do what! This is not terribly succesful when managers do it because they're not you two -- they can't see you in action and suggest anything. It's up to you to figure out what works best --- split up all the different tasks so that each of you are doing what you do best. As you go along you will find out whether it's better to write these down and adhere to them or (better yet) have them be somewhat fluid so that some responsibilities cross over.
4. One system should keep track of what's going on. Whether that's a calendar you both use, a checklist pinned on the wall, an eraseboard, or just one of you two.
5. (Regarding the previous). Think in term of goals, not minutiae. You both should be good enough that if you're, for example, auto mechanics, one of you says, "Find out where the noise on the Pontiac is coming from" rather than saying "From 10:30 to 11:00 I want you to inspect the following parts and pieces of the Pontiac: A, B, C, D..."
6. Keep everyone else out of it! Once a system is established and you've learned to rely on each other it's going to be really obtrusive to have others meddle in.
7. Meet together with management whenever possible.
8. It helps if both of you have similar goals as to the level of your performance. Even if both of you are skilled gurus and one of you is checking job sites because they need to leave in the next six months, that's not going to work out.
This is, as I said before, from about a year's experience working day-to-day with only one other person. I hate paperwork, don't really like a lot of "busy" work and, in both cases, the other person just wasn't very good at some of the major intricacies of the position. The first time, we were more succesful than either of us was alone (generally being 2.5x times as productive as any individual). The second time, we were doing about as much as eihter of us were doing individually.
The good thing is that now I'm back by myself and have become a lot better thanks to the teamwork environment. I wasted a couple of months, but that's behind us now.
Small potatoes make the steak look bigger.
I think the best approach is to pair an experienced person with a less experienced person, and make it clear to both that the more experienced person had two votes and the less experienced had one in any disagreements.
;-) He's the only one in his group I'd be willing to work that way with, though.
I wouldn't mind being partnered with someone with a lot more experience. I would consider it an opportunity to turbocharge my own learning, and though I would ask lots of questions and might even gently challenge some decisions, I would make it clear that they were HIS decisions to make, even if the boss didn't manage it that way.
I also wouldn't mind being the senior partner as long as the junior understood that, though I would appreciate his input, the decisions were mine.
Two inexperienced people shouldn't be paired. All of their arguments will end up being over who is able to make who back down. Complete waste.
I would also be willing to be paired with another experienced person, with my (senior) level of experience, if it were the right person. It would be harder to make this work with two arbitrary people than the case with unequal pairings and one guy in charge. In the case of two experienced people, if you had to specify which one was in charge, it probably wouldn't be a good pairing.
I had a discussion with another senior architect (like me) the other day, and both of us agreed that it would be fun for us to try pair programming together some time because both of us have concluded that the other has expertise that we wish we had.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."