Re: Technical Certification

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


Previous by Author: Re: Doing your own graphics (an illustrators perspective)
Next by Author: Re: Automotive writing
Previous by Thread: Technical Certification
Next by Thread: Technical Certification


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads