Archive | January, 2012

Technical writers

11 Jan

People out in the working world many times find that their jobs require a lot of writing—a job that many of these people don’t exactly recall signing up for. Whatever the case, the writing still must be done, and it must be done well in order to meet the needs of those receiving it and of those it represents. Technical writers have the opportunity to sort of come to the rescue during these times of crisis for non-writers.

A technical writer must be able to see and analyze the needs involved in creating or editing documents for others before doing anything else. The job of the writer is to use his or her knowledge and set of skills to fulfill those needs and reflect the qualities of the person or business involved in the best way possible. This essentially means that the technical writer is a representative for those whom he or she is working for, which places a load of responsibility on the writer. The writer must make sure he or she accurately reflects the client because the end product establishes some kind of understanding of the client (or client’s business) for the audience. This is especially significant in terms of ethos, pathos, and logos. In each of these aspects, the writer should be able to enhance the client’s reputation in a good way.

In Miller’s article “Technical Writing Theory and Practice,” I found her description of practicality in the “low sense” to be kind of amusing when she talked about it in relation to technical writing and the Greek city-state (15). Her explanation of the Greeks’ delegation of work seemed to be an analogy to the work of a technical writer. I never would have thought of technical writing in that way on my own, but I guess it makes sense that communication in general is (or should be) a basic task in the working world, but communication—through writing, especially—is viewed negatively as another thing on the chore list and is easily passed on to someone else. On the other hand, I don’t think I know anyone who would consider technical writing “prehuman,” or part of “the animal realm.” But, thankfully, Miller clarifies that at the end of the section, stating that, “In a world in which it is more dishonorable to own slaves than it is to work for a living, we might question whether this association should prevail” (15).

Two years ago, I took C Programming because I thought I wanted to minor in Information Technology. I learned very quickly that I should not be a programmer, but if given the time and opportunity, I could pick up on the C programming language enough to read it fairly well. By the end of that semester, I couldn’t program a thing by myself and barely scraped by in that class, but I had learned enough about programming to be familiar with the technicality of it and understand its use better. I feel that this really shaped a better understanding for me in technical writing as well, especially in regards to the job I’ve recently started at the AU OIT.

It’s nice to be somewhat familiar with the world of computer languages so I can actually write about the sites and software with a slightly deeper perspective without having to ask questions about every minute thing. On another note, the programming class familiarized me enough with code to know that any “minute thing” can also make a huge difference. So, anytime I’m not sure about something, I make sure to ask, or at least make notes to ask, because it’s crucial to document their work accurately, as it is with any technical writing task. Technical writing can be a lot of work, but fortunately, the responsibility is a choice and challenges rather than enslaves.

Miller, C. R. (1989). Technical Writing Theory and Practice. Fearing, B. E. (Ed.), & Sparrow, W. K. (Ed.).

New York: The Modern Language Association of America.