Tag Archives: writing

Writing a Book

One day I’ll write another book. Perhaps a sports book about people and their stories, or the story of search engines and the people that build them.

I wrote my first book in 2001 with David Lane, and we rewrote it in 2003 for the second edition. I wrote another book with Saied Tahaghoghi in 2004 – the truth is I started it, and he picked up the pieces when I changed careers and countries; he’s a good man. The first book sold over 100,000 copies over the two editions (I still get a royalty check quarterly) and the second modestly (Saied and I earned our advance back). They’re both dated, old books now.

Web Database Applications with PHP and MySQL. My first book in its second English edition.

Web Database Applications with PHP and MySQL. My first book in its second English edition.

It’s thousands of hours of work to write a book. I spent at least 20 hours per week for 18 months on the first edition of the first book – that’s 1500 hours at least. I got out of bed at 5:30am and I did a few hours of writing before work. I’d also squeeze in a little more after work (typically some proof reading), and a longer period of writing on the weekend (where I’d still get out of bed at 5:30am).

Did I get rich? No. Typically, the authors get less than 10% of the wholesale book price — a couple of dollars per book sold at most. I got more than the minimum wage for the first book (roughly dividing the royalties by the number of hours by the number of authors to get an answer). The second book didn’t pay its way.

The longer I worked in a single sitting, the more productive I was. It takes a certain fixed amount of startup time to begin writing – you reread what you’ve written, edit it a little, get the context back, think about the structure of what you want to say next, and then start writing anew. But I can’t write for an extended period – it’s tiring, and I need to stop and take time away to think about what I want to do next. Three or four hour stints are the most productive for me.

When I wrote the first book, I’d count how many words I wrote in a session, and use that as a measure of success. I’d decide that I was going to write 1000 words before I took a break. It turns out, that doesn’t work for me: I’ve learnt that what’s important is sustained output, averaged over a month or so. Some days, I’ve got writer’s block. But I’ve learnt that that’s when I am doing valuable thinking – I’m working through a larger problem, or thinking through structure, or solving something that’s been bugging me for a while; sometimes, this is a subconscious activity. Other days, I’m a machine: I write as fast as I can type, and thousands of words flow. A whole chapter has been known to flow after a writer’s block.

My second book, Learning MySQL in its one-and-only edition.

My second book, Learning MySQL in its one-and-only edition.

Writing slows down as the book takes shape. I’ll be in the middle of a new section, and I’ll want to reference something else I wrote using something like “as you learned in Chapter <x>, the <something>”. Then I have to figure out what chapter it was, and what exactly was that <something> – that takes time. And, as the book gets longer, you repeat yourself – at least, my memory isn’t amazing enough to make sure I only say the same thing once. I’ll find myself waxing lyrical about some great idea, only to discover that it is somewhere else in the book too. Then it’s a case of figuring out where it should be – which is going to lead to editing a was-finished chapter elsewhere in the book or rethinking what I’m writing today.

I worked with a major publisher, O’Reilly Media Inc., and the wonderful editorial skills of Andy Oram helped me on both books. Editors are awesome – they push, prod, ask questions, push for clarity, and say things that make your book better. But they create a ton of work – you’ll get feedback such as “Perhaps you could merge those two chapters?” or “Chapter 4 needs to be broken into two chapters, and you need to really go into much more depth”. That often happens after you think you’re finished. You’ll get asked for extra chapters, rewrites, more or less content, and complete changes in style. It makes your book better. Between the first edition and second edition of my first book, Andy helped me change my style from a formal computer science style to a more conversational, chatty style – the kind that I use in this blog.

Writing a book isn’t a social experience. You need to enjoy being alone with your thoughts. Prepare for one hour of inspiration and conversation to turn into a hundred hours of hard labor and iteration. If it takes a couple of thousand hours to write a book, ten of them are the inspirational ones where you create the fundamental ideas. I wrote much of the second book in my parent’s Winnebago – parked on the grass, a good distance from the house, deliberately without wifi, and with nothing inside to distract me.

So, why do it? I enjoy writing – there’s rewarding impact in sharing knowledge with thousands of people. If you’re lucky, someone’s success or their impact will be because of what you shared. Or maybe you change how someone thinks or sees the world. Or you make their life better. It’s also cool to see your name on the cover, and to feel it in your hands – it’s even cooler when it’s translated into a language you don’t understand. I wonder what joy there is in knowing people are reading a digital copy? The digital sales on the royalty statement have never quite inspired me the same way.

