All Articles

A Writing Process

I’m always looking for ways to be more efficient in both coding and writing. For a very long time, I’ve struggled with forming a writing process that really worked for me. Of course there is never a ‘right’ process that is going to work for everybody, but I’m fairly satisfied with the one I’ve come up with so far— for me, at least. It merges some of my coding habits with my writing habits and so there’s less context switching when I go from one to the other.

Here are my typical pain points when it comes to writing:

  • Everybody wants a different output format (docx, pdf, Google doc)
  • Everybody wants a different output style (line spacing, margins)
  • I get really caught up in WYSIWYG editors. Because they reflect what the actual outcome will look like, I feel a lot of pressure to make the words that I’m writing right now be perfect because it looks like a finished product
  • I want to see my word count easily (really this is only for NaNoWriMo, but occasionally it’s useful just for seeing how chapter lengths compare to each other)
  • I want to write chapters separately, but still be able to see them easily and combine them into one document easily
  • I want to be able to find and replace across an entire document easily (even if all of the chapters are in separate documents)
  • I want to be able to share my writing with people who can give me feedback on it, but not in a 100% public way

For the most part, these pain points broke down into three ‘phases’ of writing:

  1. Writing
  2. Editing
  3. Feedback gathering

Writing

I had a brief stint where I used to use LaTeX in emacs to write. This was mostly driven by my not really being able to write in WYSIWYG editors. I would get too caught up in how many pages a chapter became, or where the page breaks occurred, font sizes, if a paragraph’s last sentence was just a little too long and ended up with one word on the last line… In emacs with LaTeX, there is no way to know what your output will look like while you’re writing, and I found that very relieving. And I could get around the editor pretty well with my emacs shortcuts. I also liked the idea of there being a literal compilation step between my raw writing and the final output. It made each word that I wrote not feel as set in stone.

But LaTeX is hard! And annoying! And most computers don’t have a LaTeX compiler. Furthermore, doing things like italicizing a word takes a lot of effort. You have to encapsulate the word you want to italicize in textit{word}, which is quite a few extra keystrokes. Also quotation marks are very annoying— at least when I was working with LaTeX, you would use the double back tick `` for the starting quotation. This didn’t map well if I ended up having to copy the raw text to another editor. And I would find I would need to do that every so often because a PDF output wasn’t enough. Also, writing in LaTeX didn’t totally get rid of any thought of what the output would look like. For instance, you still have to specify the margin size, font size, line spacing, in your document’s header.

Recently, I decided markdown was the way to go for me. Italicizing is just a matter of encapsulating a word in _ or *. There’s no need to specify anything formatting related except for text styles (italics, underline, bold, and maybe some header marks for chapter titles). It’s also less overhead than LaTeX, in my opinion, where a lot of software can preview Markdown files (way faster than it takes to compile a LaTeX document, too). And I like having the notation of my formatting directly in my raw text. It means my formatting always sticks around, and I don’t have to just hope that if I copy and paste between two documents the formatting will carry over the way you would between Word documents.

Editing

Something like markdown you can write in any text editor. I could’ve continued using emacs as I was doing with LaTeX, but there was something endlessly annoying about my emacs setup in OSX, where the shortcut ctrl+e would take me to the end of the paragraph I was working on instead of the end of the visual line. I looked up how to change this before but I guess I didn’t look that hard. In any case, I was using VS Code for software with emacs shortcuts, so I figured I might as well use the same editor for my writing. This worked out great for me. I set up my workspace to automatically text wrap markdown files and also to show a word count in the bottom toolbar. I could see all the chapters I had in the file explorer on the left. I could find and replace across the whole document really easily. And I could preview markdown files super quickly.

I often found myself wondering things like:

  • I called this character a ‘captain’ just now— am I consistent with that? Or did I use ‘commander’ before?
  • With this compound word I made up, was it hyphenated? Jammed together? Or spaced out?
  • When did I start using this character’s nickname?

    • Who uses this character’s nickname?
  • Am I over using the word ‘eyes’?

Pretty much all of these questions could be answered really quickly by a whole document search, which VS Code is very fast at thanks to its indexing. It also has a nice feature where you can click on a word and see where else you used it in that particular markdown file.

