When I first started pair programming, I found the most important part was even if I had a solution that would work, if I couldn't explain it to my partner, it was not a very good solution.
Being able to convey an idea often forces it to be closer to the simplest and most comprehensible version of that idea.
> if I couldn't explain it to my partner, it was not a very good solution
Absolutely. I used to work in an aviation company writing software. When we were discusing architectural decisions (big or small) we often played around with the following thought experiment: Imagine that there was an accident with an airplane which was using our software. Maybe it was our fault, maybe not. Nobody knows. You are sitting in a cramped room with an irate NTSB investigator who points at this part of the code and asks “why on earth did you think this was a good idea?” If you don’t have a good and easy to understand answer to this question maybe we shouldn’t do it that way.
> ...if I couldn't explain it to my partner, it was not a very good solution.
I've found that in situations like that, I just write out a prototype and that clears up the confusion.
Usually, what I'm trying to explain is good, but there's some context that I can't get out of my head and into theirs that's critical to understanding the thing I'm trying to explain.
At an early stage of my career, a product person asked me to walk them through our code to show how a particular algorithm worked so that they could verify it worked according to their initial design.
Since I was using higher-order programming to control dispatch of various business rules, and they were not familiar with higher-order programming at all, there was a bit of a communication barrier/learning barrier that needed traversal.
Being able to convey an idea often forces it to be closer to the simplest and most comprehensible version of that idea.