Books.w3clubs.com

Web dev book reviews and interviews

 

What to expect when you’re expecting… to write a computer book

computer book

I was IM-ing with a future book writer today (no names, don't want to jinx them) sharing some wisdom about the writing process. I don't really like very much telling people what to do and how to live their lives, but I thought I should capture some of that here. After all I have a few computer book titles behind my back (and the scars to prove it) so I guess that makes me as qualified as it gets.

Money/Rewards

If you want to write a book and become rich... well, try writing a book on a topic to the likes of: how to achieve happiness, relieve debt, lose weight, manage people, manage successful projects, sell crap, make friends... you get the point. Oh yes, a book on how to become rich by writing books will also have a fair chance. Anything that a tired business traveler will pick up at the airport while waiting for their delayed flight and munching their junk food.

Anyway, the point is, it's almost unthinkable to leave your day job and live off by writing computer books. If you don't trust me, head over to Doug Crockford's blog, one of the top JavaScript professionals today, whose book is #1 (Amazon sales rank) in the broad category "JavaScript". Check out his royalties. Writing anything more niche than JavaScript and you're doomed. Or be someone less famous than Doug. Or be #2 sales rank in your category.

That doesn't man that writing a book is not rewarding... it is, but not in the monetary department. It's good for your career, it teaches you discipline (it's a marathon, not a sprint), it helps you understand your topic even better (learning by teaching), it will make it easier for you to get invited to speak at conferences...

How much time is involved?

When writing my last book I was trying to answer this question and came up with some figures, a little on the optimistic side.

Now, this is a creative process and sometimes it may take hours with nothing show for it, in terms of page count. You make a plan, you work on the outline, you structure and restructure your chapter's content, you research, you experiment, you write code for the examples. There's really no way to tell how much time this takes. But once this part is done and you have a clear idea what to write (including your headings), then it's only pure work. OK, how long?

I came up with this simplified formula:

1 page =  1 hour (writing first draft) + 1 and 1/2 hours editing.

Some comments:

  • Writing first draft includes no editing, I mean none, not even reading what you write. It's very important to let it out, however clumsy and grammatically incorrect. If you edit while you write, it will be way harder. Resist that urge.
  • There's no limit to how much time editing can take. You have to put an end to it at some point. More or less arbitrary. A picture is never finished. So is a chapter. Let others (your editor and reviewers) have their say before you go crazy tweaking indefinitelly.
  • Disclaimer: English is my third language, so I may be way off :)

Book length

I mentioned Doug Crockford's JavaScript book already. One of the things I like about it is that it's short - exactly 100 pages excluding appendices. I'm a strong believer that the days of those huge Java books are over. Be short. This increases the chance of someone actually reading.

Another bummer is that computer books are pricey. And when people part with $40 for a book they might be tempted to buy the 700 pages book and not the 200 pages one. More pages theoretically increases the chance that there's something between the covers that will make you smarter (and sexier). That's wrong and everyone who has bought a huge book and never read it will reconsider buying the next huge volume.

So what length can you expect? I'd say aim for 100-150 pages (almost impossible) so you don't end up a lot over 200-250.

Back to the time estimates

200 pages that each take 2 and a half hours per page gives you 500 hours. That's 62.5 8-hour workdays. But you also have a day job, right? Let's assume you write from 8 pm to 2 am every night and a little more on the weekends. That's a crazy schedule, I know. Watching movies? Yeah right, fahget-a-bouutit. BTW, editing while commuting using public transportation definitely helps the schedule.

So if you somehow manage to put 8 hours of effort every single day, it will take you a little over two months. Or 3 moths if you decide to nap over the weekends and work only 20 days a month. Remember, that's just writing, after all the thinking and coding is behind you. And excludes any communication, emails with editor, reviewers feedback, etc. Now think about a 500 pages book? As a reference when adding all this... my last book took me a year.

Huge effort, isn't it? That's why I have nothing but respect for anyone who has written a computer book. True, there's a lot of crappy computer books, but let's forget about them for a bit. If you meet an author... pat them on the back, they deserve it.

Tips?

Writing is hard, it takes insane amount of time and pays under the minimum wage. But it's worth doing. At least once. So ... tips to help you survive and maintain some form of sanity.

  • Let me repeat about the first draft. Absolutely no editing during the first draft. First draft is where you will get stuck if you start paying attention to what you write. Don't read. Write. Let it out.
  • Have a chapter outline first, including the headings. Heading break down the text. They make the text easier to read. And easier to write. Divide and conquer. Once you split up the little topics and points you want to make, then the writing becomes merely filling in the blanks. Aim for at least 1 heading per page. 3 per two pages.
  • You want to do a good job so you'll find yourself reading posts like this one with hints on how to write. BTW, there's an excellent blog about computer books by David Barnes of Packt Publishing. Check these out, pick some words of wisdom that make sense to you... all that before you start writing. Once you start writing don't interrupt it in order to read on how to write. That leads to editing. Don't edit when you write.
  • "Write to please just one person. If you open a window and make love to the world, so to speak, your story will get pneumonia." Kurt Vonnegut
  • Motivation. Be passionate about the topic. If you're not passionate, when the hard times come, you'll just give in to desperation and start missing deadlines and it's all downhill from there.
  • Consider a co-author. Or two. Then the 300 pages of effort become 100. And if you sit down over the weekend and work hard you can have 20 pages first draft. Which is already a fifth of the whole book. Not bad.

Good luck!

And once your book is out, send it to me to post a review on this blog ;)