Example of using VS Code to find other word occurrences

In this picture, by clicking on the word ‘markdown’, the editor highlights both other places that I’ve used it within the text, and also shows marks on the right scrollbar for where that word occurred relative to the entire document. Sort of like Kindle’s X-ray feature.

I’ve found these features to be really useful in editing, particularly for making sure I was consistently using certain words. Now you can’t track changes quite as powerfully as you could if you were using MS Word or Google Docs, but I’ve found using GitHub (now that there are free private repos) and committing at significant points to be good enough. Using git commits is also exciting to me since the git log can be exported, and then you wouldn’t be too far from figuring out words written per day.

Feedback gathering

This was the hardest part for me. I happily wrote a ton in markdown with VS Code, did a first pass at making sure my words were consistent, and then I had to figure out how to share it. Normally, I turn right to Google Docs if I want someone to leave me feedback on any writing, since Google accounts are pretty common and leaving comments and suggestions is simple and intuitive. I have a few complaints about Google Docs, none of which I’ve been able to resolve, but here they are in case there are other commiserators:

  • There aren’t private comments. If you want feedback from multiple people but don’t want one person’s comments to influence another’s, you have to make separate Google docs for everybody
  • There isn’t a way to aggregate comments across multiple identical documents into one (very much related to the first point). This would be super useful as the writer, to see all of your beta reader’s comments in one place.
  • There’s not an easy way to link files as you may want to do for chapters. After reading one chapter, you’d like there to be a button for the next chapter, but instead you have to go back up to the file structure and click on the next chapter
  • You can’t format a bunch of chapters at once all with the same format (that I know of)
  • There’s no easy way to go from markdown to a Google Doc

This last point was pretty rough for me. StackEdit promised to be able to do the markdown conversion to Google Doc, and I remember doing it once before a year ago, but when I visited the site again I could not at all figure out how to do the conversion again. I could back up the markdown file itself to Google Drive, but it would still look like a Markdown file (with #’s, *’s, _’s and all), not a fully fledged Google Doc.

I began to wonder why this was so difficult. So many things were so close— GitHub has a great markdown renderer for the web but I didn’t want to make my repo public, and I would only get 3 free collaborators with a private repo, and even then, I didn’t want to make all these people get GitHub accounts. And how would they leave comments, with pull requests? The privacy of the document was important to me since many publishers are real sticklers about if a piece of writing has been published anywhere on the web before.

I toyed with the idea of making a password protected Gatsby site that would let me control things like a next button to go to the next chapter. But again, there’d be no notion of leaving comments.

So I searched around for another answer and finally settled on using pandoc to convert my markdown files into PDF. It can concatenate all of my markdown files into one document, build a table of contents, and let me specify my formatting not in the markdown documents itself, but in the command line arguments for building a document. This was a pretty important layer of abstraction for me— the actual writing process should be only about writing, and as little about formatting as possible. And can you guess what convention pandoc uses in order to specify things like margin, font size, and line spacing? LaTeX’s! I could hardly believe I had come full circle. I even had style templates in LaTeX before. An example template that I used recently might look like this

\usepackage{setspace}
\onehalfspacing                                 # 1.5 spacing
\usepackage[vmargin=1in,hmargin=1in]{geometry}  # margin size
\setlength{\parindent}{2em}                     # size of paragraph indent
\usepackage{indentfirst}                        # indent the first paragraph of every section
\usepackage{palatino}                           # use the Palatino font

Then I uploaded the PDF to Google Docs. Again, this doesn’t become a full fledged Google Doc. I tried their convert feature, but then I lost all my italics, despite how hard I had tried to keep them around through the writing process… So I just uplaoded the PDF as a PDF, and you can still leave comments on it in the same way as a Google Doc. You can’t make inline suggestions if you just want to correct a typo, but I don’t see that as a huge loss.

Conclusion

The hardest part about writing is the actual sitting down and writing part. I believe that should be the part that has the least barriers, and markdown combined with VS Code provided that for me. It sacrificed some features in getting feedback, but I think that’s a good tradeoff. But maybe the people I’m asking for feedback from don’t…

It’s not ideal, but this process smooths out the writing part for me, and that’s about all I can ask for!