I recently speed-wrote a mini-book Ray Tracing in One Weekend available on the kindle store.
I loved doing it. This post is about the mentality and tools for this sort of endeavor.
Over the course of my career in computer science there have been many trends that I think are good signs of maturation of our discipline. One, for example, is the rise of programming environments with heavy GUIs like xcode and visual studio. The one I like the most is the rise of “agile” approaches (this would be a counter-trend to the GUI programming environments). The most obvious example is agile programming methodologies. In line with that is the YAGNI (you aint gonna need it) to feature evaluation. The lean startup and MVP is the software business manifestation of agile.
Something that in my experience is the opposite of agile is writing a technical book. I think this is one reason most people don’t write one. The book I have the most knowledge of is the one I wrote with Steve Marschner on Computer Graphics. Everything about making that book was not agile. That is ok from the point of view of “is the book good?”. Yes, it is a very good book. And I know from working with Steve Marschner I would like to read any book he was involved in. But I would be surprised if he writes more. Not because Steve doesn’t like explaining things-- he is in his element in front of a white board. But writing a traditional book is as much about wrangling LaTeX and Adobe Illustrator as it is about explaining things. I would call the process “epic”.
Last year I taught a graphics class at Westminster College in Utah. One thing about the class is that half the majors were taking it so I decided to gear it toward making it a fun class that gives a feel for what graphics is all about. This is as opposed to a class the punishes the students with the “spinach they should eat” if they are going to make a career in graphics. I think the class was really fun. It occurred to me that maybe I should write a mini-book on ray tracing based on the class assignments. Then I thought about the epic book writing process and said “no way”.
Over the next six months as I occasionally posted things on my blog, I realized how un-epic blogging was. First, you can’t control the exact visual format-- different browsers and size setting make that impossible. Second, there is no cultural expectation that the graphics design elements or the language be perfect so you can just concentrate on the information. This is an example of an agile process. Then it occurred to me-- why not write an “agile book”. And what is that?
First because it is a graphics book, it needs diagrams and equations. What is the easiest way to do those? I considered drawing them on paper or a white board and photographing them. Instead I used a white boarding program, limnu, to make the process more fluid.
For the code, I didn’t want people cut and pasting any code. I am a big believer in typing it in. But I also think seeing code is often the best way to communicate something. So I put in screenshots of code. For the writing, google docs seemed like the path of least resistance and something very fluid. That is the entire tool chain.
Writing the book this way was fast and fun. And since 100% of my brain was focused on generating the information rather than fighting layout tools and getting uptight about look, I don’t think the book is any worse than if I had spent five times as long and make it a traditional book.
All in all, I think this is a good way to write some books. Write it fast, make sure the information is right (for CS writing code as you go ensures this), and stick to a narrow subject with a well-defined goal for the reader. After the experience I definitely encourage others to write books this way, and I would like to read them.