I was told to choose pairs randomly each session. However, important to avoid same knowledge level programmers, as one of the goals of pp is to learn from each other. So two seniors or two juniors doing pp is not a good idea in my opinion..
We tried this once, but was a complete disaster.
We had a star coder who was twice as good as the next man who would enter a zen like trance for 10 minutes and then his screen would fill with reams of perfect code. Put anyone with him and the second person might as well not be there.
Also put the two worst people together - instead of two turds you get on slightly more polished turd. But it is still a turd.
A couple of people didn't get on, so they couldn't work together - it would just degenerate into a discussion of their birth legitimacy.
Everyone on the team should try and pair with everyone else on the team. A 'Pairing Matrix' (a grid with developer names along the top and side) can help keep track of how many times everyone has paired with each other. Put a checkmark in the appropriate grid square whenever two people pair.
A major advantage of pair programming is Knowledge Sharing. This generally refers to knowledge of the code that is currently being written, but you can also take pairing as an opportunity to transfer knowledge from a senior developer to a learning developer.
Pair programming is a weird one in the sense that it really depends on the personalities of the people involved as to how well it will work. I've seen people start to do pair programming then five minutes into the exercise the observer decides to leave the driver to the job. This can happen for a variety of reasons, e.g. either the driver doesn't give feedback (or take feedback) well. Some people are just used to working on their own and hence want to do it that way, breaking this habit is hard. Some suggestions:
From an HR/review perspective it might be worthwhile to encourage pair programming by tying it to a six monthly or yearly review process, a section in your review dedicated to collaboration and pair programming could be good for encouragement. Hope that helps.
If the pairs are working effectively, it doesn't matter who pairs with who. So the problem to solve isn't who pairs with who. It's how do we work effectively.
Effective pair programming means:
I can't tell you a lot more than that, because there is no technical trick to achieving effective pair programming. It is 100% a "people" problem and 0% a technical program. That means when it works wrong, you will sometimes have trouble putting your finger on why; nor will always know the reason it worked right. But one of the core values in an agile process is to ask each other questions such as:
If people are having difficulty working together, these questions should be asked right then and there, and resolved. It's that important.
There is one trick I know of that can help to achieve effective pair programming: Whichever of the pair is the expert (in the domain, language, tool, etc.) should not be driving. That way nothing gets onto the screen unless both programmers understand it: After all, I can't type your great idea unless you can get me to understand it, and if you have to tell me each character to type, that's just driving by proxy. So help me understand so I can turn the broad brush strokes into code.
When it comes to who is mixing up with who, let your knowledge of the goals behind effective pair programming guide you. Are John and Sam pairing together so much that there are parts of the code only they know? Then knowledge is not being distributed beyond that pair, and they should mix it up. Otherwise, if the goals are being met, if the team is working effectively, don't worry about it.
In our team we let a random generator decide on the pairs each week and we make sure no pairs work together for two consecutive weeks.
If you have two people that really can't get along then you have a big problem anyway. I haven't seen this happening anywhere I worked so far, at least I didn't notice. I wouldn't want such a situation in my team. If you end up with people fighting, it's probably best if one of the two leaves the team.
If the skillset is very far apart, the weaker person has a chance to learn very very quickly. A smart developer should be very happy about such a chance to improve and try really hard to follow. If people stay with the company, you may end up with many zen coders eventually.
Of course it's usually easier if at least one person in the pair has experience with the area in the code the team will work on. For us this automatically happens because we let the pairs pick their tasks from a queue of tasks with enough to choose from.
Although I principally like Wayne Conrad's reasoning that the expert should not be driving I would argue from our experience that this may reduce the velocity by a factor of 2 or more. Sometimes you don't want that slowdown. When you are refactoring old code that only one person knows there may be a lot of jumping around and then the person that knows the code is so much quicker. When you work in a language that only one person knows well, the weaker person may loose too much time for finding brackets, delegate syntax and whatnot.
If you have the great luck to work together with a true keyboard wizard (like Rodrigo BamBoo), it's just great to sit back and watch. For me that was one of the nicest experience I had pair programming so far: I had a vague plan about the domain (Queries into BTree indexes), he knew better than me how to put things into code.
I think that the best pp will pair onself. The HR job is to listen, to watch and to ask.
If the overlap is too big, the better programmer will tell: I won't work with this newbie, and the newbie tells: he is killing me!
Choosing pp by trial-and-error method may be a good way to experiment, measuring productivity.
BTW, How do you convert programming skills to percents??