Are there specific things that you look out for before getting the team into pair programming? Obviously pairing someone who's great with C++ with another who knows ASP.NET best won't get me far, but how about someone who's great with C++ with another who knows Java best but can pick up C++ quick enough?

What else? Experience levels? Character traits?

  • 4
    I don't understand why C++/ASP.Net is not a productive pairing in your eyes.. Commented Dec 18, 2010 at 8:57

5 Answers 5


At my last job we did a lot of pair programming. We found it was not a good method for teaching/learning. When we tried to use it for teaching often the pair would lag, one would get frustrated.

The best performance was usually from 2 people of similar skill level with sightly differing strengths, approaches and ideas. People would develop a sense for the others strengths and weakness and would be an effective complement as a result.

We also found pairing to not be very effective for simple bugfixes, features. Areas where the work was straightforward and simple.

Then again that's just my experience in one development team.


I've found pair programming very useful for learning/teaching. But don't put a guru with a newbie, the newbie will be overwhelmed and the guru annoyed. You should have one person who knows a bit more than the other, or two persons that know different things. In that case pair programming is a very efficient way of transferring the skill set.

It is IMO least useful when two programmers have worked so much together that they would solve a problem in exactly the same way if they did it separately. Then you are wasting one persons time.

  • 1
    Spot on! I agree completely - pair programming works best when there's a good dialogue going on. Two people with the same take on something will usually never have that sort of dialogue.
    – FinnNk
    Commented Dec 18, 2010 at 23:26

Heh, since my experience on the subject is merely theoretical and I haven't actually got any first-hand experience of any agile development methods, I'll still throw my thoughts to the mill. I would believe that the best outcome from pair programming would be in such situations where the two programmers have a slight difference in their experience and skill levels and have been working in slightly different areas. The "writer" should have less experience than the "reader" to utilize the teamwork the best way. The reason is that the "writer" gets to learn and become much more confident with his/her code and the "reader" gets to share his/her experience to benefit the team and the project. At no point should they feel unequal though; I would imagine that if the "reader" feels less experienced and somewhat lost, then his/her efforts won't be used to their full potential. Active switching of roles, both being able to give and acquire constructive feedback is the key; it's useless to try to pair persons who can't get along that well.

  • absolutely, it's crucial to have the pairs almost matched. otherwise, at each point the one that's least experienced would slow down the other.
    – Javier
    Commented Dec 18, 2010 at 11:21
  • @Javier - I disagree, one of the biggest benefits of pairing is spreading knowledge within a team and also challenging each other's decisions (in a good way). I wouldn't recommend pairs with such a big differences that the sessions are basically tutorials, but looking at it from the team perspective a pair with different backgrounds or levels of experience is better than one that is exactly matched. I agree with youngdood - it's far more crucial that they can get on with each other.
    – FinnNk
    Commented Dec 18, 2010 at 23:23

You shouldn't look at pair programming in what language one knows better than the other, I believe if you want a program to be done in C++ pick 2 people that are good at that, or a fast learner, the same goes to any other language/technology.

Try looking at other assets that the two might have, they should have always different approaches, if they fight over ideas that's a good thing because from 2 good ideas a great one might be found, unless it gets ugly.

Also a pair should always be of people with similar skills otherwise one will be doing all the work and the other trying to catch up, worst case scenario it will take double, or more, of the time as if the best person would be doing it all alone, as he will always be explaining what he does.

This is from my experience at university as we always do works in teams, working with people that have similar skills, to me, has always proved to be more rewarding.


There is a book called Pair programming illuminated (ISBN 9780201745764) which describes several aspects of pair programming, among other things teaming up persons with different experience. One of the chapters is named "My Partner Is a Total Loser" and Other Excess Ego Problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.