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
