The experiences of a technical author

You know, jet lag sucks. Jet lag combined with ill health sucks even more. As such, I woke at 4.30am this morning, wide awake. I headed into our company IRC channel and got chatting to some others about writing books. It struck me that this kind of discussion could be useful to others, so I figured I would totally blog about it (said in tacky American accent).

Writing is a funny old game. These days it seems every man and his dog have a book deal, and at pretty much every conference I go to, people are talking about getting their chapters in on time. This is understandable. Writing a book says something about you – it demonstrates an astute knowledge, a drive and an ability to convert complex concepts and subjects into a language that others can understand. Not only that, writing a book shows how you can organise and structure your thoughts effectively. Eloquent those reasons may be, they are not why people write books. People write books for ego. They write books because writing a book has a lot of wow factor, and that wow factor wins jobs and the admiration of others.

People certainly don’t write computer books for money. The money involved in writing is pretty abysmal. An average computer book will net you between $5000 and $10,000 in an advance payment, with some kind of royalty agreement when that advance has been earned. This requires a certain amount of books to be shipped, and with the computer book market struggling, you cannot guarantee that you will make lots of money from royalties. Th equivalent amount of work for the freelance magazine trade can net you two or three times as much money. This is why so many people write one or two books and then stop. They typically stop due to money reasons as well as the sheer workload involved in writing a book.

Getting a book contract various hugely between different people. There are hundreds of publishers out there, and while some publishers are very cautious about who they take on, some publishers will take on just about anyone. There are two approaches to selling books here, and most publishers take one of these two approaches. One method is to take on a limited number of high quality authors and projects, spend lots of time working on them, and spend lots of money in the reseller channel and marketing them. The books are higher quality and better marketed, but there are fewer products to tempt people with. This requires larger unit sales per book for it to be a success. This deal here is usually a large advance and smaller royalties. The other method is take on a huge number of projects with less established authors and sell fewer copies of each book with more limited marketing applied to each book. The deal here is typically a lower advance but very high royalties – you make your money if it sells. The problem with the latter approach is that there is a higher possibility of failure when it comes to these projects as the writers are less experienced and less familiar with just what is involved in writing a book. The upside of the latter approach is that those publishers are often more diverse in the subjects they cover.

Getting the contract is different for everyone, so let me outline my own experience. When I was at university, I used to do lots of uni work during the days and lots of drinking, partying and coding in the evenings. I used to go out to the pub or gigs most nights, get back in and then spend every night between the hours of 12 midnight and 7am hacking on KDE software, watching the Paramount Comedy Channel and just doing my own thing. I would then be up for university the following day from midday until 6pm. This demanding lifestyle gave me the benefits of university work (during the day), time with my girlfriend and mates (the evening) and time for my own work (most of the night). Sleep was a 7am – midday thing.

It was in the midnight – 7am period that I started freelancing for computer magazines. I remember going to the Linux Expo in London the first year at university, and I got drunk with the Linux Format guys in a bar near Olympia. It was there that I asked if I could write an article for them and they said “sure, but if it sucks we get to reject it and not pay you anything”. It sounded reasonable to me, so I started writing. After two years or so of writing a huge number of articles for three Linux magazines, a book agency approached me to ask if they could represent me as an author in the book trade. After some conference calls I agreed, and I have been with the same company ever since. If it was not for my crazy life at university, and the large number of articles I wrote in addition to my uni work, I would never have been approached by my agency. My experience is certainly not the same for everyone, but every author needs to prove themselves somewhere before they will be accepted to write a book, particularly if you want to write for a decent publisher who will actually sell a decent amount of units of your book.

