Why Red Means Red in Almost Every Language (2015) - <AUTHOR> http://nautil.us/issue/76/language/why-red-means-red-in-almost-every-language-rp <comment><USER3> I know that authors do not choose the titles of their articles, but it was somewhat vexing that the question of "why 'red' means 'red' in almost every language" went entirely unaddressed.

<comment><USER4> Ah, but that _wasn 't_ the title, precisely. They weren't talking about 'red' (the word) at all, but rather _red_ —the semantic concept that the English word 'red' points to. The mysterious assertion being followed up on is, in other words, not:

        en["red"] ≡ en["red"].translate(other_lang)

(i.e. "other languages also have a word 'red', that is the translation for the English word 'red'"), but rather:

        en["red"].referent ≡ en["red"].translate(other_lang).referent

(i.e. other languages have a word _eqivalent in referent_ to the English word 'red'), or even:

        ∃other_lang, ∀color_word: en[colorWord].referent ≡ en[colorWord].translate(other_lang).referent

(i.e. there are other languages that share a complete set of color-words _referents_ with English, such that you can bijectively map each English color-word to an equivalent color-word in that other language.)

...which _is_ the topic of the body of the article.

<comment><USER3> That seems a bit hand-wavy to me. Firstly, that _was_ precisely the title. You are talking about the _meaning_ of the title. Secondly, I did understand the title, and I am not speaking of the word 'red'. I am speaking of the semantic category referred to by the word 'red' in English. Thirdly, it is clear from the article that not all semantic color categories match cleanly and bijectively across languages. Fourthly, the assertion that 'red' _does_ match bijectively across "almost every language" is not made in the article, and no explanation of any reason for any such claim is given. Fifthly, there is no information in the article that affirms the why of _any_ semantic matching (or mismatching) occurs across languages: a theory of biologically-based thresholds in retinal perception is mentioned, but as a hypothesis, not as useful science. The article merely discusses the history of the similarity (and dissimilarity) observed in a series of studies.

<comment><USER4> My point was that there was a difference between your quotation of the article's title, and the article's actual title. You put quote-marks around 'red'; the article itself did not. This is a _use-mention distinction_ : when writers—but journalists especially—talk about (i.e. mention) words, they put them in quotation marks. When writers _use_ them to refer to their referents, they don't.

This is important because news articles themselves get translated to other languages. Consider what the title of the article would be if the article were translated to another language. If they were attempting to mention the English word 'red', you'd still see the quoted English word 'red' in the translated title! Whereas, if they were attempting to refer to the semantic category, the title would just say, translated the destination language, "why [local red- equivalent color word] is [local red-equivalent color word] in every language."

My point was to clarify that you were making a very different argument by asserting that the article never clarified "why 'red' is 'red'..." than you'd make by asserting that the article never clarified "why red is red...".

> Fourthly, the assertion that 'red' does match bijectively across "almost > every language"

Again, be careful: that's not the claim the article is making, but it _is_ the claim _you_ appear to be making by putting 'red' in quotes like that :) You have to be explicit when speaking of semiotics!

> Fifthly, there is no information in the article that affirms the why of any > semantic matching (or mismatching) occurs across languages

Well, that's just moving the goalposts; nobody was claiming that the article backed up its claims. It's just one of an innumerable number of these science- journalism blurbs about the weird color-category finding. For another one, see: [https://www.wnycstudios.org/podcasts/radiolab/segments/21121...](https://www.wnycstudios.org/podcasts/radiolab/segments/211213-sky- isnt-blue)

<comment><USER3> Okay, I had missed that. You're right, I did put quotes around 'red' (like that) and I can now see why that was a communications failure on my part. In truth, I had initially echoed the title with the single quotes around the 'red', and then gone back and put the whole phrase in double quotes while failing to remove the single quotes.

However, the article clarifies neither why "'red' is 'red' in almost every language," _nor_ "Why Red Means Read in Almost Every Language," as you seem to agree while mysteriously somehow also disagreeing with me. It is true that the article does not claim that red (category) matches bijectively across "almost every language," but that is my _entire point_. It is the _title_ that introduces the notion that "Red" will somehow feature prominently in the content of the article, which it _does not_. We could argue about whether or not bijectivity is implied by the title, but that would be irrelevant.

Regarding whether this is moving the goalposts, I rather disagree. It is the _title_ that makes the claim that the _why_ of anything at all will be addressed by the article. If it is moving the goalposts to point out that the article not only does not establish "Why Red Means Red" also lacks significant information about the "why" of anything, then it is surely moving the goalposts in the direction of the kicker.

You wrote to affirm that the true meaning of the article's title referred in a sufficient way to the actual topic of the article, contra my apparent complaint. I see that there was a misunderstanding involved, but that aside — right, the title was not referring to the _word_ 'red' — I disagree and actually I don't see how you can sustain any such argument.

</comment></comment></comment></comment></comment><comment><USER5> "His professors and textbooks taught that people could only recognize a color as categorically distinct from others if they had a word for it"

This is counterintuitive to me should this not be the other way around - <USER2> only categorically distinguishable colours have words describing them?

<comment><USER6> I'd say it should be rephrased as "could only name a color as categorically distinct from others" to make it more obvious. If you're asked if something is blue or red, then turquoise would definitely be described as blue, but green also. It's not that you wouldn't see the difference between sky and grass, it's just that you'd classify it all as a different shades of the same color, as it's closer to it than to say red. On the other hand yellow would probably be a shade of light red in that example. Once you're used to that palette you'd start simply ignoring the differences in shade for practical usages, like for instance Cambridge Blue is called blue, while to me it's really green.

<comment><USER7> Well I mean, obviously you can't "name a color as distinct" if your language doesn't have a distinct name for it. That doesn't mean it's perceptually indistinguishable.

I'm not sure why this tautology is regarded as such a big deal.

<comment><USER8> Even if you don't have a different word for green and blue, one could certainly express the idea of a blue that is like a leaf rather than the sky.

<comment><USER9> You'd assume so, but this is in fact false. [https://en.m.wikipedia.org/wiki/Blue–green_distinction_in_la...](https://en.m.wikipedia.org/wiki/Blue–green_distinction_in_language)

<comment><USER10> That doesn't really support your contention. The color naming debate underlying the entire discussion is primarily focused on _basic_ color terminology, for which colors that are merely allusions to a physical object (e.g., turquoise, gold, lavender) are excluded. But that doesn't tell you what terminology people will actually reach for in description. Japanese, for example, uses "ao" to refer to essentially the entire blue/green spectrum, but "midori" (lit. "leaf") is used to green, increasingly to the exclusion of "ao" in modern Japanese (side note: this is _literally_ an example, explicitly mentioned in your reference, of what the GP is suggesting happens).

</comment></comment></comment></comment></comment></comment><comment><USER11> mandatory mention of hungarian, where "red" does not really exist, and in its place there are two different words, roughly equivalent to "dark red" (wine or blood is vörös) and "light red" (fire or apples would be piros).

I am not sure if it's saturation or light or hue difference or whatever, and I can't really tell the difference, but I would quote the example I received first: "it's normal for someone to have vörös hair, but someone with piros hair would likely be a punk".

<comment><USER12> I'm Hungarian and it's hard to describe the difference. Your examples are good indeed, before wine, blood and red carpet we exclusively use 'vörös', as well as for red headed people, but I'm not sure it is because a different colour (bit darker, saturated red. We also (in a slightly literatury way) say vérvörös, blood-red coloured, I think that's the colour I would associate the word with) or simply because they are almost fixed prefixes.

We also use 'bordó', to mean an even darker red (though for my not particularly "trained" eyes they are practically the same as vörös)

</comment></comment><comment><USER13> I think it is hard to imagine that evolution did not result in some hard- wiring of our reactions to the sight of blood.

Blood=violence, LOOK OUT!

<comment><USER14> Except for the half of humanity who bleed regularly without any violence to look out for.

<comment><USER13> Surprisingly, there indeed seems to be no hard-wired understanding of periods. Freaking out on your first one is common for unwarned young women. Dealing with this has been off-loaded to culture.

And the various idiocies in traditional cultures about how to deal with menstruating women show that freaking out about this has been pretty common through history.

</comment></comment></comment><comment><USER15> > When shown a wheel of similarly colored squares, people identify the offbeat > shade more quickly if it comes from a different color category (as shown in > the wheel on the left) than if it comes from the same category (as shown on > the right). This effect suggests that the words we use to describe colors > influences how we perceive them.

Or much more obviously that we name colours based on how we perceive them?

</comment><comment><USER16> How do we know we all see same red color ?

<comment><USER17> As a kid I used to entertain myself with the thought that we don't, we just agree on the names. Even in the hypothetical simple case of RGB perceived as GBR I would still learn to name G as R.

</comment></comment><comment><USER18> Long form articles like this ought to contain summery!

 _infants were quicker to recognize a color from a new category if it appeared in their left visual field, which sends inputs to the right hemisphere of the brain. Adults, on the other hand, were quicker to recognize a new color category if it appeared in their right visual field, which corresponds to the left hemisphere, where the language centers reside._

<comment><USER19> Ok how does that translate to everyone saying red for the color? I'm confused as to what they're trying to communicate from the title.

<comment><USER20> Colours don't translate nicely across languages.

Sometimes, blue and green are different shades of the same colour, sometimes light blue and dark blue are two different colours, some languages consider pink to just be lighter red etc.

So, the title claims that the colour red is always red, regardless of the language.

<comment><USER21> > sometimes light blue and dark blue are two different colours

I believe it's so in russian

