The Tools I Use to Write Books (2018)
thorstenball.com
thorstenball.com
Apress used Word templates back in 2013 when I did my first book with them. Manning let you use asciidoc or Word templates when I worked with them. I wrote my first book with them in markdown and translated to asciidoc using pandoc. There were so many formatting issues and I found the tools for asciidoc so immature that I ultimately went to using their Word templates on my next two books with them despite preferring purely text formats.
Now I'm working on my next book and I think I'm going to try self publishing. I'm liking leanpub's use of a markdown like format. But again none of this really matters. You can fix formatting later. You have to sit down and write!
PS Thorsten's "Writing an Interpreter in Go" is great: https://amzn.to/3yLTJjE
In the end gdocs turned out to be a great choice because it's so easy to collaborate. All of the articles talking about markdown seem to assume that you're the only person that's going to work on it, or that everyone else is going to figure out this diagram and your git workflow. It's so easy to email someone a link and let them comment on it, or suggest edits.
For producing the final PDF I found a plugin that embeds the doc directly from Google into InDesign so I can typeset it into something that looks pretty great. Then I just upload the PDF to Leanpub.
The tool that had the biggest impact though was Beeminder, which has a hook into Docs and measures your progress by counting the number of words in the book every day. If you don't make progress you have to pay! It's a great way to make yourself accountable. I kept a 100+ day streak for the final push.
The second reason was to do with a change in format as the book was nearing completion. It's aimed at kids (8+) and adults, but we decided having an open and lay flat printed edition made the most sense because it makes following the tutorials easier. This resulted in the layout needing to be tweaked for a couple of hundred pages, which the publisher handled because we used their template system.
So while it may be annoying for a writer to have to change their methods, it can save you a hell of a lot of work because things change unexpectedly (and in my case for the better).
I've only very rarely seen actually productive people talk about the way they do things -- probably because they know there isn't a one technique, and have tailored their own things to themselves entirely. Balzac used debt to keep motivation alive, Hemingway wrote while standing up and used the counter of his chimney -- who cares?
In Markdown, there's no concept of pages. So you can get one row in a table get pushed to the next page and the rest of the page is blank, even there are contents after. Generating PDF with pandoc will usually take care of this through LaTeX, but I don't think leanpub is doing that.
That being said, Markdown + git are a really nice combination.
May your mind be focused and your sitting-upon body parts be made of iron.
And it is really a great book. Especially suitable for people in junior roles right now or people in any kind of role with a knack for solving interesting problems.
- I try to do drafts of whole chapters at once, even if it’s an all nighter.
- I reread the chapter over and over again at every review stage.
- As many say to be a good writer you have to be a good reader. I read a lot.
- I get it done. I hear about people spending years on books. I keep it succinct and to the point. Most readers appreciate that. I never miss a deadline. I write in weeks what I hear about others writing in months. To be fair, I’m privileged that my job as a professor at a teaching college allows for this (over the summer for example).
https://www.advancedfictionwriting.com/articles/snowflake-me...
The gist (might work better for fiction, unsure): write a single sentence summary, then, three sentences to describe what major things happen, then fractal it out - keep expanding. This way, from the start, you have a cohesive story with a planned-out arc.
The first sentence is the _core_: you write and rewrite this a lot, because the entire talk builds up to it. Next three sentences are the major supporting ideas for your core. They also get rewritten a lot, because again they're really important, they flesh out your core idea. Then you write a lot of detail, one chunk per idea.
I'm glad to know the name for this technique, it works really well!
Binding is it's own special hell: There are huge expectations of barcoding, which plays with your cover artwork, and the positioning of things on the cover is a function of the width of the spine, which is a function of pointsize, margins, wordcount, paper density/weight/thickness. I became very dependent on other peoples templates and calculators to "get this right"
Perhaps the oddest part of this, is the join over paper and ePublishing: they are very unequal in terms of DPI expectations, for both font and artwork. I think the golden rule here is "preserve your pixels as long as you can" but there is also "think about metadata, in images and in fonts and text" because producing print ready PDF and ePub formats, the meta is what the printery/bindery is going to work with. EPSF and other stuff comes to the fore very quickly.
Page numbering is another bugbear: some places demand you DONT number pre and post, some expect it to reset, some expect one to be roman numerals, the rest in decimals. some want it spine, some want it edge, some want it centered. Get too close to the margins, now the printer hates you...
I basically wrote everything using markdown files, and a pdf/epub/mobi is automatically generated from the folder using a Github Action. The action will also modify the date of the last update on the webpage, which gets deployed via cloudflare pages (although github pages could have been used). On the other side Stripe handles the payments (No server side code for me) and zapier detects new customers and sends the artifacts by email.
It’s magical :) the next time I want to write a book I’ll focus purely on the content and everything else will be taken care of automagically.
I started out writing it in markdown but ended up moving to a workflow that was mostly Google Docs. My general flow was:
1. High level chapter outline
2. Outline for each individual chapter
3. Write each chapter according to the outline
4. First draft done!
5. Read through each chapter and highlight each sentence according to color code (Green: good, Orange: good but needs to be revised, Red: bad, needs to be rewritten)
6. Work through each chapter and revise/rewrite based on colors.
7. Second draft done!
8. Developmental edits (Get feedback, move chapters or sections around, add missing sections or talking points)
9. Copy edit (This is where I'm at now)
10. Prepare for publication
11. Done!
I love how LaTeX lays things out, so I'm using LaTeX. I'd like to have a web version possibly but I can think about that later.
And now, I better get back to it...
I used Highland, the writing app developed by the same fellow (John August), to work on a screenplay a couple years ago. It's good, but quirky, especially for non-screenplay applications. The advantage of Fountain, of course, is that it goes anywhere plain text does.
Highland 2: https://quoteunquoteapps.com/highland-2/
About John August: https://johnaugust.com/about
This is the same thing I did for my first book, except that I want a pocket book size format and there isn't one that both Leanpub and Amazon KDP currently support, so instead I will be doing some LaTeX wrangling to produce a PDF formatted for KDP. I haven't yet decided how I will do that, as there doesn't seem to be a Markua -> Markdown convertor anywhere (pandoc only goes in the other direction).
For reference: https://thorstenball.com/images/book_tool_pipeline.svg
Not sure what the author used.
- I do the writing first using Word (or Google Docs)
- Once my writing is done, I use the cool tools (if needed)
It a little more work at the end (if any), but it's totally negligible because the trunk work is already done (the writing itself).