Reconsidering Pair-Programming

I re-read All I Really Need to Know about Pair Programming I Learned In Kindergarten as well as Programming in Pairs Testimonials. I admit I haven't been a fan of pair-programming because it hasn't worked for me. I like to sit alone following a train of thought, and I can't do that when someone else is there. If find I'm like that for any kind of analytical work, like for some of the cases in my Finance classes - I have trouble thinking when my groupmates are around. Still, I find the arguements for pair programming valid - continuous code review, having someone to discuss your thoughts with, reducing the temptation to be distracted, etc. Particularly the third argument - I tend to wander off (read my mail, read an article, nap...) when I should be working.

I think the reasons for Pair Programming failing with me are the following:

• Not being able to develop a working relationship with a programming partner - Prior to being partners in our company, Butch and I did our consulting "on the side". The logistics of this arrangement didn't allow us to meet and code together every day. We tried to remedy this with "code sprints" on weekends, but it still wasn't enough to build an efficient synchronicity between us for pair-programming.
• Not being able to code continuously - My time is currently divided between programming and business tasks - a schedule too disruptive for pair programming. I'm hoping a partner can come on who can take over much of my business tasks so I can spend more time in coding. Part of my plan is to offload marketing to strategic partners so that our team is more focused on our core competence.

Here's how I think pair-programming can be most effective:

• Dedicated, contiguous coding time. - I need to be free from most non-programming tasks for weeks at a time. Hopefully a partner can come on board that can take over much of these for me. If this can't be done, time-box non coding tasks, like replying to emails only in two forty-five minute periods in each day, and reserving only one day a week for client calls and other non-programming related meetings.
  
• 10%-50% done doing solo work. - The "Kindergarten" article said that some work should still be done solo, such as exploratory work or work involving deep concentration. The way I see it, pair programming should be scheduled, say, two hours in the morning then two hours in the afternoon, and then the rest of the time doing solo work.
• Daily planning. - I think a pair should decide on what they aim to accomplish for the day and general design approach before they start to code. My experience in the "ad-h0c" pair programming is I have a particular train of thought and my partner disrupts it with a very different approach. I think some daily planning ensures that the pair pulls in about the same direction.
  
• Unit-tests should especially be done in pairs. - According to Butch. I think this is because the unit tests define functionality anyway, so if you get those right, much of the rest of the code becomes trivial to implement.
• Bigger monitor! - Butch and I are not small, skinny people. It gets cramped looking at the same screen (usually a 15" or 15.4" laptop screen). I need to get myself at least 19" monitor someday. Heck, even better, a dual-monitor set-up!

If ya'll have any more tips on how to make pair-programming more effective for a lone wolf like me, do post it here.