Das Book

I'm still feeling flush with excitement at completing my first book.  It's been a wonderful, long, unexpected, enjoyable process.  I'm still kind of processing everything that has happened and what it all means.  Without further ado, let's commence the rambling.

The way it all started was a bit like a fairy tale, with Ray Rischpater playing the part of the fairy godmother.  I had thoroughly enjoyed my previous technical editing gigs for Ray and Chris Haseman, which allowed me to go outside my normal technical circles, pick up some good new skills, and, even better, exercise the critical and analytical parts of my brain.  The two books were very different - Chris's was written quickly, relatively casually, and was extremely dense.  Ray's lasted for many months, was more structured, and regularly stepped away from the code to take a higher view of the mobile space.  I like Ray and Chris, and it was an honor to work with them in this new venue.

I really enjoyed the process, and daydreamed a bit about writing my own book, but never really did much about it.  Then, due to a fortuitous turn of circumstances, Ray connected me with some of the people at Apress to write about BlackBerry.  It just so happened that I'd been focusing on BlackBerry almost exclusively at work, a change from my previous BREW-heavy experience, and felt like I had a lot that I could contribute to a book.  We discussed it, and the book proposal went through several iterations.  When it all finished, I had a five-page proposal I'd written, complete with a table of contents, and a title: Advanced BlackBerry Development.

Having completed the earlier technical reviewing gig definitely helped prepare me somewhat for the process of writing a book, but it was still fascinating and occasionally surprising.  I don't think I've ever really appreciated just how many people are involved in this undertaking, and how they come in and out of the picture as the book comes along.  The editor who had initially recruited me seems to be more business development oriented... we keep in touch, but he wasn't hands-on for much of the writing process.  Instead, I worked primarily with another editor who showed me the ropes, got me used to the Microsoft Word templates that Apress uses, offered useful feedback, and generally helped give me confidence that I was moving in the right direction.  Later on I'd work closely with a coordinating editor/project manager; we'd check in frequently, often multiple times a day, to make sure that materials were being received and edited on schedule.  Towards the end of the process I got to work with a technical reviewer, a copy editor, and the fine folks at production and layout.

Possibly the biggest surprise for me is how fast the whole thing was.  On the one hand, yeah, it has taken me about four months from start to finish.  On the other hand, though, the actual chapters just flowed out.  Apress maintains a wiki that, among other things, contains useful advice for new authors, and they promulgate a phenomenal strategy for writing a book.  Basically, you should subdivide, then subdivide, then subdivide again.  When you have a manageable chunk, do everything you need to do with it: do your research, write sample code, draw diagrams, come up with examples and tables.  Then you write it - as they observe, by this point, it practically writes itself.  Once it's done, you move on to the next chunk.  There's no worry about losing your place, about forgetting to cover something, about repeating yourself.  You create a plan, then execute the plan - what could be simpler?

The original schedule had been for me to finish the first 3 chapters by September, and the rest of the book by November.  I realized that this schedule would allow me more than 2 weeks per chapter for the first 3 chapters, but about a chapter a week for the rest.  Since I would also be doing edits and such at the end, I was concerned about creating a bottleneck, so I asked my editor if I could write ahead of schedule.  He said, "Go for it!"  And I did.  For week after week I wrote and wrote.  Not a single day went by that I didn't write something.  I tapped away on the Caltrain commute in the morning, and tapped again in the afternoon, and switched to my desktop computer for further tapping once I got home.  Some weekends I would hole up in my living room and just pound out more and more of the book.  It was exhausting, but also totally exhilarating.  I felt a constant sense of accomplishment: "Yes!  I drew another diagram!"  "Yes!  I finished another section!" "Yes!  This chapter is DONE!"

