Latest posts by techwriter (see all)
- How to Number Your Documents Properly – A Document Numbering Strategy - April 24, 2017
- How to Avoid Repeating Words in a Headline - April 18, 2017
- Leveraging Multi-Function Printers With Document Imaging Software - April 10, 2017
One sometimes hears the comment that technical writing is not only “boring” but “unnecessary” as well. Nothing can be further from the truth.
Good technical writing at its best is INVISIBLE. You don’t even know it’s there and that scores of people have benefited from it. And at its most extreme, yes, good technical documentation do save lives.
Bad technical writing, on the other hand, can be a frustrating and maddening consumer experience, at the least. And at its worst, bad technical documentation can outright kill people.
So I think the “unnecessary” charge is actually a COMPLIMENT since it denotes an excellent documentation that manages to keep itself under the radar, so to speak.
Here is an example… When Captain Chesley B. “Sully” Sullenberger III and his crew managed to land USAir Flight 1549 safely onto the Hudson River back in January 2009, everybody applauded the Captain, as they should. It was a spectacular achievement worthy of the highest praise.
Perhaps you might also remember that the Airbus 320 used its Auxiliary Power Unit (APU) manufactured by Honeywell Corporation after losing both of its engines. That’s how Captain Sully could steer his Airbus 320 to a safe landing.
Now, here are two questions.
1) How do you think Captain Sully was trained that well, at that spectacular level of expertise?
2) How was the APU system installed and configured properly to make sure that it kicked into action smoothly when the “moment of truth” arrived?
Excellent technical communication is a part of the answer to both of these questions.
Think about all the technical documents that Captain Sully has read, studied, and memorized to learn how to fly military jets and passenger planes both in a simulator and also in real training flights? Guess who wrote all those manuals and guides?
Again, think about all the installation and configuration guides used to install the APU system properly into a flying hi-tech wonder such as Airbus 320. Do you think the technicians would know how to do that if it weren’t for the untold hours of work that unnamed technical writers poured into those documents? Would you agree that no documentation EQUALS no APU installed-and-working-properly?
The reverse is equally true. Bad documentation almost always leads to one disaster or another.
Do you remember what happened on Mars in September 1999? NASA’s $125 million Mars orbiter crashed into the Mars surface and burned, instead of landing gently as planned, because… one team of engineers used metric system while another used English units for a crucial spacecraft maneuver! That really happened. And who do you think forgot to pay attention to that simple unit conversion between two different sets of documents? Why, a technical writer of course.
That’s why I shake my head in disbelief every time I hear someone talking about the “insignificance” of technical documentation; that how technical writing “does not matter” and is “unnecessary”…
I pray inwardly that those very same folks never fly in an airplane assembled with deficient or “unnecessary” documentation since their lives may actually depend on it and they may not even know it.