Pair Writing across Time and Space


Much like in pair programming, working with a partner through pair writing provides increased support and valuable immediate feedback. But there are additional obstacles when you and your partner are not collocated. Here are some tips on how you can still implement pair writing successfully when you can't collaborate in person.

Writing for publication is never really an individual exercise. You get feedback from editors or peer reviewers and, ultimately, from readers, which teaches you how to improve your writing the next time. Unfortunately, these can be slow feedback cycles, and in some cases the helpful criticism is too late to improve a particular piece of work.

We’ve each found significant value in pair programming—the development practice where two programmers jointly work on the same piece of software, usually side by side. Pairing has helped us produce better software: Two heads are better than one, in part because we can provide immediate feedback to each other.

We decided to collaborate on a series of articles a few years ago. Pair programming had worked well for us; why not pair writing? However, we aren’t collocated; we live a thousand miles and a time zone away from each other. Consequently, we had two significant challenges:

  • We couldn’t share physical artifacts like card walls or whiteboards
  • Because we both traveled, we were sometimes many time zones apart and unable to connect via Skype or Hangouts

We needed a way to share information and ideas despite the disconnects in time and space.

We agreed that Google Docs would be our primary mechanism, but we didn’t think too hard initially about the collaborative process. We were fortunate to have written together before, so we already understood each other’s writing style, and each of us trusted the other’s taste and viewpoint. We figured that once we had a shared medium to work in, we would be able to resolve any issues as they arose. Indeed, we coalesced rapidly due to the immediacy of the sharing and pairing.

A Simple Design for Writing

Writing is like programming in that the first draft tends to be messy. We’ve been taught to continually refactor our code to keep it clear and maintainable. We discovered that the same continual improvement habit works well for prose.

Paragraphs and sentences are akin to classes and methods, respectively. The single responsibility principle of class design—that classes should have only one reason to change—applies equally well to paragraphs. A good paragraph, as we learned in second grade, covers a single coherent concept. It supports that concept with just enough detail to get the idea across. We factor our larger paragraphs until each, like a good method, is only one idea long.

We similarly factor longer, run-on sentences to single-purpose, clear statements.

And so it goes with pair writing, except that two heads make it even better. What Jeff writes, Tim has to understand and accept, and vice versa. It’s no longer one person’s unchecked idea of what is palatable. Our reading of each other’s prose is our set of tests. If Tim can’t understand it or finds it distasteful, Jeff’s content has failed the tests. Tim either fixes it or flags it to be fixed.

User Comments

Laurie Harris's picture

My organization has been discussing paired writing. We are a technical documentatuion organization with about 20 writer in the US, UK, Germany and India. I shared this article with my manager and she is interested in your processes. Do you have more information on those processes?

March 4, 2016 - 9:57am
Tim Ottinger's picture

As documentalists, you may not be familiar with pair programming, so you should look into the writings on Pair Programming first.
If you want a book on that, you will find that Laurie Williams and Robert Kessler wrote a great one called "Pair Programming Illuminated."

The most important thing is that you both have equal access to keyboard, mouse, screen, etc. If you can't take over in the blink of an eye, you are going to struggle. You can use a local, physical setup with dual screens, keyboards, and mice if you like or you can use a screen sharing app like ScreenHero. But being equal matters.

The other thing you need is rapport or at least respect and a little trust in each other, that neither of you is going to take over and make the other a "passenger." Nothing is worse than sitting around waiting your turn. This is why a lot of new pair programmers practice "navigator/driver" in which the one at the keyboard is only operating the machine and the one whose hands are not on the keyboard is deciding what to write -- and they switch frequently, whenever the "driver" wants to "navigate" a while.

Hogging the thought stream or the keyboard are considered no-nos.

Sometimes people even set timers so that they have equal time, but I consider that overkill.

Once you are practiced, you'll find that no formality is really necessary. You will switch rather fluidly.

Jeff and I sometimes edit simultaneously in Google Docs, even without any voice contact between us. We've got a kind of "mind meld" going on. 

Good luck to you, Laurie!

March 4, 2016 - 6:08pm
Jeff Langr's picture

Hi Laurie,

Thanks for the inquiry. I recommend reading Weinberg's book (, which will fill in the details on his Fieldstone method. Beyond that, it's been an incremental/iterative process, and as such Tim and I evolved it to "good enough" for our individual needs--honestly, what we've described above should be enough to run with. We've defined no additional formalities, though recently (with this article, in fact), we introduced a third party--a copy-editor into the mix, whicih brought some new wrinkles for us. (Previous articles were copy-edited offline.)

I'd suggest your organization, if interested, start with a small group and grow it slowly, rather than try it with 20 writers all at once.

March 4, 2016 - 10:16am

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.