What It Means To Be A Writer, Part 5 => Actually Writing the Book

I’ve heard from many, many people that say they would like to write a book. And yet, most don’t know about the logistics of that process (specifically with respect to technical non-fiction; fiction has its own process). In this post, part five of my What It Means To Be A Writer series, I’ll walk through the actual writing process, from looking at a blank computer screen to there being a physical thing in the reader’s hands.

With technical non-fiction, you normally don’t begin actually writing the book itself until you’ve already:

• Thought about, in great detail, who the book’s audience is
• Though about, in great detail, what the book should say
• Created a table of contents
• Signed a contract with a publisher

If it’s your first book, you may have already written a sample chapter, depending upon the publisher. Other than that, though, you now have to write 200, 300, maybe 500 pages of material. That’s 40,000 to 100,000 words (although you can use the same word more than once). And you have to come up with all of the examples. And manufacture all the images. Oh, and did I mention you have about 3 months to do it?

How in the world do you do that? Well, I’ve written 23 books as I write this post, and the best answer I can provide is that books are written bird by bird. (That link is to Anne Lamott’s excellent book for writers, in which she explains the “bird by bird” approach.) In other words, you just do it: a word at a time, a sentence, a paragraph, a page, a chapter. People think there are tricks to it, that you have to be inspired or whatever, but no: writer’s write. That’s all there is to it. If you can’t force yourself to sit in front of a keyboard for a couple of hours at a time and just keep moving that cursor to the right, then you can’t be a writer.

The Writing Process for Publishers

Before looking at how you write, let’s look at the general process for writing a technical, non-fiction book. Here’s the life of a single chapter in the publishing process:

• You write a chapter and submit it, along with all the images and other materials (e.g., scripts), to your editor.
• The technical editor will review the chapter for technical accuracy and make comments.
• A copy or line editor will review the chapter for grammar, punctuation, and clarity, and make edits.
• The project or managing editor will review the chapter to look at the work of the technical and line editors, plus make sure the writing fits in with the publisher’s style, the series style, etc. (The managing editor takes care of the big picture, including the schedule, payments, and so on.)
• The chapter is returned to you for rewrites. You rewrite the chapter, taking into account all of the above, as well as any other changes you’ve thought of since you first wrote the chapter.
• The chapter goes back to the managing editor, who will do a final clean up and pass it to the compositor.
• The compositor takes the writing, the images, the scripts, etc., and lays it out in proper page formats, adding book styles, page numbers, icons, and so forth. The end result is a PDF that looks like the printed book will look.
• The managing editor reviews the PDF for any layout issues.
• The compositing editor reviews the PDF for any layout issues.
• A proofreader reviews the PDF and fixes any remaining grammar, spelling, or punctuation errors.
• You review the PDF to catch any last problems and to address any comments or questions raised by the above.
• The compositor takes into account all the edits and outputs a second version of the PDF.
• The managing editor, the compositing editor, and you all review the PDF for any issues at all, and to make sure that the previous issues all got fixed.
• The compositor takes into account all the edits and outputs a third and final version of the PDF.

Whew! I bet you did not know it was that involved or that so many people worked on a book. I know I certainly wasn’t aware of all that when I first started. (And yet, errors and mistakes still make it to the final edition, much to everyone’s chagrin.)

Once all the PDFs are done, they’re sent, along with the PDF of the cover, plus the PDFs of the book’s other materials—copyright, table of contents, index, and so forth—to the printer.

Your Process

If that’s the life of a single chapter, what does the writing process look like to you? To start, most publishers use Microsoft Word. It’s a fairly terrible application, yes, but it’s the only one that handles revisions well (e.g., comments, tracking of edits, etc.). Entire publishing systems have been built up around Word, like the templates used, how Word docs are converted to PDFs, and so forth. Most of the publishers I know still use Word, although some, like O’Reilly, use geekier tools such as Docbook.

So you’ve got Word (or OpenOffice) open, you’ve created a new document using the publisher’s template, and you’ve incorporated your outline for this chapter. Now you just have to fill in all the blanks!

How you do that will depend upon the book’s subject and format. For example, if I’m writing a Visual QuickStart or QuickPro guide, the focus is on teaching individual ideas. In that case, I have to first explain the ideas being covered and then I have to come up with the examples to demonstrate those ideas. Then I write out the implementation of that example. As you write the chapter, you’ll sometimes realize that in order to make a point at the end of the chapter, you have to add or say something different earlier in the chapter. Hence, you edit and revise. When the chapter’s content is fairly well determined, you have to create the images, captions, and so forth. Along the way, you also have to make sure that everything is formatted per the publisher’s guidelines. This includes such things as how URLs are referenced, where captions are placed, and whether you can use the second person plural (i.e., say “we” instead of just either “you” or “I”).

Books or chapters that are task-based (e.g., my “Effortless E-commerce with PHP and MySQL” book, or the example chapters in many of my books), I start with the complete code and then write all the words that explain it.

Plan on 3-4 drafts of each chapter before you submit it to your editor. Which leads me to an important point, which I’ve written about before: don’t sweat the writing, it’s the rewriting that matters. The point of writing is to give yourself something to rewrite. Then you rewrite and rewrite until you’ve said what you wanted to say. Accept this and you’ll never have a moment of writer’s block again.

In terms of the schedule, keep in mind that, on most books, you’ll need to get at least one chapter done per week, if not a bit faster than that. So all of the above has to be done every 4-5 days or so. Ideally, it’s nice if you can find a day off to not write between chapters.

When you’re about halfway done with the first submitted draft of the book, you’ll begin getting edited chapters back for revisions (see the above sequence). From there on out, you’ll need to work on both new chapter submissions and rewrites of existing chapters.

By the time you’re left with just reviewing the PDFs of the chapters, you hate this book and everything you wrote. The idea of re-reading the same chapter for the umpteenth makes you nauseous, but this is offset by how annoyed you’ll be when mistakes are caught after the book has been published. Do your best to seriously reread the chapter one more time; you’ll be glad you did.

The Technical Editor

A tricky aspect of writing technical books is working with a technical editor. The technical editor exists solely to help you create a better book. A technical editor doesn’t just help to catch mistakes, but also makes suggestions as to how the book could be better. Ideally, the technical editor is just as smart about the subject as you are, if not more so. Whether the technical editor conveys this attitude or not, he or she probably thinks he or she should be the one writing the book. And that’s okay. Because you’ve got the contract.

Working with technical editors is tricky in part because it’s yet another reminder that it’s not just your book: an entire team is working on it to make it the best book possible. In my experience, ideally, about one-third of the technical editor’s comments will be wrong; another third will be a matter of personal preference (much like many programmers will have slightly different opinions on best practices); and the last third will be comments that you really should accept. In order to make the best possible book, you have to get over your own ego, and your annoyance at some of the comments, so that you can recognize and accept those comments that are valid and useful. If you can do that, you’ll have a better book.

On the other hand, you have to be confident enough in yourself not to let a technical editor’s invalid comments (invalid for whatever reason) erroneously let you change something you shouldn’t.

The same can be said for the line editor, who is improving the grammar of the writing. Except, you should pretty much accept all the changes that the line editor makes.

Oh, and the managing editor: he or she will be more diplomatic about making suggestions (hopefully), but you should really defer to him or her as much as you can. No matter how many books you’ve written, the managing editor has undoubtedly worked on more.

So there’s an insight into the writing process. In the next, and possibly final post in this series, I’ll write about what life is like after your book has been published.