When I first started working at Headway, I noticed that some of my pair programming sessions were better than others. At first, this was a mystery to me, but the picture eventually became clear. Through my daily practice of pair programming here at Headway, I made different discoveries and observations which I will share in this post.
I hope my experiences and tips can help you identify issues, make improvements, and find better ways to create value every time you pair with someone on a project.
Faced with a daunting codebase, and being new to Ruby and Rails, I spent a lot of time asking for help in our Slack channel and doing live pairing sessions. Most of these pairing sessions consisted of jumping to different points in the codebase, exploring what was already there, and trying different patterns until something worked.
It was very effective. It was also completely alien to me.
Up to that point, I programmed like a bricklayer, building up layers of knowledge until I understood the whole thing–and only then, executing a solution. I found myself in different pairing sessions, growing more disoriented with each new open file that appeared in the Vim terminal, grasping at different chunks of code as they whizzed by, wondering when the session would be over so that I could return to the self-study deep-dives that I was used to.
And yet, during other sessions, I experienced a series of quantum leaps, which would have taken me hours to grasp, if going it alone.
Some sessions delivered value to me, and others didn’t—-this was a mystery to me, that I quietly placed in the back of my mind, as I continued my daily work.
From time to time, other coworkers would ask me for help. It always made me nervous. Not only was I new to this vast codebase and to Ruby, but I also had to navigate the awkward moments of pair programming.
At first, I avoided pair programming. As time passed, I developed my own unique style, and things got easier. I became aware of some personal strengths, which could help the team out in different situations.
This was a big moment for me because I finally felt competent with pair programming.
But, just like when receiving help, some sessions were better than others. Even though I was competent while pair programming, I still didn’t enjoy it.
I wondered why, even after contributing to the group using my own unique strengths, I was still missing something, during certain sessions, but not others.
Again, I placed this mystery in the back of my mind, as I continued my daily work.
At the time, I was going through a bass guitar tutorial. The tutorial was saying that in addition to having good technique, you need to listen carefully to what the rest of the band members are playing and play certain notes to make them sound even better.
“Of the unique skills that I am capable of giving, what does the team actually need, in this specific situation, to be effective?”
I put myself in my coworker’s shoes, and asked the question, “When this certain developer asks to pair with me, in this certain situation, what is he/she really looking for, and how can I supply that?”
And here’s the thing: a person’s needs are different on every pairing session. Different individuals need different things while working on different parts of the project at different times. Part of discovering these needs is a trial-and-error approach: throw different things out there, and see what works. And in order to know if your trial-and-error attempts are working, you can compassionately listen and be fully present during a pairing session, and continually ask yourself “What notes can I play, at this given time, to make us sound awesome?”
So there you go: pairing sessions now go smoothly, deliver tons of value, and are actually fun.
Pair programming can be viewed as a transaction: the person requesting help needs something, and with your unique talents, you have a way to supply it. Both sides of the transaction have to balance: the other person needs to find value in what you’re giving them, and you need to find value in the process of giving it.
Identify what, specifically, you or your coworker needs to move forward. Are you stuck on inspiration? Implementation is difficult? Lacking specific domain knowledge? Lacking the “story” of the domain use-case?
There is an infinity of tools you can use to make a pairing session successful. A “big picture” question might help to clarify the approach. A well-placed “what if” question might prevent a security issue. A simple statement, such as “that’s awesome”, or “I like they way you built this” might provide reinforcement against a difficult problem.
Sometimes, even a measured silence can be helpful: witnessing your coworker struggling through a difficult process, acknowledging their journey, and allowing them the space to discover the solution on their own terms.
Pay attention to the overall “energy” of the session, whether it’s moving forward, or stagnant. If it’s stagnant, do something different. See if you can develop a sixth-sense when pair programming (certain queues you can listen for or watch for) that will tell you if the things you are providing are actually helping the other person.
Tips, tutorials, and resources for thoughtful pair programmers.
Examines “The need behind the request” for any given communication.
Explores the idea of becoming aware of the present moment, and appreciate it, instead of mentally trying to figure everything out.
See all the ways we can help you grow through design, development, marketing, and more.
A podcast about building successful software. We provide actionable advice around product validation, execution, and promotion.
Receive the latest articles, resources, events, and more!