Writing a book is hard…really, really hard. I remember when I started my first book, which was a non-starter KDE 2 project for Sams (the book came about when I was doing my final year at University, so never really got very far), I was told by my agent that “Writing a book is one of the hardest things you will do. Everyone expects it will be much easier than it really is, but it will test your time management, technical skill and mental ability to cope with a large writing project”. He was not wrong. Writing a book takes a huge amount of energy, and unlike freelance projects, the huge scope of a book means setting firm deadlines and making sure you hit those deadlines. When I wrote Linux Desktop Hacks, I divided the project length by the number of hacks I needed to write and this gave me a deadline for each hack. I also factored in a one day buffer per hack – this would account for those hacks that required extra time. Each book is different, and requires its own planning. For Practical PHP and MySQL, I divided project length into a bunch of milestones, but each chapter had its own PHP application that needed developing too, so I dedicated one week for coding each app and one week for writing each chapter. The key thing here is that you should always aim to smash your deadlines early. This always gives you more flexibility for crunch time.

Crunch time on a project is when you are nearing a deadline, and everything ramps up a notch. For book projects you will have an editor who looks over your work, and when each chapter is complete it usually goes out to reviewers. Each of these reviewers leave their opinions and comments, as does your editor. Your responsibility is to then fix these issues as soon as possible. At the end of a project, the time allocated for this process is very thin and this can mean huge amounts of extra work to get everything ready. This is particularly relevant for new authors who make a number of common mistakes. As an example, Practical PHP and MySQL was originally going to be an O’Reilly title, but O’Reilly vastly over-commissioned a bunch of books, and mine, like many others got the chop. After my good relationship with Prentice Hall over The Official Ubuntu Book, I took it there. When I originally wrote the content for what is now Practical PHP and MySQL, I wrote it in a very British way, fairly passive with lots of amusing quips and random humour spread throughout the book. This was very different to the largely North American O’Reilly style. As such, as the project continued to develop, large chunks of my content needed rewriting to cater for this style.

This is where a good publishing house really comes in. A good publisher will have very high quality editors working for them, who will help you get the style, tone and organisation of your book right as you write it instead of when you crunch at the end. I have worked with a bunch of different publishers, some of which were shocking when it came to editing. A new author with a good editor can make amazing books. A new author with a bad editor will make heartburn.

I know a bunch of you will have read this blog entry with interest as you are yourself keen to write a computer book. My main intention is to not scare people away from writing books, but to provide some experience of the real world issues when taking on a book project. It is an intense process, often driven by intense people, and it is not for everyone. But, if you like a challenge and you can write, it is an incredibly rewarding process. When you get your first printed copy sent to you, you feel hugely proud of your efforts. If it then sells well, it is even more inspiring. My main interest is in helping prospective authors to see the full picture and be prepared for some of the strangeness in the publishing world. Good luck!

  • Jimbo

    “so I figured I would totally blog about it (said in tacky American accent)”

    Thanks Jono for the blanket generalization of American vernacular. You are like SO lame!

  • jono

    I am sooo not lame! I totally think you guys rock – f**king A!

  • Jimbo

    That was SO not funny :grin:

  • jono

    Oh my god, I can’t believe you said that! You are freaking crazy with your crazy ass totally crazy shit! I need a corn dog to calm me down and then I will pop a cap in your ass.

  • Jimbo

    Welcome to America, Jono … (sniff) … you passed the test homey!

  • jono

    Boo yah!

  • Huygens

    Although I can speak, read, write and understand English, and I use it daily for work, I have to say that the meaning behind the exchange of comments from #1 to #6 is totally Chinese to me. As you say, I cannot make head or tail of it!

  • Spads

    You so totally blogged that.

    (notice, no “about” necessary to truly emulate Cory Doctorow, despite rumors of Canadianism)

  • http://zer0her0.info zer0her0

    I actually read this piece to understand technical writing as a whole. I have a long way to go before I can consider any book deals. I find it interesting to gain insight into how the process works, and more importantly if we can learn anything about it to help the documentation process for FOSS projects, as they so often are clamoring for better documentation.

  • http://advance-payment.pierresccservice.com/the-experiences-of-a-technical-author/ Pierres Service » Blog Archive » The experiences of a technical author

    [...] An average computer book will net you between $5000 and $10000 in an advance payment, with some kind of royalty agreement when that advance has been earned. This requires a certain amount of books to be shipped, and with the computer …Read more: here [...]

  • http://none jimmy

    are there corrections to your book published anywhere on the net?