Pair Programming help

[Rala Hami]

Hi,

I currently do pair programming on a daily basis. I have being doing this for about 5 months now, in a group of 8 developers. I have mixed feelings about paring. I find that I enjoy pairing much more with some people than I do with others.

I have two main issues with pairing:
1) I am an introverted person by nature, and I find it hard pairing with "Type A" people who always wants to do their own thing. Eg, do things in the order they like or explore or not explore things. What currently happens in these situations is that I get over ruled all the time, and I end up sitting there following them, and not getting a chance to try out the things that I have in my mind. Or I don’t get the time to explore options and try out things end to end so I can completely understand what is going on.

2) The other situation, is when I am pairing with a girl(usually), they seem to think in parallel. This means when we are working on a story together, they do a bit of this here, then a bit of that there, and soon its a big mess in my mind. But in their parallel mind, they seem to be able to comprehend it all. The way I like to do things, is make a list of everything that needs to happen, and then do them top down or bottom up, using TDD. But when I have to pair with a person, who is "messy" I find it hard to pair. And me being non assertive doesn’t help.

I enjoy pairing with people who do things in a logical sequence, and who have time to answer my questions and work together exploring options. And one of those people is a Type A person, who takes the time to explain what is going on.

I am open to pair programming but can you please help me overcome these situations in pairing.
Thanks.
Rala.

[Ernest Friedman-Hill]

Hi,

Welcome to JavaRanch!

I know it sounds too simplistic, but the best remedy for your problems is just more communication and more assertiveness. Talk with your pairing partners about the best way to proceed. If someone is moving too fast and not involving you, say "Hey, slow down! Please let me know why you are (whatever)?" If someone is proceeding in a nonlinear way, say "Let's make a list of things we need to accomplish." If someone overrules all your suggstions, ask for explanations of their decisions. Decide whether you can learn something from the choices they've made, or whether they need to pay more attention to your ideas -- and either way, tell them.

Pairing a two-way street: it's everybody's job to work together effectively. If that's not happening, then it's a failure for both people. Take the initiative to find out why by communicating more with your pairs.

[Ilja Preuss]

Another option you might want to consider is to hold short reflections at the end of a pairing session. I like the idea described in last two paragraphs of http://www.think-box.co.uk/blog/2008/04/people-do-pair-programming.html

[Ernest Friedman-Hill]

That's an interesting idea, Ilja. I like the way it lets you manage individual evolving relationships on the team. You could look at all the half-cards you're holding and look for common ground; these would be issues you'd need to generally work on, even with pairs that haven't mentioned an issue specifically.

[Rajah Nagur]

Hello Ranchers,
Does not XP recommend to have one senior and one junior in the pair programming?
Majority of the time, it is the senior who is the navigator and the junior a driver.The navigator observes the code, does strategic thinking, mentors the junior , reviews code.
Is my understanding correct?
Yes, there can be variations of the above rules, but at-least, was this not the original idea behind pair programming?

Originally posted by Rala Hami:
Hi,
I have two main issues with pairing:
1) I am an introverted person by nature, ...........
Thanks.
Rala.

Rala, since already know that you are introverted, you should work on this, improve and drive the show. Take small steps at a time and always give this kind of feedback to the coach.
Suggest to your coach to take a session on pair programming and educate the team-members on best practices and rules of this.

[Ilja Preuss]

Originally posted by Rajah Nagur:
Does not XP recommend to have one senior and one junior in the pair programming?

I don't think it does.

Majority of the time, it is the senior who is the navigator and the junior a driver.

Many teams find that when the person with the less knowledge about the task at hand drives, pair programming works better, yes. That would also apply to senior-senior and junior-junior pairs.

The navigator observes the code, does strategic thinking, mentors the junior , reviews code.

I think the *mentoring* ideally happens in both directions. I agree regarding the strategic thinking.

Yes, there can be variations of the above rules, but at-least, was this not the original idea behind pair programming?

I don't think that the senior/junior thing was a fundamental part of the idea, though it probably was one of the many perceived benefits. I could be wrong...

[partha naveen]

Rala,
I am not sure if you have the recommended stand up call that usually happens in any Scrum project. The problems you are facing should be brought forth as an impediment (even though its a minor issue, but could have a major impact) to the team.

Agile - Scrum is typically a team effort and as someone said earlier communicating , shedding inhibitions and being a part and parcel of the team is the key scuccess for any scrum project.

If talking it out is an "introvert" issue. then do inform your scrum master thru a mail or something before the standup call.

The more we neglect these issues, the more impact will it have on the development process.

Regards
Partha

[Anirudh Vyas]

I personally have had similar experiences in the past with XP. IMHO, what happens most of the time is, that a more assertive programmer ends up asserting his thoughts into the code and you end up typing stuff out for him, rather than pushing your ideas. This is wrong approach, the ideal pair programming approach would be to allow for less experienced or junior programmer to work on his own and then code reviewing it after he or she is finished. Or may be just sitting with him and giving him the ideas (I know that's not a pure Pair programming stance) but still I think it'd be more effective in finishing the task at hand in the most effective manner.

Regards
Vyas, Anirudh

[Ilja Preuss]

I think it would be most effective if the more shy programmer learned to speak up, and the more assertive programmer learned to actively listen. Both are skills everyone can learn.