Getting to the Point in Plain English

You could say that the core meltdown that occurred on Three Mile Island in March of 1979 was the result of an engineer’s poor writing.

Months before the accident, an engineer sent a long memo to every engineer at the facility. Filled with jargon and detailed explanations, the most important element, which might have kept "Three Mile Island" from becoming a household phrase, was left to the penultimate sentence.

The example is a favorite of Les Perelman, Director of Writing Across the Curriculum for MIT’s Program in Writing and Humanistic Studies. The specific problem with the memo, as Les points out, is that the most crucial point was hidden in the last paragraph of the memo. "Important information is not a treasure that you bury," he says.

But the memo also illustrates a more general problem that often plagues engineers when they turn to the language of the layman: The proof is not the point, it’s the point that’s the point. Reports, memos, e-mails, and speeches to mangers, subordinates, nonengineers and engineers alike, need not, and should not, attempt a complete proof of any problem. Clarity and being concise are what count. "Proof is not the point," says Perelman, "That’s why God created appendices."

The career paths of MIT alumni changed dramatically in the 1980s and 1990s. Where they once might have started as bench engineers and worked their way up to become senior or principal engineers, now, after five years or so, they were becoming managers, at which point the amount of writing they had to do doubled. Meanwhile, surveys of alumni revealed that they felt confident with all the skills their jobs required of them except for the ability to write and speak effectively. Subsequently, MIT started their Writing Cross the Curriculum program. The communication component for many courses now counts for 20 percent of the grade. "MIT students and engineers are taught to be optimizers—they’re going to optimize any system. At any less than 20 percent, the students could blow it off," says Perleman.

To Perleman, the trick for his students and for engineers in general, is to realize that mathematical sense and the more general reader sense are two entirely different entities. Engineers often have several ticks that reveal they haven’t totally separated the two. One is the run-on sentence. A sentence filled with multiple clauses and conjunctions might make logical sense for someone willing to parse it out, but the typical reader will get lost by the end of it.

Perelman tells his pupils to think of the reading human as a computer. Short-term memory keeps track of what is said verbatim. Then the human brain changes the verbatim sentence to a logical proposition and stores that. "Which is why if I ask you ‘What did you say?’ you probably won’t be able to give back verbatim what I said, only the logical, semantic content of what I said," says Perelman. "The human brain has a very small amount of RAM. Basically, what they’re doing is overloading the buffer."

In addition to buried treasure and run-on sentences, engineers hoping to write to the point, and not the proof, should not fall back into proof-like habits. "Some engineers get so involved in the process that they don’t translate it into English. They’ll plop in 15 lines of pseudo-code and expect that everyone is going to understand, instead of giving a two- or three-line explanation of what the pseudo-code does. The worst I have ever seen is when someone used a memory address as a verb; gave the hexadecimal memory address. Something like ‘It then 6a4b1 it.’ "

To avoid such pitfalls, engineers should keep in mind both who their reader is and also that they need only tell, not prove. "The whole point is that a mathematical explanation can be very complex because you can’t break it up," says Perelman.

"They want to continue that in words, and it doesn’t work the same way."

Michael Abrams is an independent writer.