Feb 27, 2022
My two simple rules were 1) I like plain flavors and 2) I broke Scrivener. I guess those aren’t exactly “two simple rules”. I didn’t set out with clear rules in mind, I just, like most people, worked according to deeply-held tendencies and opinions. Reviewing the list of principles in the article was a nerdy delight; they concisely defined the foundations of those opinions and tendencies. Moreover, here were some patterns of working that I had mainly picked up in the realm of programming, but, like many, felt were deserving of a wider adoption outside of that realm, ala Tenet 7. Before I continue, I should register my respect and amiration for Scrivener. It’s clearly designed for serious work, avoids predatory pricing models, and seems to be created by a team that listens to its community. Ultimately, it was more than I wanted, and I managed to break one of the key features that was important to me – exporting to multiple formats.
Something I did among my many footnotes and comments caused Scrivener to crash on any attempt to use the “compile” feature. I habitually use markdown syntax, and I think doing so in those contexts stripped some gears deep in Scrivener’s machine. Or something – I never really got to the bottom of it because I ended up “exporting” the entire book by copying all the text as Markdown and editing it in Folding Text or Sublime Text. As soon as I started doing that, I realized I should have been doing that all along.
The most important thing Scrivener did for me was provide a structure of documents and information about those documents across the devices I used to write, like any modern code editor does. I could have my notes, my drafts, my comments, and my text generally in one place. The actual handling and formatting of the text was secondary.
So, as I wound down on composing the book and transitioned into editing and formatting, Scrivener became an organizational layer only, and I eventually moved all the text to a canonical markdown file. Footnotes and comments were the biggest roadblocks. As Scrivener would output footnotes in markdown style but not comments, I set about resolving all my comments. Once I passed that milestone, I was able to move off of Scrivener entirely.
Post-Scrivener
I was “done writing” the book almost a year before it was ready to read. What I really mean is that’s when the model for the project “Write the Conceptual Labor book” was able to treat the sub-model for “Think About The Conceptual Labor Book” as a closed-loop of conceptual labor, because all the remaining work was going to happen within the bounds of a text that existed, rather than having to define those boundaries while filling them up. (It’s debatable how much of a closed of a loop that really is when you end up rewriting 1/4 of the book while “editing”, but let’s not get into that…) One concrete example of the difference there is that I was no longer adding comments to the text, instead I was resolving them. (Of course, resolving some of those completely exploded my supposedly “bounded” model of “The Book”, but, well, that’s conceptual labor.) Once they were all gone, I was able to produce a markdown file that contained, if somewhat messily, everything that constituted “The Book.”
Being able to think about The Book
Being able to open a file and see the entire book was even more of a mental relief than I expected. The above article does an excellent job of explaining and advocating for why and how to use this toolset, so I’ll defer to them on the how and why to. I’ll just say that even if you are unfamiliar with markdown, markup, or any other other code-y terms, I think you would feel a similar relief if you are writing a complex text and can get it into an accurate markdown file.
When we look at a formatted document in a program like Scrivener or Word or even Google Docs, our model of that document has to contain specific qualities of the program that we’re using to write it. In most cases, our knoweldge of those qualities is not exhaustive, so they remain potentially open loops of conceptual labor, costing us attention and brainpower. A writer’s text is more of a verb than a noun to their mind anyway, so the more we can escape the eccentricies of individual programs, the more nimble we can be with our ideas.
Case in point: I’m writing this in Obsidian right now, on my iPad, and the third-party plugin for Typewriter Scroll just doesn’t want to kick in, so my text is crowding the bottom of the screen, tilting my head down, distracting me from my points… bah nothing’s perfect is it??
It’s not just a fussy matter of convenience, or preference, though. The difference between a model of your labor of writing that situates conxtext of your work in particular program versus one that occurs in a context of a particular file is one between philosophies of how humans should interact with software. Should our ideas, and the data that captures them, remain ours, regardless of the software that we use to interface with that data? Or should our ideas become the software as soon as they are encoded as data? That is the approach that has led to articles about how kids these days don’t know what a file is, and why trying to switch to a different phone OS might carry the risk of losing years of photos and text messages.
I don’t think these two competing models only affect our work after it’s done, either. We write differently if we are writing longhand, on a typewriter, on a phone, or in a Google Doc. I think, if you are used to looking at text as independent from the program that is rendering it for you, your brain can be a little more comfortable, a little more itself.
It’s like cooking for yourself vs a friend. Sure, your brain might know all of Google’s food allergies and preferences, and might really have come to rely on the many things Google offers, might even enjoy spending time with Google. But there’s a certain freedom to being able to slop ingredients around without a second thought, humming to yourself, as you cook something up without a plan, seeing what happens as it happens.