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.