> some languages consider pink to just be lighter red

This is interesting. Here in the UK pink is generally described and accepted as light red, but I've always considered it to be a separate colour, and I met someone who mentioned he though the same, so it's not just me.

There's light red but to my eyes that is qualitatively different to this [https://www.macmillandictionary.com/dictionary/british/shock...](https://www.macmillandictionary.com/dictionary/british/shocking- pink?sa=X&ved=2ahUKEwiU0O2n96rlAhVISsAKHen8ALMQ9QEwAHoECAUQBA)

Any other views? Perhaps someone with knowledge of chromatics can better resolve the question.

thanks

<comment><USER22> You're articulating the difference between "pink" (a red tint, i.e. red mixed with white) and "hot pink" or "magenta", the fully-saturated midpoint between red and purple.

<comment><USER21> Well that's interesting. I can see that now.

But looking at [https://en.wikipedia.org/wiki/Shades_of_pink](https://en.wikipedia.org/wiki/Shades_of_pink) it appears to lump your magenta (red/purple) into the same category as red/white. So really we've got 2 categories with the same name of 'pink'? 2 different things?

<comment><USER22> Here's a more comprehensive, if somewhat convoluted, explanation: [https://www.quora.com/What-is-the-difference-between-pink- an...](https://www.quora.com/What-is-the-difference-between-pink-and-magenta)

"Pink and magenta have the same hue. What distinction there is to be found between magenta and pink lies along other axes than that of hue [i.e. saturation and value]. All pinks are magenta and all magentas are purple, and by extension, pink is a purple. However, it does not work the other direction: it does not mean that all purples are magenta nor that all magentas are pink, let alone that all purples are pink."

(Visit the link for a more detailed picture of the differences)

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> > wrangled pre-linguistic babies

I don't know why I love this wording, but I do.</comment>


Eric Schmidt looking at things - <AUTHOR> http://qz.com/42082/eric-schmidt-looking-at-things-in-north-korea/ <comment><USER2> +1</comment>


Ask HN: Considerations when asked to write a book? - <AUTHOR> I've been approached by 2 different publishers to author a programming book, based on the strength of a few technical articles I've written. They are both established publishers - think O'Reilly, Packt, Manning, Wrox, etc - and it's darn flattering to be asked. I think it'd be a fun experience, and a feather in my cap. Though I'm under no misconception about the monstrous amount of work it entails.<p>To those who have been down this road: Before I get into bed with a publisher, what else should I be thinking about? What questions should I be asking? What is a fair, market-rate deal for a first-time technical author writing about a popular subject? What are the areas to negotiate? Thanks HN! <comment><USER4> _What is a fair, market-rate deal for a first-time technical author writing about a popular subject?_

You're going to be shocked and dismayed by the offer they give you. Let's get that out of the way now. This is the model: they'll tell you to not do it for the money, in exactly those words, prior to explaining to you terms which imply that they're not doing it for ~92.5% of the money.

You will _likely_ be offered something akin to a $5k advance and a 8% royalty rate on paperback sales with, perhaps, a modestly higher royalty rate on e-book sales. The advance is guaranteed contingent on milestones. The royalties first "earn out" the advance and then start getting actually paid to you. (i.e. You have to sell $5k/0.08 = $62,500 of books on those terms prior to receiving any additional money.)

Most tech authors _do not earn out advances_. You should expect to receive just the advance and then occasional minor payments ($1k to $2k) for foreign rights if the book turns out to be so popular that e.g. it gets translated into e.g. Japanese.

If you want to make money in writing books, it is very possible. You'll want to start collecting email addresses, start publishing more things which get more people interested in trading you their email address, publish the book yourself, and sell via your own site/email list. For bonus points, sell packages (book, book + videos, book + videos + code samples) and price much, much higher than you're comfortable with ($49/$99/$249 is popular and works well).

There exist numerous people on HN who have successful businesses doing the second model. Understand that the second model is far more akin to running a business than it is to writing books. This is true of writing books generally, but it is more obviously true when you don't have a publisher to blame for your marketing/sales outcomes.

<comment><USER5> I'd be shocked if anyone got a 4 figure advance. I got a few hundred dollars for an XML book in the height of the XML times. Ultimately the book never got finished but everyone I know who has written a tech book (unless it's a huge seller) says expect nothing more than lunch money from it, plus the employment opportunities.

