Ad

Our DNA is written in Swift
Jump

Writing a Book

A couple of months ago a publisher contacted me about writing a book. I have written a lot in my lifetime, blogging in general on my German-language personal blog and later on my Cocoa development blog Cocoanetics. But of course I’ve never written something spanning more than a couple of pages.

Like everybody who likes to write I’ve toyed with the idea, but not knowing about what is involved in creating a technical book I shied away from it. I was assuming that all those book authors have to take time off their normal jobs for writing. I couldn’t imagine exclusively writing for 6 months and not having time for my regular development interests.

But then there was this contact who took the time to walk me through the initial steps toward my first book contract.

I’d like to write down what I think I understood so far about the process. I found that this is a good way for me to process new events. Also maybe somebody else finds it interesting considering also authoring a book.

Book Size

There appear to be two kinds of technical books, full-size and half-size. Full size books are between 400 and 600 pages, half size 200 to 300. It seems to me that most technical books are half size, unless they are about a whole framework or technology, like Core Audio.

My publisher was looking for a half size offering. Being full off … ideas, I was able to present 3 suggestions for topics that I felt would make for a nice half size book. All of this we discussed over the phone. He asked me which of these ideas I preferred and so I went with my favorite, though I am keeping the other two stored away at the back of my head.

Filling that many pages seems daunting at first. I did have a relatively clear idea what kind of content would fit with my chosen topic, but I had to structure them somehow. So I draw a 1-page mind map of the book. Sorry for not including a screenshot here, but I don’t want to discuss the book on my blog until it is well under way.

Proposal Review

Out of my mind map I furnished a Table of Contents (TOC) and wrote a 2-page book proposal.

Such a book proposal consists of these questions which you should answer with a couple of sentences each:

  1. Proposed Book Title
  2. About the Author(s)
  3. Proposal Summary
  4. About the Topic
  5. Book Description
  6. Competing or Comparable Sources
  7. Readers/Market
  8. Book Size and Illustrations
  9. Tentative Table of Contents with Annotations
  10. Contact Information

It is basically a formalized pitch. The tentative TOC I created in Pages based on my mind map which showed the main chapters already. The Book Size and Illustrations are supposed to be estimates for the number of published pages, the number of figures and the number of code listings.

Publishers probably receive a large number of such proposals and to find out the ones that show the most promises they send out the proposal plus TOC to around 10 people from the tech industry who are supposed to review the proposal and give feedback.

Of those 10 reviewers 8 returned the questionnaire and I got to read these as well. It was fun to see a few people amongst the viewers that I had had a passing encounter on Twitter before. All these reviews where generally very favorable, with only one being slightly critical about the scope of one chapter I had proposed.

Revising the Table of Contents

My proposal TOC did have all names of Apple Frameworks underlined because I figured that somebody looking at the TOC might get a feeling that there was more interesting content if it was clear which section to turn to for specific technologies.

The person dealing with me in lieu of the publisher was a so-called Acquisitions Editor aka Commissioing Editor. That’s the job title for somebody whose job it is to find authors and find proposals that make sense for the portfolio of the publisher.

Though at the time I didn’t know that those where not one and the same. So it came to me as a surprise when this person told me that he needed a revised TOC to present to the publisher. He told me that I should remove all references to Apple frameworks or names of technology because the publisher wouldn’t understand those.

So I produced a first revision 1.1 according to his wishes. Another big difference was that I was asked to follow a certain structure for each chapter.

  1. Chapter Intro
  2. Example Intro
  3. Example Walkthrough
  4. Explain Example
  5. Other Related Info
  6. Chapter Summary

So basically each chapter was supposed to be a sample app with the sections following the above pattern. I let myself be guided by this, since I am thankful for any kind of guidance I could get been a novice. But to make it sound a bit more interesting I had to put a personal touch on it and invented some very fancy section titles.

Generally a book is structured in Parts, Chapters and Sections. A half size book probably can do without parts that group multiple chapters. My proposal TOC had had 5 chapters with the last one being multiple app examples. With the examples now being elevated to being center pieces for the individual chapters I eliminated this extra chapter, and so version 1.1. had only 4 chapters with the last one having two examples.

A while later I heard back, it went well, but there was some critique related to my creative section titles. Also a second revision of the TOC was asked for, this time re-adding the names of Apple Frameworks. So my initial hunch was correct that people would want to see these in an iOS-themed tech book.

