Journeyman Pairing Sessions

This is the third and last part of my series about my Journeyman Tour two years ago. In how to Journeyman Tour I summed up all facts and advice regarding planning such a tour. Then I described what I learned by going on a Journeyman Tour. Today I want to share more about the actual pair programming sessions. During the tour I already summarised some findings, e.g. I wrote about discussing expectations with your pairing partner up front and bringing a keyboard for all languages used in the area.

The Very First Session
When I started my tour I did not know how it would work out. I was uncertain how others would react and afraid to screw up. It helped me that the very first session took place in my usual environment. Raphael and I met in a co-working space I had been before. I knew the place and how to get there. Also we worked in Java, the language I had been using almost exclusively until my tour. By using my main language I was not bothered by the language and its tools. Third we started a new project from scratch, starting with a detailed introductory discussion. There was no old code I had to understand. And finally Raphael and I shared the same mindset. It was clear from the beginning that we would do TDD and create high quality code that he needed for his games. The only thing that was new for me during our pair programming was being on tour and pairing with a stranger. It was the perfect start. Probably I was just lucky, but I recommend starting your tour like that. Look for someone you know, working in a place you know, using a programming language you know. This might be a colleague from a previous engagement or someone from your favourite meetup community who agrees with you on most things.

Warm-up
When pairing with a stranger for the first time, I needed some time to establish a rapport. During my tour it took between a few pomodoros (two hours) up to the while day (eight hours) to get in sync with my partner and understand the domain to an extend that I was able to contribute. On the second day we usually worked much better. Due to this warm-up I recommend sessions of at least two full days with each person - assuming that you are looking for real pair programming during your tour.

Interruptions
Most of my pairing partners had blocked their calendar and made sure they were available the whole day without interruptions. Many did not even check their email all day. Some had even organised a meeting room so we could work on our own. Unfortunately not all people I visited knew how to "behave well". Working with heavy task switchers was really difficult. As the guest I did not complain about task switches, but when the interruptions became too many or too long, I went back discussing our expectations of the pairing. Few young developers had to be reminded to stay focused on the task at hand.


Tasks
In the introduction of my Code Cop Tour I explained my conditions as following: The only condition is that we will pair program. It should be a quiet time without meetings where you plan development activities on the mainline of delivery, e.g. writing code, writing tests or improve your build system. Obviously not all kinds of work, even on the mainline of delivery, were useful to me. For example researching or spiking, where we both had no clue how to continue, did not work well. And I hated spending two days of my tour looking for a single bug, tracing execution through auditing records in the database. While I believe that pair programming might be useful for debugging in general, I did not have the relevant experience to help my pair here. I recommend rejecting such work for your visit, or at least discuss the problems with your pairing partner up front.

Taking Notes
I brought a large notebook with me to record all interesting things. I wrote down the full names of my pairing partners, their expectations and any learnings during the sessions. I kept notes of each session retrospective and a kind of personal diary. I glued in business cards, Post-it notes and all stickers I collected during my tour. In the beginning I used a cheap pen, which made my hand hurt after some time. I had not practised my hand writing for almost 20 years. I fall back to my fountain-pen, which created a mess of ink now and then, but was a better writing device by far. I wrote a total of 55 pages A4, two pages per pair programming session on average. For road thoughts I used the standard voice recorder of my mobile phone. While it worked I do not recommend using it during driving, especially when going fast on the highway.

Known Or Unknown Pairing Partners
In the previous blog posts I quoted some other Journeymen and named their advice according their names. While these rules make sense for me, you may chose to ignore them. The last of these "rules" is Samir's rule: If I do not know you, I will not pair with you. What Samir meant was to meet before the session, to get to know the partner and make sure that both get something out of pairing. This is definitely a way to reduce uncertainty and avoid surprises. Checking future pairing partners helps aligning your expectations with potential learnings. On the other hand - depending on your learning goal (see Daniel's rule, you need a learning goal) - you might want to pair only with people you do not know because it gives you more coverage.

That ends my notes. If you plan to go on tour yourself and have some questions I did not discuss, do not hesitate to contact me. And when you have been on tour, I would love to talk about how it went and compare our experiences. Please get in touch with me!