{"id":2063,"date":"2017-10-26T16:47:30","date_gmt":"2017-10-26T13:47:30","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=2063"},"modified":"2020-01-14T18:30:21","modified_gmt":"2020-01-14T16:30:21","slug":"remotepairprogramming-ep-002-strong-style-pairing","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2017\/10\/remotepairprogramming-ep-002-strong-style-pairing\/","title":{"rendered":"#RemotePairProgramming Ep 002: Strong Style Pairing"},"content":{"rendered":"

About<\/h2>\n

The second episode of this #RemotePairProgramming series is about Strong Style Pairing. My coding pairing partner this episode is Llewellyn Falco.<\/a><\/p>\n

Strong Style Pairing<\/h2>\n

The Driver is just the typist of the Navigator<\/p><\/blockquote>\n

Pair-programming is a technique where two programmers stay at the same computer and code together on the same problem. 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 strong style pairing, the Navigator will take all the decisions. The Driver focuses on the small details, just to do what the Navigator has in mind. If something is unclear the two have a dialogue. The same as with traditional style pairing, both roles have the same focus: try to solve the problem as fast as they can with the highest quality possible<\/strong>.<\/p>\n

\"Strong<\/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 strong style remote pairing I was the driver and Llewellyn was the remote navigator being the strong pair.<\/p>\n

Debriefing<\/h2>\n

We paired for a while, and we decided it’s time to stop and make a debriefing. Here are mine and Llewellyn’s thoughts of Strong Style Pairing.<\/p>\n

    \n
  • Talk in intention, then location, then details<\/li>\n
  • Navigator will use the time while the Driver is doing something to understand what to do next<\/li>\n
  • It’s impossible for one of us not to be talking<\/li>\n
  • Have the dialogue courtesy<\/li>\n
  • The navigator can program much better in a pair than alone, because not crashing between the low and the high level<\/li>\n
  • Two situations: when the driver knows what to do, and when driver doesn’t know what to do<\/li>\n
  • You can always learn things while pairing<\/li>\n
  • The navigator can learn a lot from the driver<\/li>\n
  • It’s OK to go down the wrong path<\/li>\n
  • Confidence increased with often commits and good unit tests<\/li>\n
  • Use comments when the intent is more complicated<\/li>\n
  • Always have the intent clearly in your head, in “English”, and only after say what you mean to your pair<\/li>\n
  • The readability of the code is important<\/li>\n
  • Ask for “trust” on short term when you are navigator and you are doing weird things<\/li>\n
  • When someone doesn’t trust you, it doesn’t matter how much logic you use<\/li>\n
  • As a navigator in strong style time goes faster, because you are in a flow<\/li>\n
  • The navigator is more engaged in strong style pairing<\/li>\n
  • Domain knowledge increases dramatically when doing pairing<\/li>\n<\/ul>\n

    Video<\/h2>\n