TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The most interesting part of this discussion to me is to contrast Tim
Altom's "levels of thinking" with Michelle Davis' "(my structure) is all
stored in the enormous database called my brain."
Clearly this is technical writing and not short stories or novels, and
structure has its place. Surely each chapter in a manual or manual in a
series should be organized in the same manner; notes, cautions, or warnings
should be presented the same way every time, etc. And, I suppose just as
clearly, this stuff can be basically accomplished either following one's
internal guidelines--i.e., skills, experience--or by following a cookbook.
I have to say that tools such as Tim espouses are good things and serve as
communication vehicles for use when working with those unfamiliar with this
field and more importantly as checklist or reminder or review material for
those who are or learning material for those in training to be.
Nevertheless, I offer that skill is most important and caution that
structure can be seen as a "magic bullet" by the uninformed that, for
example, convinces them that "secretaries" can do technical writing given
In addition, and it seems more relevant to Tim's position, "structure,"
i.e., a level 3 approach, is surely a useful tool for selling contract
technical writing services (and that's not a bad thing). I can see myself
in the position of having on staff a writer or writers who are creative and
out-of-the-box thinkers. When it comes to hiring contract writers, on the
other hand, I may assume a "practical" mode and look for those with tools
for getting the job done quickly and efficiently.
For internal staff for sure and I suppose just as surely for procured
writing, perhaps the best "structure" is that provided by testing the
writing with potential users--does it work? Hey, if a "hip shooter" can
please the user, that seems all the "structure" required, and perhaps the
(first) term needs rethinking. Just "a pro" might do.
And, as postscript and perhaps an expanded direction for this thread,
"structure" so far sounds like something used more often in situations where
the writer is called in after the product or process is developed. I sure
do prefer the situation where the writer is part of the product design and
development process from its inception. Where the writer has some product
knowledge; maybe even engineering qualifications or the like along with the
writing qualifications. This is likely a different kind of "structure"
altogether, and ... how often do contract writers participate in this