Have fun. See you soon.

Five tips for Writing a Presentation

I’ve had hundreds of chances to experiment with presentations, through teaching, invited talks, and day-to-day presentations at work. If there’s a mistake you can make in delivering a presentation, I’ve made it. Today, I’ll share with you the top five things I’ve learnt along the way — hopefully, they’ll help you write a great talk!

One major point

You’ve been asked to give a presentation that’s less than an hour in length. My advice: deliver one major theme or point to the audience – you want them to leave unambiguously ready to understand, believe, act, or follow the point you’ve made.

Don’t share two or more major points. The audience will leave with different key takeaways. Or, worse still, you’ll confuse the audience or seem rushed in your delivery. And you usually won’t land that key message that you want the audience to act on or evangelize for you.

What is a major point or theme? It depends on the length of the talk. If I was speaking for an hour, I’d design a talk that lands a broader theme than if I was speaking for fifteen minutes. For example, in an hour I might land “how to deliver a great presentation”. If I was speaking for fifteen minutes, I might land “tips for verbal presentations”.

What if you have to speak on two topics in one session? For example, your boss wants you to present to her boss on two topics next week. Write two talks: start and finish the first, change decks, and start and finish the second. Consider having question time between the two. Pretend you’re two different speakers coming up to the podium.

One slide every two minutes

Rule of thumb: one slide for every two minutes of presentation. A one hour talk, thirty slides maximum. A fifteen minute presentation, seven slides. Really.

If you fly through slides, you’ll seem rushed. If you stay on one slide, you’ll kill the audience with boredom.

If I’m speaking for an hour, I restrict myself to thirty slides maximum — I’m always tempted to have more, and every time I do I regret it. If anything, err on the side of caution: I’ve given a few one hour talks with twenty or fewer slides, and it’s worked out fine.

Keep the slides simple

A slide with the right amount of content

A slide with close to the maximum amount of content. I’ve delivered this one a few times, and it’s hard to get through it in two minutes.

I like to have four to six lines of text on a PowerPoint slide. I try to avoid sub-bullets. I definitely wouldn’t have more than eight lines of text; I know when I reach eight that I’ve got two slides of content.

I dislike quadrant slides, they’re too complex for a presentation. I dislike two-content slides too — the ones that have text on the left and an image on the right (or vice-versa). If I want to include an image, I typically make it the feature of the slide and accompany it with at most two lines of text above or below the image.

Signpost the structure

I include the following signposts in most talks I deliver:

  • A title slide, with talk title, my name, company, and contact information

    An example title slide with talk title, my name, company  and contact information

    An example title slide with talk title, my name, company and contact information

  • An overview slide that explains the structure of the talk to the audience; that way, they know what to expect, it helps them to know when to ask questions and what’s going to be explained

    An overview slide. Usually the second slide in my presentations, and there to outline the structure of the talk

    An overview slide. Usually the second slide in my presentations, and there to outline the structure of the talk

  • An occasional subsection slide that shows we’ve arrived at a major section in the talk

    A subsection slide that explains where we are in the talk structure. I'll typically include two or three of these in a longer talk, and they'll reference back to the overview slide

    A subsection slide that explains where we are in the talk structure. I’ll typically include two or three of these in a longer talk, and they’ll reference back to the overview slide

  • (Sometimes) A concluding slide that contains the key points from the presentation
  • A subsection slide that includes the phrase “Questions?” or “Q&A?”

    A final slide asking for questions (and doing a little advertising)

    A final slide asking for questions (and doing a little advertising)

I count these slides in my “two minutes per slide” rule; these don’t come as free extras.

Be careful with the colors, design, transitions, and builds

When you’ve got Microsoft’s Powerpoint as your tool (or something fancy such as prezi), it’s tempting to include lots of slide builds, transitions, zooming, and animation. Resist. These are very often a distraction — and can lead to your audience thinking you’re more about style than substance.

I particularly dislike builds. Why? Because it looks like you’re hiding something, and it doesn’t give the audience the chance to read, understand, and put what you’re saying in context.


I was fortunate to work with Justin Zobel for many years, and developed my early presentation style with his coaching. His book is worth the money — highly recommended for anyone who needs to write and present in the field of IT or computer science.

See you next week.