A writer pointed out to me that writing a book is very similar to building a tech startup. The hours are long, it's critical to build a strong platform and there are the same swings from despair to elation.
Additional data points are always very much appreciated and it's very good of the author to release his tools and methods for others to learn from. Of course, the $5k in 2 weeks doesn't account for the time it took him to write the book or the opportunity cost of not taking other work, so this still might not have been a financially worthwhile venture, but hopefully it will keep selling and he'll publish more about it.
Yeah, definitely the $5k in two weeks doesn't include the development time. I figure I broke even on the writing when it hit $7k, but it's definitely not any kind of substitute for a full time salary.
Would you mind telling us how long it took you to write? The impression I get is that people routinely underestimate how long good writing takes by orders of magnitude.
Having written a Ruby book I would definitely agree, even though my book was very modest in size it took an order of magnitude more work than I had expected. Coming up with code examples, editing, creating a book cover, not to mention how grueling it can be to write especially after a long day of coding.
Sure. 70 hours for the first draft and probably another 70 for the editing and revisions. I had the first draft done on July 1st, then spent two weeks editing before starting the preorders. I was developing the companion rails application at the same time so it's hard to get real numbers.
I have had several people work through it and stumble at points because the book assumes quite a bit of rails knowledge. At some point I'm going to add content for beginners but that's probably a few months away.
I was thinking more in terms of people who want to learn more about Stripe yet do not use Rails and have no immediate need or interest in learning it.
My guess is that an accomplished developer with a few languages under his/her belt might be able to understand and translate aspects of the code. At one point it becomes more opaque and you can't go further without learning Rails. I know nothing about Rails, which means I don't have a real sense of how difficult it might be for someone coming from, say, Python, to read and understand Rails.
Note: This isn't criticism. I am interested in the book but don't work with Rails and don't have the time to dive into learning it. Because of that I am trying to determine if the book would really be useful to me. I am currently working with Python and have good command of probably a dozen or more other languages.
Ah, I see. Well, the broad strokes are definitely applicable and if you can find substitutes for the gems that I use (in particular, a background worker system, automatic state machine semantics for models, and a way to keep an audit trail) then the code examples will probably be at least understandable and sort of useful.
Additional data points are always very much appreciated and it's very good of the author to release his tools and methods for others to learn from. Of course, the $5k in 2 weeks doesn't account for the time it took him to write the book or the opportunity cost of not taking other work, so this still might not have been a financially worthwhile venture, but hopefully it will keep selling and he'll publish more about it.