- Consulting / Coaching
- Jeff’s Blog
I’ve been amiss at my writing for the past year-and-a-half while knee-deep in a startup. I wrote this post somewhere near the end of 2013, but never published it until now. I’ll be adding a follow-on soon. You’ll also have an opportunity to read more about this distributed development experience at PragPub in an upcoming issue.
There are a few familiar things, including Jenkins and vim. Altogether, it’s well over 20 new technologies in less than 50 days of work. All this while occasionally bouncing back to Windows, Visual Studio, C#, Fitnesse, and some C++ (to support the release of Modern C++ Programming with Test-Driven Development). I’ve regretfully had to put aside my ramping-up on Android development.
Even more challenging: Most of us work from home.
It’s insane, frustrating, and somehow exhilarating. These are all technologies I’m happy to learn, so it’s all good, but most days I feel fairly stupid. Of course I’m not anywhere near mastering any of the new technologies. Right now, we’re bouncing mostly between Clojure and Coffeescript/Angular, so I hope to master them in due time.
It shouldn’t work, but it does. Why? Everyone on the team is an accomplished programmer. We pair online through most of the day using Google Hangouts, and switch roughly daily (though sometimes every couple days, a bit long for my taste but it helps to have the time to immerse more on the unfamiliar stuff). We communicate frequently through the day via a persistent campfire chat, a morning business briefing, a morning dev planning session, and ad hoc hangouts as needed.
What’s not to like? Well, the pairing constantly sometimes gets old, and we’re pairing a little longer per day than I’d prefer. Bouncing around so frequently between technologies has been rough. And remote communication has its hiccoughs that detract from the experience. Ultimately, nothing is as good as being there.
However, our efforts have been very effective, even with most of the other programmers (about 10) not masters of most of these technologies either (many are intimate with Ruby). We’ve managed to make the customer happy with a quick first effort, and are well into incrementing on a second product.
I can’t imagine attempting something like this without pairing. We’ve had at least one candidate dismiss the opportunity because of pairing–“it can’t possibly be anything but a waste of time to have sharp programmers work together.” But they’re the ones who are missing out–it’s hyper-productive, rewarding, and has been the glue in keeping us from devolving into complete chaos.
I enjoy writing, though I’m not as prolific as I’d like to be. I tend to re-read what I wrote many times, often second-guessing it. Like any writer, I also find difficulty from time-to-time, getting stuck on how to phrase a paragraph or a sentence. I’ll typically mark things and return to them later. All-in-all, I can slam out text, but getting polished product out the door can be challenging.
I read and enjoyed Weinberg on Writing: The Fieldstone Method when it came out. I already had been employing its core idea to an extent: capture thoughts as they arise (index cards work great!), then incorporate them as appropriate in an article or book. Each idea on a card might act as a central idea around which writing can build, or it might be used to fill in a “hole” in the text. Emphasizing this technique has made writing a lot more fun, and I tend to not lose great thoughts that had popped into my head.
My best writing experience, however, has been collaborating online with Tim Ottinger, originator and co-author on Agile in a Flash. We had a slow winter–after writing a pile of articles for PragPub, we both got very busy with work, and did little writing. We finally found some time to commit to delivering a new Agile in a Flash post, Is Your Unit Test Isolated?
Two days ago, we got our headsets on, started up a Skype conversation, and talked for a few minutes to agree on what we’d work on. We started some single-threaded editing on a very rough draft at Blogspot, but that wasn’t effective, so I pasted it all into a Google Doc.
Google Docs doesn’t provide the best document editor in the world, but it is highly effective for collaborative writing. You can see each others’ cursor and typing as it occurs, and you can look at offline revisions if necessary for comparison.
Mostly we’re not talking via Skype (and in fact sometimes we’ll collaboratively edit without a voice conversation at all). Instead we’re communicating through the document. Tim will start re-working a paragraph that I might have just finished writing, and I’ll get out of the way. Sometimes I’ll watch and toss in a comment–just typing it right into the document–and other times I’ll go off and stab at a paragraph that Tim wrote. Or I might go off and re-read the document, looking for flow and completeness problems. It’s pretty haphazard, yet it works, and it’s fast. We might go back and forth at a paragraph a few times before we figure it works.
Collaborative writing works best if you grow a layer or two of skin. We’ve learned to be pretty direct: “[[ I don’t like that ]],” Tim might type (the brackets are our way of setting off comments). Ok! Good technical writing requires harsh critique. Better Tim drop a pointed comment than a few thousand readers.
At times I’ll return to find something I’ve written completely gone or gutted and rewritten. It was a little disconcerting at first, but I’ve learned to trust Tim’s reworkings. I can always look at the old revision if I thought an important idea got deleted.
The unit test article took us about an hour to get to 98%. We let a couple outstanding concerns sit for a few hours, made some offline changes, and published it the following morning (yesterday).
As with pair programming, I’ve found such highly collaborative pair-writing to go much faster than writing on my own, and produce a far more effective product.
For almost a year, I pair programmed on a daily basis as part of a team working for GeoLearning, a small software company that is no more. My enjoyment was tempered by the fact that I was pairing remotely, online with a headset and sometimes a camera, using Skype and WebEx. The contrast to live pairing was marked.
Pairing or not, as a remote developer I didn’t feel like I was a real part of the larger, “live” team. I felt that my influence as a remote person was insufficient.
The remote pairing also carried the same issues that “live” pairing can create, most of which are minor. For example, the team had very few standards, which led to some wasteful debates during many of the pairing sessions, still not that big a deal. But couple a lack of standards with stubborn people, and you have a useless pairing session.
I can get along with just about everybody; not the case this time out. I paired with one developer whose concept of TDD was almost completely opposite mine. We produced virtually no useful product during our two or three pairing sessions (we then ended up on different teams, thankfully). In attempts to stop the arguments, I would often say, “Let’s just go with your preferred way of doing things for now.” No such luck. Some folks are simply contrarians.
Remote Pairing Pros
Being remote sucks in so many ways–primarily the isolation from the rest of the team–that I wouldn’t have even considered the position had it not been for the ability to pair. I never felt like I was a real part of the larger, “live” team, and I felt that as a remote person I was unable to influence the team much.
So despite the negative aspects of my remote pairing experience, it was the best that I could expect for this opportunity. Ultimately, having this opportunity remotely was better than not having it. And the pairing brought me a small but significant step toward feeling like I was a real part of something.
I’m currently working a three-month contract for a local firm. It’s a very stable company, there’s no travel on the near horizon, and my commute is about seven minutes door-to-door (it’s three miles away, with only one stoplight inbetween). Those three elements are great, but just about every other element–ranging from pay to preferred way of working to technology–is a concession.
There’s no pairing. My first “real” week (i.e. past most of the HR and setup BS) was spent sitting in an office, digging through a (test-less) codebase, occasionally IMing my teammate a couple offices over to ask questions. It’s a typical no-process environment.
Here’s how I feel about no longer pairing:
Pairing is not for everyone or every team. The bullets above suggest that there are serious challenges both with pairing and with not pairing. But most of the time, I’ve found pairing to be far more enjoyable and productive than not.