Pairing Makes Progress
So, I invited people the other day to pair with me. Some of have taken me up on the opportunity. This has been great fun, and I look forward to some upcoming pairing appointments.
Here are a few insights that I’ve had so far.
It takes a little time to get started. I notice people are a little skittish in the beginning. They’re feeling vulnerable and so am I. There’s usually something kind of difficult looming on their minds, and they know they don’t know all the answers. (If they did, why pair, just write the code and be done with it, right?)
I took notes on some of what goes on in the beginning of a pairing session. People are organizing thoughts, catching up with the ideas to be implemented, reading over notes. Some of this might be really useful, as someone is finding courage to expose their thoughts and do their best efforts.
It took a lot of trust to have people expose their half-baked thoughts. The results, though, are stunning. Really insightful ideas were worked out. Things that I thought would be too complicated turned out tractable.
Since I was the senior developer in our experiments so far, I found that mixed in a little tutoring with our pairing. I don’t know if that worked out as well with my pairs. I’ll ask them if they felt it was a good use of their time.
As time goes on, I’ve been overwhelmingly tired. I remembered how tiring pairing can be. It took a conscious decision for me to lean into the session. After about five minutes, my energy levels shot right back up and we were doing great.
For the remote pairing, I had Line In running. It’s a feedback loop that comes back to my headphones so I could hear myself speak. It helped me annunciate better, even though I still mumbled sometimes. It’s a free app, and worth using to be more clear.
We used Google Hangouts mostly today. In the past I’ve used JoinMe, Skype, HipChat, ScreenHero and probably several others. My favorite is to use a remote proxy. It takes a little set up and the pair programmer needs to feel comfortable on the command line to pull it off. All the details were laid out well in Remote Pairing.
In these recent sessions, however, let the remote pairs type and we took turns when we were pairing in person. If only one person can type, the more-junior developer should do that. It’s harder for the non-typer to stay engaged, so let the person that’s not trying to ingest an encyclopedia of new information worry about that.
I let the sessions go a little long. When I suggested we call it a session, my pairs were always ready for that. They may have been a little intimidated to say they were tired. I’ve known some career-long pair programmers that have no problems with sharing how they are doing. It’s important, though, to take breaks when people are tired. Otherwise pairing is just a chore.
Humor was my best ally in the experience. Any time I could tell a little joke or keep things light, my pair seemed to relax more and lean more into the experience.
That’s about it for now. I’ll share more experiences as I have them. I’ll also talk with some of these super pair-ers and see what they’d suggest. The invitation is still open, of course. If you’d like to stretch your coding muscles, drop me a line at david@hirablecoder.com and we’ll find a time to do this.