I often think of the William Gibson interview for the Paris Review in which he says that he starts off every writing day by reading his drafts from the very beginning until reaching what he finished writing the night before, and that’s where he picks up.

Interviewer: What’s your writing schedule like?

Gibson: When I’m writing a book I get up at seven. I check my e-mail and do Internet ablutions, as we do these days. I have a cup of coffee. Three days a week, I go to Pilates and am back by ten or eleven. Then I sit down and try to write. If absolutely nothing is happening, I’ll give myself permission to mow the lawn. But, generally, just sitting down and really trying is enough to get it started. I break for lunch, come back, and do it some more. And then, usually, a nap. Naps are essential to my process. Not dreams, but that state adjacent to sleep, the mind on waking.

Interviewer: And your schedule is steady the whole way through?

Gibson: As I move through the book it becomes more demanding. At the beginning, I have a five-day workweek, and each day is roughly ten to five, with a break for lunch and a nap. At the very end, it’s a seven-day week, and it could be a twelve-hour day. Toward the end of a book, the state of composition feels like a complex, chemically altered state that will go away if I don’t continue to give it what it needs. What it needs is simply to write all the time. Downtime other than simply sleeping becomes problematic. I’m always glad to see the back of that.

Interviewer: Do you revise?

Gibson: Every day, when I sit down with the manuscript, I start at page one and go through the whole thing, revising freely.

Interviewer: You revise the whole manuscript every day?

Gibson: I do, though that might consist of only a few small changes. I’ve done that since my earliest attempts at short stories. It would be really frustrating for me not to be able to do that. I would feel as though I were flying blind. The beginnings of my books are rewritten many times. The endings are only a draft or three, and then they’re done. But I can scan the manuscript very quickly, much more quickly than I could ever read anyone else’s prose.

My Writing Processes

I’ve tested out multiple writing setups over the years, each one different from the next depending on the kind of writing I need.

When writing notes and academic papers, I’ve always used the notes app in my phone and Microsoft Word. For notes, the phone is convenient but formatting is a pain. For papers and long documents, drafting with Word has been good enough as I mainly need a table of contents, sections and footnotes, but longer documents would be difficult to edit because the program would slow down. I used Word for my editing process for two reasons. The main reason was to send the document to my Kindle, where I could comfortably read and edit long texts without staring at a bright screen or having to print the pages. Sharing the Word document to the Kindle via e-mail was easy and convenient since Amazon takes care of the formatting. The second reason of course is because Word is the de facto standard in academia and publishing, and submissions often asked for Word documents.

For personal writing this process was terrible. Most of my online writing is technical, more often than not including blocks of code, links, footnotes, citations and images. Word is simply not the tool for this (try adding syntax highlighting for your favorite programming language), especially if the end product will be hosted on my own websites anyway. For this type of writing, I have enjoyed using Markdown and Jekyll, but this approach isn’t perfect either. The truth is there is no such thing as a perfect writing process, since every writer has to develop their own process over time. I am sharing mine here because I enjoy reading about people’s writing processes and I’ve learned a trick or two this way.

Jekyll

Jekyll is a fantastic tool, and static sites are underrated. I could write a whole entry about this topic alone. My issue with Jekyll is entirely personal and it’s due to what I would characterize as a lack of discipline, or perhaps a lack of separation of concerns.

When I write a document within my Jekyll setup, I start a new Markdown file in my text editor, running a local server so I can preview the formatting as it will appear online. Part of the fun in using Jekyll is to be in full control of the site’s appearance. I’ve spent hours sometimes updating styles, choosing fonts, modifying spacing, tweaking line heights, swapping syntax highlighting themes… and I love doing this. I find great joy in writing for the web because I am in control of my words and their appearance. I know I can use a theme designed by someone else and simply focus on writing, but I wouldn’t have as much fun.

The problem starts with having my entire site’s files right next to me. It’s so easy to get distracted with changing things when all I have to do is open a file, update a line or two, and check out the new changes in my browser window. I can’t avoid this if I’m writing within a Jekyll site, since my documents are stored in the same directory as my program files. When I’m ready to publish what I’ve written, I inevitably open the command line and manage my changes with git, so the line between writing and programming gets blurred every time.

