How to Win Friends and Pair Program
3… 2… 1… My first blogpost! I feel like I’m on the jumbotron at a Dodgers game so hoping not to embarrass myself more than usual in case anyone out there in the crowd is actually reading this.
Last October I decided to make a sharp pivot into software development from a career in the non-profit space where I had focused my energies for most of my career after graduating clown college. I’ll share more about the the hows and whys of that transition in a later post or even series of posts, cuz it’s been pretty awesome. Currently I’m three weeks in at an epic coding boot camp at the Flatiron School in Lower Manhattan, surrounded by highly intelligent, motivated and interesting people from all backgrounds taking the plunge together together into exciting new careers in tech. Like many other programs of its kind, Flatiron takes people with little to no professional technical experience and makes them ready for hire over the course of twelve weeks.
In my short but intense three weeks thus far, I’ve come across countless ideas, tools and practices worth sharing and discussing. I heard a great podcast from Ruby Rogues on “pair programming” during my morning commute that inspired me to write about this topic. Its one of those subjects that’s easy to become excited about from an early stage in life as a developer.
What is Pair Programming and why do we care?
Pair programming is an outgrowth of the Agile Software and Extreme Programming movement that picked up a lot of steam in the mid 90s. I think the XP folks said it well in their manifesto
Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status.
On the simplest level, pair programming consists of two programmers working together, often side by side in front of a shared screen. Typically one person will “drive” and the other “navigate;” the driver codes, analyzing the specific methods to build and charting a path through the problem toward a solution, while the navigator observes, reviews, and helps guide the driver by maintaining a more strategic, big-picture view. Having a clear understanding of roles up front can avoid an otherwise frustrating and perhaps inevitable tug-of-war.
We don’t want that.
When it goes well, pair programming can have many important benefits. Among them:
- Learning: working together on a codebase is a great way to learn a lot, whether about new tools, different ways of doing things, or even higher level approaches to solving problems.
- Productivity: pairing can help keep both participants more focused and accountable for their work. You’re less likely to aimlessly scroll down your Facebook feed when there’s a live human nearby expecting you to communicate.
- Happiness: its a great way to build rapport and connection between teammates, share successes together and mitigate stress.
Are there different approaches or is there a right way?
The answer is yes.
Flipping around through different tech blogs I was intrigued to find a wide range of opinions on what pair programming is all about and how its supposed to go down. One major point of contention is: how do we deal with an expertise gap between the two programmers? Some, like programmer Alan Sorkin, see this as undesirable. They think that the real benefits to be gained from pair programming emerge when you have two experienced programmers working together, with some marginal benefit in a situation of inexperienced developers working together on a “simple” problem. On the other side of the fence, some advocate specifically for the pairing of novice with expert for the express purpose of allowing the novice to learn from the expert.
Despite these differences of opinion, there are definitely common themes that emerge. Here are a two of the most interesting ideas I’ve picked up that would be applicable in a variety of pair programming settings.
- Switching roles should be natural and comfortable
The power dynamic between the pair should be flexible. Jeff Dickey, a CLI engineer at Heroku says that it should “always be okay to ask for control” and when for some reason it isn’t, this suggests that the pairing is not a happy one.
For the pair to succeed, both people need to be engaged and concern themselves with engaging one another. A disengaged partner may either check out or force their way into control (say by grabbing the keyboard) when they feel left out in the cold. Two heads are better than one, provided that both heads aren’t at each other’s throats. Dickey adds that the “goal of pairing is always to learn… you should be learning something new the whole time.” This perspective should help motivate a reasonable person to want to respect the relationship and allow the benefits to accrue to both parties.
2. Let your partner make and learn from his or her own mistakes
This is hard. If you see someone coding down a path that seems incorrect or overly complicated, it is very tempting to want to help them correct course and immediately point out a simpler/better/more awesome way of doing things. But this is problematic for two reasons. Firstly, her way might actually end up being better or have redeeming qualities that you didn’t anticipate. Secondly, even if that’s not the case, its very important to give them space to figure stuff out on their own.
I read an interesting post from ThoughtWorks that shared this rather counter-intuitive lesson. Many a well-meaning and inexperienced navigator will jump to correct a driver or offer advice as soon as they come across an apparent roadblock. This is especially tempting when you’ve got code to ship and due dates rapidly approaching and you just want to get it done. But feeding an answer to a partner when he could figure it out on her own with a little bit of exploring and testing is basically an instance of giving him a fish instead of letting him learn on his own. If they go through the maze a bit on their own, they’ll come out with lessons learned and will be better equipped to help someone else with a similar challenge later down the line. There are limits to this as well, though. You don’t want to be that guy who lets his partner pull his hair out all day long over a problem and then say “I knew the answer all along!” That’s going to feel a bit like this
Pair Programming in Context
If you do a Quora search on Pair Programming, you’ll find two of the top four questions to be:
“Why is it that when pair programming produces better code, almost no company practices it?” (for the record, many answers debunk the assumption that few companies practice it)
and
“Is pair programming worth the trade off in engineering resources?”
The second question informs us a bit about the first. Even though students in coding boot camps might have lots of opportunities to pair program, in the actual workforce, those opportunities might be limited to a few hours a week or even non-existent in your job depending on where you are. This is both because the cost in man-hours associated with assigning two people to a single task might be too much for a manager to swallow (though many would argue that the expense in man-hours is more than compensated for in the time saved in subsequent debugging) and also because many experienced programmers themselves may doubt the merits of pair programming or just be meanies. Regardless, a beginning developer should take every opportunity to pair program, particular with those with greater expertise. Happy Pairing!
