Ask HN: I'm 23 and got a contract to write my first book, on HTML5, any advice? | Hacker News Reader

Ask HN: I'm 23 and got a contract to write my first book, on HTML5, any advice?

14 pointssimonsarris20 comments

(I asked this a week ago and got very little exposure. I know that discussions on resubmitting Ask/Show topics have been met with wildly different sentiment, but here goes).

I'll be writing a book on HTML5. I signed the contract last week.

I hope for it to be around ~500 pages, give or take, with the largest part being Canvas[1] at ~150 pages. The book will be in full color with syntax highlighting.

I've never written anything of this scale before and certainly never authored a book.

I'm looking to solicit advice in general. Is there anything you'd wish was in an HTML5 book that might not be present in others so far, etc? Do you have any advice for me on the writing process?

I gave my age in case that was relevant, at least to me it seems uncommon for technical books to be written by "young" people. I'm not sure if my age in itself will hinder or help, but its offered in case it changes your advice.

Also, do you have any pet peeves about technical books, or things you wish authors did more or less of?

Thanks for reading!

[1] Canvas is easily the part of HTML5 I'm most knowledgeable about. I've answered about 10% of all questions ever asked for Canvas on StackOverflow (and am top answerer for both the Canvas and HTML5 tag). Many of the usage examples in the Canvas section will be from real world problems that were solved during my time on SO.

I hope for it to be around ~500 pages

Too long.

It takes more work, but try to make it shorter.

The best value I've gotten from books is being able to avoid the slew of occasionally useful factoids and be told what stuff I should really care about.

The endless details I can find on the Web if I need them; the problem a tech author should solve is in helping the reader know what to care about and when.

Not sure if this is still true but I heard some publishers had a minimum pages requirement.

I've written for Wrox (the first edition, the one that went bankrupt :))

When I was one of two co-authors of a book I don't recall being told to hit a specific page count, but there was a push for a certain degree of "thoroughness." This typically meant going into possibly tangential details to avoid sending someone off to another resource. (Though if the other resources was another Wrox book then allowances we made.)

For example, in a book about XML (Pro VB 6 & XML[0]) there was a need to go through the XML specification. A whole chapter. I ended up using this as an opportunity to explain the spec and build some helper libraries that would make interacting with a DOM easier later on, so not a total loss, but it had a feeling of busy-work to me.

That was sort of a best-case scenario; two authors splitting book. I also worked on assorted individual chapters for other books and there I had an incentive to bolster the word count because in some cases it affected the pay.

In my experience writing a single chapter meant either a flat amount or a per-word rate. Writing multiple chapters opened up the option of royalties instead. I took royalties on the VB book and did OK. Sadly this gave me a false impression of tech writing as a profession.

Many Wrox books were more a collection of padded chapters than coherent, well-planned, guides. OTOH I think many people plunked down $40-50 just to get specific chapters that would get them past some problem.

[0]: As the Velvet Underground sang, "Those were different times." :)

Seconded. Read "On Writing Well" -- write something, cut it in half, then cut that in half, and then once again cut that in half.

When writing for publication, I enjoy pondering this quote: "If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it's not going to be fired, it shouldn't be hanging there." From S. Shchukin, Memoirs

That is to say, if you're going to write something, every word has to have potency. This gets at the cut in half, cut in half, cut in half advice.

In short, good writing is concise.

At some techie user group someone had a copy of a pretty brief O'Reilly Rails book. I observed that the book price seemed the same as what O'Reilly charged for "full-length" books.

A friend then said he would be happy to pay even twice as much if the author could have made it half-again as short.

BTW, I could have sworn that quote was from Chekov. Either way, on the money.

Yeah, it's Chekhov's gun: http://en.wikipedia.org/wiki/Chekhov%27s_gun

Yeah, I think it's a variation of the Chekov quote (I pulled it from the chekov's gun's wiki. That was the quote that stuck out to me the most from my classes in Uni).

I've co-authored a couple of tech books, published by Wrox and Apress. I don't think your age matters at all for this kind of thing, I think I got my first deal when I was your age.

