Imagine a basketball court...

Imagine two players, two basketballs, and two hoops.  Each player stands at his own end of the court shooting free-throws.  Every time one makes a shot, he has to run and fetch the ball, then run back, then reset for the next shot.  This is not only exhausting, but distracting:  The player cannot concentrate on shooting baskets well.

Now imagine two players that have just one basket and one ball.  One stays at the free-throw line, focusing on shooting.  The other stands underneath the basket, and fetches the ball for the other.  Often, this second player can leap and tip the ball in.  Each player is critiquing and learning from the other.

To make sure they get a balanced experience, the players trade roles from time to time.

Notice how adding a third player (or programmer) probably wouldn't help much.

It's a wonder that any coach would have the players on his team all throw hoops by themselves.

Now, how this applies to pair programming:

When you program solo, you are constantly making the mental "run and fetch" between thinking about the low-level task at hand and the higher-level implications of the task.  When you program in a pair, one person stays focused on the low-level, and the other on the high-level.  Each person is sharing experiences and experiments with each other.

It's a wonder that any coach would have the programmers on his team all program by themselves.

Contributors: RonWelte, GarethMcCaughan, some WikiGnome''''''s

----

Imagine: "DiningPhilosophers" who care (i.e. "thanks for the fork") -- paulgibby

''Sorry... huh?'''

----
CategoryMetaphor
----------------
ProgrammingWillNeverBeTheSame