9/27/2017 - 6:12 PM

[Initial draft, adapted from Mike Bowler, @mike_bowler and Dave Nicolette, @DaveNicolette]

Pair Programming Styles

Driver-Navigator The driver is at the keyboard, and takes a tactical view of the problem. The navigator observes and takes a strategic view of the problem, offering suggestions and asking questions. The roles may switch back and forth as needed, depending on how the work flows and how the interaction between the two people works

Useful for general development and for knowledge/skill transfer. When used for knowledge/skills transfer, the junior member takes the driver role and the senior member takes the navigator role

Ping-Pong One member of the pair writes a failing unit test. The second member writes production code to make the test pass, and then writes the next unit test. The first member writes production code to make that test pass, and then writes the next unit test. The pair continues in the same way to solve the problem.

The ping-pong style is usually applied when two peers are working on a problem together.

Silent Running Typically as a variation on the ping-pong style, the developers do not speak aloud, but communicate only through the test code and production code they write.

Silent running is sometimes used as a way to alleviate the monotony of a long pairing session.

Pair Programming Anti-Patterns

Superman: He refuses to be impaired by a slow partner. He will hog the keyboard and save the world all on his own.

Absent-Minded: He’s distracted, sleepy, or preoccupied with other things besides the task at hand.

The Back-Seat Driver: As navigator, he breaks the driver’s train of thought with a non-stop stream of trivial comments.

The King of Shortcuts: As navigator, he mentions every keyboard shortcut the driver fails to use, but doesn’t make practical or meaningful observations.

The Anti-Mentor: As navigator, this senior developer leaves his junior partner without guidance.

Fearful Freddie: He refuses to refactor code he didn’t personally write.

The Defactorator: He reverses refactorings others have done to make the code consistent with his personal preferences.

The Soloist: He works solo as much as possible, and has a large repertoire of excuses not to pair.