10 Lessons I Learned After Writing My First Tech Book
While I was away speaking at the Fluent conference, I received the first royalty check from O’Reilly for my book, Introducing HTML5 Game Development. I have been waiting for this moment for several reasons, the most important of which being finally having an opportunity to talk about what it’s like to write a book from scratch and get paid for it. It’s an incredibly rewarding feeling to have a published book and, until I created one, the entire process was a total mystery to me. I figured I would share my entire experience in enough detail to probably get me in serious trouble. If you have ever thought about writing a book, especially a technical one, this post is for you.
Surprisingly enough, my book didn’t start out as an HTML5 game dev book. I had originally pitched an introduction to Flash game development book to O’Reilly. It was a topic I had been thinking about doing for a very long time. In fact, this wasn’t even the first book I had started. Months prior, I was originally going to do a book on high-performance Flash, which fell apart as these things tend to do. After some time “alone,” I decided to reach back out to O’Reilly to pitch my Flash game book. O’Reilly accepted my book pitch, and I agreed to write one of O’Reilly’s short-form books, which usually average in at around 100 pages long.
Unlike a traditional book deal, there was no upfront payment. In lieu of an advance, I received a slightly larger royalty cut, which I don’t think I can contractually get into, but let’s just say it’s nothing too impressive. Generally, with a traditional book deal, you get an advance of a few thousand dollars and you don’t see anymore money until enough sales cover the money you received upfront. Depending on the type of book you write, that could take months, years, or never even happen at all. Even worse, if you work with multiple authors you all have to split the advance, so that could mean even less money. After being involved in the previous book deal, I knew that if I was offered any money upfront it wouldn’t be much and chances were good that I would never see a dime after the sales unless it was a runaway hit. So, taking no money upfront wasn’t as bad of a proposition as it sounds. Plus, I already had a great headstart on the book. I usually don’t sign myself up for something unless I have an ace up my sleeve.
I was well into my Flash game book when news broke out that Adobe had stopped development of the Flash player for Android’s browser. I was already up to page 85 of my 100-page book. At this point, I could hardly hide my contempt and disgust for the platform and how Adobe was handling its agonizingly slow death. While I was writing the book, I was also getting deeper into HTML5 game development with the ImpactJS framework leading up to a workshop I had planned on doing at RIA Unleashed. In the back of my mind, I really wanted to do an HTML5 game dev book, and it was almost torture trying to finish the last 15 pages of my Flash game book. Plus, I still had to do a large chunk of the code examples. Code examples are the hardest part of doing a technical book; I can knock out a 50-page post in a few nights given the right motivation. This brings me to my first lesson about writing a technical book: Write about something you really love.
It may sound like common sense, but a lot of people get roped into writing books they really don’t want to do simply for the “thrill” or “exposure” of writing a book. Doing a book on Flash gaming, which has been totally done to death, was an easy one for me since I was seeing the writing on the wall with what Adobe was doing to the platform by making it only for games and video. The problem was that I didn’t have my heart in it and just working on the code examples was so painful I had no motivation to even finish the book. I also jinxed myself by playing with something even more exciting on the side, which was the Impact framework. I convinced myself it would work out since I was also drafting page upon page of documentation for my Impact workshop and that, as soon as I was done with my Flash book, I would turn around and knock out the HTML5 gaming book. Adobe’s announcement was just the opportunity I needed to kill what was left of my morale, and I asked to change my book from Flash to HTML5 game dev.
While convincing O’Reilly wasn’t incredibly difficult, Adobe was making a total mess of themselves in the press, and the iron was hot, so I struck. It didn’t hurt that I had roughly 50 pages of HTML5 game dev documentation sitting around and that I could gut almost two complete chapters from my Flash game book that, with a simple find and replace of the word Flash to JS, could give me almost 70 pages without my due date slipping. It was the beginning of October 2011 and my deadline was the end of the year to deliver a final book. I repitched a table of contents and submitted that along with what I had already written to help seal the deal. Once O’Reilly gave me the okay, I was invigorated with all the motivation I needed to knock out the rest of the book and all my code examples by January 1, 2012. I put my head down and got to work on my new book, Introducing HTML5 Game Development.
I am not a stupid person; I can add up all the things against my book and clearly see that I was not going to make any money on this endeavour. But, the reality was that if I was going to teach people about making HTML5 games, they were going to need a solid framework, and Impact was the best one I could find. Not only did Impact offer a great platform to build JS-based games with, it came with a level editor, which saved me a huge amount of work writing my own from scratch or covering a third-party one, which may not even work well with HTML5-based games. Impact was a full product, complete with everything anyone needed to build a game from scratch. So, I took the plunge and accepted the reality that my book was not going to be the next Making Things Move.
Now that I was commited down the path of writing about Impact, I got into a good cycle where I would vet out my ideas through the material I was writing for my workshop, and that material was feeding my book. I gave my Impact workshop at the end of October, and everyone who attended received a 50-page “beta” of what would eventually become my final HTML5 game dev book. The workshop went off without a hitch, as well as you can expect trying to cover a ton of material in three hours, and I began to look for ways to milk all the content I had generated so far. I had less than two months left to finish my book and a lot of experimental code, a half-finished workshop document, and I was bleeding into my own time and money. By the way, I equate time I am not working on paid projects as costing me money. It also didn’t help that I didn’t make a single cent from my workshop. At this point, I considered myself in the hole. This brings me to my third lesson of writing a tech book: Recycle as much as you can to raise money.
With an edited down version of my workshop document, I pitched a 25-page article introducing Impact and HTML5 gaming to Adobe for their developer connection site. I got lucky and they accepted the pitch and paid me for the article. This allowed me to fill my coffers to help fund all the extra work I had left to do on my O’Reilly book, such as getting artwork, my time, and my personal editor. This also helped get me on people’s radar as an Impact and HTML5 game expert. One of the best parts about having an article on Adobe’s site is that people can find it on Google, so the exposure also helps feed into the PR you will eventually need to do to help promote your book. The only consent I had to make on my article was to somehow tie it to Dreamweaver, which wasn’t that bad. Looking back on it, it was the perfect window of opportunity since there is no way Adobe would ever accept an HTML5 game article now that it conflicts with their Flash as a gaming platform strategy. I guess I have the honor of being the first and only HTML5 game development article on Adobe’s site for the foreseeable future, unless they take it down now that I drew attention to it.
So, I had two solid months left to finish my book. I gutted my workshop demo game, which was a deconstruction of a demo that came with Impact, and started working on an original game. I hired an artist to help out with pixel art, but he wasn’t able to get me what I needed in time. These things happen all the time; you just learn how to roll with the punches, and it didn’t hurt that I can also do my own art. But, it put a lot of pressure on me now that I had around 30 pages left to write, all new code examples to do, and I had to come up with all my own artwork. With two months left, I really only had half that time because it takes an incredible amount of time to test all your code examples. I can’t imagine ever doing a book over 100 pages. With my day job, family, and the holidays, I wasn’t left with much time to get it all done. This brings me to my fourth lesson about writing a tech book: You need to learn how to focus and be productive with any free time you have.
Creativity cannot be scheduled, but you have to learn how to harness it when you need it. Fifteen years of firefighting consulting development experience has taught me how to be a code writing machine. Give me 30 minutes and I’ll create something amazing. But, writing a book means balancing three things at once. First, you need to have a clear plan since you are teaching people something and not just hacking code together to get through a launch. Second, you need to clearly articulate what you are doing and how you plan on doing it so people can follow along. Finally, the third thing you need to be able to do is keep the writing and code consistent throughout the entire process. Nothing prepares you for this. It’s true that writing technical articles for years has helped and my years of consulting covers the code side of things, but doing both at the same time under pressure is a true artform. This is the toughest part of writing a book.
With only one month left to have a rough draft and code examples, expect life to throw everything it can at you. I had blocked out a few days of solid writing time over the course of deals with my wife to watch the kid on the weekend, holidays, and a vacation. I shit you not, I was sick through most of the month of November. It was so bad we had to cancel a week-long trip down to Florida to see my parents and my best friend’s wedding. I only went down for a day and flew back after the wedding. The first week of December came and I hardly had what I needed to feel like I was on solid ground, but I had no choice and started sending chapters off to my editor. This brings me to my fifth lesson of writing a tech book: Find a good editor you trust.
I am the world’s worst speller. It doesn’t stop there; I also suck at grammar. I have learned over the years that it doesn’t matter what it costs, I no longer post anything to my blog unless it goes by my editor’s eyes first. I actually allocate personal money each month just to make sure I am covered, because nothing makes you look like a total moron more than spelling and grammar mistakes in your posts. You could be the smartest person on the planet, but as soon as you get a comment, which is usually the first one by the way, about how you misspelled something, you have lost all credibility. This post will be in my editor’s inbox as soon as I am done writing it. I bring all of this up because O’Reilly really didn’t give me an editor for the book. Since this was one of those short-form books, you are kind of on your own. They must expect a very well-polished book because there was only going to be a basic read through before it went to press. I have cold chills running down my back imagining what they would have done if I had delivered my 100 pages of spelling and grammar errors come January 1. So, I used my own editor, out of my own pocket, to simply not embarrass myself.
A good editor should be able to do two things for you. First, they should make you look like you know how to command the English language. Second, they are there to sanity check your writing. Most of the time you write chapters totally out of order. You have mood swings while writing. Adobe makes an announcement and you accidentally find yourself bashing Flash in your book for no apparent reason. Your editor is there to keep everything consistent, and a really good editor like mine can take a collection of bullet points and turn them into an amazing summary paragraph when you are too burnt out to finish a chapter. A good editor also learns how you write and emulates your voice in a way that no one can ever tell the difference between the two of you. If you plan on writing a book, make sure you have a good editor or hire your own. I have no regrets doing so, but it did put me back in the hole since I paid for it all out of my own pocket.
By the middle of December my book was basically done. I had all my code examples working and it was time to go out and find people to help test out my code. Usually, O’Reilly would offer an inadequate sum of money to a collection of eager people to help test out a book, but again, doing a short-form book put the burden on my shoulders. I had two goals for my book. The first was to not get a single comment that I couldn’t write English, which I solved above with my editor. The second was that I didn’t get a single comment that one of my code examples was broken. I am a perfectionist, and once something is put down in print you can’t take it back. I went out and begged seven people to test my code. I couldn’t offer any money, and in the end, only three actually did it. I still have nothing but love for the other four scumbags who didn’t spend their precious free time reviewing my code for a lousy mention in my book, but I don’t hold a grudge. This brings me to my sixth lesson about writing a technical book: You are the only person who can really test your code.
Don’t ever rely on another human being to test out your code. Humans are lazy and inherently miss things. The only advantage you will ever get from someone testing your code is to make sure you don’t miss the big things. You will need to go over every single line of code over and over again until you hate it. And you will hate it. I was already completely frustrated after having to re-read every chapter of my book over and over again when changes would come back from my editor, so just imagine when a single line of code changes and, not only do you need to test it all over again, but you also need to make sure all the copy stays in sync as well. If you are unfamiliar with who Sisyphus is, you should do a Google search. By the end of December I wasn’t done, and the perfectionist in me wouldn’t release the book to O’Reilly. I still wanted the code to be cleaner and, due to the holiday that everyone swore they could use to read through and test my book, I hadn’t gotten back a single comment from my testers.
January started and I was frantically trying to wrap up the last one percent of my book. I was late, I was still finding small annoying bugs in my code, and just as luck would have it feedback from my code started rolling in. Dominic Szablewski, who created Impact, was the first to get back to me. While he didn’t go through all the code with a fine tooth comb, he had some great feedback. Dominic also had some other news for me, which I had been dreading to hear since I decided to go with Impact. He was about to release a new version. While it didn’t “break” my code, it basically required me to rewrite half of a chapter. Even worse, the other code reviewers, who I was convinced were never going to get back to me, hadn’t been testing on the new version. Go figure the next few emails I would get back from people reviewing my code with the latest build would have show-stopping bugs. This brings me to my seventh lesson about writing a tech book: As soon as you are ready to publish your book, there will be an update to the platform, language, or framework that will render your book outdated in some way.
I knew this day was coming ever since I had to abandon my Flash book thanks to Adobe’s inability to deliver a positive press release regarding Flash. I really hadn’t prepared for it, but in all honestly what makes writing technical books so difficult is the fact that they are almost outdated the moment they are published. I would be lying to you if I said I didn’t consider just abandoning the entire project, posting what I had for free, and moving onto something else. Nothing kills your morale when writing a book more than when the underlying technology changes in some way. Luckily, it wasn’t a terrible change, but after removing the parts of my books that were no longer relevant I was now short 10 pages.
I was really left with no choice. I couldn’t add more code due to the sheer amount of effort required to retest everything, so I did the only thing I could think of. In my book, I had a section on game design with a sample game design document in there. My original document was much shorter than what made it into the final copy of the book. I ended up taking a much longer game design document I had written about a side project that was around 25 pages long and swapping them out. After editing it down, I netted out about three pages ahead of where I was before the framework change. The only downside was that I wasn’t using something that made more sense in the context of the book. The GDD I did end up using is a very good one, but there was no way I could write a 15-page one based on the demo game readers ended up building at the end of my book, so I rolled the dice and decided to go with the longer of the two documents. This brings me to my eighth lesson of writing a technical book: Do want you need to do in order to get it done.
I cut a lot of corners in order to get my book out the door. You sort of get a little desperate when you miss your deadline and want to get the project off your plate. I was very fortunate that O’Reilly wasn’t putting any pressure on my at all, because I’m sure this happens all the time, but the fact that my own perfectionism, reliance on an ever-changing technology, and inexperience in writing a book got me to the second week of January making it time to put this thing to bed. I updated all my code examples for the latest build of Impact, got some solid feedback from my code reviewers, and my editor had reviewed it and was ready to hand it over. Time to format everything I wrote in O’Reilly’s template, how hard could this … crap! I just learned the hard way that I did this totally backwards! My ninth lesson of writing a technical book: Don’t write your book in Google Docs and use the publisher’s Word template from the beginning.
Google Docs is an amazing thing. I use it for almost all of my writing. There is no better collaboration tool out there for writing. I don’t think I would have been able to get as far as I did with my editor without the collaboration tools Google Docs has. Coupled with the fact that everything is in one place, I never had to deal with losing a version or going back and forth via track changes. While Google Docs does all of the above well, don’t ever ever write a book in Google Docs. Converting a Google Doc to a proprietary publisher Word template is next to impossible without going slightly mad in the process. I had finally reached my lowest point while writing my book. And again, it was my own stupid mistake. As I frantically searched back to the first email I got after being accepted to write my book, which had the template conveniently attached to it, there was a list of things I should read before starting my book. Of course I marked this email as “unread” and never got back to it. The first few bullet points talk about using the template, using their macros (by the way, I had never used a Word macro before and hope to never use one again), and writing each chapter as its own document to make editing and organization easier. All these things would have saved my ass. This brings me to my final lesson when it comes to writing a technical book, which is: Read the fucking manual.
Every publisher gives you a set of instructions when you get started writing for them. I am one of those people that always threw the instructions out with the box and just winged it. You can’t do that with a book. If you have never written a book, you don’t know anything about what it takes to get a book ready to go to the publisher. I’m at the third week of January now and I am going through 100 pages of words, code, and images trying to cram it into what appears to be one of the most archaic Word templates I have ever seen in my life. Once I got everything in, I did a final page count and had lost 10 pages! Nothing can prepare you for the moment when you have lost pages due to formatting. It’s like everything you have ever known about your book was a lie and you now have to magically pull out more pages from your ass. I did the only thing I could think of at this point, I got creative with images. I felt like I was back in high school trying to get my research report to the page requirement by changing the font to odd values such as 13px so the teacher doesn’t know, except this time I had no control of the font, which is 10px by the way, and I had to add more text and images. It ended up making the book better because I was able to better illustrate some areas that may have gone ignored. After getting the book up to 102 pages, rereading every single line, having my editor reread everything, and retesting all my code, I was finally able to submit my book three weeks late.
After I submitted my book, I didn’t know what to do with myself. I now had to wait for O’Reilly’s editor to go through my book and give me the final thumbs up. While I was waiting, I finally got to see my animal cover, which let’s face it is the only reason I went with O’Reilly to begin with, and it was a fish. My first thought was thank god it wasn’t a bird. I hate birds and, for what it was worth, my fish, which is called a gemmous dragonet, looked uniquely different than anything I had seen before. I had actually asked for a pitbull, for my dog that had passed away, but you don’t really get a choice. I even offered to pay for the artwork myself, but the fish is what I got and that is alright with me. I eventually got the thumbs up that my book was done with a few minor tweaks and it went to press the first week in February, right around my birthday and a modest four weeks late.
Nothing can prepare you for shipping a book. There is something magical about holding your own book in your hands and seeing your name, words, and story immortalized in print. Once you have a book, you have instant “technical street cred.” You can walk into any job interview and leave a copy of your book and people know you fought your boulder and pushed it over the hill. It has taken me almost eight pages to describe a summary of the effort I had to put into a 100-page book. It was easily one of the hardest things I have ever done. And, once you complete your first book, you immediately announce proudly that you will never write another book again … ever! On top of that, once your book ships, you have to promote the hell out of it. So, not only do you hate everything you had to do in order to get this book out the door, you are now responsible for telling everyone with a straight face that it’s going to be the best thing they have ever read and must buy it.
I still feel a little shallow and empty inside because the book that shipped still feels like it is incomplete. If only I had more time, or another 50 pages, I could have done even more. But, all of this is moot since the book is printed and out there for everyone to consume, judge, and comment on. For the first three weeks, I obsessively checked Amazon making sure I didn’t see a single comment that my book was riddled with spelling errors or that the code examples didn’t work. Despite the somewhat deceptive title, that wasn’t my fault by way, people genuinely liked the book and left very positive remarks. Also, people were quick to point out that my book’s title didn’t accurately describe its dependence on Impact, which is in the subtitle by the way, yet it was worth the read and the cost of the framework. That was the most rewarding part of the entire experience, to see people like my book and speak positively about it. And, while a few commenters retracted a star rating due to the dependency on Impact, I have been able to maintain four- and five-star reviews so far. Any author can tell you how hard that is to achieve. It almost makes me want to write another book … almost.
So, now it’s been four months since my book went to print and I got my first check. I made you read through all of this article when all you really wanted to know was how much money I made. According to my first statement as of February 29, 2012, my book sold 135 print copies and 83 ebooks totalling 218 books and rewarding me with $316.44. Now, there are a few things you should know about this number. First, most publishers are incredibly behind on real numbers of books sold when it comes to your royalty check, so this is just the first invoice I have received. I was actually told before I received this check that my book has sold just shy of one thousand copies, so I expect to see a bigger check in the next quarter. Second, I went in knowing that I wasn’t going to make any money. If it wasn’t for the article I wrote for Adobe, I would be totally in the hole right now from just my editor’s costs alone. I can’t even put a price on my own time, or I may throw up, but I figure I must have spent well over 200 hours on my book. And, out of the four workshops I have done, I was only paid for one, which netted me in an extra $750 that also helped cover some of my time that went into this endeavor. So, if you do the math, even with my workshops and my first book sales check, I have barely broken a grand. So, was it worth it?
In the end, there is nothing quite like writing a tech book. If you go in knowing that it is a losing proposition, you will be somewhat mentally prepared for the reality of what you will have to do in order to write a successful book. While I jokingly say I would never write another book, I can’t help but acknowledge the attention I have gotten for it, and there is nothing like being able to tell someone that you have “a book on the subject.” Since I don’t make games for a living, having a book on HTML5 game development isn’t going to do wonders for my career, but it did fulfil the first lesson of writing a tech book, which is to write about something you really love. Like most things in life, try to do what you love and hopefully it will reward you. After all, I have been able to speak at conferences about my adventures in HTML5 gaming and have successfully satisfied my ego by having my own book sitting on in my bookshelf. Even if I couldn’t afford to pay for the bookshelf it sits on with the money I got from the book. It should be noted that Mrs. F. and I have expensive taste in furniture.
If you made it this far, there is one more thing I want to say. Most people gloss over the acknowledgements section of a book, but I wanted to post it here so someone actually reads it. Before I do, I want to thank O’Reilly for this opportunity. I can’t thank them enough for the chance to fulfill my dream of writing a book for them. Ever since I picked up my first animal-covered Flash book I knew I wanted to be an O’Reilly author, and I’m honored to be able to add that to my resume. With that said, here are a few people I would like to thank:
First and foremost, I would like to thank my wife and son for all their support while I was making this book. I’d also like to thank my parents and family for all their help and support over the years. I also have a lot of respect for all the thought leaders in the development community who continue to inspire me such as Keith Peters, John Lindquist, Jesse Warden, Chuck Freedman, Sean McCracken, Michael Labriola, Nate Beck, Troy Gilbert, Joel Hooks, Brendan Lee, Scott Penberthy, Seb Lee-Delisle, Rich Shupe, and especially Jobe Makar who taught me how to make Flash games years ago.
Thank you as well to Mary Treseler and Rich Tretola from O’Reilly Media, Inc. for providing me with this opportunity and to Dominic Szablewski for his feedback on this book and for creating such a great game framework. I also couldn’t have done this book without help from my amazing tech editors: Riche Shupe, Gareth Parker, and Richard Davey.
Finally, I wanted to give a special thanks to Dan Wolfe for creating the splash screen art for Resident Raver as well as for his artistic help on my other games.
The last person I want to thank, who isn’t in my acknowledgments, is my editor, Kristin Kelly. I fought hard to make sure she got an editor mention in my book, which is why she isn’t in the acknowledgments. I really couldn’t have written this book without her, or this post about it, and I am sorry for all the work I put her through trying to dredge through all the red underlined words and run-on sentences.