About a year ago, my team leader decided that she would start delegating tasks for me and a colleague to tackle as a pair. It started out just fine, it was our first pairing job, and we were trying to adapt, and we kind of got the hang of things, and started getting the benefits of pairing for like a week. But thing is, maybe we're not too compatible, maybe we don't think the same way, but when we disagree about two viable solutions it often feels like discussing the disagreement is unproductive and we get hung up on small stuff with no mutual decision, and given enough discussing it gets exhausting.

Anyway, as the months dragged on, constantly having to sit together and work side by side got tiresome, so we fell into the habit of each working on different parts of the task, or one working while the other didn't really participate too much. We're on very similar skill levels so eventually it got to us just discussing what should be done and then one does it while the other waits, only getting involved if something unexpected comes up. We kind of burned out of each other, or at least that's what it felt like to me. I tried raising these concerns with my superiors and they reacted by asking for specific reasons why we're tired and I couldn't really explain so they basically insinuated we just weren't doing it right, and just "give it time" and we'll get the hang of things.

It's been almost a year now. I took a vacation and upon returning we got back to pairing and we had a really productive first few weeks, it felt like all I needed was a break, but now we're distant again and not really working together, even though we're technically pairing.

I'd like to know, is this a common thing? Is the company doing something wrong or are we not pairing right? How common is it for the same pair to work together for a full year? What should be done about this?

  • 1
    Possibly helpful: When does pair programming work? When to avoid it? Jan 4 '17 at 20:06
  • Is pairing with someone else an option?
    – user8365
    Jan 6 '17 at 22:00
  • Learn more about pair programming, then go and show you pair that you think you guys are doing it wrong and here is why. Then you both go to your supervisor, if agreed, and state that you like it but you need to do it the right way.
    – Sandra K
    Jan 9 '17 at 4:16
  • JeffO, we're a very small team, 4 people total. I've suggested switching pair, but they seem resistant to the idea, not sure why.
    – bpromas
    Jan 10 '17 at 19:38

Pair-programming marriage is a pair-programming anti-pattern. You should not always pair with the same person for weeks, even for days.

Here is an excerpt from content from Agile in a flash card related to pair programming :

All production code

Must be developped by a pair

Both parties contribute to the solution

switching roles beteen "driver" and "navigator" frequently.

Change pairs frequently

three times per day or more

Develop at a confortable workstation

that accomodates two people side by side

End pairing when you get tired

Constraint to no more than 3/4 of your work day

And the detailed version:

I love the opportunity to sit and program as half of a pair. I'm sure it's not for everyone, but I too was once one of those who resisted the idea. Part of my resistance was my fear that people might realize I didn't know as much as they thought I did. I got over that. Many people who have given an honest effort to pairing (done by the rules) have found out that it's actually very enjoyable and effective.
Another common resistance is misunderstanding of what pairing is, and of what benefits you might get from it. To be effective, you can't just sit near someone else and expect magic to happen. The rules are simple, but not obvious. It makes perfect sense to me why someone would hate pairing after doing it poorly. The least obvious rule is "change pairs frequently." A typical conception is that pairs are married at the hip for days at a time or even weeks. No, I'd slit Tim's wrists and he'd slit mine were that the case. Instead, we switch pairs often. The tedium of dealing with one person all day long aside, one of our goals in switching often is to ensure that not just two, but at least three people contribute to the solution of a task.
The downside of frequent switching is the overhead cost of context switching. It takes time to explain things! But that's where the synergies in the original XP practices come in: If you're doing TDD well, following simple design, coming up to speed on the test at hand isn't a terribly difficult proposition. And in fact, the need to minimize context switching overhead is a subtle force in the direction of improving code quality.

  • 4
    Lois could you add the core content of the linked site to your answer and then add the link as a source instead? if the link dies your answer will lose a lot of value for future visitors, but will Keep credit to the original Author. Jan 5 '17 at 13:08
  • Is pairing with another person an option in this case? Pairing for part of the day may be more applicable.
    – user8365
    Jan 6 '17 at 21:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .