Surviving Chaos with Pairing

by Jeff Langr

March 30, 2015

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.


My Distributed Development Workstation

For the past three months, I’ve been working as part of a startup (minus a few weeks’ worth of other customer engagements). I’ve found myself more often than not working with a new (to me) technology each new day. Here’s a list of some of the new elements:

  • MacOS (my first day-to-day Mac!). Getting used to the keyboard differences, particularly Ctl-Option-Command stuff, has been the most challenging aspect of things, particularly since I’ve still had to switch off to Ubuntu/Windows machines throughout.

  • Ruby. I thought this would be my chance to stop being a Ruby newbie, but we’ve moved on to something better:

  • …Clojure. I’m excited to being picking this up, though it’s my first-day-to-day experience in a functional language. I’m feeling somewhat comfortable with basic language concepts after maybe 6 days of working on it, but of course I’m not anywhere near knowing how to do things the “right” way.

  • Coffeescript. My web UI development experience has always been minimal. It’s kind of weird to be learning Coffeescript with only a shallow foundation in Javascript, thought Coffeescript seems like a nice clean approach (but you still need to peek under the covers at times).

  • Angular, D3, _, and a few other odd Javascript libraries

  • Emacs. Never really wanted to take this on (I prefer vim), but glad I’m learning it. Learning a whole new voluminous set of keymaps is pretty challenging!

  • RubyMine, IntelliJ. It’s been several years since I did any heavy lifting in IntelliJ. Another set of keymaps to remember.

  • Elasticsearch, Sinatra, Jasmine, RSpec, Minitest, numerous other Ruby gems, Nginx, guard, lineman, bootstrap, RabbitMQ, Kafka, Amazon EC2, and maybe a few other small things I’m not remembering. Lots of little tools, none on their own very large an undertaking.

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.

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.