First things first: welcome, welcome, and welcome! I am happy to welcome you to my tiny little corner of the interwebs.
The word “errata” is a plural and comes from a Latin root meaning mistake. Similar words include error and erratic. (Erratic really means something more like inconsistent.)
It is unfortunate, but wholly appropriate, that my first blog post here details some errors in the First Edition of The Dog Barks When the Phone Rings: An Engineer’s Guide to Solving Problems.
Shortly after distributing a few copies from the first production print run, my friend Jack Lane quickly read through the entire book. The next day he said, “Bob, you forgot something really important. You don’t talk about the situation where you have two problems at the same time!”
My reply was confidently stupid. “Sure I do. It’s right here in Chapter 20, here on page—oh, rats. You are right!”
I was pointing to an ambiguous reference to peeling an onion that was supposed to kick off a whole discussion of digging through multi-layer problems. I even use some of that discussion as part of a demonstration in one of my short talks based on the book. But it had not made its way into the text.
Jack shared an anecdote that had made him recognize my missing discussion. Several years prior, he had completed construction of an exquisitely detailed, remote controlled, scale model of a paddle-wheel steamboat. It is about four feet long and quite impressive. From time to time there are ceremonial launchings of the boat, shared with friends or family.
A few days before our discussion, Jack had transported the model to a distant location. Before the launching, he had checked the operation of all of the electrical functions and found that most had stopped working. Needing quick resolution, he had explored some of the battery connections and found an open circuit in one wire. A jumper wire with two alligator clips restored that connection, yet did not fix the problem. After a lot more debugging, he found that a connection spring at the bottom of a battery-holder assembly had become overstressed and no longer made contact to the bottom of its cell. He applied a toothpick as a spring-stretcher, and all was right with the world again. Well, at least the boat worked again.
Doing his extra pre-launch testing had revealed problems which were likely caused by the shock and vibration of transportation. The net result was that the launching went off successfully and happily.
There is an important lesson here. Having found one problem, Jack did not simply stop debugging. He had to fix that first problem and then continue testing and fixing. If he had stopped after fixing the first problem, the boat still would not have worked. If he had ignored the first problem he had found, fixing the second would not have allowed the boat to work.
Both fixes were necessary to get the boat running. Sometimes, you will have problems where you uncover multiple defects.
There is another error in the current First Edition printing. One entry in the bibliography was accidentally duplicated on page 236. Although I enjoyed The Psychology of Computer Programming when I first read it, it was not intended to be listed twice in a row.
If you find a mistake in my book that belongs in my next errata report, please tell me.
If you find something in my book that you don’t like, please tell me. It is the only way I can make it better.
If you find something in my book that you like, please tell everybody you know.
Best Regards,
bob