Separation of Concerns

When I started Commit Redux that was exactly the problem I sought to fix.

If I want to change something about the site, I need to go out of my way and search for the project directory in my files, open up my text editor, add my updates, commit my changes to git, deploy these changes to the server, wait for my Dokku container to restart, and then I can see the final output.

Here’s an example of what I mean. I’m currently editing this post, and I’m noticing the “Update” button below my text area isn’t green like the “New Post” or “Share” button because I forgot to add the CSS class. I’ll get to doing that later, but I’m not going to stop writing right now because those files are out of my way at the moment. This separation of concerns keeps me from getting distracted. I have to make the conscious choice to stop writing and begin coding, whereas with Jekyll it all happens in the same space.

This has worked out well for the type of writing I want to share here, namely write-ups in which I go over what I’ve been programming, limited in scope to the last commit I made so the posts don’t get too long. It’s the same issue I have with Jekyll, which I wrote about this last Monday:

While working on redesigning this site’s UI I ended up finding other aspects to refactor. One of the reasons I made Commit Redux is to control this bad habit since each of these posts corresponds to a specific commit, otherwise I end up going on programming tangents to resolve unrelated albeit important things, but the time I spend on those adds up.

Having identified this recurring issue in my own writing process, now I can share a new approach I’ve adopted, especially for personal notes and long documents where editing is more important than drafting.

Pandoc

At one point in the interview, Gibson talks about printing his manuscript at every stage.

Interviewer: How much do you write in a typical day?

Gibson: I don’t know. I used to make printouts at every stage, just to be comforted by the physical fact of the pile of manuscript. It was seldom more than five manuscript pages. I was still doing that with Pattern Recognition, out of nervousness that all the computers would die and take my book with them. I was printing it out and sending it to first readers by fax, usually beginning with the first page. I’m still sending my output to readers every day. But I’ve learned to just let it live in the hard drive, and once I’d quit printing out the daily output, I lost track.

With Pandoc, I’ve found a happy medium between writing within the confines of my text editor and seeing my writing in a more final form. Like I mentioned earlier, I’ve mostly relied on Microsoft Word for papers and long documents. A considerable appeal to this approach when it comes to editing is getting a feel for the document as it will appear once it’s printed. I also like making notes on the page margins (or on the Kindle) and letting the project mature over time while I gradually incorporate my changes.

I can’t overstate the convenience of Markdown when it comes to formatting, I much prefer it to Word, but I don’t want to be responsible for formatting my document when I’m deep in the process of writing a paper or a story. That’s where Pandoc comes in.

Pandoc is an open source universal document converter created by John MacFarlane, a philosophy professor at UC Berkeley. The program accepts various filetypes for input and output. I’ll be using Markdown for input and PDF for output, but other formats include Word, ODT, HTML, EPUB, LaTeX, and many others.

Per Pandoc’s documentation:

To produce a PDF, specify an output file with a .pdf extension:

$ pandoc test.txt -o test.pdf

By default, pandoc will use LaTeX to create the PDF, which requires that a LaTeX engine be installed.

My preferred text editor for Markdown is GNU nano. I mainly use it for its paragraph justification feature, where Ctrl J keeps line length uniform while respecting long lines (usually for links or footnotes). I also love its interface. My personal website is even modeled after it!

To keep long documents manageable, I’ve been breaking them up into manageable sections and using pandoc to combine them into one PDF. Here is a sample file structure for a typical project:

.
├── cover.md
├── section1.md
├── section2.md
└── section3.md

I use the cover page file to set the front matter (pandoc only reads front matter from one file) and add a \newpagedirective. For everything else, I let the command line and pandoc take care of everything.

The contents of my cover.md file:

---
title: Hello, world!
author: Fulan Ito
date: Thu 15 May 2025
---

\newpage

The other files are just Markdown. No front matter, nothing other than the text itself. Since Pandoc can accept multiple documents for input, I sort in whatever order makes sense for the project (alphabetical, last modified, creation, etc) and output a list after passing cover.md as the first argument.

$ pandoc cover.md section*.md -o example.pdf

That’s all there is to it!