{"id":2195,"date":"2017-11-23T08:30:40","date_gmt":"2017-11-23T06:30:40","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=2195"},"modified":"2020-01-14T18:29:54","modified_gmt":"2020-01-14T16:29:54","slug":"remotepairprogramming-ep-004-pairing-techniques-with-michel-daviot-michel-as-navigator","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2017\/11\/remotepairprogramming-ep-004-pairing-techniques-with-michel-daviot-michel-as-navigator\/","title":{"rendered":"#RemotePairProgramming Ep 004: Adi & Michel Daviot – Michel as Navigator (part 2)"},"content":{"rendered":"

About<\/h2>\n

During this episode from the #RemotePairProgramming series we continue the exercise from previous episode<\/a>. My coding pairing partner this episode is Michel Daviot<\/a>.<\/p>\n

Pairing Techniques<\/h2>\n

Question (Michel)<\/strong>: When would you use this remote pairing\u00a0techniques and pairing (like Strong Style<\/a>, Farsight Navigator<\/a>, etc)?<\/em>
\nAnswer (Adi)<\/strong>: When people are very used to their code, but don’t know how to refactor it, it is very useful to use Strong Style<\/a>, because the Driver would know how to navigate around the code, but won’t know how to refactor or use a specific legacy code technique. The Driver knows the language, the project and so on, but the Navigator knows the techniques.
\nWith new code Strong Style is very useful when you get stuck. And then the driver took control, pushes the rhythm and the steps to have progress.<\/p>\n

Question (Michel)<\/strong>: Do you explain to the people you use Strong Style<\/a>?<\/em>
\nAnswer (Adi)<\/strong>: Not really, because just coming up with theoretical concepts up-front feels weird. I just say “let’s pair and try this”. Maybe at the end of the session I might explain.
\nThe other approach is a game called Farsight Navigator<\/a>, where the Navigator looks far away for the design, and the Driver takes the small decisions. This technique works quite well, but you need to have very good Navigator skills to know where the design is going. So the role of the Navigator is to know which design options are not good and the solution would get stuck.
\nWith Strong Style the Driver doesn’t need to know anything about the code, design, direction, etc.<\/p>\n

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

<\/p>\n

The Problem<\/h2>\n

Scientists have sticks of different length and ants that walk on the sticks. When there are more ants, they collide on the stick and both ants change the direction. We need to compute the time each ant spent until reaching the end of the stick. During the codecast we need to model this problem using TDD and Strong Style Pairing. Adi is the navigator and doesn’t know the problem, while Michel is the Domain Expert and the driver.<\/p>\n

Video<\/h2>\n