Assuming that the more experienced person in the pair has the temperament to mentor the other person, pairing someone with little experience in the language or the problem domain with an experienced person would facilitate knowledge transfer. The less experienced person would have a mentor to instruct them on the language, the domain, the application, and the best practices or conventions of the team.

There’s an interesting summary on C2 wiki about knowledge transfer using pair programming. The more senior person, who was brought on to serve as the team mentor, learned a lot from the junior programmers and his knowledge even increased as a result of being paired with more junior, less experienced software developers. There are some other stories about expert programmers being pair with domain experts, as well.

This is exactly the use case pair programming was made for: sharing experience between old beard and young grasshopper.

This is a two-way sharing: agile insects have much to teach to rheumatic brains.

When I got promoted to my current team I was the newbie in J2EE but I was the expert in the domain. My senior (the new team leader) was skilled in J2EE but not in the platform.

I think I learned more about Java2EE in these 4 months with pair programming than reading a book and the team leader learned about the platform as well.

The experience gap between the two is the key to pair programming imho.

I’ll describe my experience and try to get some “strategy” out of it.

I’ve once pair-programmed with a complete non-programmer. He was expert on the subject matter of the software product we developed. On the contrary, I had no experience in the problem domain. And he also was my supervisor at the moment (I know this may sound strange 🙂

Major benefit of this methodology was that I had to explain implementation of many things from his knowledge domain, thus ensuring the exactness of implementation and his understanding of the process, which meant he understood why it took this time.

Another benefit is easy focus on the task, no distractions (ha-ha, imagine opening Twitter before the nose of your boss).

It was quite intimidating at times, however, since even a tea break became quite a “distraction from work” (not from his point of view; it was just inconvenient to ask for break and so on).

So, this isn’t really a pair-programming since he pretty much couldn’t review the code as it was typed in. However, it seemed to be a sane strategy (at least for some time). It ultimately worked at all because of relative simplicity of both development methodology (I mean, no complex software design techniques like OOP Patterns were involved) and subject matter. This would’t work in case we had to develop a compiler I think. I believe it still could work in case non-programmer observer is participating in the process of development of small clearly defined pieces. Say, it’s ok to have him watch programming of a function “compute the parameter X from Y and Z by given algorithm”, but may be not so ok to have him watch overall system design process (meaning development of software architecture, i.e. hierarchy of classes, since it’s too abstract).

I think it would work even better in case he would have some basic programmer skills, as I would’t have to explain “what’s an array is”.

Hope it helps 🙂

In my experience if both the programmers have low skill level it can be a problem. In that case there is often a tendency to try copy-paste programming. I think it can be a good idea not to pair two novice programmers together until they reach specific level determined by the team.

Otherwise pair programming can be a great idea assuming of course two guys are ready to share what they know. Not only is it a great way to keep everyone informed of the source code but also acts as good place for new ideas and discussions.

So long as the team members have respect for each other, pair programming can be beneficial regardless of the programmers’ experience levels. Even if a junior programmer just spots a few syntax errors (which we all make!) before the more experienced programmer, that’s still time saved in compiling code.

I also think it can open up a programer’s attitude towards the capabilities of other members of their team, especially if they have an open mind and expect that everyone can teach you something.