Pair Programming Slides - Code Like This

Pair Programming

Pair programming =

Two people +

One problem

(and usually, one computer, one keyboard, one screen...

...notwithstanding remote pairing tools and face-to-face pairing desks)

One driver, one navigator

Listen to how engaged the navigator is. They are focused on what's coming next, but they are not idly speculating. E.g. circa 4min in

Two heads are better than one!

avoid dead ends and ratholes
simultaneously focus on current problem and context (one focus per person)
"rubber duck" - explaining a problem out loud often leads directly to a solution
instant code review
exploit complementary expertise / memory / personality / energy levels
less likely to fall into bad habits or get stuck

[show graph of maxima]

Every person thinks a little differently, has different expertise / experience / energy / perspective.

So for any given problem, at any given moment, one of the partners will be more able to solve that problem.

With pair programming, you get the best of two at every moment.

(And often you get solutions that are better than any individual would have come up with alone.)

MYTH: pairing reduces productivity by 50%

FACT: pairing (when done well) increases productivity, especially when the problem requires creativity to solve

(pairing also increases communication, satisfaction, and the rate of high-fives per minute)

Docendo discimus - "by teaching we learn"

Expert-expert pairing -- best case; experts share tidbits and experience as peers
Novice-novice pairing -- good case; novices can struggle and discover together
Expert-novice pairing -- beware -- in this case, the expert must accept the role of mentor or teacher, and be patient and let the novice drive most of the time

writes code, runs tests, has control of code
focuses on one problem at a time
self-narrates at a high level
- e.g. "Okay, now let's introduce a random number function"
- NOT "I'm now creating a variable named X that I'm assigning the value 4"
- assume your navigator can read the code and understand it; the goal is to communicate purpose and intention, not mechanics

keeps a "todo" list
politely reminds driver, e.g.
- can we write a test for that?
- can we refactor a bit now?
- let's check in
- let's revert
- let's take a break
always asks permission before grabbing the keyboard
- "do you mind if I drive now?"
silently count to 10 before interrupting with e.g. a typo or syntax error
- chances are that the driver will notice and fix it themselves