

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

(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).<p>I'll be writing a book on HTML5. I signed the contract last week.<p>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.<p>I've never written anything of this scale before and certainly never authored a book.<p>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?<p>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.<p>Also, do you have any pet peeves about technical books, or things you wish authors did more or less of?<p>Thanks for reading!<p>[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.
======
jamesbritt
_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.

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

~~~
horsehead
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.

~~~
jamesbritt
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.

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

------
jefflinwood
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.

------
thejerz
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.

------
waivej
-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.

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

------
bobfirestone
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.

------
iKnowKungFoo
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.

------
dctoedt
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.

------
lucperkins
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.

------
mmsheeh
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.

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

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

------
sparknlaunch
>> "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.

