The Making of Core HTML5 Canvas
Synopsis: An explanation of the process I used to write Core HTML5 Canvas.
In his excellent book brain rules, John Medina recounts the story of Dimitri Mendeleyev, who discovered the periodic table of elements in a dream. Medina also tells of an experiment in which rats who run through a maze in the daytime replay that same sequence of brain activity many times, at high speed, when they sleep. It appears that sleep reinforces what we learn during the day.
Like most aspiring writers, when I wrote my first book, Graphic Java in 1995, I spent a lot of time staring at a blank page trying to get started. And once I did, I had to constantly go back and make substantial changes that were very time-consuming. It’s a wonder I ever got anything written at all.
Since then I’ve written eight other books and somewhere along the line I developed a writing process so that nowadays I never stare at blank pages trying to get started, and I rarely make substantial changes once I start writing. That process is what I used when I wrote Core HTML5 Canvas, and it involves, to a great extent, writing in my sleep. Here’s how it works:
To avoid staring at blank pages trying to get started, I don’t write into blank pages at all. Instead, I write into pages full of screenshots, code, diagrams, bulleted lists, tables, tips, notes, and cautions. I refer to that stuff as scaffolding, because it’s the structure that supports the writing. You can see an example of some scaffolding I’m currently working on in the screenshot above.
Code is the first thing I write when I start a chapter or an article. Then, once I have a set of finalized examples, I start building scaffolding. I spend a lot of time building and refining the scaffolding before I write a single word (other than what I write in the tips, notes, cautions).
As an aside, I believe that scaffolding is the most important part of any technical book. Technical books are not novels; readers almost invariably read content out of order and spend a great deal of time skimming instead of actually reading every word. I purchase technical books mostly based on the merits of the book’s scaffolding. If a book has excellent screenshots, diagrams — especially diagrams — tables, notes, etc. it will be much easier to read than books which are mostly just verbiage and code listings.
But here’s the real kicker. Building complete scaffolding and subsequently writing has an almost magical side effect: My books write themselves while I’m sleeping. It takes a lot of time to build and refine scaffolding for a single chapter. For a 50 page chapter, for example, I can easily spend 3-4 weeks full-time scaffolding. And that’s where the magical side effect comes in, because over the course of that 3-4 weeks, as I’m iterating over scaffolding, my mind is busy while I’m sleeping figuring out how to write about it. I will be in the shower, or eating breakfast, or just doing some other mindless task, and passages just pop into my head at random.
Sometimes while I’m scaffolding, the urge to write becomes almost overwhelming. But I know from painful experience that giving in to that urge and writing prematurely will only mean rework for me in the future.
Finally, when scaffolding is complete, I start writing. And now, writing is easy. It’s easy because I don’t have to think about the big picture at all anymore. How the chapter flows, the synergy between examples, and the reference material has all been finalized and all that’s left is for me is to fill in the words along the way. It’s also easy because my subconscious has already written the chapter for me. All I have to do is turn on my thermo-nuclear top-secret weapon — voice recognition software — and start regurgitating those passages.
Of course, that’s not the end of it. When I first started writing someone told me that writing is mostly re-writing and they were correct. After I’ve finalized the scaffolding and written the prose, I iterate over the writing trying to eliminate as many words as I possibly can. But that’s the topic of another blog post.
- Posted in: Technical Writing