Tuesday, September 20, 2011

On parallel writing

A couple of weeks ago I taught "pair programming" in class, portraying it as a setting in which one person (the "driver") writes and the other one (the "navigator") advises and comments.

A few days ago, with a colleague wrapping up their visit, we decided to write our preliminary findings in a draft paper.
-"Since we have a few hours left, let's start it together."
-"Ok. Let me get my laptop out. Do you want to be the one typing, or shall I?"

Then I had an idea: let's do it simultaneously! We opened a google document, and, each one of us working on our own computer, sitting in the same room, simultaneously edited the manuscript, occasionally exchanging brief comments.

It's a very different way of working. There is no formal role. Each can switch from driver to navigator at will, alternatively looking at what the other person has been doing, possibly editing some of it at the same time, and writing away our own ideas.

The result of that experiment? Too early to tell, but I definitely want to try it again. When we discuss research together, each has a view of how the other person is reasoning about problems; it's a wonderful way to learn more about how to do research. When we draft a paper together in this manner, it gives us a view of how the other person goes about composing a text: do they go top-down, linearly, is there a lot of backtracking, do they stop to think every few words or every sentence or every paragraph? We can see it all. It might be a wonderful opportunity to learn more about how to write a paper, if we exploited it.


  1. If somebody uses a tracking system (like SVN) some of these things could be measured. Which are the sections you start with? How often and how much is the first draft edited, etc, etc

  2. Yes. The tools are there. But what to do with them? I am not sure.
    Don't you think that it would be interesting to take measurements of the kind of parameters you propose, and then see if anything striking comes out?

    We know a little bit about how famous writers compose their texts, but it's all anecdotal.

  3. I just tried http://code.google.com/p/svn-time-lapse-view/, which looks like an easy way of using latexdiff (it highlights difference between successive commits). It is great to track who modified what, but its aim is not to detect patterns.
    http://code.google.com/p/codeswarm looks nice (from the visualization point of view), but I did not give it a try yet.

  4. Somebody did something similar. A visualization of successive commits of an accepted NIPS paper: http://www.stat.columbia.edu/~fwood/Papers/sLDA-evo.pdf


Note: Only a member of this blog may post a comment.