What is technical about tech writing? Dobrin may have an answer....

What David Dobrin does in his article “What’s Technical About Technical Writing?” is address ways in which other technical writers try to define technical writing, while also providing his own interpretation of what tech writing should be. What Dobrin first claims is that what tech writers choose to define “determines the definer’s project” (108). What he means by this is that there are two terms that are trying to be defined by technical writers, “technical writing” and “writing technically”. Technical writing, as written by John Walter, consists of the three characteristics format, style, and content (109). These three characteristics are embraced by Patrick Kelley and Roger Masse, who believe that “technical writing is writing about a subject in the pure sciences…in which the writer informs the reader through an objective presentation” (109). Dobrin sums up all this up stating that--according to Walter, Kelley, and Masse--technical writing can only be understood by experience. Writing technically, according to John Harris, is “the rhetoric of the scientific method” which calls for the writer to be objective in their writing and that “the information itself is far more important than the writer’s attitude towards it” (109-110). As an addendum to this, Earl Britton adds that technical writing must also be univocal, that a word can mean “one thing and one thing only” to everyone (111). Dobrin links this idea of objectivity in writing technically to the universalist view of language, which describes that a sentence means a particular thing and it can be understood by all (113). Dobrin acknowledges these views, but promotes his own theory that technical writing should simply accommodate technology to the user. Going against what Kelley and Masse say, Dobrin believes that experience cannot be total nor “sufficient enough to comprehend the texts”, and that the universality of language is flawed--there can be no one definition for a word (109). Instead, Dobrin relates to the monadist view of writing, to “see language as it is actually used, rather than as a formal system” (115). Dobrin sees technical writing as a more fluid form, able to be altered to fit any document, user, or situation.

What Dobrin is trying to accomplish here is what I think every technical writer struggles with at some point: defining what exactly it is that they do. When we are asked by people outside of the field what technical writing is, we frequently go with the definition that Walter, Kelley, and Masse give dealing with style, format, and content. Dobrin is not satisfied with this definition and gives his own, which I think has a great deal of merit. The definitions of technical writing and writing technically are fine, but are also very limited in what they can do. Dobrin’s definition is very adaptable, it adequately defines the core of what technical writing is. What we do is make technology, in whatever form it may take, accessible to users. It could be a new type of Word program, a power tool for the garage, or a way of mailing a package; all of which make use of technology at some point and need to be made accessible by users. By taking up the monadist view of language, the technical writer is not limiting themselves and can better explore the methods for success. Dobrin states that this new definition “questions the values of what we do” but perhaps it will allow us to be “more responsible, more creative, and more fulfilling” in our jobs (122). Despite what it may bring for tech comm, I know this definition has made my answer to what I do for a living easier.