Pairing is a great way to give new life to an old problem. Even when I pair on a simple kata, my pair always do something I don’t expect, like using a data structure I would never think to use, or write a different test. All of these make me go out of my usual route and see the problem differently. At the time when Tom and I paired (ping-pong style) on the bowling kata in Ruby, he had never done it before. I had done the kata in Java a few months earlier. If it was only me doing the kata again in Ruby, I would probably do it very similarly to how I did it in Java, use the same algorithm, write the same set of tests, in the same order. Pairing with Tom had some extra perk since he is a mathematician and he approaches problems very differently from me. When it’s time for Tom to write a test, he would not write the test I had in mind, which in turn force me to solve the problem differently now that I need to write the code to pass his test. This dynamic took us in a whole new direction from what we would have done alone. I found the process very enjoyable.

Pairing at its best can be very powerful, as in you can learn a lot from your pair and together solve problems that a single person cannot. I’ve had this great experience while pairing with Ian, a crafter from our LA office last week. Ian was fixing a bug that causes a date/ time picker on his TypeScript/ React frontend app to go haywire. He had tried several options with no luck. After 2 hours trying out a few possible solutions Ian has in mind and still could not solve the problem, Ian told me to drive. It can be a little overwhelming driving the pair when you first jump into the codebase, knowing that you don’t understand the system very well. In order to be useful, I needed to understand the system better, by asking questions. My questions were very simple, how does this field appear here in the first place, which function puts it there? However, as we go through this simple process, me asking questions and Ian explaining the system, we eventually arrive at a part of the codebase where Ian had not thought to check and long story short, that was where the bug originated.

There are times when I am not sure if I can be of any help to a crafter as I pair with them in a codebase that I have no context whatsoever. My mentors have assured me time after time that there is value to crafters by having an apprentice by their side asking question. They even told me to approach pairing with a crafter as helping them do their work in order to get in the mindset of being more engaged in the process.

Sometimes after working on a codebase for so long, you think you know it well and you are just set in your way. When someone new comes along, asking questions, if you can explain everything to them, that’s proof that you understand your system very well. Sometimes their questions can make you reconsider your way of doing things, if it is the best way. Especially when solving a persistent bug, sometimes you just need a fresh pair of eyes, a different perspective.