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.
On 3/1/00 12:41 PM, John Posada (jposada01 -at- yahoo -dot- com) wrote:
>It would be apparent that the user had thought about
>the document requirement, had identified specific
>needs, had applied that analysis to their specific
>environment, and was still having problems. Then, even
>if individual issues weren't addressed, I'd have the
>comfort to know that the person would even have the
>first clue about what to do WITH the information once
>I'd sent it.
Just to briefly expand on what you're saying, this is the same set of
skills that helps a writer Work and Play Well with developers. I've
worked with many, many colleagues who visit a developer, sit down, and
say, in effect, "Fill my empty head with information." Developers often
respond badly to this, and send those writers packing. (The writers then
go off complaining loudly to their friends about how difficult and
anti-social those pesky developers are...)
A writer who sits down with the spec (if there is one) and the product
(no matter how rough, buggy, or otherwise dangerous) and learns as much
as possible first will be welcomed with open arms by most (OK, far more)
developers than that lazy writer in my first example.
