The Case for Writing about Tech Writing

Technical writing, being a fairly recently-emergent discipline, is still in the process of developing a set of standards and protocols. In this, it distinguishes itself from well-defined disciplines such as mathematics, empirical science, deductive logic, and (even) cooking.

Despite the field's incipient nature, technical writing has been described in a number of books that are worth study and discussion.
For instance, in the office that Tim and I work in, everyone is issued a copy of JoAnn Hackos's Managing Your Documentation Projects and is told to read it. Candidly, I doubt that many of our recent hires persist very long with Hackos's book, but only a cruel and heartless martinet would hold it against them. It's tough to understand how Hackos's 5-phase model of the publications-development lifecycle is relevant to your new job writing something you don't yet know about a technology that isn't yet completely developed. It's much easier to understand how learning about the technology you're writing about is relevant to your job than to understand where your organization is classified in Hackos's process maturity model for publications organizations or which of the five phases of the publications-development life cycle model you were hired during. Probably already you've quit reading this paragraph because of the long and unintuitive nature of these terms, and have skipped ahead to find something more engaging, making the same judgment and taking the same action (in miniature) that our new hires do.

Technical writing is--under most circumstances--the most boring writing in the world. It remains so until suddenly, due to exigent circumstances (an angry boss, a dead car battery, a confusing defibrillator), you care about the content of the technical writing. Then the technical writing containing the content you're interested in becomes--for a brief while--the most interesting writing in the whole of literature. In those tense moments--searching for the software feature that will get your boss off your back, or searching for the location of the car battery in the unfamiliar hired car as the desert sun beats down like a hammer, or fumbling with the paddles over the chest of your rapidly-expiring spouse while trying through tears to read the poorly-translated manual--you become intensely, minutely critical of each clause of the technical document even as you scan it, hoping to gain the knowledge you need to get out of the situation that drove you to the documentation.

Poor technical writing not only prolongs crisis situations, it prevents people from learning new things. It doesn't take a long paragraph to demonstrate this: just think of one of the many things you've taken an interest in over the years only to give up that interest after reading a few dozen pages of confusing gibberish. Consider how many more things you would know if the books written about them had been more engagingly written, and had presented the information you wanted in a more accessible, more engaging way.

So: technical writing is--despite what people may feel, most of the time--actually important to people, and for that reason writing about technical writing is important to us, the people who create technical documentation.

And for that reason, I'd like to make a list of books about technical writing that are worth reading, so that we can have a decent bookshelf and have some common experience to discuss.

See our next blog post for a list of books about technical writing.

Note: Tim Hildred is on holiday until mid-November. Zac Dover is blogging in his absence.