Initial cover design. |
In my now-somewhat-dated article for prospective technical book authors, I mention how much time authors invest in writing a book, with estimates ranging from 1.7 to 6 hours per finished book page. I was curious about how much time I spent writing EMC++, so I tracked it, sort of. I actually tracked the days where working on the book was my primary activity, and the result was that I spent 29 weeks from the day I started writing to the day I had a complete draft of the entire book. (The weeks were not always consecutive.) During these weeks, writing the book was essentially my full-time job.
If we figure a 40-hour work week, that'd yield about 1160 hours, but although writing EMC++ was my primary activity during those weeks, 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. That yields 928 hours to produce a full draft of the book.
Sending in files for publication. |
At that point, I'd marked up the manuscript for indexing by the publisher, but I hadn't reviewed the resulting index, nor had I reviewed the typeset pages or digital files for the rest of the book. That work took place in bits and pieces over the course of about 8 weeks. I didn't track my time, but I figure it took at least two full-time weeks on my part, so let's call it another 64 hours. That pushes the total "writing" time (which includes reviewing and processing comments from outside readers of pre-publication manuscripts as well as reviewing pre-publication files from the publisher) to about 1344 hours. Let's round up and call it 1350.
That amount of time, viewed as a full-time 40-hour-per-week job, corresponds to 33.75 weeks, which is a little under eight full-time months. EMC++ has about 310 final printed pages that I wrote (i.e., excluding pages whose content was generated entirely by the publisher), so my productivity was roughly 4.3 hours per final printed page.
My book has about 310 pages. Bjarne's fourth edition of The C++ Programming Language has about 1340. Do the math and marvel at the effort such a book requires. Even if he's twice as productive as I am, that represents 2880 hours--sixteen full-time months! I'm glad I don't have his job.
Before you can write a book on modern C++, you have to learn about C++11 and C++14. For me, that work started in 2009--four years before I felt able to write a book on it. Here are some EMC++-related milestones:
2009 | Started studying C++0x (the nascent C++11). |
July 1, 2013 | Started writing what was then known as Effective C++11/14. |
June 20, 2014 | Completed full draft of Effective Modern C++. |
September 5, 2014 | Submitted final manuscript and index information to O'Reilly. |
November 2, 2014 | Approved print and digital versions of the book for publication. |
December 4, 2014 | Received first printed copy of EMC++. |
18 comments:
Oh, I didn't know it was time to start writing Rust.
Well, I'm about 2/3 through your book, and I can testify that your effort was well worth it. The book is pure gold. It provides true insights, which are hard to come by, and I'm very much enjoying it (I'm also having a good time improving my code). Thank you for your making the C++ world a better place.
Here's an idea on how to make your book actually relevant: try creating a large scale project with all the 'clever' techniques you're so fond of and let us know how it works out for you.
@greg7mdp: Thanks for your kind words. I'm glad you like the book.
Scott, I'll go ahead and buy this (as I own and read your awesome Effective and More Effective C++ books) though these days I mostly try and avoid writing new C++ code, in favor of Javascript and plain old C.
What's the best way to buy it from your perspective?
Best Wishes,
Jonathan
@Watmough: The best way to buy depends on what you're looking for. O'Reilly typically has coupon codes floating around for 40% off the print book and 50% of the digital versions. (Search around for them--I don't know them off hand.) Amazon also sells the print book and the Kindle version. Whether they're cheaper than O'Reilly, I don't know, but their Kindle version ties you to Kindle; O'Reilly digital files are device-independent (DRM-free). If you want both the print and digital versions (which I personally think is most convenient--I use both), I think you're probably best off buying both from O'Reilly, but be sure to get both coupon codes, because that's cheaper than their nicely-discounted print+digital bundle.
I'm sure other places sell the books, too. Perhaps other people can comment on what they view as the best way to buy the book. I don't have to buy them, so I'm not necessarily up on the cheapest (legal) ways to do it. (It's a perk: work for 1350 hours, get a free book!)
I think what @Watmough was trying to ask was "what is the best way of purchasing a book like yours to most benefit the author?"
If not, I'd like to know for myself since I appreciate all the work involved and want to help people like you make a living off of it.
Thanks!
This is awesome! Can you tell us a little about your experience with O'Reilly as a publisher vs. others? What made you choose them now?
Thank you very much for your great work! As a recent grad wanting to work in C++ your books were indispensable!
The book is great.
It was also quite necessary. C++11 and C++14 require to learn and clarify several concepts.
Effective C++ collection are my C++ favorite books.
I allways recomend them to all programmers.
thanks
So , Anon's comment is pretty snarky, but it asks a legitimate question, and one I puzzle over -- where does one get the code base(s) to investigate and evaluate particular techniques, new constructs, etc?
I'm fortunate in that I'm responsible for a couple of fairly large real-world code bases that I'm pretty familiar with, and that give me a "proving ground" as I'm looking to adopt new/better approaches.
It would be interesting to know if there are any code bases that you work with as you're putting together your books and articles.
Thanks!
@Wagnoid: An author's royalty is based on how much money the publisher gets for the sale, so I make the most royalty on a book you purchase from O'Reilly at full price. IMO, however, the best way to support an author isn't to avoid discounts when purchasing the book, it's to let people know you like the book and encouraging them to buy it. The royalty on two books at 60% of list price is more than the royalty on one book at 100% of list.
Positive reviews at Amazon and elsewhere, postings at various social media sites, and word-of-mouth are all worth more to an author than the royalty on a single book. Encouraging your team lead or department head or VP of Engineering to purchase a copy of a book for everyone on your team or in your department or throughout Engineering is great, too.
Thanks very much for your support.
@Delip Rao: I plan to put together a separate blog post about publishing options. In that post, I'll discuss my decision to publish EMC++ with O'Reilly instead of with Addision-Wesley (or a different publisher or on my own). I don't know when I'll get to that post, but I'll say right now that the decision wasn't based on having some kind of fundamental problem with AW. I continue to work with them on updates to my books with them, and I continue to act as Consulting Editor for the Effective Software Development Series, which has new books coming out at an increasing rate.
Olivier L.: I'm glad you found my books useful. Good luck in your software development career!
@WallSt Prog: I don't work on any code bases at all. In 2006, I wrote the following (taken from this article, which I'd forgotten about until it was cited in the Hacker News thread about this post):
I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (make? Who needs stinkin’ make?) My living is based on C++, but it’s not by virtue of the programs I write in it.
Nothing has changed since I wrote that, except that even more time has passed since I last wrote production software. Which is why it's reasonable to ask why I think that my advice should carry any weight with people who program for a living.
There are two reasons. First, my books try to justify everything they recommend, and they try to present a balanced account of the advantages and disadvantages of the practices I advocate. You should be able to look at my reasoning and, as a professional, evaluate whether it makes sense and is consistent with your experience. Second, I spend a lot of time dealing with professional programmers. I present training courses to them, I exchange email with them, I get into debates with them. When it comes to technical topics, software developers are not shy. If I say something naive or impractical or incomplete or suspicious, they let me know it, and they push back. Hard. I weigh such objections very heavily when I choose and word my Items and when I write up their justifications. The result is that the information in my books has been extensively vetted by people who use C++ every day and who are in a position to evaluate whether it makes sense for purposes of real software development.
I am well aware that I don't write production software, and I worry that I will drift away from the interests and constraints of people who do. That's a primary reason I had so many people act as pre-publication reviewers for Effective Modern C++. (There are nearly 30 listed in the book's acknowledgments, and that doesn't count comments that came in through O'Reilly's Early Release program, Safari's Rough Cuts program, and my blog when I posted draft book excerpts.) It's also why I spend as much time as I do maintaining the book's errata list. I do my best to come up with what I consider good advice for C++ software development, but I rely on people who use C++ for a living to keep me honest. I don't offer my advice in book form until they've had a chance to make sure my recommendations are grounded in practical reality.
Does this book make the older ones (Effective C++ and More Effective C++) irrelevant? I am new to C++ and wondering if it would be better to start with this book or the older, Effective C++ (After getting down the basics of course).
@Brian: Effective Modern C++ covers entirely different material from what's in my other three C++ books (Effective C++, More Effective C++, and Effective STL). Those other books are written for C++98, while Effective Modern C++ focuses entirely on features new to C++11 and C++14. The information in Effective C++ is just as relevant to modern C++ programming as to C++98 programming, so I suggest you start there, then move on to Effective Modern C++. (For my take on the relevance of Effective C++ in the age of C++11, consult this blog post.)
@Scott: Fair enough. Just to be clear, I did not mean to imply criticism, just curiosity. (Got all the books, and love 'em).
Post a Comment