September 20, 2004

From Gerald R. Lucas

Technical Writing: In Search of. . .

I haven’t taught technical writing in a number of years, so I figured a cool way to begin the class would be to try to figure out just what we mean by “technical writing.”

Most definitions I have found, like this one at docsymmerty, suggests that technical writing makes varying degrees of technical information accessible to various audiences. Others, like Online Technical Writing, nuances this by adding that all disciplines are composed of technical knowledge – information that is “not widely accessible” – and strong technical writing would be able to make information available to the layperson. Lanon suggests that technical writing appeals to our understanding, rather than our imagination, like creative writing does. This idea, then, posits the paramount importance of the audience when considering any form of technical writing. Technical writing produces documents that are reader oriented and efficient, and allow “colleagues, customers, and supervisors read to use our knowledge.”[1]

Audience, then, in technical writing, will depend on who is most likely to use our knowledge in the most efficient way possible. This suggests that not only does the prose need to be precise and articulate, but the document must be designed in such a way as to maximize this efficiency: sloppy design makes for a poor document. This observation may be supported by consulting almost any web site on the Internet. The prose could be the best on the planet, but if the site cannot be accessed easily, then so what. Think of it another way: it’s like my student who was complaining about his grade on an essay. He said: “I know the grammar is poor, but the ideas are good!” You may have good ideas, but they won’t mean anything if obfuscated under poor sentence structure and typos.

So it seems to me that any good definition of technical writing must begin with the audience, as Alred does under “technical writing style.”[2] Your specialized knowledge means nothing if it cannot be shared. The best technical writing shares this knowledge most efficiently with the intended audience. Strong technical writing does not make its audience work too much. Writing Guidelines for Engineering and Science Students begins its discussion with audience analysis and offers some good tips in this area.

Technical writing uses an objective, not subjective, tone.[2] An audience is rarely concerned with editorializing, which would feature the political opinions of the writer; thus, writing that focuses on the writer is subject-oriented. Writing that highlights the specialized information – be it a computer, genetic engineering, ship construction, or literary criticism – and tries its best not interject the subjectivities of the writer would be more object-oriented. Indeed, to remove all authorial voice and opinion would be a futile task, and probably produce a document that feels like it was written by a computer.

Technical writing, and professional communication for that matter, favors documents that are ostensibly free of personal opinion (they need your professional opinion), but they do not have to be dryer than a cracker in a desert. According to Alred, a strong technical writing style is “direct and utilitarian, emphasizing exactness and clarity rather than elegance or allusiveness.”[2] Still, this does not necessarily mean dry and utterly boring.

Yet, how does technical writing maximize the flow of information and minimize misunderstanding? Maybe technical writing is heading in the direction of open source? Consider the Wikipedia, an online encyclopedia that depends on a community of writers and readers for its continued development. Anyone can contribute, and anyone can rewrite what has already been written. With many eyes considering the writing – not only in its facts but also in it presentation – then maybe the final product might be the most effective for the most people? Perhaps, unlike the business model for most creative writing (copyright closely guarded usually for financial reasons), technical writing should consider an open source model. Good writers must also be good readers.

Citations

  1. Lanon 1997, pp. 2-3.
  2. 2.0 2.1 2.2 Alred 2003, p. 533.

Works Cited

  • Alred, Gerald J. (2003). Handbook of Technical Writing  (7th ed.). Boston: Bedford / St. Martins.
  • Lanon, John M. (1997). Technical Writing (7th ed.). New York: Longman.