John McIntyre, whom James Wolcott calls "the Dave Brubeck of the art and craft of copy editing," writes on language, editing, journalism, and other manifestations of human frailty. Comments welcome. Identifying his errors relieves him of the burden of omniscience. Write to, befriend at Facebook, or follow at Twitter: @johnemcintyre. Back 2009-2012 at the original site, and now at

Monday, June 1, 2009

To err is human

Imagine, if you can, a book a copy editor would find more inviting than Joseph T. Hallinan’s Why We Make Mistakes (Broadway Books, 283 pages, $24.95). Mr. Hallinan, who formerly wrote for The Wall Street Journal, offers a catalogue of our predispositions to fallibility.

Because we — that’s us as a species — are impatient and have a misplaced confidence in our ability to figure things out, we don’t read the instructions. Subaru, for example, determined in study of customer complaints that one in five questions to the company’s call center involved a point explained in the owner’s manual.

We are too easily distracted and dangerously prone to the illusion of multitasking. Talking on cell phones while driving, or worse, texting, divides our attention dangerously. So do all the gadgets with which automobiles come equipped. An Eastern Airlines jet crashed in the Everglades because the flight crew got so distracted over determining why the landing gear indicator light hadn’t come on that they forgot to operate the airplane. The industry has a term, “Controlled Flight into Terrain,” CFIT, to describe just such occurrences.

We are overly reliant on our perceptions, which are partial, and our memories, which reconstruct rather than record. This is why eyewitness testimony in trials so regularly contributes to the conviction of innocent people.

And, copy editors should take particular note here, we defer too much to experts, who are in turn overconfident in their expertise. The medical industry, in an effort to reduce anesthesiologists’ errors in the operating room, has taken a number of measures, among them “attitude adjustment.” Pay close attention: “They began discouraging the idea of doctor as know-it-all, and encouraged nurses and others to speak up if they saw someone—especially the anesthesiologist—do something wrong. In error-speak, this is known as ‘flattening the authority gradient,’ and it has been shown as an effective way to reduce errors.”

Some of the scandals in the newspaper industry — the plagiarisms and fabrications, the articles based on shaky information — can be attributed to too steep an authority gradient. The copy editors and lower-level editors were either not encouraged to question the work of stars or decisions of the high command, or were ignored when they did.

One way to avoid error is to develop systematic defenses, like the checklists used in the airplane cockpit and the operating theater. The sorts of questions that copy editors ask are like those checklists: Is this right? How do we know this? Who says so? Do we have independent confirmation? Does this make sense?


  1. Outliers: The Story of Success, by Malcolm Gladwell, has an interesting chapter about that authority gradient and how it relates to flying airplanes.

  2. A reader who has been having trouble with the comments function here suggests "that Subaru has only itself to blame if people can't find the information in the owner's manual. The index is just terrible; every time I look for something, I have to browse because it's not in the index (or not where a normal reader would expect it, anyway)."

    Point taken. And anyone who has had to deal with the instructional material for, say, computer hardware or software is aware of how much text is generated without much thought of the reader.

  3. I don't have a Subaru, but I strongly agree with your reader who has a problem with the manual. I don't think I've found any manual (cameras, printers, computers, phones, etc.) useful in the last 10 years or so. In fact, I've found many of them to be complete wastes of time, not only because of poor indexing, but also because of incomprehensible writing, and in a few cases instructions completely contrary to what actually needs to be done! I think I spent 3 days on the phone with HP a few years ago, trying to get a printer/fax to do what the manual said it should do, only to learn that what's in the manual is nothing but wasted ink on paper. I still can't make it do what I want, because the steps the tech told me aren't written down anywhere and I have a poor memory. Oh well.

  4. As a person who writes and edits computer software documentation, I feel duty-bound to protest that not all documentation is useless. Also, I have a point about erring and being human, which I'll get to in a moment.

    It is true that documentation can be pretty bad. (I mock it regularly myself.) But let me note the following:

    * Documentation is rarely a buy/no-buy feature for a product, and as such, short-sighted companies sometimes try to cut corners. (They pay in the long run, of course.)

    * Users are not in a benevolent frame of mind when they open the documentation; they want to work with the product (now!), not sit around and study a manual. That's a very tough audience to please.

    * Complex products often require users to understand certain basic functionality. For example, on a camera, the steps for how to take a photo on a timer probably assume that you know all those buttons (which are illustrated in the first few pages of the manual).

    * Products themselves have too many features (which most users don't want or need). This often leads to poorly designed functionality, with obscure, multi-modal interfaces. Documentation can only go so far to make up for a badly designed product.

    More generally, writing clear documentation is very hard. Indexing well is hard and time-consuming. Creating good illustrations is hard, as is creating good layout. As with designing the products themselves, it's not often that all of these things are done really well, or that companies are willing to make those investments. Which is too bad.

    Ok, about erring. A commercial pilot I once knew maintained that the reason private planes crash 25x as often than commercial planes was that the kind of people who could afford to buy their own airplanes were people who did not accumulate the necessary wealth by plodding along by the rules. So they were impatient with things like pre-flight checklists, they were overconfident in their abilities, etc. That always seemed like a plausible explanation to me.

  5. Mr. McIntyre, I so appreciate this post! My kids never understand why I won't focus on changing the radio constantly while I'm driving. It's because the car won't drive itself. It seems that other drivers think their cars will, though. And, heaven forbid we should question the stars. I was once commanded to plagiarize part of another product manual because the project leader didn't know plagiarism was stealing; I complained to my company's legal department, and won an award for protecting the place from a lawsuit.

    Like Mike, I am a technical writer/editor who, in "corporate" days, spent much my time trying to be a champion of user-advocacy. The whole point was to write for ease of use and with utmost consideration for the user's point of view. The foremost thought was, "I am the user; what do I want to know, and what's the fastest way to get me productive on the job with this item NOW?"

    We are usually required to meet slipshod product rollout deadlines set by people who know nothing about what goes into making high-quality documentation; if that's not the case, we must make up the deadlines ourselves based on a ridiculous budget. Thus, we make it short and to the point ("chunk" it. See Mike's excellent bulleted list, above). It's largely a lose-lose situation; we do it because we really care about accuracy and want users to be satisfied with their product. Mike is right about the doc being dependent upon the usability of the product in the first place. If it's clunky, the writer is stuck. Designers and engineers often write goofy specs and you have to base your writing on the specs first without being able to do any quality control on the thing. In addition, the creators may spend inordinate time (yours) explaining to you not what the thing offers users, but how clever they are in their design and how cleverly they stuck in the features--not how to use the features (they are in love with their design and ultimately don't care). It starts out promising a robin, and comes out being more like a bear . . .

    The only truly good, and infallible, user manual I've seen is for an old Singer sewing machine that I still have. It was my grandmother's, and the manual's copyright date is in the 1930s. Somebody evidently had sufficient time AND the machine to test it, even during the Depression. As it should be.

  6. I don't know if you allow responses to other comments here, but if you do, this is to sputnik: They don't allow you access to the machine/device when you are writing the manual for it? GAAAHHH! No wonder the end results these days aren't so hot. Seriously, that's a problem. I have to give a nod to SOME of the people who answer the phone help lines though. You usually have to go up the chain of command to get anyone who can help (with the first 3 or 4 people, I knew more than they did--it was so sad), but sometimes you will get a golden one who has the knowledge that fails to get into the manuals. And I wasn't even trying to do anything unusual--just basic stuff, that you would think would be intuitive. Ugh. Now I understand though: If the manual writers are expected to write based text the designers gave them (HA) without getting to test the products themselves--Phew, talk about a "telephone" game!