How I Write a Technical Book

I have written four technical books (with three more in progress) and have edited seven others. They have all been different, but I do now have something approximating a process. For Software Tools in JavaScript it went like this:

1. Draw a concept map for major topics (about 20 nodes and 40 links).

2. Start writing point-form notes for each chapter.
   • Topics map to chapters about 2:1.
   • Leave FIXME markers where figures are needed but don’t draw them yet.
   • Write notes and code for 3-4 hours/week over 12 months (on average—it’s very bursty).
3. Write all example code while drafting the chapter.
   • Do a lot of rearranging at this stage, e.g., introduce sub-topic X as part of main topic Y.
   • Add some topics/chapters at this point: “I need to explain Z in order for X and Y to make sense and it doesn’t fit an existing chapter.”
4. Write 8-10 exercises for each chapter and revise the point-form notes so that this is possible.
   • Do some more rearranging at this stage.
   • More importantly, cut material because it just doesn’t fit this book.
5. Turn the point-form notes into prose.
   • One hour a day for 5 weeks turned 19 chapters of point-form notes (about 4 pages per chapter) into finished prose.
   • The finished prose is anywhere from 140% to 250% the length of the original notes.
6. Draw the diagrams.
   • About 90% of the intended diagrams survive; I don’t think I added any at this stage, but I should have—I hate drawing diagrams.
   • One entire chapter was cut at this point because the examples didn’t work and the content didn’t really fit anyway.

At this point I have 385 printed pages. Based on previous books it will grow by 125% to 150% based on feedback as I explain things that were clear to me but aren’t to anyone else.