Oooh, before I forget: this book also taught me to love diagramming.  I do really enjoy sketching out design and architectural diagrams on a whiteboard or notepaper, but my handwriting is horrible.  I'm used to fighting with Microsoft Visio or Rational Rose for drawing diagrams on the computer, and just hate them.  I can easily spend five or ten minutes just trying to make all the lines straight, and the programs still won't let me get them just right.  I think that I've improved myself a lot while writing this book, and the most dramatic instance may be becoming a far better illustrator.  And, 100% of the credit goes to OmniGraffle.  (With an assist to Ray, for introducing me to the program, which he used in his own book.)  OmniGraffle is... well, it's like sorcery.  It's a Mac program, you drop shapes onto a sheet, drag them to where you want them to go, and then draw in the lines connecting them.  Poof!  The process takes less than a minute, with a result that looks far cleaner than something I could have spent twenty minutes on in Visio.  It uses helpful guides that help ease shapes into place, automatically display rulers when you're trying to line something up, lets you grab and move multiple pieces together... oh, and the magnets just work like magic, keeping the lines where you want them to be.  On the really complicated diagrams, it let me take control and manually position things where I wanted them to do; for the bulk of my diagrams, no extra effort was required on my part.  Hats off for a job well done!

Back to the book proper - I kept dropping off chapters to my editor.  He had some great, detailed feedback on the first couple of chapters.  I had initially designed the book by looking at the table of contents for Beginning BlackBerry Development and picking up where that book left off.  As a result, the book assumed the reader was up-to-date on all the basics of BlackBerry programming, and plunged right into new material.  We eventually decided that it would be helpful to include an introductory chapter that would review the basics and cover the most important points.  This would be helpful for people who were going directly to this book without reading the "prequel," or for people who had waiting a while between the two and wanted a quick refresher course.  Because we realized this so early, I could build it into my schedule, and more importantly, tailor later chapters' contents slightly differently by controlling when and how certain concepts were introduced.

The feedback became more minor as the chapters continued.  I asked the editor if I should keep writing after I passed the third chapter.  To be honest, I would have kept writing regardless, but I was really curious whether I should keep handing them in or just sit on them until the September deadline.  He encouraged me to keep writing and keep submitting, so I did.  It was so much fun, I just couldn't stop!  A lot of the book, especially the first several chapters, covers material that I deal with quite a bit at work and that I could code in my sleep, like media capture and playback.  As I got further in, I started to tackle chapters where I had less hands-on experience.  That was even better, because I got to learn some new stuff, process it, play around with code, find out what worked, figure out the best way to do certain things, check out the collective wisdom on the forums and technical articles, then distill it all down to a compact and (hopefully!) helpful segment.

Funny story: Of course, I kept my day job during this whole process.  We were (and are) working on a high-profile project that can lead to a lot of pressure.  We had been going back and forth for almost a week on a particular problem with authenticating our client against a third-party server.  The people who write the server are way overseas, so we could never work anything out in real-time; we'd ask questions, and get an answer when we came in to work the next day.  Anyways, on this particular day we had a 9AM conference call (beginning of our day, end of theirs) to try and hash out this problem once and for all.  I arrived in the office a bit before 8 to prepare for the call.  I found that the server team had finally fixed the issue that we had been reporting.  I fired up the RIM emulator and hit the server.  Success!  We were getting data back.  But, wait - as I looked at the bytes for the first time, I realized that they were returning the data in Base64 encoding instead of raw binary.  "Oh, no!" I thought to myself.  "Converting from Base64 to raw bytes is a pain.  I remember because it was annoying to write that part for my book.  Wait!  That's right, I already wrote that code!"  I hopped onto Google Docs, found the relevant chapter, copy-and-pasted the decoder into our source, and then ran it again.  Success!  When the 9AM call came along, I could calmly and confidently lean into the speakerphone and say, "Yes, thank you for solving that problem on the server.  We are now able to log into the system."  Ain't nothing like a side gig that directly increases your value on the main gig!

Because I kept flying, I was almost done with the book by the time the first 3 chapters officially came due.  I handed the last few off to my coordinating editor, and then started the review process.  Reviewing proved to be a serious case of "Hurry up and wait."  I went for almost a month at one point with absolutely nothing back to review, then would get 8 chapters all at once.  It was fine, though.  Reviewing was a much quicker and easier process than the writing itself; even on chapters that I hadn't looked at in months, it was always really simple to figure out what needed to happen.

I found that moving from full-on writing mode to editing mode was surprisingly difficult.  I had gotten so used to months of constant writing... it used to be that, any time I had any free time at all, I would think, "Oooh, I should try to fit in another section!"  Once that was done, I would realize that I had some free time, then just sort of sit down and say, "Soooooo.... what should I do with myself?"  This is when I picked up HalfLife 2 and started playing games again after an incredibly long wait.

