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.
Subject:Re: Technical Certification From:Win Day <winday -at- IDIRECT -dot- COM> Date:Wed, 15 May 1996 07:05:49 -0400
At 06:08 PM 5/14/96 EDT, you wrote:
>First, Dan Martillotti stated, "You should not be concerned with whether
>the individual is
>an expert in Frame, Word, or RoboHelp... If there appears to be a problem with
>the new writer learning or using the tools, YOU should send that writer to a
>training class to learn the tool."
>Then David Dubin said:
>>Perhaps I am way off the mark here, (and I am sure that y'all will tell me so
>>if you think it) but I believe that a **good** technical writer is a good
>>writer with certain software skills. As an industry, we do not write with
>>pencil and paper anymore, we use complicated and sophisticated software.
Then Rick Lippincott threw in his two cents:
>Although most of the people on this list are involved in software
>documentation, fact is there are a lot of people out there who still write
>about hardware. Or, like me, do a mix. And it's that mix that causes me
>to fall on the side of Dan, not David. Moving from platform to platform
>hasn't been a problem for me. Any delays that I might encounter in my
>work don't normally stem from a lack of knowledge of Interleaf or Frame,
>but of wondering how a change from T1 to E1/R2 signalling affects a system,
>or what the exact pumping sequence is on a vacuum system, or knowing the
>affect of changing a high-pressure turbine blade design.
>Does this mean that software documentation is easier than hardware
>documentation?
Maybe it depends on the kind of software being documented.
The stuff I write about has two components: the process control package that
runs on refinery distributed control systems, and the PC-based design
software that complements it. I worry less about cross-platform
compatability than I do about feedforward versus manipulated controllers,
commercial simulations that aren't as accurate as they're cracked up to be,
and whether the refinery unit has been revamped since the last set of piping
and instrumentation drawings were produced so the drawings match reality.
Most of the software runs invisibly to the engineer or operator; only the
design stuff is really accessible. I have to create documents, based on
information supplied by engineers with multiple doctorates in mathematics
and engineering, so that the less-educated but competent operators can
understand what the software does to the refinery they're ultimately
responsible for.
Technical explanations about control philosophies are more common than
descriptions of software platforms.
Win
-------------------
Win Day
Technical Writer/Editor
Email: winday -at- idirect -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