The biggest thing to understand that isn't obvious for a first-time author is that as soon as you sign the dotted line, you'll be on the publisher's schedule. They have to plan out when to release and sell your book months in advance.

All of those chapter deadlines are also for the other people involved - tech reviewers, copy editors, production, etc. So if you run late, it squeezes them. I've done tech reviewing for a couple of programming books, and when the author gets behind, the editor pushes the tech reviewer to get the chapter turned around extremely quickly. Guess what that can do to the quality of your book!

Another thing to know is that the "control" of your book is very strange, especially if its successful and the publisher wants 2nd and 3rd editions - check your contract, but they may have the right to assign another author to the book and release an update if you refuse to do the update. What this means in practice is that you end up having to do the update yourself whether you have the time scheduled or not to keep someone else from doing a crummy job updating your book.

Congrats! This is a really cool opportunity.

I would suggest thinking about what kind of a book it's going to be, and who the audience is. Is it more of a reference book for people who know HTML and want a hard copy? Or is it for people who are learning HTML for the first time, and want to learn HTML5? Is it a book that assumes people know what vim and emacs are? Or is it a book that takes 1-2 paragraphs to explain what a text editor is? Is it a book for nerds? Or a book for retired dads looking to make their first website?

I'm not going to say 500 pages is too much or too little, because I don't know what kind of a book you're writing yet.

Also: some hackers here already mentioned that a lot of HTML5 information is available on the internet. I would think carefully about what your book will do that a google search can't.

-Sometimes books clutter lessons with too many words. I look for concise books that cover what I need. -It's like laptops...make it big enough to be useful but small enough to carry in your computer bag.

-Make examples as small and concise as possible. I hate paging through example code in a book. -Consider the book a complement to people working through code samples you provide on their computer. -Make a single place to download all of the examples easily.

-Build a good outline and refine it carefully. -Build a way to track your progress through the book. Ex: a jar of candies counted out for each chapter or milestone.

-Write with as much maturity and wisdom as you can muster as that will make an exceptional book. -Plan how to handle every distraction that will come up.

-Smile when you write.

"Smile when you write". Excellent advice. I also liked the brevity of the A Book Apart series.

Who is the target audience? beginners, intermediate or advanced?

Something I have found in common with many of the thicker books (400+ pages) that I liked is they are broken up into a couple of very distinct sections. The first part is usually an intro and explanation of the material. The middle is more elaborate examples of how to use the materials. The back is more of a reference section.

Something that drives me crazy is when books skip steps. Don't assume that the reader knows what the middle step is just because it's mentioned in chapter 2 doesn't mean I'll remember it when I get to chapter 9. Or 6 months later when I am looking at the book trying to remember how to do something. It's a book not mysql you can have something in more than one place.

If you're thinking 500 pages, consider breaking it into two books. One for the core functionality and one for Canvas and its uses. The audience for one is not necessarily the audience for the other.

Emacs, org-mode, and LaTex.

Org-mode is an Emacs mode with a first-rate outliner and a Markdown-like syntax. It easily exports to LaTex and/or to PDF.

A good example for you might be the "jQuery: Novice to Ninja" book. It cuts out a lot of the BS that makes other books annoying and cuts straight to the chase of DOING. Think of a group of sample projects, or maybe even think of a single project to build and build upon over the course of the book.

Think about the overall tone you want to use. Do you want your writing to read like directions or do you want to do something more "fun," such as using humor and making pop culture references throughout the text? Congrats on the book deal.

I think you may want to check out how Maneesh Sethi wrote his programming books when he was a teenager. www.hackthesystem.com

good job...which publisher..Orielly? I would like to see more cool examples and tutorials?

>> "I hope for it to be around ~500 pages"

Firstly congrats on the contract. You must be an expert in the field to be offered a contract.

The aim of quantity (pages) rather than quality is troublesome. I would be aiming to write something that achieves an objective - like an average web developer will understand how to apply HTML5 after reading; or a complete newbie will be able to start using HTML5....

I recommend going to a bookshop and checking out the current books on programming languages/frameworks. Try and find a style that matches your objective. Look back at books you read and what helped.

Unless this is an extensive reference guide, focus on quality content rather than reams of paper.

Reply on news.ycombinator.com