Many want to write a book, but what most people don’t realize is the actual extent to which it takes to write said book. Grueling hours and exhaustive editing processes make the experience one I’ll likely not forget. My new book, Serious Cryptography, will start shipping in a few days.
I’m often asked how long it took to write this book, and how the collaboration with No Starch Press worked. This post will give you some answers, and will provide you with useful information if you’re thinking about writing a book. I also recommend that you read the advice by Tina Seelig and Chris Sanders, both in line with my experience.
I first contacted Bill in spring 2015 and sent a description of my project. We then signed the contract establishing each party’s responsibilities, including how much royalties I would get.
As you can see from the image below, the tentative title was Crypto for Real. We later agreed to change it, and after both throwing out a couple of titles, Bill came up with Serious Cryptography, which I think was the best pick.
After signing the contract I established a list of chapters, that I would deliver to the editor (Bill was my main editor, though other editors contributed) upon each chapter’s completion. We didn’t define precise deadlines, so it was up to me to decide when to send a chapter (up to reasonable delays).
The first hard thing for me was to work in LibreOffice, and getting used to the No Starch template, after adding a number of keyboard shortcuts to make my life easier. I tried OpenOffice too and could have chosen MS Office, but I initially settled with Libre, on a MacBook, because No Starch also uses Libre. I thought it would minimize the risk of interoperability bugs.
If you’re used to plaintext writing such as markdown or LaTeX, a full-fledge Word processor is—at least at the beginning—a lot of additional friction and productivity loss. The worst part was dealing with tracked changes and comments added by the editors. These would slow down the editor, especially when scrolling, and would sometimes crash the program altogether—I once had to spend half an hour debugging the XML file after it failed to recover after a crash.
For the last chapters I switched to MS Office (under macOS) which turned out to be a much less painful experience, yet still far from pleasant; still some bugs when scrolling over tracked changes, for example.
Conclusion here, and perhaps the single most important advice to future No Starch writers: Only use MS Word on Windows.
I quickly realized that I didn’t know everything about crypto. The book isn’t just a dump of my own knowledge, but rather the fruit of hours of research—sometimes a single page would take me hours of reading before writing a single word.
I had to determine what would be in the book and what wouldn’t. I had to find the right trade-off between simplicity of exposure and level of detail. My goal was to convey the important ideas without dumbing them down, yet without too much formalism or mathematical notations, which tend to scare readers away.
I took notes during my research and sketched a chapter’s structure before starting writing. The first draft would typically be relatively quickly written, but not rushed either. After writing the Further Reading section—the last section in each chapter—I then did at least 2 or 3 passes of editing and restructuring before sending the chapter out to No Starch.
Another challenge was that English isn’t my native language. Consequently my word-per-hour throughout is inferior to that of a typical native speaker. The style in my first drafts was likely less fluid, with fewer idioms, and more grammatical errors to fix during editing. But I got help, from Zinsser, Vonnegut, Clark, and Graham to cite a few.
After hours researching, writing, and editing my chapter, and being relatively happy with it—though never totally satisfied—I would get the edited version back from No Starch (Bill, most of the time). I then discovered the meaning of the word “editing”, and how indispensable it is to any writer. Not only editors corrected typos and fix grammatical constructs, they often restructured the text, rewrote parts of it, ditched any clutter and useless digressions, and more importantly challenged me to improve by clarifying explanations, adding missing points, or creating diagrams—not my favorite activity.
After one, two, or more rounds of editing, the next step was the technical review. The editor would send the chapters to a subject matter expert whose job was to review the text for technical accuracy, to suggest any missing content, and test any source code included. Erik Tews was the initial tech reviewer, then Samuel Neves later in the process. I also benefited from reviews for specific chapters from Jon Callas and Philipp Jovanovic. They uncovered technical errors, obsolete points, missing details, and suggested better examples—a job that a non-expert editor can’t do.
The next step was copyediting, a thorough hunt for typos, grammatical errors, style consistency, and more, by a dedicated copyeditor (Bart Reed for my book). They would correct the manuscript, send it back to me for my approval and with a number of questions for me to address. This step was one of two other rounds of corrections per chapter.
After editing, tech review, and copyediting, the document with tracked changes would look like this, MS Word display bug included:
You can’t Ctrl-F in a real book, so indices are still needed. I did the book’s index myself—with later some help from the production editor—and indexing turned out less boring than I expected. To make the index consistent, I first wrote a list of rules and conventions that I would follow throughout the book, regarding acronyms and abbreviations, sub-entries, capitalization, and so on. It would then take me between one and two hours to index a chapter of 15–20 pages, by adding index tags in the Word document.
I also learned that indexer is an actual job and it is a subject of academic research.
Now it starts to look like a book. The .odt or .docx files are turned into actual book pages to reveal the familiar No Starch layout. The person who works on this is called production editor (Laurel Chun for my book), and their work isn’t restricted to convert chapters from Office to InDesign files: Laurel thoroughly reviewed the book for consistency (like when I used both n and N to denote an RSA modulus in a same section), made sure that all figures and equations look good (sometimes having diagrams redesigned by No Starch), and made a great deal of changes and corrections upon my request.
Another job of the production editor was to produce the Early Access version of the book, which gives readers access to a non-final version of the book after they pay to eventually receive the final version. As a writer for No Starch, you are encouraged but not obligated to release your book in Early Access, but I strongly recommend that you do. Early readers reported a surprisingly large amount of typos and minor errors that we had all missed. I worked with Laurel, production editor, to review readers’ comments and decide how to address them.
About 2.5 years will have passed between contract signing and the first printed copies (which should be out very soon). It looks relatively long, but it’s not that much given that most of the work was performed during my free time, on evenings and week-ends, and also some spare time at the office. I estimate that, on average, each single page took me about 3 or 4 hours of work, or about 1000 hours for the whole book, which is 125 eight-hour days of work.
I initially defined my goal as writing the best book ever about cryptography—otherwise, why bother? I’m not ashamed of the result, but nor do I have a total feeling of accomplishment; I know too well the book’s imperfections and limitations. But I hope that readers will pardon these.