I particularly enjoyed the copy-editing process.  I'm an English Lit major, and have a sick enjoyment for copy editing myself... I need to be careful when other people ask me to edit their stuff, because some people can be irritated at the things I'll comment on.  ("Don't use passive voice here... don't end a sentence with a preposition...")  Anyways, almost all of the copy-edits were clear and good and made things feel tighter and sound better.  One of the most rewarding aspects of this process was identifying some gaps in my own skillset.  I've been writing and editing for my entire life, but I've never taken a real, former grammar class.  In a way, I've mainly been skating along by reading a TON and then editing so things sound right.  But in some cases, things that sound right to me aren't actually right.  The biggest example I saw here was something that I apparently do a lot: place adverbs after verbs.  For example, I would say, "I went to the store quickly," or "They kissed passionately."  My editors, though, would change it to read "I quickly went to the store" or "They passionately kissed."  (NOTE: Sentences are for illustrative purposes only.  No kissing occurs within this book.)  Now, when I read those sentences, they sounds just as good to me, but now that I know the latter is preferred, I can try to be on my guard and catch myself when I make that mistake clumsily... or rather, when I clumsily make that mistake.  :-)

The last few weeks have, honestly, just been all fun.  I've reviewed the galley proofs, written the acknowledgments and introduction, signed up for my Amazon author page, and started talking with Apress about marketing the book.  I decided to splurge and hire an actual photographer (a friend of a friend) for an author photo.  I can't wait for the moment when I first see the book on an actual bookshelf.

The whole journey has been incredibly fun.  That said, now that I've been through it once, there are definitely some things that I'll do differently the next time (assuming that there is a next time).

First and foremost, I want to take more time on it.  Like I said above, the speed was one of the most exhilarating parts of the whole process.  However, because I was so eager to get the words down and send them off, I did only a cursory editing pass between writing and submission.  My reasoning was sound: I wasn't sure how much the structure of the book would change during the course of initial editing, and I didn't want to take a lot of extra time on fine-tuning passages that might be drastically restructured or rewritten anyways.  Since I knew that there would be multiple editing stages, both over technical and over grammar contents, I'd have plenty of time to tinker with them.

Now that I've been through the full process, I know that that isn't necessarily the case.  Yes, there are multiple editing passes, but not as many as I'd thought - with Ray's book, I had tech-reviewed each chapter twice, with the second pass basically just double-checking Ray's corrections.  For this project, there was just a single technical reviewing phase.  (The second would have been the perfect time for me to revisit the flow of the chapters, once the technical content was locked but before copyediting started.)  Additionally, even though I might go for weeks without getting any chapters, when things did come in for review I needed to turn them around very quickly.  I had enough time to respond to all the specific edits I got, but not enough to strongly rework things as I would have liked.  With copyediting, again, I had expected to get another editing pass to make final adjustments, but it turned out that we just had the one.

