Week 3

Johnson advocates what he calls an “involved audience” which is exactly what it sounds like. Through examples of real world projects, Johnson shows the benefits of bringing the audience in during the development of the intended product. Even without examples, the theory seems to make a lot of sense. The technical communicator must produce a product for the audience, so it is logical that a better product would be made by consulting with the audience to determine their needs and expectations. This shows that technical communicators should be able to communicate across an expanse of mediums (writing, speaking, coding, etc.).

Johnson-Eilola takes issue with the thought technical writers as the people who merely transcribe the work of others. It was a bit difficult to understand exactly what Johnson-Eilola is getting at, but basically, he seems to be saying that learning only the basic and practical skills in technical writing is useful in getting and keeping a job, but having such sparse instruction really limits the field as a whole. He uses the example of third party technical manuals, showing how technical writers can use abstraction and collaboration to write a more complete and encompassing manual for a product. The moral here is that the good technical writers are also strong analysts. They must not only understand the technology, but they must know how to best interpret it and fit it to the needs of an audience.

Coming from a practitioner, the article by Casady is provides perhaps the most useful moral of all: no one wants to read your technical writing. In fact, they probably hate the very idea of having to read a manual or report. Therefore, the good technical writer should accommodate the user by being as clear and concise as possible. Having to read technical writing is a big enough job for the audience. They should not have to decode it as well. However, I think this is really true of any writing. This article seemed to show that engineers and developers sometime perform technical writing and transcribe everything they know in relations to their primary job function – leaving the needs of the audience behind.

These articles really remind me of Dobrin’s definition of technical writing. It really is more than just writing about technology. It is accommodating technology to the user.