[wolfram74]

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.

[krisoft]

> 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.

[simoncion]

> ...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.

[ludston]

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.

[ludston]

Can you give an example of a solution that you came up with that you decided couldn't be very good based on it being hard to explain?

[darkerside]

Probably not that you'd understand very well