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?"
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.
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.
That's one good reason for pair programming, but it's far from the only one. Here are reasons I like promiscuous pair programming:
That last one is probably my favorite. When I'm on an XP team, taking a vacation is never a big deal, because I'm never the only person who knows how to do something.
Programming doesn't introduce some new kind of situation to deal with that teams of two haven't been dealing with for centuries.
1. "their strengths have to fix your weaknesses, your strengths have to fix their weaknesses"
By far the most important. An old rule of thumb (before the Mythical Man Month) was that "if one programmer can do it in one year, two programmers can do it in two years." When and if the "two heads are better than one" comes enough into play, the answer can be two months!
3. "who is going to do what". Bad place for management to meddle. People tend to hide their weaknesses, even from management. When a team works, individual weaknesses are very well hidden from all onlookers.
4. "One system should keep track of what's going on."
Absolutely. In fact one bad system will beat two good systems.
You can tolerate different goals or directions. You cannot tolerate different positions of where you are now.
6. "Keep everyone else out of it!" Effective teams become very suspicious of all "foreigners", not excluding management.