Hacker News new | past | comments | ask | show | jobs | submit login

This is interesting, but the hours are vastly overestimated, at least compared to similar metrics (e.g. from the deliberate practice and expertise literature):

If we figure a 40-hour work week... it wasn't my only activity. Let's knock that number down by 20% to account for my occasionally having to spend time on other things.

There's no way anyone spends 40 or even 30 hours a week writing. Most authors spend something like 3-4 hours a day writing - and that's a good day!

See for example the chapter on writers in Cambridge Expertise Performance Handbook (http://www.amazon.com/Cambridge-Expertise-Performance-Handbo...).

In general this type of reasoning (40h work week => time for 40h of writing) makes time estimates troublesome in my opinion. Another example is people who claim to write code for 40, 60 or even 80 hours a week. A look at actual RescueTime data gives a sober picture: https://news.ycombinator.com/item?id=209195

Of course, you could claim a lot of the work happens in breaks, and I would agree. But then the actual weekly number for our most beloved artists, programmers, and scientists is more like 24*7, literally. In that case, it makes more sense to talk about it in on the timescale of days, weeks, months or years.




I find the hours amazing. My understanding is that a typical tech publishing cycle is three months for a first draft, with an SD of around 1.5 months, and a page count of 300-600. Not infrequently the book will be a side project and not the author's main gig.

E.g. When iPhone OS (as it was) first appeared, in-depth guides like Erica Sadun's were on the shelves almost as soon as it was released.

Even if some of those authors had limited distribution beta versions, they still worked their way through all the new features of the OS, wrote and tested sample code, and wrote all the content in a couple of months.

I understand Meyers wants to make sure the content represents industry practice, and that takes longer than just cranking out some code and making sure it works.

But even so - that's still a surprisingly long time for a tech book.


I think that the lesson here is that it is kind of silly to try and put a time estimate on these things. How do you define time spent "writing"? Does it include time spent researching? Time spent thinking of the structure? If you pause to formulate the next sentence or line of code, should you stop the clock? Maybe we should only measure time taken in each individual key press.

It makes much more sense, and is less ambiguous, to talk about "time to complete a project". Like a book, for example.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: