{"id":2061,"date":"2017-10-19T13:40:05","date_gmt":"2017-10-19T10:40:05","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=2061"},"modified":"2020-01-14T18:30:29","modified_gmt":"2020-01-14T16:30:29","slug":"remotepairprogramming-ep-001-traditional-style-pairing","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2017\/10\/remotepairprogramming-ep-001-traditional-style-pairing\/","title":{"rendered":"#RemotePairProgramming Ep 001: Traditional Style Pairing"},"content":{"rendered":"

About<\/h2>\n

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.<\/p>\n

My remote parter this episode is Llewellyn Falco.<\/a><\/p>\n

Traditional Style Pairing<\/h2>\n

Two people stay on the same computer and code, for a specific problem.<\/p><\/blockquote>\n

But it is more than that. We have two roles: driver and navigator.<\/p>\n

Driver<\/strong> = the partner who writes the code, and focuses on small details, on short term.<\/p>\n

Navigator<\/strong> = 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.<\/p>\n

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<\/strong>.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

The Problem<\/h2>\n

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.<\/p>\n

Debriefing<\/h2>\n

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:<\/p>\n

    \n
  • The person at the keyboard will take decisions<\/li>\n
  • The navigator will watch over<\/li>\n
  • Navigator helps when:\n
      \n
    • Driver makes mistakes<\/li>\n
    • Driver can make things simpler<\/li>\n<\/ul>\n<\/li>\n
    • It is quiet<\/li>\n
    • It gets louder when we’re stuck<\/li>\n
    • With remote paring is difficult to stay engaged<\/li>\n
    • Changing typing is a good option, but it’s harder to change<\/li>\n
    • The driver needs to explain what they are doing<\/li>\n<\/ul>\n

      Video<\/h2>\n