Why Do We Pair Program?
- better designs
- fewer bugs
- much better spread of knowledge
- moral support
- harder to procrastinate
Over do (or under do) the work
This pair does a great job of walking through many forms of awkwardness
that can happen when people first pair program. They act out various
highs, lows, do's and don'ts of pair-programming collaboration. They
have many high value takeaways from training people on pair
programming.
"10X your teamwork through pair programming"
- Selena Small,
Michael Milewski
(RubyConf AU 2020)
Various models to choose from including Driver Navigator Model, Backseat Navigator, or Ping Pong Pairing
It is all about good etiquette, Programming out loud and Switching
roles often
Years of programming in open plan offices did not prepare me for programming out loud.
When programming out loud you are literally talking through your thought process. With everyone else working in pairs around us, it made it easier. The process of articulating your thoughts helps to clarify them.
The driver handles typing, navigating between files, and basic implementation. The navigator, on the other hand, looks at broader concerns and checks for mistakes. Does this method fit with the architecture? Are we potentially duplicating an implementation from elsewhere?
Like driver-navigator, the driver sits with his hands on the keyboard and executes the mechanics of typing and such. But unlike driver-navigator, his partner dictates tactical instructions. This might mean that she tells the driver when to create a method or open a new file. She might also tell him what to name a test or a variable.
The first person writes a failing test and the second person gets it to pass. Then the second person writes a failing test and the first person gets it to pass.
We mostly used Ping Pong Pairing at MyWave. Sometimes there would be some investigation required and we would slip into some form of Driver Navigator or Backseat Driver. Once we worked out more about what we needed to do we would slip back into the rhythm of the quick short bursts of coding and writing tests then swapping. But it was always about Programming out loud.
As navigator we could set a time limit. Like agreed to explore something but put a time limit on it to get us back on task. You make rules and adjust them as you go. Which is why Programming Out Loud and Etiquette are so important.
When pair programming we would make a commit to the code base we
would using the :pear: emoji in the commit to specify the other
person's name.
eg:
git commit -m 'this is a commit about programming :pear:
sandy'