I no longer plan to update my books to fix technical errors.
It's not that I'm too lazy to do it. It's that in order to fix errors, I have to be able to identify them. That's something I no longer trust myself to do.
If you write books and you're anything like me, you make mistakes. You can read and reread 'til your eyes bleed, test 'til your heart gives out, proofread 'til doomsday, and cajole the most exacting technical experts into reviewing your manuscript 'til they stop answering your email, and still you'll publish stuff that's wrong. Some of it will be laughably wrong. I don't know why. That's just the way it is. At least that's the way it's been for me.
Since originally publishing Effective C++ at the end of 1991, I've done my best to fix errors in my books as soon as possible after I found out about them. When I found out about a bug in printing n of a book, I normally worked with my publisher to fix it in printing n+1.
I most commonly find out about bugs from readers. They send email describing what they think is a problem, often including what they believe is a fix. If you look over my books' errata lists (links are at the bottom of this page), you'll see hundreds of problems I've addressed in response to reader reports. I'm grateful for every report I've received. Each time I updated a book to include fixes stemming from reader reports, I've updated the book's acknowledgements to include the names of the readers whose reports have improved the new printing.
In my experience, most bug reports are valid. But some are not. Sometimes readers assume that the compiler they use is Standard-conformant, but it's not. Sometimes they are unaware of or misunderstand provisions in the Standard. Sometimes they make mistakes copying the code out of the book before running their tests. Their best efforts notwithstanding, readers, like me, are fallible.
So when I get a bug report, the first thing I do is evaluate whether it's valid. Given the technical nature of my books, the complexity of C++, and the finickiness of my readers, this is often challenging. Separating valid bug reports from (sometimes subtly) invalid reports requires I be at the top of my game. Otherwise, I risk rejecting legitimate bug reports or, worse, editing my books to incorporate invalid revisions.
This applies only to the technical material in my books. It just so happens that my brain here is only mostly dead. For the time being, I figure I can still evaluate the accuracy of reports about incorrect fonts, missing words, improper formatting, etc. So if you find an error of the non-technical variety, let me know. Heck, if you find what you believe is a technical error, go ahead and send it to me, if you want to. Just don't be surprised if what you get in response looks a lot like the reply above.
Scott
It's not that I'm too lazy to do it. It's that in order to fix errors, I have to be able to identify them. That's something I no longer trust myself to do.
If you write books and you're anything like me, you make mistakes. You can read and reread 'til your eyes bleed, test 'til your heart gives out, proofread 'til doomsday, and cajole the most exacting technical experts into reviewing your manuscript 'til they stop answering your email, and still you'll publish stuff that's wrong. Some of it will be laughably wrong. I don't know why. That's just the way it is. At least that's the way it's been for me.
Since originally publishing Effective C++ at the end of 1991, I've done my best to fix errors in my books as soon as possible after I found out about them. When I found out about a bug in printing n of a book, I normally worked with my publisher to fix it in printing n+1.
I most commonly find out about bugs from readers. They send email describing what they think is a problem, often including what they believe is a fix. If you look over my books' errata lists (links are at the bottom of this page), you'll see hundreds of problems I've addressed in response to reader reports. I'm grateful for every report I've received. Each time I updated a book to include fixes stemming from reader reports, I've updated the book's acknowledgements to include the names of the readers whose reports have improved the new printing.
In my experience, most bug reports are valid. But some are not. Sometimes readers assume that the compiler they use is Standard-conformant, but it's not. Sometimes they are unaware of or misunderstand provisions in the Standard. Sometimes they make mistakes copying the code out of the book before running their tests. Their best efforts notwithstanding, readers, like me, are fallible.
So when I get a bug report, the first thing I do is evaluate whether it's valid. Given the technical nature of my books, the complexity of C++, and the finickiness of my readers, this is often challenging. Separating valid bug reports from (sometimes subtly) invalid reports requires I be at the top of my game. Otherwise, I risk rejecting legitimate bug reports or, worse, editing my books to incorporate invalid revisions.
Having retired from active involvement in C++ over two and a half years ago, I'm no longer at the top of my C++ game. That's been true for a while, but until recently, I've remained confident in my ability to assess incoming bug reports. Recently, however, a report came in where, having thought about it for a while, I realized that I just didn't know whether it was valid. Rather than give myself a crash course in C++ to the point where I could make an accurate determination, I decided to throw in the towel. I sent this to my reader:
As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action.From now on, if you send me a bug report about technical material in my books, you'll probably get the same response.
This applies only to the technical material in my books. It just so happens that my brain here is only mostly dead. For the time being, I figure I can still evaluate the accuracy of reports about incorrect fonts, missing words, improper formatting, etc. So if you find an error of the non-technical variety, let me know. Heck, if you find what you believe is a technical error, go ahead and send it to me, if you want to. Just don't be surprised if what you get in response looks a lot like the reply above.
Scott
12 comments:
Makes total sense, Scott. Rock on, your work speaks for itself.
Your email to the "bug submitter" (my term, hence the quotes, even if that isn't the correct use of quotes) was very polite and sincere.
Please throw us a bone every so often and post something, even if it's about something entirely unrelated to C++.
Scott, it's okay, you can go play Golf now. You don't have to fight anymore.
Thank you for your work in the past. It helped me in my life, a lot.
I think you should just have a webpage where you post the bug reports (upon approval) along with a comment section. If there is a nice clean interface for viewing, sorting, and searching the bug reports, most of them could likely be solved via crowd sourced help.
No reason not to delegate this to the public, and you could do a lot to help that process with a good web page. Given that your books are significant enough to the public to warrant this, I think it would be a good idea.
@Anonymous: I think having a crowdsourced site to post and discuss possible errata is a fine idea, but it's not one that I'm personally interested in pursuing. If somebody were to set up such a site, I'd happily refer bug report submitters to it.
We appreciate very much everything you've contributed to the community. Lots of books go uncorrected over time. Can't keep it up indefinitely.
Perhaps you can ask people to post bug reports as "Is this a bug" questions on stackoverflow.com, and then send you the link. That will eliminate a large number of false bug reports.
@Anonymous: That's not an unreasonable suggestion. Perhaps I'll give it a try.
The stackoverflow idea seems like a good one, however, I can hear Brian groaning about stackoverflow, though :-)
Thanks, Scott,
I am a reader from Taiwan,
and I've to say, your books helped _a lot_.
Very much appreciated, and yet, have fun!
Thanks!
Scott, your passionate work over the years is very much appreciated. I'm sure I can speak for many of us, that your publications are still valuable practical citations for many years to come.
Thank's for all the fish Scott. ;-) Enjoyed reading your books. Got a *lot* of value from them.
Scott, I have read all your books. They taught me C++ in a fantastic way. I remember the first time I read Effective C ++, I never thought that reading a C ++ programming book could be so pleasant. I loved the details and the depth of the explanations, the easy to understand format and, of course, your sense of humor and your unpretentious personality.
Best wishes from Italy!
Post a Comment