We'll respond shortly.
Pair programming is the subject of endless discussion and debate. How often should we pair — 25%, 50%, 75%, or even 100% of our development day? Should we pair on remedial tasks as well as feature development? What about infrastructure work or research? Is pair programming valuable at all, or should we kick that hippie kumbaya crap to the curb, put on our headphones, and get some real work done?
Personally, I’m somewhere in the 95%-pairing range. Simple stories and bug fixes have a way of becoming complicated (or implemented sloppily) when soloing. Infrastructure is a notoriously siloed realm and spreading that knowledge around can only help everyone. Investigating production database issues, estimating stories, writing CSS, chopping up images using Fireworks — share the love!
So what is the last 5% for? Futzing.
I’m “futzing around” when I’m not doing anything important, maybe even wasting time, at least from a pure productivity perspective. Interestingly, while I’m not implementing features or fixing bugs, I’m expanding my mind. I’m learning in a way that is not conducive to pair programming or any interaction at all with other people: I’m exercising my personal way of learning that that is unique to me. Here’s an example:
On my current project, we’re using very advanced, powerful CSS selectors that blow my mind. While I understand what we are implementing and can see the immediate affect upon the application, it is impossible for me to grok the enormity of these techniques even though my pair is a master and great teacher. I’m learning, but not necessarily understanding. Collectively we are not in a teaching mode, we’re in a cranking-out-awesome-stuff mode. Now, I am not suggesting that we are hacking or moving too fast to learn — on the contrary, we are both learning much, and I often ask my pair to slow down and explain what the hell
.div:first-child:not(.row) + .row is doing. Our joint mission, though, is to get stuff done, not to explore every CSS pseudo selector. I’ll futz around with that later.
When I’m learning something new, especially when it’s complicated, I eventually need to futz with it by myself, with nobody looking over my shoulder. I need to flip all of the switches, break it, fix it, break it again the same way, fix it, throw in a little salt and pepper and try again. I need to try every parameter individually, then try to combine them. I need to hack and not feel bad about it. I need to do stupid stuff that could never possibly work because, even if I’m told such, I need to try it myself. Finally, I need to do this for 30 minutes until the “ah ha!” moment hits me and all of the tumblers fall into place in my mind.
Why don’t I do this with a pair? Because I must be in the driver’s seat the entire time with no consideration for pair programming etiquette: talking things through, taking turns, letting my pair try his ideas — no way. I need those brain cycles to figure this stuff out, to make the mental connections that are shorting out. I don’t know what I don’t know, and I need to find out for myself, in my own dumb way, by futzing around and making mistakes. Finally, I need to more than learn: I need to understand. When I’m done, I will use that new understanding during the other 95% of my development time to help my team build the best products we possibly can, and encourage them to futz around a bit on their own, too.