The document discusses pair programming, involving a driver and a navigator to collaboratively write code, emphasizing its benefits such as improved code quality, shared knowledge, and better problem-solving. It addresses challenges like passivity and fear of judgment, proposing strategies to enhance the experience through communication, empathy, and structured practices. Additionally, it highlights tools for remote pairing and the importance of understanding team dynamics through personality profiling.

1. #1 - What is pair programming?
1 driver + 1 navigator
“two people working together at a single computer”.
Extreme Programming (XP)
#2 - Benefits: why pair programming? (workshop write on board, or sticky notes)
better code => pair pressure (don’t let the other down) => code and fix
natural tendency (slot machine example)
learning
sharing knowledge
better thinking: two brains are better than one, bouncing ideas
Rubber duck debugging or the expert theory (deep questions)
there is ALWAYS something to learn, to teach.
become better at articulating your thoughts
reduction in coordination efforts managing N/2 divs => managerial argument
Improved resiliency to interruptions (although potential internal
interruptions)
But we have code reviews… => choices have already been made that could have
been better with another brain, chances to influence these choices are gone.
#3 - How to pair program?
1 Driver, 1 Navigator
Every fifteen minutes or so (or a full pomodoro), the pair switches roles
by sliding the keyboard over
Ping pong with TDD : write test, other implements and write another test
##EXERCISE: Pair draw a landscape with life (any kind of life) => Pen switches
hand every 3 minutes.
#4 - Challenges, pitfalls of pair programming (workshop write on board, or
sticky notes)
passivity: active engagement at all times
running commentary going silent => programming out loud
fear (of judgement, fixed mindset)
lack of confidence, imposter syndrome
intrusion on personal space => use pomodoro, timeout
pairing is NOT mentoring, both should be considered equal
remote pairing
culture
#5 - How to improve the experience? (workshop write on board, or sticky notes)
##Abstract:
make each other look good : Agile Australia the Spark team
No blocking No wimping No hogging
adopt a growth mindset : Agile Australia Peter Heslin - leveraging mindsets
for effective leadership
example with kids exercise : you are smart vs you worked hard
embrace ambiguity
give space
be humble and accessible
forget pride, it will only get in the way => equals
don’t judge
use empathy, be compassionate
don’t fear/induce fear -> avoid bashing
##Concrete:
personal hygiene
alternate to find the speed of the pair, ideally a bit faster than the
slower
use pomodoro/timeout to ensure you have breaks, enjoy short break together,
long break separately.
discuss all the things : announce what you intend to do, and why, ask for

2. feedback early, code out loud
use the pair programming ping pong pattern
visualize => sequence diagrams
give feedback regularly => 320 feedback techniques, sh!t sandwitch
slice thinly, it will boost confidence (plan well, whiteboard)
##EXERCISE: Pair slice a story, must have 8 to 18 steps : Alistair Cockburn
Elephant Carpaccio
#6 - Personalities challenges
Profiling can help you know how to be a better pair if you can’t read
people
Lots of profiling tools out there, those aimed at interaction are obviously
a better choice, ex: DIsC
Remote pairing => tools sharing screen can make the experience awesome (ex:
screen hero)