This is the first episode of a series of codecasts where I will explore, together with a remote (duh!) pairing partner, what remote pair-programming is. It is also about pair-programming techniques, and how they help us, or not.
My remote parter this episode is Llewellyn Falco.
Traditional Style Pairing
Two people stay on the same computer and code, for a specific problem.
But it is more than that. We have two roles: driver and navigator.
Driver = the partner who writes the code, and focuses on small details, on short term.
Navigator = the partner who understands what the driver writes and focuses on long term decisions. Typically the navigator’s focus is around the design, architecture concerns, clarity, conceptual cohesion, etc.
During a session of traditional style pairing the roles can stay the same, or they can change. But both roles have the same focus: try to solve the problem as fast as they can with the highest quality possible.
We started with a very simple kata, solving roman numeral addition, like the romans would add them. During this session of traditional style remote pairing I was the driver and Llewellyn was the remote navigator.
After a while we stopped, because we thought it was enough of a demo to show what traditional style pairing is. And we had a debrief. Here is the result:
- The person at the keyboard will take decisions
- The navigator will watch over
- Navigator helps when:
- Driver makes mistakes
- Driver can make things simpler
- It is quiet
- It gets louder when we’re stuck
- With remote paring is difficult to stay engaged
- Changing typing is a good option, but it’s harder to change
- The driver needs to explain what they are doing
Many thanks to Llewellyn Falco for taking the time to record this codecast with me.
Check the next episode of #RemotePairProgramming: Ep 002: Strong Style Pairing