About
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.
The Problem
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.
Debriefing
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
Video
Acknowledgements
Many thanks to Llewellyn Falco for taking the time to record this codecast with me.
What’s Next?
Check the next episode of #RemotePairProgramming: Ep 002: Strong Style Pairing