learning to go with the workflow
This article appeared in modified form in the Maven Game newsletter. Sign up here.
Today, I’m sad to announce that I’m leaving the book business for good.
Just kidding, suckers. I’m not sad. I’m excited! Last year, I sold my first screenplay. Now that the movie is finally coming out, I’m finally headed for the big time. Beaucoup bitcoin, baby. Is there such a thing as a Tesla Humvee? Because I want one.
You know that trend of gender-switched remakes (Ghostbusters)? You know that sub-trend of gender-switched remakes of Tom Hanks movies (Splash)? Presciently, I decided the time was right to pull out a script that had been sitting in the back of my drawer for ages.
Sara Dipity is a gender-switched remake of Forrest Gump. It’s the story of a simple woman who “serendipitously” wanders into every key moment in smug Baby Boomer history.
Featuring Julia Roberts as Lieutenant Danielle. December 2016 release.
In the meantime, I’ll keep writing the Maven Game.
I recently read Track Changes: A Literary History of Word Processing by Matthew Kirschenbaum.
As I’ve learned from a number of conversations about it so far, if you’re the kind of person who would read a literary history of word processing, you’re in the middle of ordering a copy and not even reading this sentence anymore.
The rest of you should probably scroll down to unsubscribe now. I don’t know what’s wrong with you…and I don’t care to know. Good day, sir. I said good day!
Kirschenbaum, a professor of English, lavishes his attention on the turbulent period in the late 70s and early 80s—spoiler alert!—when relatively affordable word processors and personal computers began to appear on the market.
Many of the early adopters were, of course, writers. As the benefits of writing on a screen became clear, the conversation at writing conventions turned to the subject of getting these fussy new systems up and running without accidentally, you know, deleting your life’s work. (Hijinx ensued.)
Kirschenbaum highlights a salient fact about the history of our profession. Prior to the word processing revolution, “professional writer” was an operation. You could hide up in your garret and scribble away wearing fingerless gloves, but if you wanted to publish regularly in the 20th century, you couldn’t do it alone. Typing and re-typing drafts, organizing and re-organizing stacks of paper: The prolific writers of the 20th century depended on their spouses and assistants to support them in their work. Writing was a team effort.
With WordStar, WordPerfect, and their kin, working as a solo professional writer became feasible…just. As with many other technological innovations, word processing eliminated some work and created new kinds to replace it: making backups, keeping track of digital files, calling tech support, and so on.
Typically, a new productivity technology leads to a cultural and economic shift reducing the number of workers expected while only partially reducing the overall work required. The result is what economists call “shadow work.” Losing an assistant and having to enter all your expense receipts into Concur: shadow work.
(Leaping nimbly across the rooftops with a fistful of throwing stars: a different kind of shadow work.)
Let’s take a specific example: prior to the PC, Isaac Asimov spent his whole day writing. Morning till evening. I can’t really wrap my head around that in 2016—it seems so luxurious.
(Little-known fact about Asimov: his sideburns grew as he typed. At the end of the day, he’d shave them off, but the next morning they’d start creeping back down again. That should give you some idea of how much writing he did.)
Think of how peaceful it must have been in his head. Asimov’s only responsibility was to write. Asimov’s wife and his publishers worried about everything else. They kept Asimov’s writing organized and routed each page through each stage of the publication process. (Let alone the business end. Can you imagine the royalty statements on 450+ books?) Asimov didn’t even care whether he spelled anything properly or not. His copy editors were expected to figure that out. In fact, they’d often have to call him for help in puzzling out his erratic keystrokes.
Nobody thought less of the guy—writers weren’t expected to know how to type or spell properly. This was typical of a time when correcting a typing error was time-consuming and messy. It was assistant work. Asimov’s time was far better spent typing new words than fussing over something someone else could correct. Who else was going to write Foundation?
The dynamic changed when Asimov switched over to a PC. Now he could easily go back and fix things without correction tape or Wite-Out. Heck, he could go back and revise an entire sentence. Or paragraph. Or chapter.
Decisions, decisions: keep moving forward to actually finish the draft of book no. 456, or go back and fix that one thing. Sound familiar?
Today, we take it for granted that we can jump around in our documents, revising and repairing as we “write.” It creates a subtle but powerful drag on our creative flow. Revising as you write is, in my experience, the most common bad habit among writers.
There are software tools designed to discourage this practice by disabling the delete key or actually erasing what you’ve written so far if you stop typing, but building muscle memory around a one-trick writing tool strikes me as a profoundly bad idea.
Meanwhile, keeping track of all your digital assets and ideas as a busy professional is difficult and distracting. Most of us don’t have assistants to manage this for us, and even the most sophisticated digital tools are far from complete replacements for His Girl Friday or Her Dude Tuesday.
Most of my time at work is spent writing and editing across multiple large projects simultaneously, so I’ve invested weeks of effort in creating a workflow using the best available tools. My goal was to create something as simple as possible but no simpler; I don’t have time to mess around. My workflow has to be able to handle a professional-grade writing process.
I mentioned this workflow briefly when Julia Roy interviewed me on her new podcast, and a few listeners asked for details. Here they are.
Why establish a workflow?
I used to think I was a bit odd to geek out about writing workflows, but I’ve learned from talking to many other writers that a good workflow is an essential tool in ensuring a long and productive career today.
We’ve all heard stories of the guy who wrote an entire novel on his commute pecking away at his flip phone, but:
- How many subway-cellphone novels have you read, let alone enjoyed?
- Where’s that guy now, and why do his thumb joints look like walnuts?
If you’ve never written a nonfiction book on deadline before, you may scoff at the need to give your writing workflow any thought. Writing an email or even a typical blog post is generally a one- or two-step process.
Longer blog posts, articles, books—as the scope expands, the headaches increase exponentially. Research, planning, organization, formatting, polishing. Process becomes essential. Throw in our tendency to revise our own writing into oblivion (because we can) and it becomes clear we need to manage ourselves as writers so that we can get out of our own way and produce our best work.
One excuse writers often make here is to point to their predecessors: “So-and-so wrote all of Such-and-such in Microsoft Word. All this workflow stuff is just procrastination.” Don’t be fooled. It’s generational.
Many professional writers whose careers took off more than a decade ago still rely on nothing more than Microsoft Word. They developed that workflow when they needed it and they have no intention of messing with what works. Malcolm Gladwell, for instance, mentioned his reliance on Word in his recent interview on Tim Ferriss’s podcast. (Gladwell was clearly a bit startled Ferriss would even ask that question. He’s like, what else is there?)
When Gladwell was starting out as a journalist in the 1980s, his older colleagues laboriously pecked away at typewriters. Using a computer to write at the time was considered unprofessional by many, as Kirschenbaum relates in his book. Gladwell probably took some criticism from older colleagues for it, but he saw the advantages and decided it was worth investing in this new technology. Colleagues certainly looked askance at me for editing in Word instead of with a pencil when I started in publishing more than a decade ago.
Times have changed, and now Gladwell is the crusty old pro pecking away at his tool of choice. Today, using Microsoft Word to write a book is like taking a dinosaur to the sock hop. You may enjoy the dance, but you’ll end up tearing a hole in the space-time continuum because dinosaurs are extinct.
If Word works for you, keep on trucking. If you write as much as you want to write in the time allotted, drive large writing projects through to completion on schedule, and have no problem keeping track of your work and your research, congrats. In reality, of course, if you write anything for the Web or you don’t work with a traditional publisher or magazine the way Gladwell usually does, Word doesn’t suffice as it is. So let’s just accept that we need a more sophisticated workflow and figure one out, shall we?
Markdown as your writing “source code”
I’ve been writing on a computer since my dad got us an Apple II+ back in the early 1980s. I’m still trying to convert my old documents rescued from 5 1/4″ floppy disks I found in the basement a few years ago. While it seems likely that we’ll possess the ability to interpret a Word document for at least our own lifetimes, personally I can’t rest easy unless I know my words are stored in plain text files.
Markdown is a simple set of syntax conventions for marking up a text file with basic formatting. It’s designed for writers. It takes two minutes to learn and, once you get the hang of it, you’ll be hooked for life.
Nothing beats plain text for ease of use, and Markdown means you can format where necessary while leaving everything perfectly readable in any application and on any computer. In Markdown, you put an asterisk at the beginning and end of a word to mark it as italic. Simple, right? Here’s a one-page summary of everything you need to know to write with Markdown.
As a writer today you’re constantly repurposing your work. You write a blog post that becomes a newsletter. Part of the newsletter ends up in a book. You go back to the blog post and convert it into a guest post for someone else’s site. Often, the formatting doesn’t cut and paste properly. You have various copies and versions of everything scattered everywhere. If you’re sending stuff out of Word, it’s loaded with all kinds of hidden formatting codes and strange characters.
Never fuss with any of that again. In this workflow, you’ll draft the primary version of everything in Markdown and store it in Markdown, clean and future-proof. When you need to send it somewhere, you go back to the text “source code,” tweak it as necessary, and then spit it out in EPUB, PDF, HTML, DOCX, or any other format, in one step. I’ll show you how.
Research. I advocate idea hygiene. Use separate buckets for your research (books, websites, quotes, etc.) and your own ideas. You don’t want to accidentally Lehrer all over the place.
If you’re an academic, I recommend Zotero for research. It’s a platform-agnostic citation manager that will create your bibliography or endnotes automatically. It also saves webpages and PDFs, allowing you to read and annotate them in one place.
That said, Zotero is clunky, especially on mobile. You can use apps to read your Zotero research on the go, but expect headaches.
For most writers, Evernote is still the best choice for saving other people’s stuff. It has its flaws, but I have not found a smoother multi-platform option appropriate for writers that can handle anything you throw at it. (If you want to debate me on Evernote vs. OneNote, DevonThink, or any other research tool for this specific purpose, I invite you to write back.)
Ideas. For jotting down and organizing your own ideas, I recommend Ulysses, a sophisticated, cross-platform writing app that handles Markdown beautifully. Create a “Group” for your ideas, subgroups if necessary, and keep all of them there, in Markdown.
Often you’ll scribble down an idea for something you plan to write later and discover on looking back that you actually phrased it nicely the first time. There’s just no point in separating ideas in various states of polish. Keep things simple. If it’s still in the idea stage, keep it in Ulysses.
Ulysses is pretty much identical on mobile, so making notes on the go couldn’t be easier.
Writing. Again, Ulysses. It’s my typewriter. Ulysses is an extraordinary writing tool, with all the bells and whistles offered by modern apps like full-screen mode and night mode. It’s completely fluent in Markdown: I can select text and hit Cmd-B (for bold text) and it will automatically add two asterisks at the beginning and end to make the text bold. Its appearance is fully customizable, and it exports to all common formats.
Now, how to write so you don’t get caught in the revision trap? I use the Pomodoro Technique. You set a timer for 25 minutes and write continuously for that time, no backsies. Take a 5-minute break, and do it again. After 4 pomodoros, take a 15 minute break.
Only turn to reading and revising once your planned drafting sessions are complete. For a blog post, you might plan on 3 writing Pomodoros and 1 Pomodoro to revise, depending on how quickly you work. But plan for revision when you plan your writing session and stick to that plan. Your brain will always try to convince you it’s time to go back and start fiddling before you’re done.
If you’re working on a larger writing project like a book, I wouldn’t even begin any revision until you’ve completed the entire first draft. Really. (If you want to make a case otherwise, again, please write me back with why revising as you write your first draft is an effective strategy.)
For Pomodoros, I use Forest on iPhone because it lets me grow virtual trees with every completed session, but any timer will do.
Although it has the capability, we’re not going to use Ulysses to do any exporting or organizing. You keep your ideas in it, and you do your writing in it—I’m writing this in Ulysses right now—but once you’ve finished a writing session, move on to the next step.
Organizing. If you’ve drafted a blog post, you’re ready to go. I recommend pasting the Markdown text into Hemingway to improve its readability. Once you’re happy with it, pop it into WordPress. (Mind you, half of what I write for the Maven Game gets tagged red for readability, but I know you’re a sophisticated audience of authors, agents, and editors that can grok a few sentences above a third-grade level.)
WordPress handles Markdown just fine if you tell it to in the settings. I believe in keeping one source copy of each piece of writing in one place to avoid confusion. In my case, I store my “originals” of the Maven Game in WordPress and then adapt them for the newsletter version when I send it. I clean the working draft out of Ulysses when I’m done, leaving only the standard intro and other template text behind for the next post.
For essays and larger writing projects that will take more than one day’s work, take your drafts from Ulysses as you complete them and bring them into Scrivener.
“You recommend using both Scrivener and Ulysses? Are you mad‽”
Look, if you’re already firmly on the side of one app or the other I won’t try to convince you otherwise. I’ve used both extensively and the fact is Scrivener beats Ulysses on everything related to storing, organizing, and exporting big, complicated writing projects.
For one thing, it allows me to create distinct project files—for different clients, for example—instead of trying to lump all my writing into one database like Ulysses does. (There are workarounds in Ulysses, but they have problems.) The logic of Scrivener just works better for books. The problem with it is that Scrivener doesn’t see Markdown. No syntax highlighting, no shortcuts.
So I write in Ulysses, my typewriter, because it’s pleasant and clean and Markdown-friendly, and when I finish a session I paste the text into Scrivener to work with it on a macro level. I can move the chunks around, label them, combine and re-combine to my heart’s content. Then Scrivener makes it easy to export any part of the larger project as a text file in Markdown and use Pandoc to turn it into a PDF, an e-book, whatever. Which brings me to…
Sharing. While Scrivener has its own export functionality for most formats, I prefer to use it to send out raw Markdown text and then convert it with Pandoc, a free “universal document converter.” I export whatever portion of the project I need as text with Markdown and let Pandoc turn it into whatever I need: PDF, DOCX, EPUB, HTML.
Does this sound complicated? It is, kind of, but it’s the good kind of complicated that front-loads the heavy lifting. Once you’ve invested in setting this workflow up and learning it—a week of reduced efficiency, maybe—it will save time, reduce effort, and prevent problems on every writing project you tackle moving forward.
Everyone’s specific use case is different. If you want to use this workflow, you’ll have to make some tweaks to adapt it for your own needs. That said, I hope the general principles make sense.
- Plain text with Markdown for all your writing.
- Export to other formats only when necessary, archiving the original version in Markdown for future re-purposing.
- Idea hygiene: Research goes in one bucket (Evernote or Zotero), your own ideas in another (Ulysses).
- Write in Ulysses.
- Quick proofing in Hemingway.
- Blogs stay in WordPress, in Markdown.
- Store and organize text in Scrivener for larger projects, one file per project.
- Pandoc for converting into any format.
A quick search turns up many demos and walkthroughs for every tool in the workflow. And there are all kinds of fiddly bits I’m not digging into now like how to deal with images. Academics use some version of this workflow to create the most technical, elaborate, and complicated books you can imagine, so I can assure you that it can accommodate your needs with a little elbow grease.
For now, see if anything I’ve shared here is useful to you, and feel free to email back with any questions on the specifics. Believe me, if you’re running into a problem, I’ve run into it myself in one form or another.
Speaking of which, back to work.