<comment><USER6> My book (my first and only) <[https://www.packtpub.com/application- development/d-cookbook>](https://www.packtpub.com/application- development/d-cookbook>) got $3000 advance, plus an on-time completion bonus, and now, two years later, continues to pay me ~$200 royalty checks in excess of the advance every quarter...

That's not a large sum of money, considering that it took about 6 months of nights and weekends it took to write the book, but it isn't nothing either.

<comment><USER7> Link is broken.

<comment><USER8> HN's link recognizer misjudged the length by one, and so is including the ">" end delimiter in the href.

Here is the correct link: [https://www.packtpub.com/application- development/d-cookbook](https://www.packtpub.com/application- development/d-cookbook)

It would probably be a good idea for HN to recognize <URL> and "URL", since those are specifically mentioned in RFC 3986 as common ways to delimit URLs in text.

</comment></comment></comment></comment></comment><comment><USER9> I'm currently an author with O'Reilly, writing about the design space. ([http://shop.oreilly.com/product/0636920038887.do](http://shop.oreilly.com/product/0636920038887.do))

I am in the final stages after over a year and half. I was in your position not too long ago and researched as much as I could before accepting, so I will skip things you will find in a quick Google search.

Negotiating:

1\. Everything is negotiable, remember that

2\. Under promise on #pages, they ask you for an estimate but lowball it because thats how they price it and then will ask you to fill it.

3\. Get in writing what they will be contributing.

Choosing the topic:

1\. Choose a topic you are passionate about

2\. Choose a topic you know a lot about

3\. Choose a topic you can write a lot about

4\. Don't be afraid to tweak the topic half way in.

5\. Choose a topic that will sell in a year and half.

Writing the book:

1\. Write an outline, write the first chapter, throw it away, and rewrite the outline agin.

2\. Its better to lose work than to keep going in a direction that isn't working

3\. You'll be busy but be reading other books as much as you are writing.

4\. Wake up early or stay up late, 0 distractions is the best for writing

5\. Talk out loud, like youre presenting to an audience to get unstuck from writers block.

6\. Get feedback as soon as possible.

Marketing the book:

1\. If you can, get in writing what marketing they will do for the book.

2\. Negotiate on how many free books you can get to give away

3\. Sales on Amazon are important, direct sales there, esp on launch day.

4\. Start a newsletter (yay more writing!)

Other:

1\. This is a second job

2\. It does open a lot of doors

3\. Consider a co-author for your first book. I added one towards the end and wish I had done it sooner. Its easier to collaborate and bounce ideas off each other and keep each other accountable.

<comment><USER10> > Negotiate on how many free books you can get to give away

What's a realistic order-of-magnitude number there? 50? And do you have to agree not to sell them?

<comment><USER11> If you forget to negotiate with them, and you go with O'Reilly, they are really good at sending free books for book signings to conferences which can be a really great chance to both get the word out and meet people that care about the tech you wrote about.

</comment></comment></comment><comment><USER12> I've written 3 technical books. I highly recommend talking to an agent. I used studiob.com. Not only will they negotiate money on your behalf, but they'll get crappy clauses taken out. Stuff you've never heard of like "cross accounting clauses". My last contract had a right of first refusal for my next book in their opening offer. The acquisitions editor even laughed when we asked about it because she didn't know it was there.

The agent will take 15% and believe me it's worth it.

Whatever deal you cut, pretend like it's not going to earn out its advance. Because it probably won't. As everyone says, you're not doing it for the money. You're doing it because you love the topic, love to write, and to be seen as an expert in the field. Writing the books themselves earned me very little money. Follow on work, like articles, and using it in salary negotiations, more than paid for itself.

I'd suggest you figure out the book you want to write then shop it around the publishers (again, agent helps). And be picky about the publisher, talk to other authors that used them. They're not all the same. When one publisher hires editors and pays their technical editors and another expects a lot of self-editing and offers a free book to the tech reviewers, the outcomes will be vastly different.

</comment><comment><USER13> As an author of several books with an "established publisher" I guess my main advice is that you know 1000x more about your domain than your publisher and you have a better idea than them what the book should be like so that it will sell a year and a half from now.

The best way to write a financially-successful book is not to negotiate the best royalty rates possible, but instead to make sure you write a book people are actually going to want to buy once the book comes to market... make sure you get a reasonable contract, but after that use any remaining leverage you have to make sure you get to write the right book for your market.

<comment><USER14> That sounds like very good advice. Let me add to this that it is extremely important for a programming related book to double and triple check for technical accuracy, and in particular check again and again that code snippets actually compile if they are intended to be complete.

Don't rely on any reviewers from the publisher to find mistakes.

<comment><USER15> A reputable publisher -- O'Reilly, certainly -- will ask you to find appropriate technical reviewers. The reviewers will get paid a very modest amount. Remember to include them in the acknowledgments.

(Source: me, technical reviewer on 2 O'Reilly books.)

</comment></comment></comment><comment><USER16> As someone who's currently 1/3 of the way into doing exactly what you've been asked... I'd advise you to really strongly consider the time it takes. I was wrong by a factor of 4. Thinking I could spend an extra few hours a week takes hours a night.

Expect no support, their staff are only there are a conduit to move things around. The other thing that shocked me is how crude it all is. The publisher I'm engaged with only has email and word docs. No form of document management nor version control outside of manual naming of the documents.

Even if my book sells well, it won't cover the cost of the time if I'd simply consulted that many hours. If you are considering it for the money, don't accept. If you want to study a subject in detail and get partially paid for it, then it might work out.

<comment><USER17> 100% this.

What I thought would be a quick few hours a week thing turned into taking up all of my free time over the weekends. And writing the first draft isn't even the most difficult part. In the review stage, you'll be revisiting stuff you wrote more than 5 months ago and we amazed at what a poor job you did then. Of course, time constraints make it impossible to re-write the whole thing, which is something we programmers like doing so much! So you do the best you can and move on.

And the tooling is non-existent. Word documents and emails are what I had to deal with. There were multiple instances in which I was editing the wrong version of the chapter, or the editor was looking at an older version, etc. I hope better tools exist for this process.

</comment></comment><comment><USER18> I've published two books through publishers and the actual writing experience was very similar to the book that I self-published.

For the self-published book I followed he basic path set forth in Nathan Barry's Authority[0]. Financially speaking it was definitely more lucrative to self-publish, but I've got access to a large audience to sell to.

There is another approach that I've seen that I find interesting and that is of the "open source" variety where the book is given freely and later published by a major publishing house. You Don't Know JS is a recent example.

My personal experience with OReilly was a good one. They send you a framed cover and it was a decent experience. We got no advance and the pay was peanuts, but it served to get me recognized at the time in a specific space.

Sure, money isn't the only motivator when setting out to write a book, but it's definitely a motivator!

[0] [http://nathanbarry.com/authority/](http://nathanbarry.com/authority/)

<comment><USER19> Thanks for sharing your experience. Never heard of Authority, I'm going to check it out!

</comment></comment><comment><USER20> Look for any "right of first refusal" clauses in the contract.

I was approached by Packt a few years ago, to write a book in a fairly niche topic ([http://amzn.to/29LR9Ly](http://amzn.to/29LR9Ly)). Their reputation is not the most stellar, but I put a lot of work into making a high-quality book with source code on GitHub and live examples running on Heroku. So I "beat the odds", I guess... earning several times the (small) advance, and getting some positive reviews on Amazon and Goodreads. The money doesn't justify the time that I put in, but it's tremendous resume fodder and played a large role in taking my career to the next level with my next job change.

However, my biggest regret is that I signed a clause giving Packt the right of first refusal on my next two books. Realistically speaking, I doubt I'll ever get around to writing another technical book again. If I do, I'll probably pitch it to Packt and then self-publish if they don't want it. But it sucks being locked in like that.

Truth be told, if I had known then what I know now then I probably would have just self-published in the first place. There's no real money in book authoring no matter which route you take. Publishers don't really promote books, and you're really on your own anyway for author support during the writing process. I doubt that most employers looking at my resume would care whether the publisher was Packt or Leanpub, so I probably would have gone the latter route just for the freedom.

Of course, if one of your publisher options is O'Reilly, then maybe that's another discussion.

<comment><USER21> Steven I'm managing editor at Packt. Thank you for publishing your book with us.

If you want to publish your next work yourself or with another publisher just mail us and ask. I'm sure we wouldn't enforce that clause against your will.

</comment></comment><comment><USER22> Most technical authors don't write a book for the money -- they write a book for the prestige (and proportionally higher consulting rates).

<comment><USER23> This is likely to be the more useful answer here. The biggest benefit comes from listing "author of [book you can buy at bookstore]" on your CV or web site. The marketing power of your name being seen by potential employers (or their employees who point to you as the domain expert of a topic). Not from actual royalties past the royalty advance which, as others have mentioned, would be rare.

Of course, the value of that would depend on if you trade on your name; e.g. if you're a freelance consultant.

<comment><USER24> > The biggest benefit comes from listing "author of [book you can buy at > bookstore]" on your CV

What about "[book you could buy at bookstore at one point, but not any more]"?

<comment><USER23> I guess that would depend on if the book is still relevant to and likely to be owned by the person you're pitching.

Or, of course, you're making a glib commentary about retail bookstores, in which case, _s /bookstore/amazon\\.com/g_.

<comment><USER24> > s/bookstore/amazon\\.com/g

Well, anybody can self-publish on Amazon (and I do mean anybody, including the completely illiterate), so I'm not sure that's a very high bar.

<comment><USER25> While many can, I'm pretty sure not many actually do :) (at least for technical topics).

It depends on whether the employer will care to check your book references or not, I guess.

</comment></comment></comment></comment></comment></comment><comment><USER26> I wrote a kids programming book. £1.5k advance and 8% royalties if I remember correctly.

My biggest takeaway, is forget your tool chain. I wrote it in org mode, and exported to Libre Office and then Word. As soon as the first draft was returned I ended up battling with Word the whole time, for edits and redrafts.

Also, designers don't read code like programmers. Indentation was often messed up, incorrect quotes used and line breaks added to suit formatting. One particularly badly formatted piece of code had me ripping my hair out. Everything beneath the first line was messed up. The designer came back to me a bit confused, saying the only problem he could see was the first line of code was 4 spaces too far to the left. Being accustomed to an absolute left limit on code, defined by the first line, it hadn't occurred to me to view it like this.

<comment><USER27> I've heard (but can't verify) that the Pragmatic Programmers have their own tool chain, and that it's quite good. It will, for example, check that code snippets are syntactically correct.

I have a few of their books, and they're pretty good. Their store is also very straightforward and friendly.

Does anybody have experience writing for them?

</comment></comment><comment><USER28> I did this with Pearson (SAMS imprint) and wrote _HTML5 Unleashed_. My first time = $10K advance and 12.5% (I think, forget) royalty rate. I'd gladly answer any questions.

> what else should I be thinking about?

Time. I spent a better part of a year of my free time researching and writing the book. Its almost like I skipped a year-ish of life. Of course, the next time I write a book will be a lot quicker.

In terms of hours worked, its not a lot of money. If you like writing (and I do), it may still be worth it. Like most projects, the second one you do will probably be much quicker and feel a lot better than the first!

By the way everyone I worked with at Pearson was an A+ friendly, helpful person. I have a much less favorable impression of Packt, but never wrote for them.

<comment><USER13> > Of course, the next time I write a book will be a lot quicker.

That's what I thought, until I wrote my second book.

</comment></comment><comment><USER29> I've just spent 18 months working on a title for Manning which is due for publication soon: [https://www.manning.com/books/cross-platform-desktop- applica...](https://www.manning.com/books/cross-platform-desktop-applications)

\- Writing a book is a huge undertaking - make sure that you have the time to do it.

\- Find a good environment to write the book in - if you have kids/pets/others that will interrupt you, try to find somewhere else to do the writing - <USER2> Hammerberg (the co-author of Kanban in Action) wrote his in coffee shops, with the side effect that he gained 10lbs, so factor that in.

\- Try to pause on blockers if you can - time spent on coding/writing does not always result in the equivalent amount of book being produced.

\- Check what the tech landscape for your book's subject is like - if it's very fluid then plan around it - since I started my book, Node.js was forked to create IO.js, Node Webkit was renamed to NW.js, IO.js merged back into Node.js, and then Electron emerged on the scene and now overshadows NW.js (which is ironic given that they have something of a shared history).

\- Keep your editor informed - I've had quite an eventful 18 months and it helps to let them know what's going on in your life.

\- Writing a book is a great feeling when you see your name as a published author.

I think the one takeaway is that it is like doing a dissertation whilst also doing a job - ask yourself if you can commit to that. If you can, great. And find the right motivation too, because you are putting at least a year of your life into this project.

<comment><USER30> I just bought your book. It still talks about IO.js. Are you planning on updating that?

<comment><USER29> Yes, the mentions of IO.js in the book should mention that it was merged back into Node.js. Out of curiosity which chapter were you looking at? I will check the MEAP and make sure that it has the latest chapter versions.

<comment><USER30> Just the Welcome before Chapter 1. Why not just remove the references to IO.js? And explain Node.js.

<comment><USER29> Ah, the welcome bit, yes that was written a while back. I will get round to updating that now.

Paul

</comment></comment></comment></comment></comment><comment><USER31> I went into it for the "feather in my cap" and "fun experience" aspect as well. It's grueling, stressful, and the piddly amount of money you'll make for it doesn't do much for motivation. I stopped about 3/4ths of the way through writing it and finally admitted to myself that I couldn't go on.

Some other folks have put out information about the advances and royalties, and it's about what I saw as well. If you're doing it for the money, I think you'll be disappointed, but at least you can gauge that before accepting. If you go the self-publishing route, I'm sure the amount of money you can make can increase if you have the right network, but you may lose that sense of "making it" by being published by one of the big names.

</comment><comment><USER32> I was a reviewer for a Packt book ([http://droppdf.com/v/UTl8X](http://droppdf.com/v/UTl8X)). The review process was terrible, they ended up not taking my feedback into account and the book was published with lots of technical mistakes.

The final book is essentially a random tutorial from pre-existing web content. Avoid them.

<comment><USER33> While I was working on a video course for Packt, someone from their company approached me and asked whether I'd be free to review a video course.. (mine)

They are badly organised and most of their communication happens through Word docs randomly spread over multiple Dropbox folders.

</comment></comment><comment><USER34> I'm friends with the owner of No Starch Press, but I'd consider their published royalty schedule to be quite fair and a good sign of the upper- middle of the industry.

[https://www.nostarch.com/writeforus.htm](https://www.nostarch.com/writeforus.htm)

15 percent royalty with no advance 12 percent royalty with $5,000 advance 10 percent royalty with $8,000 advance

</comment><comment><USER35> I've been approached quite a few times over the decades.

In my opinion you will make very little money from writing the book (unless it is a rare O'Reilly blockbuster) and it will take a horrible amount of time.

I think if you do the calculation based on expected income versus the time required to write the book, it is likely be close to minimum wage. Or it sure seemed close when I did the calculation for myself.

I think that those books make money for the publishers, but not much for the authors, especially if you can make market wages in a major market, or possibly more if you can get stock or some other form of potentially lucrative compensation.

</comment><comment><USER36> I haven't followed through, but just as an FYI - many people who have written blog posts have been approached by publishers. They don't put all of their eggs in one basket - for a given topic, they go through the "outlining" stage with multiple people.

</comment><comment><USER37> I would say it depends a LOT on who it is. Packt books for instance, are mostly....not very good.

<comment><USER38> By "not very good", do you happen to mean that Packt is a content farm that produces low-quality information written by cheap labor?

<comment><USER39> It mostly seems to be, but don't overlook the occasional pearl when they manage to trick a competent person to work for them.

<comment><USER40> The content of some of their books is written by very capable technical folks. Sadly, being a techy does not make you a good writer. Especially when you're not a native English speaker and are writing in English.

What's worse is that their review process seems to be worse than useless. Recently tried to read one of their books, which credited maybe 10 reviewers, and every other line had me cringing so hard it was unreadable.

<comment><USER41> Yep, I've recently read a Packt book and I found I think at least a hundred (!) of typos, grammatical errors etc. These kind of things give very bad evidence about the publisher, and (not always justly) indirectly also about the author, even if he is very competent technically. Better avoid this kind of publisher.

I've read an HN thread a few months ago and there was a lot of folks, both readers and writers, complaining about Packt's quality.

<comment><USER42> I wrote a book for Packt (and later for O'Reilly -- much better!) and I still cringe when I think about people reading it. They gave me three months to write it, and it's been out for three years now, so code samples are slowly breaking as technology moves forward, and some of the content is badly out of date. The principles are good, and there are definitely some useful things in it, but, my god, what I wouldn't have given for a copy editor and someone to actually review the code. It was all written in MS Word, as well, which made formatting and editing a nightmare. Their editors actually put mistakes _into_ the book. I think I took most of them out, but, like I said, their deadlines are nuts.

</comment></comment></comment></comment></comment></comment><comment><USER43> I've written 10+ books for O'Reilly, and one for Wiley/For Dummies, back in the day. It's a great experience, and I'm still writing for them now. We really enjoy it, and gain credibility, clients, and speaking opportunities from it. The money is fine, but the opportunities are great. Once you've done one or two, it gets easier and quicker.

</comment><comment><USER44> I have authored a book for Manning (Java testing with Spock) and was approached like you are (they noticed some of my technical articles)

My advice

1) Unless you are going to write a big hit, you are not going to earn match. You write a technical book for prestige, not money. Writing a technical book for money is the wrong reason to write it. Stop now.

2)You should really know your topic well. I mean REALLY know it.

3)The amount of effort it will actually take will be 6x the effort you think it will take.

4)Make sure that you have enough free time and you have discussed the matter with your significant other (and that she/he approves)

<comment><USER45> I have never written a book, but having written many tutorials, shouldn't it be like teaching > prestige > money in a motivation scale?

<comment><USER46> Depends. I find sufficient quantities of money to be pretty motivating as well as quite useful. I don't have any problem with the satisfaction that comes from teaching or with egoboo but it's hard for me to justify the huge amount of work that goes into a book based on those non-monetary things alone.

As has been remarked elsewhere, the monetary rewards don't need to come from royalties. Books are quite valuable as validation for people who make income from other sources--and therefore help support consulting and other income streams.

</comment></comment></comment><comment><USER47> I wrote a book for one of the pubs you mentioned and have talked to several other authors. Know what you're getting yourself into - you're going to be responsible for all editing so it is A LOT OF WORK. Never ending work. And it will never be good enough but dates move forward.

You don't make any money publishing with a publisher - not directly from the book, anyway. Maybe a dollar or two an hour. Do not do it for the money. Once you're done, however, you can demand a higher salary as an 'expert' \- say an extra 10% or 15%. Or double your income if you move into contract or consulting. :)

One STRONG recommendation is to not promise the publisher first stab at any future books. Some publishers have this in their default author contract - that you can't publish with another publisher without first offering the publisher the opportunity to publish first (maybe for your next 3 books). That clause is one I would demand be removed from the contract.

</comment><comment><USER48> I wrote a technical book for Wiley. 12.5% royalties for paper sales. 25% for book. Negotiate the ebook rate.

The main thing that surprised me (which shouldn't have) was the complete lack of marketing Wiley did. You write it, you find the tech editors, you edit it. They assign someone to you who basically bugs you to turn in chapters. I had the cover designed myself so it wouldn't suck. Then it comes out and you are the one who has to market it. but for me it was fun just to do it.

<comment><USER49> Is that 12.5% of the list price or 12.5% of the profits?

E.g. if the list price $100, the publisher sells it wholesale for $45 and the printing cost is $10, will your royalty be $12.50 or $4.37=(12.5% of $35)?

<comment><USER42> 12.5% of publisher's revenue. In this case, it's 12.5% of $45. Publisher eats manufacturing costs, which is why their percentage is higher.

</comment></comment></comment><comment><USER50> It seems like the people who are making money at this are the ones that have a following and sell PDFs of the books + addons (video training, a product) on their own.

Manning and Leanpub are built around being able to ship chapters as you write them - I think the feedback while working would be a huge help for motivation.

If you were choosing a publisher, I'd consider what the association with the publishers says about you (e.g. I've always been most impressed by the O'Reilly books)

<comment><USER51> I'm a Leanpub cofounder and just wanted to mention here that self-publishing a book while you're writing it is not necessarily incompatible with eventually going with a conventional publisher (though if you have a publisher in mind, you might want to ask them first if this would be acceptable to them). Publishing your book while you write it can help with motivation and the feedback you get from early adopter readers can be really valuable and make the book better in the end.

<comment><USER52> I _love_ Leanpub and buy a _ton_ of books and contribute as much as I can there to works in development. The whole feedback process has 100% won me over! If I ever published a book (something I've fantasized about for years), it would be probably through Leanpub or self-published. I'd probably consider one of the smaller presses, but Leanpub would be my go-to. You guys do great work at Leanpub!

</comment></comment></comment><comment><USER53> Don't write a book for the royalties. Books are far more valuable as marketing for your expertise.

A single consulting gig (of a week or two) will likely pay more than the entire revenue of even a successful technical book.

<comment><USER54> This. But keep in mind that books generate consulting gigs. My first book probably earned $4,000 in royalties over the last six years. But I got a $10K speaking gig in Columbia almost immediately and a three year engagement in Australia at $24K/year not to mention business class seats to Sydney once a year.

</comment></comment><comment><USER55> I am late to this discussion but I have one important thing to add: make sure in your contract that the rights to the book revert to you if the publisher does not publish the book in a timely manor.

This happened to me just one time, and I learned my lesson: I signed a contract with good terms, and half way through writing the book discovered the publisher was also producing a competing book. They decided to not publish my book, but did not revert the rights. I got to keep $5000 in advance money but I was unhappy. I wanted to give back the $5000 in return for the book rights but the publisher said no.

Edit: I have published 12 books with mainstream publishers like McGraw-Hill, Springer Verlag, etc. and many more self published books via Lulu and most recently Leanpub. I totally enjoy writing.

<comment><USER56> And make sure you have clearly and favorably defined in your terms, in the contract, what "publish", and "in print" mean, so there's no wiggling out of the obligation by the publisher to return the book rights to you. That, and only license the right to the publisher. You hold the ownership of the copyright.

</comment></comment><comment><USER57> Consider whether you're writing a book you want to be a lasting resource, or whether it's a book that needs to get published quickly to keep up with software trends. This will help you prioritize and set deadlines appropriately.

</comment><comment><USER58> I co-authored a technical book about 15 years ago. The advice I got from another author was that you "can't get rich writing books", and it's not worth it for the money.

Since then, book sales have declined... particularly technical books. I wonder if things are now also worse than the experiences of other commenters? For example, David Flanagan, O'Reilly's star author on Java and Javascript, switched back to consulting because even _he_ couldn't make enough money.

All that said, it's great to be a published author! I couldn't help but smile when I re-read some of my work recently.

</comment><comment><USER59> I have written some tech books, one of them best-selling, tech edited others, and written a preface for one. I am also the author of published novels.

The amount of money and contract terms vary widely with the publisher. This is where a contract with one of the big publishers is in your favor. You can also consider self-publishing, but that is a different business model, which I will not cover here.

Don't be afraid to ask for different terms.

In particular:

\- You can negotiate for an escalator clause on the royalties. This means that the more books you sell, the higher your rate.

\- You can ask for a higher advance or a lower advance and higher royalty rate. You can ask for the advance to be split differently (on contract, 25%, 50%, full MS, final acceptance, etc).

\- You should negotiate the option clause. This is the clause that says they get the first option on your next book. Specific terms to negotiate include limiting the scope - not "next book" but "next book on the topic of game development with Python". Also make sure they have a limited time to consider your proposal before deciding to buy it or not. 60 days seems to be a common number, but you can probably negotiate that down.

\- Strike any non-compete clauses (that you will not write a book on this topic for anyone else or self publish one).

\- Strike any cross-accounting clause. This is where you must earn out the advance on every book you have for a publisher before you can receive royalties on any book (and royalties for book 2 can be counted against the advance for book 1, and so on).

Some publishers pay monthly, some pay quarterly, some bi-annually. Take this into account.

Ask your publisher what their marketing and promotion plan will be for the book. How much support are they putting into it?

Earnings vary a great deal, but I have been very happy over the years, and book earnings have paid large chunks of my mortgage. How much you make depends a lot on the size of the audience, what other books are in the market, the timeliness of the book, and the publisher's approach to distribution and marketing. It tends to be on the small side and I realize my experiences are not typical.

It has opened doors for me and my co-author. We've been offered jobs, contracts, writing opportunities, and speaking opportunities.

I would say this was the best career decision I ever made. It's also draining and time-consuming, so be aware it's a large project.

Good luck!

</comment><comment><USER60> Like a focused blog, it's really a marketing effort. It may or (more likely) may not generate direct income, so don't do it for the riches, do it for the experience (you will probably have to delve into certain topics to clarify them for the book) and the publicity.

I would say choose the publisher wisely though. I've had a couple of experiences where I was asked to review books and I had to give up after a couple of chapters because they were just unreadable; don't be _that author_...

</comment><comment><USER61> I have been asked to write books too, but I go with a no response always. My reasoning is generally that my I have read free books and learnt a lot of what I have ( was not really rich to buy all trendy books being a middle class Indian student) , my book whenever it is written would be open and free access. That will be my way to pay back. If I have to make money , I will rather do it through my work, not letting publishers have control over the knowledge source I write.

</comment><comment><USER62> I've written two books (O'Reilly and No Starch). Do it for the pleasure of having a physical token you can give to people as a gift. The money is poor, it takes forever, but when it's over you've written something and have learnt from it.

<comment><USER63> Bill Pollock, founder of No Starch press is well respected in the hacker community, especially in San Francisco. I know several people who have published with No Starch.

<comment><USER62> Yes. I like working with them a lot.

</comment></comment></comment><comment><USER64> Please follow this. [https://medium.com/@atnemecek/so-you-are-writing-a-tech- book...](https://medium.com/@atnemecek/so-you-are-writing-a-tech-book-with- sample-code-493d6d640a44#.5ry3xx7dv)

<comment><USER65> Barry Eisler and JD Konrath have also written a lot on self-publishing.

</comment></comment><comment><USER66> I wrote "Using Docker" for O'Reilly recently. My thoughts:

\- I wouldn't bother with the advance. It was a pitiful amount of money and was paid in instalments that I constantly had to chase. Instead see if you can negotiate a better royalty rate (as your first book, I don't know if this will happen). Supposedly I was lucky to get advance at all, not sure how true that is.

\- Another commentor mentioned the free books they give you; I think this is an area you can likely easily negotiate up a bit.

\- As I wrote on a popular topic, I did make some money, but nowhere near what I would have made consulting. However, it has opened a lot of doors for me. I have given a lot of talks in a lot of countries and people come to me for advice, which is a nice place to be. In terms of my career, it's certainly been a big help.

\- I wouldn't write for one of the publishers that push out lots of low quality titles. It demeans your work and you'd probably be far better off self-publishing.

\- O'Reilly have a reasonably good infra set-up; I wrote the book in asciidoc using Vim and pushed to a git repo. There was an on-line app that would then build PDF/ebook versions of the book on demand.

Good luck!

<comment><USER67> > I wouldn't bother with the advance. It was a pitiful amount of money and was > paid in instalments that I constantly had to chase.

Unless you need the prodding to help you actually get the book done...

<comment><USER66> Not sure what you mean. I had to chase O'Reilly, not the other way around, which was just a pain.

</comment></comment></comment><comment><USER68> I wrote a book ([https://www.manning.com/books/relevant- search](https://www.manning.com/books/relevant-search)). Considerations: are you willing to write the book assuming that you will effectively make nothing in direct proceeds from the book? (Close to true.) The upside from a book is in monetizing on it indirectly. For instance, as a "though leader" you'll be able to garner a higher salary at your next job or you'll be able to ask for higher rates for consulting. But the catch here is that you've got to be willing to put yourself out there, otherwise it's a nice bullet point on your resume.

Oh yeah - and don't underestimate the time and effort involved. (I know you mentioned it in your post, but still.) A due date, even if fairly far off, looms ominous. For a year you'll have trouble relaxing and having fun because you know you should be getting work done on the book. You won't have weekend back for quite some time.

Would I do it again? Yep. Will I do it again? Nope. (At least not likely :D )

Good luck!

</comment><comment><USER69> Hi, I'm the co-author of a book by PacktPub.

Throwing some incoherent thoughts together:

I was approach by PacktPub, and I did a bit of Google'ing before I started, to check it wasn't a scam but didn't find a great deal of advice. I really wish I had the good sense to ask on HN, like yourself, before I picked up the contract. I've been meaning to write it up on a blog, when I put mine together (ironically considering the subject matter of the book).

So for me I knew it was never about the money, I was intending at least not to take the advance (which is actually a kind of loan that comes out from your royalties), it was about having my name on a book, but in the end it was so much work I figured I deserved it at the very least.

The main thing that shocked me was how much time it would take to do, in the end 18 months and that was from the half way point that my co-author had got it to, to the point where I gave up with it.

It should be noted I'm not a free-lance developer, I have a full time job so all this work had to be done in my spare time. This was not well understood by the publisher even though I explained it often, but deadlines came and went without any feedback. I was asked to make Skype calls during my working hours, never times that inconvenienced them, just when it inconvenienced myself. I believe they were based in India so calling in my evenings would be 2am or so for them, but I wouldn't be able to write their book at all if I was fired.

I went though 3 (or 4) different 'project leads' who always told me the end was just around the corner. There was no outline as to how much work was involved, the contract stipulated chapters and some re-drafts, but there is WAY more effort in it than that. No one seemed to have a coherent view of what was going on.

In the time I wrote the book and it being published, I got engaged, and married, and the thing that really annoyed me, and the point where I just stopped responding to them, is that I was still being contacted while on my honeymoon after being explicitly asked not to, that and I wasted my time 2 days before my wedding writing the pre-amble that turned out had already been written by my co-author after I was told it was just one last thing (again).

As for the quality of the book? I just don't know. There are errata which get sent to me, but I am done writing books for a very long time.

</comment><comment><USER70> I did a book a couple of years back. Motivations were:

\- I have been working in a particular speciality long enough that I felt I had something worth sharing with others, and was also lucky enough to be in a company that allowed me to write about the work we had done.

\- Just having done it, being able to see a book with your name on it on the shelf, give it away to friends and family etc.

Some observations:

\- I did the book with co-authors. I have other colleagues who are attempting to write books by themselves, and are struggling with motivation under the sheer enormity of the task. If you have coauthors you not only cut the per- person workload down, but also get the benefit of peer pressure to keep things moving along. Being the lead author, I also learned a lot about managing and organizing a distributed group with strong opinions and different approaches, which was an education in itself.

\- You mentioned you have existing technical articles. Having a starting point is a great leg up versus a blank page. Our book came out of a conference presentation for which we had to write up detailed notes. So we effectively had about 30% of the raw material ready before we started on the actual book.

\- As others have said, it is a lot of work. Hofstadter's Law definitely applies.

\- It forces you to really know your stuff, and to double and triple check things before committing them to immortality.

\- The first royalty check is surprisingly decent, I believe due to initial sales to libraries etc, but it quickly drops off. As others have said, you are almost certainly not going to be doing this for the money.

\- Publisher quality varies of course, but don't necessarily expect too much from them. In terms of editing, they will pick up on some typos, but not much else. We did everything in latex so there wasn't really much extra to do. But if you calculate how much money they make from the book, it is not surprising they do not allocate a lot of resource.

\- You will get completely sick of reading and rereading the text, while still finding more errors.

If I was to do it again I think I would go the self-publishing route, just to try it, since I honestly don't think the publisher did much for us in terms of marketing or editing.

<comment><USER46> >You will get completely sick of reading and rereading the text, while still finding more errors.

To this point, you must must must have a paid copyeditor as part of your publishing process. Technical reviewers, friends and family, etc. can't be counted on to read carefully enough to catch editors even if they're decent writers.

<comment><USER71> Er... catch errors?

(Available for hire as copy editor...)

</comment></comment></comment><comment><USER72> I recently wrote a book for Packt (ASP.NET Core 1.0 High Performance - [https://unop.uk/book](https://unop.uk/book)).

I won't go into exact numbers, but you can expect an advance of around 1000 GBP (obviously, if you live outside of the UK then this is worth less now). This is paid in instalments, as you progress through writing the book.

Royalties will be around 15%, but you will need to pay back the advance before you see any of this. There will also be a minimum threshold before anything is paid out, otherwise it will be rolled over. You won't get any visibility of how well your book is selling apart from the quarterly accounts.

I don't think you can value writing a technical book solely on the direct financial return. You could probably make more in a week of contracting than you will see for your six months of effort in writing a book.

Look at it as more of an investment in marketing your personal brand. It can open doors to higher paid jobs and better contracting work. If you enjoy education (both learning and teaching) then you can look at it as a virtuous endeavour even if it doesn't pay well. As long as you go in with your eyes open to this then you won't be disappointed.

It's not normally a problem, but be careful about any lock-in on options for future works. You may wish to switch publishers after the book.

Be prepared for a very low tech process. Depending on where you work now, writing a book may be much less sophisticated than what you do to write code. The quality over time curve will not always go up and it is quite a complex oscillating wave function. :)

I may write more about this on my blog if anyone is interested. I'll also be at the London .NET User Group tonight if anyone wants to pick my brains or see a copy of the book.

 _Edit_ : LDNUG link - [https://skillsmatter.com/meetups/8274-security-basics- and-un...](https://skillsmatter.com/meetups/8274-security-basics-and- uncovering-the-power-of-the-graph)

 _Edit 2_ : Show HN for the book on Amazon UK (cheaper because of weak GBP) if anyone is interested: [https://news.ycombinator.com/item?id=12121133](https://news.ycombinator.com/item?id=12121133).

Happy to take questions.

</comment><comment><USER73> > what else should I be thinking about?

Additional food-for-thought, Tim Ferriss offers this excellent blogpost, tons of helpful links > [http://fourhourworkweek.com/2014/02/04/how-to-get- published/](http://fourhourworkweek.com/2014/02/04/how-to-get-published/)

</comment><comment><USER74> I've delved into this some. I wrote a chapter in a multi-author tech book, and got a decent way through writing an entire book, until the project fell apart because the co-author they paired me with turned out to be completely useless. I would definitely not recommend it, but I'm not sure if my bad experience was worse than usual, or if I just have a lower tolerance for bullshit.

Don't even think about the money. Assuming you're working as a programmer or similar job now, the money you'll get from the book will be an absolute pittance. Your income divided by your labor will come out to well under minimum wage.

Fun? Maybe. But you'll be dealing with people at the publisher who aren't out to have fun. Expect poor communication, horrendously unrealistic deadlines that only exist to make you work faster, ridiculous feedback on your writing, and a general attitude that _you_ need to answer _them_ ASAP, but your requests to them can be safely ignored.

Find out what format they need you to use. In my case they required MS Word. They said it would be fine. It was not fine.

Feather in your cap? Yes, for sure. But there are other ways to do that too.

My advice would be to think about what you really want out of this, and how much of that you could get from, say, starting a blog, or writing more for your blog if you already have one. The money won't be as good, but the money sucks anyway. You won't have professionals helping you, but you also won't have professionals screwing with you. You can easily get more exposure, since tech people tend to read stuff online more than in books these days.

If you really really _really_ want your name in print, consider self- publishing. There's a lot less stigma in it these days. You'll probably sell many fewer copies, but you'll get much more of the proceeds and you'll have all of the control. It's easy to get your book into online stores like Amazon and iBooks.

</comment><comment><USER75> I wrote this a while back, in case it helps:

[https://zwischenzugs.wordpress.com/2016/05/15/writing-a- tech...](https://zwischenzugs.wordpress.com/2016/05/15/writing-a-technical- book/)

</comment><comment><USER76> I am the author of two books in Robotics. Here are the book websites

[http://learn-robotics.com](http://learn-robotics.com) [http://mastering- ros.com](http://mastering-ros.com)

The publisher was PACKT

Here are the details of PACKT perks which are given to me in a nutshell

Advance Royalty offered : $ 2.5 K to $ 3.5 K

Royalty share : 16 %

Writing time : 7 months -- 1.5 year

I am from India and i will say, if you can complete writing within less span of time, it will be great.

Note: Writing a book is boring and difficult task. It also consume high amount of time too. So be sure that, you can write book along with your job .

</comment><comment><USER77> Manning once offered me the co-authorship of Hello Python for 5% royalties and (unspecified, possibly 0) advance. To collaborate with an Australian co-author in an Australian timezone. I declined. Figured if I wanted to write a Python book I could do it for sole authorship, at time and pace most convenient to me, for 100% ownership, 80-95% royalty, most format freedom, etc. with the biggest loss being less marketing power. To this day, not sure if I made the right choice or wrong choice. But declining appeared right at the time.

</comment><comment><USER78> It's generally agreed that you are unlikely to make money from the book alone, but there are other reasons for doing this too.

Is the topic is something that you really want to promote? Do you have the spare time to do this for the experience and learning alone? Will this lead to career advancement or consulting opportunities? Often things like this are the reasons why people write books.

It is going to take a lot of time though, so you need to make sure you can spare this time for what is not going to generate a large income on it's own.

</comment><comment><USER79> I've written a book, on publisher's request. It helped that I had about 7 years of experience as a freelance writer for one of their well established IT magazines.

While others in the thread have already stated the obvious (don't think of doing it for money; negotiate everything; under promise, over deliver etc...) - there are a few things you should be aware of as a first-time book author.

1: It will take a LOT longer than you ever thought possible. For every page of final product, you will have written 3-4 pages of text.

2: It's a full-time job. Expect to spend 5-6 hours a day, just writing.

3: The workflow between you and your editor is crucial. Treat the book the same way you would treat a complex software project - your editor will want regular progress reports, and _you_ want to provide work-in-progress manuscript revisions or chapters. A good editor is going to send back lots of editorial comments, questions, requests for expanding (or sometimes contracting) on varying topics and so on. Approach this the same way you would approach a very thorough code review.

3b: Ask to meet in person with your editor before you sign the contract. The two of you have to be able to work together over written media.

4: You will learn a lot about how to use written and spoken language. You may want to consider the entire project an opportunity for an extremely intensive course on written communications.

5: Before you embark on the project, find out what activity helps you relax. Then find a way to record audio. When you feel blocked, take up the activity but keep the audio recording device at hand. When your mind comes unhinged and ideas pop up, _record them immediately_.

6: Don't even try to write your book "in order". Focus on one or two chapters at a time, and think of them as 90% independent results. The time to tie the chapters together comes towards the end of the project, as you and your editor realise that a previously "logical" chapter order may not work after all. Leave yourself some wiggle room to make the chapter shuffle easier to handle.

And because we in engineering discipline are even more likely to suffer from existentialism...

7: Do your best to maintain an emotional distance. You are not your book, and your value as a human being is _not_ dictated by the progress of writing or the (lack of) success of the published book.

Basically, writing a book is easy. You sit down, open your veins, and pour the blood out.

P.S. Having an ISBN to your name is one hell of a CV item. But don't ever imagine that you're doing this to buff up your Publications section.

</comment><comment><USER80> It's going to be a lot of work and you're likely to not make any more than the initial advance of $5,000-10,000.

</comment><comment><USER81> A couple of good resources:

[https://blog.codinghorror.com/coding-horror-the- book/](https://blog.codinghorror.com/coding-horror-the-book/)

[http://www.aristeia.com/authorAdvice.html](http://www.aristeia.com/authorAdvice.html)

</comment><comment><USER82> On the other hand you can also publish (and sell) your body of work directly on the web.

It's easier than many would think!

<comment><USER83> Unless you are an experienced writer (and honestly, even then) you will still need a professional editor to help you create something that will get good reviews and that people will be willing to pay money for.

</comment></comment><comment><USER84> I'm the author of a book published by O'Reilly: [http://www.hello- startup.net/](http://www.hello-startup.net/)

Before I decided to write the book, I talked to a number of friends who were authors and they all basically gave me the same advice:

* It's a massive amount of work, especially if it's your first book. If you're working a full-time job at the same time, depending on the length of the book you have in mind, expect it to take on the order of 2 years.

* It's a different type of work than programming or even blogging. In programming, you get feedback on a near constant basis at all levels: your IDE (sub-second), your compiler (seconds), your test suite (minutes), your co-workers (hours), and customers (days or weeks). This helps keep motivation high and gives you the info you need to improve your work. With a book, unless you make a massive effort to seek it out, you get more or less no feedback whatsoever for months or even years. For a project that takes such a long time, this can really sap your motivation. You have to come back and write a bit every single day, day after day, and yet on any individual day, it feels like you've hardly made any progress at all. You have to be very good at driving yourself and you need to put in an effort to give talks, to send out chapters to friends and family for feedback, to join a writing group, and anything else you can to get the feeling of tangible, incremental progress.

* You won't make much money from it. If your book hits the New York Times best seller list, sure, you can make money. But most tech books don't sell anywhere near that much, and even if you have "decent" sales, when you factor in the massive amount of work (see point #1), it's a comically small return, especially compared to a programmer salary.

* Despite that, every single author I talked to was writing their 2nd, 3rd, or even fourth book, and they all recommended doing it, subject to the caveats above.

As a result, I took the plunge, and I am very happy that I did. The real reasons to write a tech book are:

* It's an unbelievable learning experience. I used to think that experts became authors, but the reality is that authors become experts. I did a ton of research for my book, met a lot of interesting people along the way, read a huge number of books I had been meaning to for years ([http://www.hello-startup.net/resources/recommended-reading/](http://www.hello-startup.net/resources/recommended-reading/)), improved my writing skills, got better at marketing, and so on.

* It's a great way to develop ideas. I started a company not long after writing my book ([http://www.gruntwork.io/](http://www.gruntwork.io/)) and many of the ideas for that company came directly from what I learned during the writing process. As a bonus, the book is also a nice sales and marketing tool.

* It opens doors. People treat you just a little differently when they find out you are a "published author." They are more willing to listen. You get more opportunities for jobs, talks, meeting people, and so on.

* It feels good. I love teaching and sharing knowledge. I love seeing something that I created have a positive impact, even a tiny one, on someone's life. I love creating things. It feels wonderful to see positive reviews; to get emails from readers telling you how much the book meant to them; to hold your book in your your hands for the first time; to give your parents a copy; to find it on shelves at bookstores and famous libraries (my book is at Harvard, Oxford, etc!); and so on.

</comment><comment><USER85> Is it a Perl6 book? I'd really, really like to read a full book on multiparadigm programming in a language optimized for fun and power!

</comment><comment><USER86> I wrote an introductory Python book for No Starch, Python Crash Course. Bill Pollock, the owner of no starch, invited me to consider writing a book after I gave a lightning talk at PyCon a few years ago. Writing for no starch was a really good experience, and I'd do it again.

I feel fortunate that my first writing experience was with no starch. They take each book seriously, and work hard to craft a high-quality book. They have their own editors on staff, and they asked me to recommend a technical editor. They trust their authors to know their field well enough to identify an appropriate technical editor. I am deeply grateful to my technical editor, Kenneth Love. Kenneth has a deep knowledge of Python and a strong background in teaching. He caught many technical issues, and we had numerous conversations about how best to present certain concepts to new programmers.

The writing process was clearly defined. I drafted a chapter, got feedback from a no starch editor, and then sent the chapter off for technical review. After that it went to a copy editor, and then the chapter went through a final layout process. It was my responsibility to respond to feedback at every stage. Every so often Bill would read through the chapters and offer feedback as well. At first this process felt like a bit much; in the end I really appreciated the attention to detail, and I can't imagine writing for a publisher that doesn't have a rigorous approach like this.

I committed to this work for several reasons. Writing at the introductory level is a little different financially than writing about a niche technical topic. The market for an introductory Python book is much larger than the market for just about anything else. I think of the audience for technical books as a pyramid; introductory books target the base of that pyramid. Any topic that requires background knowledge is higher up the pyramid, and the opportunity to make a meaningful number of sales is lower.

I teach high school math and science. Writing an introductory technical book has opened many doors, and I don't feel stuck in teaching at all now. I can write more, and I can easily shift to teaching CS full time if I want to. Just the process of completing a quality book has taught me a lot about following through on the less enjoyable but necessary aspects of a long-term business project.

Here's the no starch description of Python Crash Course: [https://www.nostarch.com/pythoncrashcourse](https://www.nostarch.com/pythoncrashcourse)

Here's the Amazon page. I was terrified to read the first reviews on Amazon when the book came out, but now I really enjoy reading what people have to say about something I put so much effort and thought into: [https://amazon.com/Python-Crash-Course-Project-Based- Introdu...](https://amazon.com/Python-Crash-Course-Project-Based- Introduction/dp/1593276036/)

</comment><comment><USER87> Lots of great advice in these comments. Adding a few bits based on my limited experience writing for O'Reilly:

E-books are important. They're more than half the unit sales in my case. Look for good e-book royalty rates. Someone mentioned 50% and I have no idea if that's realistic for tech books, but it should certainly be much higher than print. Some tech publishers participate in all-access online libraries, and you get royalties from these too when anyone accesses your book.

Toolchain is important. MS Word intake may mean you'll have less control over quality in post production. O'Reilly can do DocBook/AsciiDoc end to end, and can even push author-submitted ebook updates after launch. Of course if you prefer MS Word and staying hands off in post then great. But I'm always grateful for text markup in a git repo, enough that I'd consider it a big plus when picking from multiple publishers.

When you pick a publisher, make sure that you like their books and would be proud to have a year or two of your own work sitting next to them. Based on stories I've heard from author friends, there seems to be a correlation between production values and author happiness. Typesetting, paper quality, error rates, etc. are all things I care about anyway, and they're also a proxy for other parts of the experience like editorial and technical support. There are big publishers I wouldn't even consider because their catalog is so poor.

Once you start writing, don't stop. Find a steady pace and stick to it. Treat each chapter like a magazine article that's due at the end of the month. The biggest pain for my first book was writing for five months, pausing for two (weekends went to the day job for a bit), then feeling guilty about pausing, procrastinating, and nearly burning out from the stress. The work won't burn you out, the guilt will, so manage the guilt.

My editors were all good people willing to chat, answer questions, and connect me with resources. None of my editors gave me writing feedback. I don't know what's typical in this regard, but I felt quite on my own when it came to drafting and editing. I had mixed feelings about this at first: I was hoping to learn more about writing from an opinionated editor, as with magazine writing or fiction (I imagine). My editors were all good about pestering me for new material on a regular basis, which is a valuable contribution, and we had some good project planning discussions at the beginning.

Keep expectations very low for marketing help from the publisher, especially for niche titles, beyond the publisher brand itself and the occasional full- catalog ebook sale. Ask about marketing channels run by the publisher, such as companion videos, live streaming events, and publisher booths at conferences. Plan to self-promote online, and don't be shy about it. You're writing this book so people will read it, and they can't read it if they don't know about it.

Not sure if this is controversial, but personally I would trade some or all of the advance for a higher royalty. The advance doesn't come close to paying for my time, which means it doesn't shift the risk or up-front production costs to the publisher in a meaningful way. The case where I deliver a completed manuscript but the advance doesn't pay out is one I want to avoid: I want as many people as possible to read my book! If it's a failed investment for the publisher, it's a failed investment for me, even with the advance. One not insignificant advantage of an advance is that it usually pays based on drafting milestones, so it's a nice motivator, but that's merely psychological.

<comment><USER42> Will second the "look for good rates on e-books" People often underestimate income from ebooks, but it's huge. I was offered a $5,000 advance with 10% of ebook sales, or no advance with 25% of ebook sales, and it was one of the best decisions of my life to take 25% with no advance. For the past year, I've received an average monthly royalty check of $3k (albeit before taxes, which I have to pay quarterly), with most of the income from ebooks. Not only do I earn a higher royalty rate for them, but the "wholesale" price from the publisher for print books is smaller than you think it would be (not shelf price), and my ebook/print book sales are about half and half.

I also get a few hundred dollars a month from licensing it out through Safari -- each page read through the platform earns me money, which they calculate through some wizardry (all revenue, divided by all page reads, times the page reads your book got, times 25%). So really think hard about the royalty rates for online access, licensing (the book's been purchased by five international translators, and each one is another $500-$1000 for me, on top of 5% of the revenue from foreign translation sales). Those things really add up.

</comment></comment><comment><USER88> I wrote a book most of a decade back... [http://nostarch.com/xen.htm](http://nostarch.com/xen.htm) \- No-starch approached me, based on some blog posts that I thought were absolutely terrible. Now, I don't know if they just wanted to know if I knew someone, and included the "or you" bit to be polite, but I'm all about grabbing opportunities to do things I'm not qualified to do... as far as I can tell, that's how you _get_ qualified to do things.

I think I said something like "My English is Presidential, but I know a guy." I called up the roommate of a friend, and we got all excited. "We'll be done by Christmas!" We got a two bedroom apartment by the Lawrence Caltrain station and filled it with computers. Writing that book took forever. I still call it "the hardest thing I ever finished." but, it was super rewarding, and I still brag about it. I am very glad I did it.

Now, don't get me wrong, I personally am super proud of the tiny checks I get quarterly; and hell, they seem to still be coming in, like 6+ years later, and I _am_ the sort of person who refuses to pretend like salary doesn't matter, but on an objective level? It's just so little money compared to what I get as a bay-area contractor that sometimes I think I'd be happier framing the checks than cashing them. I made literally thousands of dollars!

When I negotiated, it was explained that I got a better percentage for giving up the advance, so I did, because the advance was like a week's pay from the dayjob, but if I could go back and tell myself what to change in that negotiation? I'd tell me to take the percentage payout as if I had taken the advance, in exchange for the publisher promising to spend the advance money on publicity for the book.

Honestly, I have no idea if that's a standard thing, but I don't see why they wouldn't do it if I asked.

Also note, in my case? the e-book royalties were comparatively quite substantial, even though my book isn't available in the Kindle store; you can only buy the e-book, as far as I can tell, direct from no-starch, and it costs almost as much as the regular book and the e-book. They don't sell very many e-books, but my percentage on the e-book was way higher. I imagine that percentage drops a lot if you sell the e-book through amazon; I believe the vig on a kindle book is more than what it costs to print a book, (though I know printing a book is not the only cost of distribution, so the kindle book is likely still cheaper, as the 30% covers not only printing, but distribution and retail profit.)

The people I know who make good money off books are already famous, and they sell without a publisher. But... that's really hard to do if you aren't already famous.

I went with a publisher because going with a publisher gives you a lot of credibility if you are not yet famous, and because seeing my physical book in physical stores tickles me to no end. And because it was their idea, and to be completely honest, I never would have finished without the publisher working with me.

I guess my main point is that you should think carefully about the non- monetary things you want when deciding which publisher you want, way more than you should think about the monetary things. Sure, get the best deal you can, because why not, but looking back? I totally would have traded away some money for more fame.

<comment><USER52> After this post I am considering buying your book just for more of your writing.

</comment></comment><comment><USER89> Short lessons: _) Strike out the contract part about rights for books after 1st one_ ) Beware of how fast projects that you cover move _) Put the source code on Github_ ) Have a blog where you write about your discoveries that don't fit into the book _) Ask for discount codes and throw them around; that may be the only marketing _anybody_ will actively do for the book..._ ) If you are doing the first book after all, make sure you are treating it as something you will leverage multiple times after that ("published author", increased chance of presenting, proof you can write a different book for a better publisher, etc).

Background and happy/sad story: I wrote my first book for Packt (on Apache Solr). It was a small beginner-oriented book (about 64 pages of real content). I wanted to write a book for long time, so when they approached me to do it about a popular open source project I was working with and blogging about, I jumped on it. I figured that a small book would be perfect way to see the book process end-to-end.

It did not take _too_ much time, but longer than I expected (of course). However, support from Packt for the process was terrible, both in terms of initial information, explanations of process stages, reviews, formatting support or marketing.

I believe I did a good job _despite_ that as I wrote tutorials before as well as working in a senior tech-support position, which gave me visibility into research and explanation techniques.

Still, they managed to nearly destroy my book by publishing a free sample chapter from another book on the same topic that overlapped by the topic-name with my single-focus work. The technical content was actually complimentary and used very different explanation approach, but the general titles looked similar. The beginners (target audience) would certainly be confused. Packt did not realize they were publishing both books at the same time. They did not realize they created a conflict. And they did not see a problem until I escalated the issue 3 levels up all the way out of India into the UK level of management. They replaced the free chapter in the end.

Then they screwed up on the pricing and - just after release - <USER3> moved the decimal point and made my book 10x priced. For several weeks while I notified, begged, and - relatively politely - escalated.

In the end, I pushed really hard repeatedly and am happy with what I got. I just feel it happened despite the publisher, not because of them. The book is now obsolete, but a couple of people keep buying it, despite Packt increasing the price on it for some reason. Overall, I got a couple of thousands out of that. A good chunk of that was actually not from individual sales but from some sort of global subscription (perhaps via O'Reilly Safari library).

Later, I also reviewed a couple of other Packt books, supposedly on the same subject. Or I tried to review. They were so bad I could not even start providing viable feedback. So, I pulled out. Yet, I think they all got published. (Yes, I understand what this may REALLY mean about my own book. If anybody wants to privately review and provide honest feedback on an outdated Solr book, let me know.)

I also had a go at Leanpub and O'Reilly. The topic for Leanpub book was too big for me and I cancelled it, refunding all the money back (Leanpub were awesome at that slightly-complicated logistics).

Current O'Reilly book is probably too big as well. Solr is moving way too fast to do anything but small books on with classic publisher schedule and update capabilities. I am not the first one who hit that problem and I know of another book about Solr that got cancelled when the page count went into the second thousand.... I tried to get my scope smaller, but the things are still changing faster than I can process them, never mind explain.

My current thinking is that it may make sense to go back to Leanpub and do super-focused micro-book that is absolutely up-to-date. Something like Solr mega-tutorial with all bits working and using latest features and command lines. Sell it for 4.95 with discount to my mailing list subscribers (yes, I built one). Update it as Solr updates, do other micro-guides, etc.</comment>


Kids is the best what can happen to your career - <AUTHOR> https://medium.com/@buger/why-having-kids-is-the-best-what-can-happen-with-your-career-9264b9dba275 <comment><USER2> I think that talking about having children x career/life/new skills is one of the hardest subject I can imagine.

You can easily speak about children to someone who has one (or some) around the house. But it's pointless, because the person knows how it is.

You can talk a lot with those who haven't, but they'll barely understand what you're talking about, because it's almost impossible to explain how you learn to see with fresh new eyes, and to have fun playing, and that every day is a new kind of development and negotiations and so on...

P.s.: not talking about parents-to-parents kind of conversation.</comment>


Google offers $1 million in hacker bounties for exploits against chrome - <AUTHOR> http://www.wired.com/threatlevel/2012/02/google-1-million-dollar-hack-contest/

<comment><USER2> I like this! Trends like this suggest that the hacker mentality may become a standard part of business. For many, it is already expected.</comment>


'The Idea Factory': How Bell Labs invented the future - <AUTHOR> http://www.theverge.com/2012/3/21/2887206/jon-gertner-idea-factory-bell-labs-great-american-age-innovation-book-review

<comment><AUTHOR> This is technically a book review, but reads like a regular article. It's really amazing how much came out of Bell Labs.</comment>


Front-end developers salaries - <AUTHOR>

It seems to me in my country (Eastern Europe country) the salaries of the Front-end developers are lower than the salaries of the backend developers (.NET/Java/C++). I chose the Front-end route (Javascript mostly not only HTML/CSS) and this irritates me.<p>Do you observe similar tendency in your area? <comment><USER2> I live in London and that's not quite true. There is a lot of demand for front end guys, especially with AngularJS (Backbone shows up quite a lot as well, EmberJS only rarely), NodeJS and single page web app experience. And salaries for these positions are actually on par with backend roles at the moment.

Of course there are some poorly paid front end jobs but if you have been keeping up with latest frameworks and tools in the JS world, you will fall into the lucrative group of front end jobs.

When you are contracting, they can actually be higher. I see lots of lucrative Angular and Node contracts around (£500-600/pd).

<comment><AUTHOR> Yeah, I got a job proposal via Linkedin last week for a Front-end (JS/Node/Angular) position in London and in the description was mentioned £500 per day, which is almost my monthly salary!!!

The problem is that I'm not planning to go abroad for the time being.

<comment><USER2> Btw, where exactly in Eastern Europe are you from? I'm from Eastern EU as well :)

<comment><AUTHOR> Bulgaria :)

</comment></comment></comment></comment><comment><USER3> Yes, here in SF it is much the same. However there is also the "full-stack" developer that has come to be in high demand and ranks somewhere in the middle in terms of salary. As for why it is this way I think it's just simple economics. There is more "supply" of front-end devs than back-end which in turn drives the salary of the latter upwards.

</comment><comment><USER4> "Front-end" for 80% of companies still means Photoshop/Dreamweaver and maybe a bit of jQuery.

In places where "Front-end" actually means HTML5/CSS/JavaScript, single page, MVC, etc, the salaries are comparable to back-end programmers.

<comment><AUTHOR> You're right and exactly because of the lack of serious JS projects in my country the front-end salaries are pretty low. If more larger Node/Angular projects appear, the salaries would get high as these technologies are a lot more advanced than just styling few buttons with jQuery.</comment></comment>


Valeant's Drug Price Strategy Enriches It, but Infuriates Patients and Lawmakers - <AUTHOR> http://www.nytimes.com/2015/10/05/business/valeants-drug-price-strategy-enriches-it-but-infuriates-patients-and-lawmakers.html?hp&action=click&pgtype=Homepage&module=first-column-region&region=top-news&WT.nav=top-news&_r=0 <comment><USER2> That is a generic - right? The only thing fed must do is set up a fab that sells it at cost. Even as a loss making - the goal is to show that any company trying to milk its customers will find itself in doomed competition with a entity that has the deepest pockets on the planet. They will quickly get the hint.</comment>


Firmin, a JavaScript animation library using CSS transforms and transitions - <AUTHOR> http://extralogical.net/articles/2011-04-04-firmin-javascript-animation/ <comment><USER2> The text is appreciated, but too long. More importantly, there are no demos. That text is valuable but should be broken up into smaller sectional chunks, each associated with code and functional demos

<comment><AUTHOR> I definitely agree it needs some demos: this is my priority, time permitting. Thanks for the feedback!

<comment><USER3> The lack of a demo killed my interest nearly instantly; after hunting around and spending a few minutes and still nothing buried a level or two deeper, yeah I shook my head and moved on.

This is an animation library, you should have something on the first page right at the top, even if it's not a proper 'demo' (something to see/look at to get a sense of what this is capable of).

<comment><USER4> As someone who works with HTML and animation daily I greatly appreciated the detailed text. This isn't about what is made possible, it's about making it easier to structure larger and more complex applications that have significant animation.

<comment><AUTHOR> Thanks, good to know it was of use. The concern you outline was very much the one I had in mind when developing Firmin—writing large, UI-intensive web applications where CSS transforms and transitions would be useful but too inflexible to use without some mediation through a JavaScript API layer.

</comment></comment></comment></comment></comment><comment><USER5> Looks interesting but I can't figure out why there's no hosted demo. Hard to be inspired to think of a use case or want to play with it when I can't see a demo without pulling the code.

<comment><AUTHOR> Just a lack of time, really. I actually wrote most of the library last summer, but then I quit my job and went back to university, whereupon my free time dropped precipitously. I'll see if I can rustle something up this evening.

</comment></comment><comment><USER6> I've been wanting something like this, thanks! It can be tedious to set up animations by hand in the CSS, and since animations have more to do with behavior than styling, it makes the code a lot cleaner.

A nice-to-have would be detecting the presence of common JS libraries, and falling back to jQuery/etc DOM-based animation on browsers that do not support CSS transitions.

<comment><AUTHOR> Thanks, that's an interesting suggestion. I'll have to think a little about how it would work in practice—object detection is simple, but I'd need to make sure I could map the API well enough in each case for it to be worthwhile. If I did do that, it would probably be as an optional library (specified at build time), providing a fallback in the same way I intend to provide a fallback for browsers which don't provide an implementation of CSSMatrix. The other possibility would be to embed a minimal animation library like Émile [1], and just use that directly.

The other way of doing this would be to pull Firmin into more general DOM libraries as an alternative animation backend, and toggle between them based on runtime feature detection (for an example of how to do this, see [2]). A special case of that is doing it at the application level, in cases where the potential performance gains are vital; I mention an instance where I've actually done this in the article.

[1] <https://github.com/madrobby/emile>

[2] [https://github.com/othermedia/edgecase/blob/master/source/ed...](https://github.com/othermedia/edgecase/blob/master/source/edge- gallery.js#L68-89)

</comment></comment><comment><USER7> Other than the recently proposed 3D transforms, what's incomplete about Firefox's 4 implementation?

<comment><AUTHOR> For one, it doesn't expose (that I can find) an implementation of the CSSMatrix interface.</comment></comment>


Simplicity and the Hot Dog Question - <AUTHOR> https://medium.dave-bailey.com/simplicity-and-the-hot-dog-question-d5fc4bcf21ed#.bp20ewy6b <comment><AUTHOR> In so many B2C products, the hot dog is the content and not the platform and features. It's easy to forget that content drives consumption.</comment>