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.

In the wake of posts about Shopify's support for white nationalists and DataCamp's attempts to cover up sexual harassment
I have had to disable comments on this blog. Please email me if you'd like to get in touch.