I generalize the technical book writing process into a series of moods:

Wide-eyed enthusiasm. It’s a new book project, you have a blank piece of paper (or screen, or outline form), and someone has asked you to be an authority. You set out to capture the best possible treatment of your topic.

Plumbing the depth of your knowledge. At some point, you need to explain a topic and you simply haven’t worked with it before. So you start reading code, asking other experts, and doing more basic research. This is the point at which the book goes from ten chapters to fifteen, when you realize there are entire facets of topics that you’ve ignored. Publishers love this moment, because it creates meaty, dense books, but they equally fear the resultant slips in the writing schedule.

Content stride. Parse that as “content” meaning happy or “content” meaning “words”, yes to both. You’re writing at full bore, the words are flying from brain through fingertips to disk with ultimate ease. You end up writing some things that are goofy, or light-hearted, because you’re having fun. I snuck an xkcd reference into the chapter on database design, because it seemed like the right way to explain SQL query cleanup.

Hearing your own voice. After the technical reviewers and editors get done with your initial pass, you get to go back and read your own words again. And you hate your voice, can’t believe what you passed off as humor, and wonder if the book will be turned into something publishable before the heat death of the universe. At the same time, you have the hindsight of additional sidebar conversations and research, so you know there are ten things missing.

Sand to fit. You make the final edits to the original manuscript so it flows and tells a story. Your list of ideas becomes an outline for the second edition, or topics to start in online forums run by your publisher. The page proofs come back and you see your words set neatly, with clean page breaks and header artwork.

A few weeks later, you hold a printed, bound book in your hand with your name on the spine. It’s a feeling I’m sure goes back to the painters at Lascaux, who argued over who made them look fat.

If we get the last batch of page proofs back next week, and production goes back to fix the page breaks that our proofreading damaged, the book goes to the printer sometime in the next few weeks. From the printer it goes to the Wiley distribution network, with boxes of shiny new titles going to Borders, Barnes & Noble, amazon.com, and your favorite local technical book nook.

Roughly two months from today, coincident with the first pitch of baseball season, Professional WordPress will be in full swing as well.

How do you find the time to write a book? I think the two biggest issues are sticking to a writing schedule that is realistic, and having an appropriate timeline for book gestation. From the time you have a really solid idea, you’ll generate an outline, find co-authors and editors, write the actual manuscript, go through technical review, edit and re-arrange content, review the final copyeditor and production galleys, and then wait for the book to get printed and delivered to a bookstore near you. Professional WordPress will be about ten months from an email I received asking if I was interested until I can crack the binding on a real copy; that’s remarkably fast but the timeline was accelerated by having three of us sharing the writing and editing. Once you have a sense of the overall timeline, you need to make sure you set aside time every day to write. I aim for one quality page, on average, every day. It more frequently is only an average, with me working in groups of 4 to 5 pages every few days.

How do you actually write a book? If you have a great idea, you need to create an outline, and usually write a sample chapter. Those go into a book proposal that your acquisition editor at a publisher will share in their in-house equivalent to a portfolio review: they decide if they want to take a risk on your idea, committing editing, copyedit, production and marketing resources to your project. Your proposal has to be differentiated, and it helps to have knowledge of other books in the market or what the market is lacking. There are many books about WordPress available today, but this project started when I couldn’t find a book that had an “internals” feel to it, telling me how the core functions worked hand-in-hand with the MySQL data model, wrapped up in as basic post/page display loop. That’s the book’s story, with healthy helpings of theme and plugin development as well as issues of security, migration, and performance rounding out the narrative.

How do I turn my really cool idea into a book? Most obviously make sure your really cool idea is book-length. Start with an outline, and cover all of the topics that tell the whole story. Working from that outline, make sure you have a unique approach to the content. Technical books tell stories without chase sequences, sex scenes, or convenient bending of the laws of physics. But they still need to tell a story, developing ideas from generic to specific, and capturing a reader’s attention so they’re more inclined to read your book than to use Google to search for a one-page answer. Given the breadth of most subjects, and the rate of change in the technical markets, having co-authors is often a good idea; it gives you multiple sets of eyes and views on the material, and it also helps shorten the development timeline. Most of all, you can turn your idea into a book if you’re passionate about the material. A technical book won’t make you rich, or lead to movie adaptations (that bit about the sex scenes again), but it builds your reputation (hopefully in a positive direction) and is a labor of love.

Today’s book progress is: 100% written, about 40% edited, 20% production galleys. We’re still aiming for a springtime release, meaning you can read our words while yelling at the Mets on Opening Day.