The end result of all this was that, once I got the final galley proofs, I was still finding stuff that I wasn't happy with.  Unfortunately, that's the worst time in the whole process to make any changes; here, the design of the book is pretty much locked into formatted PDF files, and any changes are difficult and expensive to make.  As a result, I'm limited to 10 corrections per chapter.  Most of these ended up going to genuine production corrections (mis-set type, altered diagrams, formatting issues).  I did get to fix all the genuine typos I found that had made it through, but if it wasn't for the limit of 10, there would be fewer things in the final book that make me wince.  (Nothing TOO bad, but some things I just don't like to do, like repeat a word twice in consecutive sentences, or use passive voice, or over-use semicolons.)  None of this is Apress's fault, of course, just my own.  Now that I've been through this and seen how it works, I'll probably slow down on the initial writing portion of the book and build in time for a more thorough edit.  It turned out that the technical and copyediting reviews didn't make any sweeping changes to the book, just adjustments, so I shouldn't need to worry too much about sinking time in there unnecessarily.

That said, doing this quickly definitely had its advantages.  We were originally planning for a final first draft in mid-November, with a publication date sometime in February 2010.  Because the drafts were done so early, Apress was able to move up the date and publish in November.  That's pretty huge, for everyone involved.  On my end, that means that I can finish the writing process earlier, relax a little, and start working on future projects.  For Apress, they get to go to market at around the same time as the Beginning BlackBerry book, which should help sales for both titles, and may get a bit of a boost over the winter holidays.  And, of course, their in-house editors can focus on future books as well.

It was also interesting to see exactly how the monetary aspect of this all works.  I'm definitely not going to be able to do this full-time, and if you divide my total funds received by the number of hours that I've spent on the book, it has been a very unlucrative endeavor.  But, again, it's fun, it's something that fits nicely into my commute time and weekends, and it's hard to argue against a pursuit that strengthens my technical skills while providing a little extra cash.  Anyways, the way it works is, you get both an advance and royalties.  The term "Advance" is a bit of a misnomer.  Unlike, say, the advance for a new novel, which might allow an author to spend months writing without needing to find work, this advance is paid in arrears.  As such, it's more like a standard work-for-hire agreement than a forward-looking or speculative investment.  You are paid one-third after Apress approves the first three chapters; this lets them check out your bona fides, see that you actually can produce on a schedule, and make sure that you're producing quality work.  The next third is paid once the book is about two-thirds done, which I guess is more of a check-in.  The remainder of the advance is paid after the book is entirely complete, including all the edits, corrections, source code submission, and so forth.  That helps ensure that authors stay engaged through the process and don't drop out once the draft is done.

In my case, it went somewhat differently.  I actually did want to use the advance as an advance, at least in part: I used the money I was expecting from my first payment to buy a personal BlackBerry and sign up for a BlackBerry Internet Service (BIS) account with T-Mobile (they have awesome month-to-month prepay contracts available, provided you call them directly).  I also created a personal account for the BlackBerry developer program and ordered a personal set of code signing keys.  (There are tons of BlackBerry devices and keys at my office, but I was careful throughout the process to keep the two separate.)  This wasn't a huge investment, but altogether it came to many hundred dollars during the project.  Anyways, I finished the first three chapters ahead of schedule, and my editor approved the first advance payment in August.  However, due to an increasingly bewildering series of setbacks, I didn't actually receive any funds from Apress until November, when the book was virtually done.  Apparently they have switched their back-office to New York - you can find some chatter from other authors online if you look around - and... actually, I don't even want to speculate what the issue is, because I just don't know.  Anyways, they finally sorted it out, and I'm hoping that I'll receive the remainder of my advance before too much longer.

Even though the advance is paid out differently, it still works similarly to a traditional book contract in other respects.  I'll receive a fraction of the price for every book that is sold.  Obviously, I don't have a lot of exposure to the industry, but I think their contract is extremely fair.  The share that you get is based on the number of copies that sell within each accounting period, so the better the book does, the more you are rewarded.  The amount that the share is calculated from is derived from the Apress profit, not the list price or the sale price, so books that were sold at a wholesale discount won't generate as much revenue for you.  There are also provisions for electronic book sales, subscriptions, and other new-media-type purchases.  All of these get counted up each quarter, and they calculate your share.  The share is used to pay back the advance, so I'm not expecting to see any royalty money soon.  Once the advance is paid off, future royalties accrue to you.

I'm curious to see how the book does financially.  Mobile software development is a niche category in the software industry (albeit a dramatically growing niche, thanks to the success of the iPhone), and BlackBerry development is a particular region within the niche, so I'm sure that the book won't do gangbusters.  Still, since I'll get to see the sales figures for the books, it'll be really interesting to figure out just how many people are getting their hands on my words.

Now we're heading into the marketing phase for the book.  I don't have anything particular planned; if we'd published a month or so earlier, I might have explored doing something for the BlackBerry Developer conference, and depending on how things work out, I might try to attend it next year.  (There are several other conferences that are peripherally related, like Java ONE, Mobile Developer Days, and so on... I'm not planning on doing anything with those, but we'll see what happens.)  Oh, and I'm also starting to write some more articles on mobile development; I enjoy doing that, and it's been a while since I have.  Other than that, it will largely be in Apress's corner.

So, yeah.  It's been incredibly fun!  I've loved the journey.  I've learned a lot, and know that I'll do some things differently the next time around, but mainly I'm just very excited to have had this opportunity.  Excelsior!