Wrox

Homepage: http://www.wrox.com/

Books reviewed on books.w3clubs.com:

Jaimie Sirovich

Homepage: http://www.seoegghead.com/

Books reviewed on books.w3clubs.com:

Cristian Darie

Homepage: http://www.cristiandarie.ro/

Books reviewed on books.w3clubs.com:

Search Engine Optimization with PHP

"Make Money with SEO", "Be #1 in Google SEPR", "SEO riches", "Google's best kept secret", "High Rankings, Fast!"... this could go on and on. There are an abundance of infomercial-type sites and ebooks out there promising you SEO miracles, as if there's some mystical secret to success and you can learn it today for just $79.99 and be rich tomorrow morning. Luckily, "SEO with PHP" is not one of these books.

Search Engine Optimization is not an exact science (some even dare say it's an art), because search engines don't want to disclose all their algorithms and open themselves for abuse. This fuzzy definition of the SEO area helps con artists step up and promise you wonders. And people buy into these, because people want these wonders to be true. The same way people buy into the next fad diet out there that reveals "the secret". The truth is, there is no secret, everything is pretty simple (don't eat crap, move more), but requires your attention for a little more than a day or two. The same with SEO, there are no secret shortcuts, just some concepts to have in mind when building a website and some amount of work you need to do. True, sometimes you might achieve temporary results by tricking the search engines (or your body) but those tricks will work against you in the long run.

Search engine optimization consists of a number of rules and best practices that every site should follow and implement, such as SE-friendly URLs, keywords, headings, titles, etc. "SEO with PHP" gives you a comprehensive overview of the rules and the ways to implement those rules. I think every developer who cares about his work should know about the core SEO concepts and keep them in mind while coding a website. This book is the right guide, if you're new to SEO or you don't have systematic knowledge. The book's main audience is developers, as there are quite a few code examples, server setup and so on, but it can also be read by non-technical folks - business people and designers, who can simply skip the code parts.

Important topics you'll master after reading this book include:

  • how search engines "see" your page
  • page rank
  • internal in-page as well as external factors that help your page rank
  • keyword research
  • link bait
  • friendly URLs, including server setup
  • duplicate content and how to avoid
  • black hat SEO and how to stay away and protect from it
  • building sitemaps to "feed" content to the engines
  • geo-targeting
  • SE-friendly JavaScript/Ajax/HTML

A nice touch is the last chapter which shows you an approach to making your SE-friendly WordPress blog. WordPress as a pretty popular tool that many people are familiar with, so instead of making up a site, the book puts the concepts into practice by using an example that is close to most readers. Another "extra" is the regular expression appendix that can teach you to be really creative with the URL rewrites, although the book has enough examples of friendly URL rewrites to get you started.

The beauty of the true SEO is that it's not counter-intuitive, it's not about stuffing a bunch of keywords colored as the background or tricking the engines with meta tags. The true SEO overlaps with human-friendliness (design for human visitors while keeping search engine robots in mind"), accessibility (e.g. providing an HTML only version of a complex interactive JavaScript site), standards-compliance (e.g. using CSS for layout, not tables) and even page-load performance.

More about the book

Buy the book