Having recently been exposed (by a class forcing us to use pair programming) to this, I have a few insights on pair programming: - Both partners must be fairly

Having recently been exposed (by a class forcing us to use pair programming) to this, I have a few insights on pair programming: - Both partners must be fairly versed in the language and methodology of the programming. I think its fairly explanatory, but there is a definite limit to how much of a knowledge gap there can be between the experienced and un-experienced programmers. If that gap is too big the only result will be slower coding, written at about the same quality as the more experienced programmer would write on their own, but with considerably more frustration on both programmers' parts. - Do not do a "test trial" of pair programming, working on simple projects. From what I has read about research into pair programming, the only gains come from working on complex problems which would be difficult to conceptualize entirely in one person's head. If work is only done on small projects, pair programming will look like a complete waste, since non-pair programming would have similar results considerably faster. - Pair programming has a sort of half-life in terms of knowledge. The lower-skilled of the pair will learn half the gap in knowledge at aproximately the same rate. While that rate will be different between people, from my experience with pair programming, the lower-skilled partner will learn half the knowledge gap in 3-4 days. This will repeat, and the gap is halved every 3-4 days of working together. On top of that, it seems to me that Pair Programming is not a good fit for long term programming. It seems best suited when there is an individual who needs to learn about a specific system, and that using it long term lessens the effectiveness it has. Once the transfer of knowledge has slowed down, and both individuals know aproximately the same ammount about the system, it seems to be much less effective. However, since their (should be) a constant learning about the system, occasional pair programming sessions would be advantageous after this point. If I were to engage in pair programming, this is roughly how I would set it up: Assuming that there a 5, 8-hour work days, divided into 2 4-hour programming sessions (for a total of 10 sessions a week), when a new individual is introduced they should spend the majority of their time pair programming with the more advanced individuals. While I am just pulling this number out of thin air, I would think 8 sessions of pair programming the first 1-2 weeks, with 2 sessions programming alone. As time progresses, I would shift to steadily less pair programming, with a minimum of 2-3 sessions per week. This is largely because I am not convinced Pair Programming leads to better coding. I have not seen any real evidence to support that, in fact, from what I have seen it tends to slightly more convoluted and difficult to debug code (although pair-debugging seems to be incredibly effective). I have, however, seen how useful pair programming is in teaching a person. The ammount a person can learn in a short time, while working in a pair is incredible, and can be simply astounding.