: Re: How should a writer use version control to track drafts, rewrites, and revisions? I'm a writer, not a programmer. I'm just now for the first time learning about version control and how it works,

@Goswami879

Vote Up Vote Down

Just to play devil's advocate a little bit, I think a case can definitely be made for not using a software version control tool in writing.

As a writer who also works in the software development industry, I have some pet theories about this, though I am still experimenting myself.

In 1967, a computer programmer called Melvin Conway coined what has become known as "Conway's Law":
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

This basically means that a piece of software is very probably (or even inevitably) going to come to resemble the organization that created it. This happens because software (like writing) is "soft" and a piece of functionality can be achieved in many ways, so a software engineer is inherently more limited by the organization they work for than the tools they use.

I have a corollary pet theory that the tools used in writing will inevitably influence the nature of the work produced with them. You might say "so what?" After all, version control systems designed for software development are wonderful and powerful tools that allow sometimes hundreds of engineers and developers to collaborate effectively. I would say "exactly".

Good writing has a different end goal than good coding. (I'm not talking about technical writing or documentation, but prose). Prose writing is intended to create an intensely personal, one-on-one experience between the author and the reader (who is usually trying to relax and escape from a chaotic, fast moving world with a time consuming but enjoyable book). The product of the writer's work is directly exposed to the reader (or end user) unlike a piece of software where 99% of the time the code a developer writes is obscured underneath an abstraction layer of a visually-based UI (user interface). In almost any software application, the user's enjoyment of the application is totally unrelated to the quality of the code in the business layer. If the code is sufficiently well written for the application to be functional at all, the experience is the same to the user if it is incomprehensible spaghetti code or beautifully minimalist, well commented art. This is absolutely not the case for a writer.

So the point of something like Git is to collect and preserve code and allow trace-ability and change control. It accumulates changes in code from multiple developers or a single developer over time and allows you to do things like deliver a change set, realize that you screwed up the whole application, and undo your change, or even integrate part of it. The point is to preserve the functional state of the application, not the cohesive "voice" of the code. Code doesn't usually have any cohesive "voice", particularly in cases where a large team has collaborated on a project. So if you use version control to write a novel, you will be encouraged by the tool to maintain multiple versions of the novel simultaneously, change parts back and forth between versions, keep every single word you have written somewhere and be able to reinsert them, and create an ever-expanding living document with no end state. A software application is continually being rewritten until it is abandoned. Every time there is a defect ticket, an update to something the application depends on, an update to a browser that uses the application, or any new delivery of functionality, there will be changes to code somewhere. The only static and unchanging software apps are dead abandonware. A novel is totally different. You have to edit the novel and shape it into a final, immutable form that will not change. Even though it is possible to have an ever-changing novel delivered to a device like a kindle, readers don't want that. They don't want to have to go back in a book they are already reading and find new changes back in chapter 2 and try to integrate them into their understanding of the story. Readers want a book to be finished and static before they start to read it.

If your tool is encouraging you to be verbose, keep potentially infinite versions of a story, and never need to reach a finished state, I think a lot of writers, particularly less experienced ones who might have a tendency to be too verbose anyway would be more likely to write gigantic "ball of mud" novels that are ultimately unreadable. I say that as someone whose first novel fits that description.

Writers have always had some connection to the tools they use, which is why people still associate novelists with clickety-clackety typewriters. The tools constrain us and force us to have our end state in mind before we put words on paper. Hemingway wrote long hand in an age of typewriters and plenty of more modern authors used typewriters in an age of computers. It isn't about being a Luddite, it's about the psychological impact of knowing that what you put on the paper is somehow immutable and can't be easily undone. It forces us to be concise, to choose words carefully, and do more writing in our brain and less in the tool. Version control encourages more writing in the tool and less in our brain. I think we have already seen an avalanche of bad writing in the age of word processors, and version control might be a step too far down the wrong road when it comes to prose.

So to answer the question: Maybe don't.(?)

(0)

Login to post a comment!