4. Share Experience
What are the benefits?
● Faster development
● Better code design
● Reduces bugs
● Peer reviewed code
● Tougher tasks solved much faster

6. Pair Programming Mind Map

7. Pairing tips

8. Guideline Summary:
Share everything. All contributions, whether great results and errors, are “ours”, not “yours” or “mine”.
Play fair. One person “drives” (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work and
planning ahead. Stay fairly close to 50-50 on driving. Let the less experienced partner start and maybe drive a little more.
Don’t hit your partner. But make sure your partner stays focused and on-task.
Put things back where they belong. Put negative judgments in the trash: Be positive about you and your partner. For both, this is an opportunity to
improve.
Clean up your mess. >Watch over the shoulder and you are really likely to find a large number of your errors!
Don’t take things too seriously. If your partner picks out a bunch of errors as you type, be glad. But do not always agree. Have healthy
disagreement/debate. Finding the fine balance takes adjustment.
Say you’re sorry when you hurt somebody while moving furniture. Sit side-by-side and program, simultaneously viewing the computer screen
and sharing the keyboard and mouse. Slide the keyboard -- don't move the chairs.
Wash your hands of skepticism before you start. Being skeptical can be a self-fulfilling prophesy. Buying in and “jelling” can lead to a whole that
is greater than the sum of the parts.
Flush. If you work on some parts independently either discard them (flush) and start over together or have the partner very carefully review the work
with you.
Warm cookies and cold milk are good for you. Periodically, taking a break is important for maintaining the stamina for another round of productive
pair programming.
Be aware of the power of two brains. Experiences show that, together, a pair will come up with more than twice as many possible solutions than
the two would have working alone. They will then proceed to more quickly narrow in on the “best” solution and will implement it more quickly and with
better quality.

9. Manners
● Pass the keyboard liberally.
● Allow the person on the keyboard to complete a block of code before
asking a question or making a comment.
● Don’t read email, talk on or play with your cell phone or other
distracting behavior while actively working.
● Don’t touch the screen.
● Rather than grabbing at the keyboard or mouse, ask, “May I?”
● Instead of sighing or huffing, keep quiet until your partner finishes his
thought and then offer your suggestions for improvement or
refactoring.
● If you get into a heated debate or discussion, ask a third party to
intervene to help resolve the situation or propose a short break and
then use that time to evaluate the importance of the discussion to
determine your next steps.
● Rather than gobbling down your afternoon snack, offer to share.
● Instead of just quietly parting ways at the end of the pairing session,
thank your pair partner.

10. Our pair programming implementation

11. Pair programming ? Pair fun

12. Side effects

14. Top Ten
● Interrupt every time your partner starts doing something in a way other than how you'd do it.
● Once you wrestle the keyboard away, delete your partner's last edit immediately. Then do what you were thinking of
instead.
● If your partner objects, ignore it, talk over it, flim-flam around it, claim to be the XP expert, and then accuse him of playing
the previous techniques. Better yet, accuse him of playing this one.
● Pair on stuff that is ambiguous so that you can diverge in intent and context every step of the way.
(AmbiguityRequiresSpikes.)
● Wait until your partner is half-finished expressing an idea. Then demand they stop and do something else. Explain that you
haven't seen a green bar in the last 2 hours.
● Speak non-stop, so your partner never has a silence in which to speak, read code, or have a thought.
● Demand silence except when absolutely necessary. When you misunderstand what your partner is doing you can have a
prolonged argument about it.
● Complain before your partner does something wrong. Create elaborate theories about their failings. Never forgive, never
forget.
● Suffer annoyances in silence until you just can't stand it any more, then blow up. For bonus points go red in face and storm
out without explanation.
● Begin every pairing session with a long discussion of all problems you ever experienced together. Insist that all problems
be resolved before a line of code is cut. For bonus points, conduct this conversation under time pressure and outside
normal work hours when your partner should be curled up at home with their poor neglected spouse.

15. When Not to Pair
There are several situations when it makes sense not to pair:
● When reading about a library that might help later on
● Spiking a complex solution or debugging a tricky error with someone that has an experience gap. In general
pairing is not ideally suited for the combination of exploration and bridging an experience gap.
● Not every task requires a pair; however, the number of tasks that require pairing is a lot higher than the number
of tasks that don't.
● Research work
○ Pairing should not start until coding.
○ If still in research part, it is prefered to be separated.
● Both have no idea how to implement project
○ Two inexperienced people, working together, may reduce the productive
○ An inexperienced people need to pair with an experienced people.Page
● Trivial work
○ We use pairing to increase productivity. If the work itself is trivial, pairing is a waste of resource.
● People hate each other
○ If partners hate each other, pairing will become a disaster.
○ We want paring to build relationship, not to hate each other more.
● One person is not around
○ When one person is sick, or have to deal with some person affairs, the other guy may need to work alone.
○ We do not need a temporary pairing.

16. Persona
The Silent Partner
Here the co-pilot pays no attention to the work at hand, sits back and lets the pilot get on with it. Whilst
giving the illusion of pairing, the co-pilot actively hands off responsibility to their partner. Symptoms
may include excessive attention paid to a mobile phone, or conversations with other colleagues.
The Dictator
This anti-pattern sees the pilot hogging the keyboard and ignoring any suggestions by the co-pilot. At
worst the “Dictator” makes destructive comments. Ultimately this may result in the “Silent Partner” anti-
pattern as the co-pilot becomes dispirited.
The Amicable Separation or Pairing Separately
Both individuals split to work on separate aspects of the current work item, sometimes even using
different laptops at the same desk.
Asleep at the Wheel
This behaviour manifests itself when the pilot is basically acting as nothing more than a stenographer.
They take no active part in the design of the code, relying on the co-pilot to direct their efforts, in some
cases even to the extent of needing to be told what to type.
The Lone Wolf
This is the person who, for whatever reason, prefers to work alone. As a result pairing with them is
difficult and they either become “Dictator”, “Silent Partner” or there is an “Amicable Separation”.

17. Pair programming formula
1+1<2

18. Pair Hero game
Pair hero is a collaboration game for pair programming where each player gets
a turn writing tests, code and scoring points. Each game is 25 minutes long so
you can keep your pomodoro breaks.

19. Pair Hero game
Scoring
● Each passing Test + 10 points
● Each refactoring + 2 points
● Switch driver in less than 1 minute multiplies your score by 2
● Switch driver in less than 30 seconds multiplies your score by 4
Writing just enough code to pass the keyboard to your pair is highly rewarded!
Ping Pong Programming
The game is based on possibly the most collaborative and fun of all the pair programming practices.
The rules are simple:
● You write a test and make sure that it fails
● I implement enough code to make the test pass
● I write a test and make sure that it fails
● You implement enough code to make the test pass
● Goto 1
Refactoring is done whenever the need comes up.

20. Happy pair :)