Since last summer I have been one of our few "remote Pivots" after I moved from San Francisco, CA to Atlanta, GA. Pivotal and I agreed that I'd try working remotely, remote-pair programming full time with fellow developers in our San Francisco and NYC offices. Overall it's worked out wonderfully for me, my teams, and clients. I use the same technologies that fellow remote-Pivot Chad Woolley recommended in 2008 -- a VPN connection, Mac's Screen Sharing.app and Skype video chat, but we're always looking for ways to more seamlessly integrate our remote developers into their teams.
With that in mind I became very excited when the iPad 2 was released, with its front-facing camera and FaceTime app. How perfect! For the last month our team has experimented using an iPad as a "remote presence" device for me.
How did it work out? Keep reading to find out!
At Pivotal Labs, we spend most of the day pair programming. The typical setup is an Apple iMac with a keyboard and mouse for each developer. We've been using the 24" iMacs for a while, usually with a second 17" display off to the side. But all our new machines are 27" iMacs, and those are so big we don't usually use the second display. The pair sits side-by-side at a desk facing the screen together. Here's what it looks like:
We have had great success pairing this way at Pivotal. But while it is a good setup in a lot of ways, it falls short ergonomically. First off, both people have to sit off to the side of the display, which can cause leaning, slouching, and twisting to get into a position to both see and type. And it's also hard to actually look at your partner without craning your neck around. Even though the desk is wide, keyboards and mice take up room, so there can be a lot of jostling and adjustment on the desktop, and chairs and such can collide as well. Those things aren't terrible, but they do detract from the experience and my spinal fitness.
A frequent feature request for Pivotal Tracker is support for parallel tracks of development for multiple pairs of developers (you are pair programming, right?) It's true that Tracker does not fully support parallel tracks within the same Project, but you can get most of the way there by doing what we do on many Pivotal Labs projects: use labels to identify multiple tracks of development. With labels, you can easily visualize and manage parallel development tracks while keeping your team's work in one Pivotal Tracker Project.
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.
Futzing Around
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.
Flipping Switches
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.