It occurred to me that everyone has their own way to get to the same destination.  In programming, a professional may read books, they may go to conferences, they might merely use the platform documentation or they might dissect the platform piece by piece to decompose its function and learn how  it worksfrom the inside out.  They might even rewrite it just to figure it out.

I have one friend who told me he doesn't learn from books.  He finds they don't suit his pace of things.  He is one of the most capable, brightest individuals I know and he'll figure things out through experimentation and analysis.  Another peer I've worked with spends his time taking things apart just to learn how they work.  Then he rewrites them and calls them his frameworks.  While he is intelligent, I think he's terribly misguided because his goal is to prove how much he knows about things and the outcome is merely that he knows alot about things but produces nothing truly useful.  Then there are the readers.  I am a reader.  I read so many things that I hardly ever finish a book in entirety and I'm usually reading half a dozen at once.  Sometimes I have a dozen books on to-be-read-queue.  Then there are those people that find the process of staying on the leading edge costly and  prefer to wait for the inevitable trickle of  important information to find its way to them. 

What if all these people could benefit from all these activities?  What if each person's tower of knowledge was a week or two from being accessible every other person?  What if the person who waits for information could be the vehicle to deliver the important things that the dissector learned to the person who reads too much?  What if all anyone did all day was talk about the new things they've learned?  How might that affect the pace of growth in a group?  All these questions are on my mind related to Pair Programming.  I was not a believer until we had Richard Sheirdan of the Menlo Institute give us a one day fire hose on Agile methodology.  He is no dabbler in a few Agile ideas, he is a hard extremist on the agile front.  He's also speaking from real world experience, a lot of it.  He is a huge proponent of Pair Programming.  I'm not talking about height (though he is incredibly tall).  He made a point to say, "I will say a few enthusiastic words in favor of pair programming and then I will drop the subject."  But then he went on to mention it a dozen more times.  We started counting when our CTO took note that he'd brought it up the required 6 times to internalize the idea.  The point, in short, is that after enough a raving about the subject, I stopped mentally blocking the possibility that it has merit in my world.  I believe I am not the only one.  ...and now these questions.

If every two weeks, a person worked with a different partner to accomplish their goals, would the knowledge of each osmotically transfer to the other?  Would that information continue to travel through the whole group?  Would the team as a whole grow more quickly?  Would their progress slow or increase?  Would the cost of sharing a keyboard repay in both quality and efficiency?

When I have a question about technology, the capabilities and cost of implementing, I do a controlled experiment.  I'll research a little, try a small scale implementation and evaluate my results.  I'll report the results of our small scale pair programming experiments.