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.

Sometimes one of us focuses on the minutiae of how to express an idea, but the other realizes that the article is stronger without it. Nothing obscures a good idea more completely than wrapping it in three more good ideas. Working with another person has helped us become less attached to our own turns of phrase so that we can recognize when they should be deleted for the good of the article.

Incremental Writing

Gerald Weinberg uses the fieldstone method for his writing, which says you don’t need to write in a linear fashion. Instead, you should capture ideas about things to write about as they pop into your head. (We often use three-by-five index cards to do so, stuffing them in our pockets until we’re able to edit our shared document.) You drop these thoughts into your overall document as you find places for them to fit—much like you would add oddly shaped rocks to a stone fence you’re building. You mortar your stone-thoughts (a chunk of one or more paragraphs) together once you have stones close enough to touch each other.

During the course of our pair writing, Tim might drop a “stone” into the document. We’re not too careful initially about where the prose goes; we put it roughly where we think it might fit. Jeff might spend a few moments refactoring the addition for grammar, conciseness, or clarity; he might also move it elsewhere. Or, he might mortar the stone in place by working on the transition from previous paragraphs or to subsequent paragraphs.

Sometimes, we recognize that excess thoughts in an article are valuable stones. Rather than delete them, we set them aside so that they can be given the full treatment they deserve in separate articles.

Just like a program, an article is never really done. We can always add, delete, edit, rephrase, or improve it a little more. But we sense when it is useful and clean enough to let it go, and we push it into publication.

Live Pairing

During the course of collaborating on a given article, we write some portions asynchronously, while others we write “live” but remotely. It’s most interesting to watch when we’re pairing live. Google Docs tracks the other person’s cursor, so you can see where they’re focusing and watch the words magically appear as they type. (Yes, it’s not magical, but it is still exciting for us.)

From a mechanics standpoint, we adopted a few informal standards.

  • We type our questions in brackets when uncertain about something. For example: [[Does this sentence read well?]]. Rather than typing an answer to the question, the other usually responds by making an improvement and then deleting the question. The resulting prose answers the question.
  • We normally don’t interact via voice. To express an idea, we write it into the shared document or make an appropriate change. This accommodates our different schedules and also gives the document in progress a feeling of “liveness.”
  • When we can’t agree, we consider the comfortable nearness of the delete key. Inability to agree through improvement is a writing smell, so when we delete, we “sniff” for larger problems in the document.
  • We try not to edit too close to the other author’s cursor. Working just one or two sentences away disrupts both authors’ chains of thought.
  • We each trust the other’s instincts for improvement. We follow Grace Hopper’s philosophy: We just make the changes we feel are prudent, and don’t worry about feelings possibly hurt by reworking or removing the other’s thoughts. Google Docs has a nice revisions feature, in any case, if either of us feels that our perfect prose has been unjustly squashed.

Pair Up and Get Started

Pair writing gives us quick, useful feedback. When Tim asks Jeff, “What does this mean?” Jeff knows he needs to clarify things. Conversely, when Tim says, “Love this!” it’s reassuring to Jeff because we trust and respect each other’s opinions. Because we’re both good at second-guessing ourselves, the positive reassurance lets us know that we can finally relinquish a piece for publication.

Remote pair writing provides us with the best of all worlds. We’re able to collaborate on writing regardless of our positions in time and space, and our combined writings are better than either of us could have produced on our own.

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.