Recently I took part in panel discussion on DVCS where my introduction ended up with “my last check-in happened in 2003.” So yes, now I’m “programming” in Outlook and Word. In Excel if I’m lucky. It doesn’t make me some sort of expert in terms of discussing pair programming, does it?
When we are at pair programming I confess I was never a fan of this practice. It somehow feels unintuitive. I actually do believe wise folks like Ron Jeffries, Corey Haines and Yoda who tell us it does work, but it’s kind of thinking “Well, for Yoda even a lightsaber works pretty damn well and I could only hurt myself with the thing.”
Anyway, I remained skeptical for a longer time, especially that none of my teams have ever seriously introduced pair programming. Recently Corey Haines made me thinking about it from a bit different angle when he told on ACE Conference that pair programming is like an instant code review. I must admit it kind of speaks to me.
The next thing which added some doubts was my recent experience which isn’t really programming-related. After all, you already know my last check-in was when people I now hire were still in kindergarten. Recently I’m often working on different documents pairing with different people. It doesn’t really matter what these documents are all about but if you tell “appraisal system” in my neighborhood I’ll make you suffer.
We’re usually trying to write something creative and, while working in pair, it works surprisingly well. Technically it’s like pair programming – one keyboard, one monitor and a couple of people switching roles occasionally: one is writing and another one is reading, commenting and asking “What the hell have you meant by that?”
One interesting thing which happens is the flow. As long as both people are focused on a document writing goes pretty smoothly – either I have an idea what’s next or you’re just telling me what’s on your mind. Also there are quite a lot of discussions about what exactly we want to describe at a specific point so we kind of cut feedback loop down to the least possible size. But here’s the best part: whenever, for any reason, someone goes out of the room, productivity falls flat on its face like instantly. Whenever I was the one who stayed it was as if someone has just turned struggle mode on. And then, when we were back in the pair, after a while we were reaching the flow again pretty quickly.
Another thing is even more interesting. After a couple of such sessions when I thanked the person who I paired with telling how much they helped me I heard as a response: “Well, it was you who did the work, I was just sitting there and commenting from time to time.” I was all like “Are you insane? What on Earth are you talking about? If not you I wouldn’t get even one fifth of this stuff in that time and it would be sort of crappy anyway.” In short, both of us thought it was the other one who did most of the work, which was quite funny.
Now a question: does it differ that much from writing code?
If asked, I wouldn’t say that pair document writing would yield such good results. Unless we tried it, that is. Now, I can hardly imagine we could have done it differently.
Of course it isn’t the best solution in every single case but the longer I think about it the more situations fit pair writing approach. I’m definitely going to do pair document writing more often.
And maybe it’s time to try pair programming in some teams as chances are it would show similarly unintuitive and similarly good results.