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.
Act I: Receiving help
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.
Act II: Transitioning to giving help, that I am capable of giving
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.
Such as:
- Sitting in uncomfortable silence, when I’m out of ideas on what to do next
- Opening a file, and forgetting why I’m there
- Temporarily forgetting my Vim keybindings, and thrashing around in the terminal, while my puzzled coworkers watched
- Constantly losing my train of thought, trying to maintain a conversation and understand code at the same time
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.
For example:
- Identifying variable and method names, that aren’t what they say they are
- Refactoring using functional programming and Sandi Metz style composition
- Asking bricklayer-style questions, double-checking how we got here, and what we’re setting out to build
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.
Act III: Delivering value that the other developer needs
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?”
For example:
- Refactoring current implementation for understanding
- Applying a computer science algorithm to a messy problem
- Making sense of, and summarizing, new business logic
- Finding new ideas
- Validating the approach they are already taking
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?”
Epilogue
So there you go: pairing sessions now go smoothly, deliver tons of value, and are actually fun.
Conclusions and ways to improve
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 the needs and goals of the session
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?
Explore new ways of offering solutions
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.
Practice awareness
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.
Resources for continuous growth
Tuple’s Pair Programming Guide
Tips, tutorials, and resources for thoughtful pair programmers.
Nonviolent Communication by Marshall Rosenberg
Examines “The need behind the request” for any given communication.
The Power of Now by Eckhart Tolle
Explores the idea of becoming aware of the present moment, and appreciate it, instead of mentally trying to figure everything out.
Pair Programming - Mentorship Styles and Techniques for Growth
Learn the pros and cons of pair programming and the mentorship styles and techniques you can use to grow with your team.
Best Practices and Tools for Managing Remote Development Teams
Learn best practices for remote software development teams to more effectively manage and complete projects. These guidelines help ensure that remote meetings, communication, and team projects are productive, even when they happen remotely.
Level Up Your Development Team with Better Agile Retrospectives
One of the best parts about creating great software is getting to collaborate with others. It's also one of the hardest things to get right.
