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.
Pam Owen <powen -at- MAIL2 -dot- LMI -dot- ORG> responded to my assertion about the need for
technical communicators to be knowledgeable about their subject matter by
disagreeing with a choice I did not make. I did not say that I preferred a
technoweenie engineer to document a product instead of an unknowledgeable tech
writer; I said that I preferred a knowledgeable tech writer to document a
product instead of an unknowledgeable one.
In my experience, when writers try to cover a subject with which they are
unfamiliar, it shows. This is apparent by inspection in the newspaper
business: even the perfectly competent beat reporter struggles when a story
from some specialized field like science, medicine, law, or technology breaks
into the headlines. That is why there are niches for science writers, medical
writers, legal writers, and so forth. When a technical writer tries to
document something without having the time, taking the time, or at least making
the effort to learn the subject, the results, as I suggested in my earlier
posting, can be useless.
Given the choice, I would prefer a job candidate with experience in the field,
and so would any employer. I think that's normal and reasonable.
Of course, I don't mean to say a writer cannot *become* knowledgeable in a
field over time. Me, I've gone from writing about business minicomputer
operating systems to office-automation products to networking software to
network management to network operating systems to PC sales support suites, but
in each case it took time to learn what it was I was documenting.