On the phone we went through the TOC one more time, cleaning it up further. My original structure was resting on the general pillars Intro, Input, Output, Interpreting and Examples. I was somewhat in love with that, mostly because it was my own idea. But it is dangerous in become too infatuated with your own ideas.

So I finally gave in to, added a new chapter on an additional Apple technology which is very prominent of late. And I broke up the fourth chapter in two. Admittedly this rounded off the TOC very well, resulting in 6 chapters of about equal size.

Version 1.2 of the TOC went back to the publisher and then nothing happened for a month. When I inquired it turned out that my email had gotten lost. This teaches us novice authors that you should never assume that the ball is out of your court. If you don’t hear back for too long it does not hurt to send of an email asking why there was no response.

Book Contract Preproduction

A short while afterwards I received the coveted response, the subject title beginning with “Contract Offer: <Your Book Title>”

At this point there is still some more planning work necessary. In order to furnish a contract the publisher requested that I provide:

  1. Contact Info
  2. Estimated Page count and number of figures
  3. Estimated Milestone Dates for:
    • TOC
    • Writing Sample
    • Chapter 1
    • 1/3 Milestone
    • 2/3 Milestone
    • 3/3 Milestone

When I asked why there was so much obsession on the TOC the editor told me that a good one makes a world of difference on the quality of the outcome. Especially on technical books the TOC probably also changes slightly as you start working on the actual text content. But having a general map in place gives you a feeling of structure to plug stuff into, as opposed to floating in thin air.

While being somewhat tedious and boring I found the first benefit of having spent some thought on it that it allowed me to do a good estimate for the page count and number of figures. I just copied my TOC into Numbers and distributed the initial estimate on the sections. Sections like a summary would not get any illustrations and very few pages. Other sections giving an introduction to a necessary Apple framework would get many more pages and also more illustrations.

Again I was very thankful for the guidance I got, estimating about 30 pages per chapter and about 5 figures per chapter. You can have even more figures for something dealing with visual content. Source code listing counts as text, not figures.

The writing sample typically is a 10-page section that you pick out with a professional editor that it maybe a bit harder than other sections. I don’t yet know the actual purpose except to prime a newbie author on how to approach the writing in terms of style and work flow.

The next thing was one that I had the most reservations about: How much time should I plan for finishing those mile stones?

Show me the Money!

In the experience of the editor writing a book is doable next to a full time day job. Most authors, once they get going, can turn a new chapter every 2-3 weeks next to their full time day job.

I’m self-employed and since I feel passionate about this book I am pretty sure that I will be devoting enough time on the book to get it done. So I put down the final milestone about 4 months in the future, adding some buffer for the first few items so that I have room to “get up to speed”.

From what I learned in the process you cannot live off the royalties of your first book. It all depends of how many copies it will be selling, you don’t generally get paid for the writing itself. Rather you receive 10% royalties on the book price. That is for paper books, purely electronic versions can pay higher percentages. But in my case I definitely want my first book to be published in paper form.

The standard for the first edition of a new book is 10% royalties with a $2,500 advance. Of this half is paid at the 1/3 milestone, the remainder when the book goes into final production.

Hopefully the book sells really well, but if it doesn’t then the advance is all you get. Let’s say I work 3 weeks for each of the 6 chapters, 20 hours per week. That are 360 hours for which you receive no less than $2,500. This calculates to about $7 per hour, less than a tenth of what I am making if I am doing iOS development consulting.

I will definitely not get rich from this, but I’ll nevertheless do it. My economic circumstances of the next few months will allow me to carve of enough time each week to progress on the book. And the final reward – being a published author – is something that excites me a lot.

Conclusion

I happen to have a topic that I am passionate about these days and so it was an incredible stroke of luck to be contacted by somebody who would want to contract me to write a book on this topic.

You cannot hope to earn a lot of royalties from a single book, but – in contrast to my previous fears – writing a book is actually achievable even next to having to work for your money. As a general rule book authors have a full time day job next to writing. So if you think about writing a book you have to be able to find the time next too your livelihood to push forward your writing.

Those are the facts as I see them at this point before my actual journey has even begun. I’m interested to hear from my book-writing colleagues where they had experiences that differ from what I described.


Categories: Q&A

11 Comments »

  1. All the best with your new venture Oliver!

  2. I wrote “Blender Foundation Compositing” a few years ago. It did not pay any bills, but helped me land jobs as it brings a ton of street cred.