ARTICLE

The experiences of a technical author

by | Wed 22 Nov 2006

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!

An invitation-only accelerator that develops industry-leading community engagement and growth via personalized training, coaching, and accountability...all tailored to your company's needs.

Want to read some more?

Happy Holidays

Happy Holidays

Just a quick note to wish all of you a happy, restful, and peaceful holidays, however and whoever you spend it with. Take care, folks, and I look forward to seeing you in 2015!

The Impact of One Person

The Impact of One Person

I am 35 years old and *people* never cease to surprise me. My trip home from Los Angeles today was a good example of this. It was a tortuous affair that should have been a quick hop from LA to Oakland, popping on BArt, and then getting home for a cup of tea and an...

Feedback Requested: Great Examples of Community

Feedback Requested: Great Examples of Community

Folks, I need to ask for some help. Like many, I have some go-to examples of great communities. This includes Wikipedia, OpenStreetmap, Ubuntu, Debian, Linux, and others. Many of these are software related, many of them are Open Source. I would like to ask your...

Ubuntu Governance Reboot: Five Proposals

Ubuntu Governance Reboot: Five Proposals

Sorry, this is *long*, but hang in there. A little while back I wrote [a blog post](https://archivedblog.jonobacon.com/2014/11/14/ubuntu-governance-reboot/) that seemed to inspire some people and ruffle the feathers of some others. It was designed as a...

Ubuntu Governance: Reboot?

Ubuntu Governance: Reboot?

For many years Ubuntu has had a comprehensive governance structure. At the top of the tree are the Community Council (community policy) and the Technical Board (technical policy). Below those boards are sub-councils such as the IRC, Forum, and LoCo councils, and...

Dealing With Disrespect: The Video

Dealing With Disrespect: The Video

A while back I wrote and released a free e-book called [Dealing With Disrespect](https://www.dealingwithdisrespect.com/). It is a book that provides a short, simple to read, free guide for handling personalized, mean-spirited, disrespectful, and in some cases,...