Four Tips for Pair Writing
Four Tips for Pair Writing
Johanna Rothman shares some tips for collaborative writing that can also apply to programming.
Join the DZone community and get the full member experience.Join For Free
I am shepherding an experience report for XP 2016. A shepherd is sort-of like a technical editor. I help the writer(s) tell their story in the best possible way. I enjoy it and I learn from working with the authors to tell their stories.
The writers for this experience report want to pair-write. They have four co-authors. I offered them suggestions you might find useful:
Tip 1: Use Question-driven Writing
When you think about the questions you want to answer, you have several approaches to whatever you write. An experience report has this structure: what the initial state was and the pain there; what you did (the story of your work, the experience); and the end state, where you are now. You can play with that a little, but the whole point of an experience report is to document your experience. It is a story.
If you are not writing an experience report, organize your writing into the beginning, middle, end. If it’s a tips piece, each tip has a beginning, middle, end. It depends on how long the piece is.
When you use question-driven writing, you ask yourself, “What do people need to know in this section?” If you have a section about the software interacting with the hardware, you can ask the “What do people need to know” and “How can I show the interactions with bogging down in too much detail” questions. You might have other questions. I find those two questions useful.
Tip 2: Pair-write
I do this in several ways with my coauthors. We often discuss for a few minutes what we want to say in the article. If you have a longer article, maybe you discuss what you want to discuss in this section.
One person takes the keyboard (the driver). The other person watches the words form on the page (the navigator). When I pair-write with google docs, I offer to fix the spelling of the other person.
I don’t know about you, but my spelling does not work when I know someone is watching my words. It just doesn’t. When I pair, I don’t want the writer to back up. I don’t want to back the cursor up and I don’t want the other person to back up. I want to go. Zoom, zoom, zoom. That means I offer to fix the spelling, so the other person does not have to.
This doesn’t work all the time. I’m okay with the other person declining my offer, as long as they don’t go backwards. I become an evil witch when I have to watch someone use the delete/backspace key. Witch!
Tip 3: Consider Mobbing/Wwarming On the Work
If you write with up to four people (I have not written with more than four people), you might consider mobbing. One person has the keyboard, the other three make suggestions. I have done this just a few times and the mobbing made me crazy. We did not have good acceptance criteria, so each person had their own idea of what to do. Not a recipe for success. (That’s why I like question-driven writing.)
On the other hand, I have found that when we make a list of sections—maybe not a total outline—pairs of people can work on their writing at the same time. Each pair takes a section, works on that, and returns to the team with the section ready for review. I have also been in a position where someone did some research and returned to the writing team.
I have also been in a position where someone did some research and returned to the writing team.
Tip 4: Use a Short Timebox for Writing
When I pair, I write or navigate in no more than 15-minute timeboxes. You might like an even shorter timebox. With most of my coauthors, I don’t turn on a timer. I write for one-to-several paragraphs and then we switch. We have a little discussion and then we’re writing again. Most of my timeboxes are 5-7 minutes and then we switch.
Pair Writing Traps
I have seen these traps when pair-writing:
- One person dictates to the other person. That smacks of first-author, all-the-rest-of-you-are-peons approach.
- One or both of you talk without writing. No. If someone isn’t writing in the first 90 seconds, you’re talking, not writing. Write. (This is the same problem as discussing the design without writing code to check your assumptions about the design.)
I didn’t realize I would make this a series. The post about writing by yourself is Four Tips to Writing Better and Faster.
I have a special registration for my writing workshop for pairs. If you are part of a pair, take a look and see if this would work for you.
Published at DZone with permission of Johanna Rothman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.