December 9, 2015

Pair Programming: Your Questions Answered

Events
Community
Traceability

We recently hosted a DevTalk webinar, “Better Together: Adventures in Pair Programming” describing our journey with pair programming. We received many great questions we wanted to follow up with a blog post. But first, if you missed the webinar and would like to see it, you can access it here at your convenience.

Here are some of the more popular questions with a bit more detail. 

If working solo in the pit, do the other people distract you?

A few people opt for headphones but most of the time it isn't a problem. The chatter in the background is kind of like learning by osmosis. Even if I am soloing, I do pick up on things are pertinent to my task if it is being talked about. Our pit is fairly small, we have 10 people in the room at most so the noise is somewhat contained.

What would you recommend be the minimum number of resources (e.g. programmers/developers, etc.) needed to be available on a "small" project in order for paired programming to be effective?

I would say 4-6 at a minimum and 10 would be an ideal. In our talk we described promiscuous pairing where each day one person from the pair stays with the machine and holds the context of the work and a new pair swaps in. Because pairing can be intense it is good to mix up the pairs so that personality and style differences are smoothed out.

I understand how the knowledge base between programmers grows together and levels off, however could this hold back the veteran fast-learning programmers?

Pairing works at all combinations of novice and veteran. Each combo has is merits. Two veterans can really take off and riff on each other. A veteran and novice can benefit from each other not only as a mentor/mentee role, but the veteran can get exposure to the beginners mind and find some real insights. Promiscuous pairing comes into play here too, every day when you switch pairs you have at least one set of fresh eyes on the problem and someone coming to the table with different skills.

What do you do when someone's sick or you have an odd number of people?

We would have one-person solo. It is perfectly fine to solo and can be a nice interlude. When someone is soloing we might use this time for a developer to pair with a designer or with QA, someone that developers don't necessary pair with. When a developer and designer pairing can be very powerful. This allows the designer to see a couple of options live and get to make the call on what looks or works best right then and there.

How did you pair with people working remotely?

We briefly worked with a team in Florida and we tried it a couple of times with them using Screenhero and Slack. It was a little clunky and felt second best to pairing in person, but I think it could work with a little practice.

What kind of tasks do you think pairing isn't well suited for?

I think pairing produces great results for most anything. But I do see an argument for not pairing on something that has a very well established pattern such as a simple CRUD operation, but even then I think that you might discover some benefits.

Can you give any advice on how to be a good pair?

A good pair needs to have skills that help any relationship grow. Good listening skills, good ability to verbalize you’re thought process, a little dose of humor and put the ego in the back seat. Easier said than done of course, but practice makes better. These skills can be learned and they will help you in both work and non-work relationships.

Thanks to those who participated in our webinar on Pair Programming. You can watch the On-Demand webinar and let us know if you any questions that weren’t addressed.