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:
-
Draw a concept map for major topics (about 20 nodes and 40 links).
- 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).
- 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.”
- 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.
- 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.
- 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.