Pair programming in consulting

I have to admit I am a solo programmer: as a lot of my coding is trial-and-error I don't really like people watching me make mistakes or mumbling :-) More on the practical side, I think it is more efective if once the code is working *and* polished I explain the what's, why's and how's (something, ahem, I'm good at, ahem). But, as a consultant, many times I have to help my customers with their coding chores. Currently, for example, I'm helping a very experienced team to get up to speed with .NET distributed development. First all, we defined our architecture (security, layers, logging, etc., etc.) and then we prioritized the use cases. What is left to do every day now is to select a task, we discuss our options, do some drawings, and start to program (somebody from the team and me). I have to admit that I take the keyboard kind of reluctantly (remember my first line) but most of the times it works pretty well: after some stumbling, the job gets done; furthermore and to my amazement, my fellow programmer finds the experience *enlightning*, which to me is kind of funny (remember, these are pretty smart and skillful people, it only happens that they don't know .NET). As I said, given the choice I'd rather programmer alone and explain what I did later but if I am forced to do pair programming I have to admit the technique works really well.