Pair Programming Tips And Tricks

AKA PairProgrammingForBeginners? or PairProgrammingForIdiots? or PairProgrammingForDummies?.

CategoryPairProgramming

Engaging

Could you help me?
Let's do it together!

During pairing

Let me drive!
Could you drive?
Here are my intentions
What are your intentions?
What should we do now? What is the next step?
Did we miss something?
Let's ask the code
How does this code work? Let's step into that Unit Test.
What's the Test?
I'm bored. What's going on?
I do not understand. Draw me a picture! Explain me!

Resting

Can we break?
Can we stop?
Can we switch peer?
Let's play frisbee outside!

Maybe

Can I take a look a this alone for a moment? (It is not pair programming but may give some relieve after intensive pairing. As long as 'a look' is only 'a look'.)

Do not

This sucks

Keep in mind:

Don't force it. Forcing PairProgramming will make people more resistant to try.
Do not drive too long. Let the other drive.
Drive enough. Take the keyboard.
Communicate: Both ways! Listen, Talk.
Break often. Don't skip breaks. (guidelines: 15 min for newbies with pp, 45 min for experimented)
Split the pair. Switch peer between pair.
Enjoy
Trust
BlameYourselfFirst
Recognize your errors ... quickly
KillYourEgo?
SlowDown
IncreasePace? (?)
Pair with someone with less experience than yourself
Pair with someone with more experience than yourself
Code belongs to neither of you but you both for the time of change until it is checked in
Try to RecordYourCommunicationInTheCode always.

See http://collaboration.csc.ncsu.edu/laurie/Papers/Kindergarten.PDF for "All I Really Need to Know about Pair Programming I Learned In Kindergarten" (submitted to Communications of the ACM)

(Extracted for XpMailingList) At 07:16 AM 7/18/2000 -0700, Kevin Smith wrote: On my team (non-XP), I've told everyone that while they are creating or modifying code, THEY OWN IT. As soon as they've checked it in, it belongs to the team, and anyone else is free to change it as required. That's my attempt to attach responsibility and pride to the work they do.

Keep in mind the importance of the NoddingDummy. Sometimes it is important to just sit and listen to someone else explain their thoughts on something (even if you don't quite get what they're talking about). A lot of times the person explaining will have a eureka moment and thank you profusely even though all you've done is sit and nod.

Also known as TeddyBear, CardboardProgrammer, or even RubberDucking.