A basic introduction of the practice of pair programming along with some common styles and tried and tested techniques.

1. Pair Programming Styles

2. $whoami
• Attila Bertók
C# technical lead
• Contact:
• bertok.atti@gmail.com
• https://www.linkedin.com/in/bertokattila/

3. What?
• Comes from eXtreme Programming (Kent Beck, you might remember
the name by now)
• Mentioned in “Extreme Programming Explained: Embrace Change”
(1999)
• So ‘90s!

4. Even older than that
• in the 70's
• "Dynamic Duo" concept observed by Larry Constantine
• the guy who coined cohesion and coupling
• in the mid-50’s
• practiced by Fred Brooks
• Author of “The Mythical Man-Month”, IBM System/360 and OS/360 dev manager

5. Why?
“
Pair programmers: Keep each other on task. Brainstorm refinements to the
system. Clarify ideas. Take initiative when their partner is stuck, thus
lowering frustration. Hold each other accountable to the team’s practices.
”
[Kent Beck]

6. Why?
• Speeding up knowledge transfer
• Avoiding silos of knowledge, advocating better diffusion of knowledge
• Solving blockers faster
• Increasing code quality (acts as continuous code review)
• Shares the workload

7. When?

9. When?
• Always*.
*: well, almost always.
• Some trivial problems might not require two to work on
• Sometimes people can be more creative on their own

10. How?
• It needs to be done right.
• It requires a certain mindset.
• There is a learning curve.

12. How?
• One big screen (don’t do it on your laptop display)
• Desk that is comfortable for two
• Two keyboards (not joking, try it)
• Another team member (not only Developers! Do pair up with your
Tester or PO once in a while to get immediate testing feedback or
business feedback.)

13. Do
• PP instead of regular coding
• change roles often
• change pairs often
• pair with different people with different
seniority
• try to share knowledge (domain,
technical, practical) effectively
• ask the computer instead of arguing
(test your assumptions, or google
them)
• ask your peer if your idea makes sense
instead of telling them what to do
• suggest experiments instead of stating
a solution
• state clearly what is going to happen
before doing anything
• acknowledge useful information that
your peer tells you
• consider architectural or maintainability
suggestions

14. Don’t
• always enforce PP
• let management tell you if you
should do PP or not
• demand result ASAP
• tell your peer what to do, ask for
opinion instead
• leave your partner behind or let
yourself be left behind
• try to always be better than your
peer
• feel ashamed if your peer knows
something better
• make fun of your peer or assume
that your peer wants to test you
• have your code reviewed by your
peer

15. Pairing Strength
• Weak (traditional): anyone can
type (try two keyboards here)
• Strong: only on of the pair is
allowed to type

16. Pair Programming Is Like a Road Trip

18. Styles of Pair Programming
Roles
• Unstructured
• Driver / Navigator
• Driver / Backseat Navigator
• Driver / Tour Guide
• Ping / Pong
Pairing Strength
• Strong
• Weak

19. Unstructured
• No predefined roles, the two developers sit next to each other, decide
who’s typing, and away they code.
• Pairing strength determines who can type

20. Demo Time!

21. Driver / Navigator
• One developer is the Driver, who types, navigates between files, and does the
basic implementation (knows how to write a condition, a loop, etc.), explains the
Navigator the reasons behind the decisions taken regarding implementation
details.
• The other developer is the Navigator, who checks for mistakes, and looks at the
broad perspective (does the implementation fit architecturally? Is there a
possible refactoring opportunity?).
• Seniority Concerns: if the more experienced developer navigates, he might be
inclined to micromanage – make the more experienced participant drive! On the
other hand, knowledge retention might be better for the driver, so it might be
useful to let the less experienced participant drive.

22. Demo Time!

23. Driver / Backseat Navigator
• Classic Driver/Navigator setup
• The Navigator is a backseat driver, tells the Driver every little detail of
the solution in mind, as well as the reasons behind those decisions.
• Seniority Concerns: the more experienced member should be the
Navigator (and should explain details to the driver on the fly)!
• Something of a Knowledge sharing session as well.

24. Demo Time!

25. Tour Guide (Driver) / Tourist
• The Tour Guide is showing the Tourist around in the code, very much
like a code review (“just sit here next to me while I code this”)
• The Tour Guide types, explains concepts, rationale behind decisions,
etc.
• The Tourist has a passive role as an observer.
• Seniority Concerns: the more experienced developer should be the
Tour Guide. (The reverse is the Actor / Director style.)

26. Demo Time!

27. Actor (Driver) / Director
• One developer is the Actor, who tries to implement the whole solution,
takes care of both the tactical and the strategical concerns. The Actor might
ask questions to the Director, but is generally working alone.
• The other developer is the Director, who passively watches the Actor act
out the role (and possibly fail), then provides feedback (something like an
instant review).
• Seniority Concerns: the more experienced developer should be the
Director!

28. Demo Time!

29. Ping-Pong TDD
• One Developer writes a (failing) Unit Test.
• The other Developer makes the test pass.
• Roles might be switched more often than in other cases.

30. Demo Time!

31. Mob Programming
• Pair Programming extended to more than two people, even the whole
team (including Tester and PO)
• One person drives (writes the code)
• All the others are taking the other roles

32. Mob Programming, cont’d
• Participants are all involved and pay attention, they don’t leave the
room, don’t check their emails, etc.
• If one participant stops (bathroom break, coffee break) the whole
team stops
• Participants are encouraged to ask questions whenever they lose
context – if they fall behind, explaining things later will be more effort

33. Mob Programming, cont’d
• Driver should be changed more frequently then during PP, to keep
participants focused

34. Demo Time!

35. Q&A & Thank You!