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: Object-Oriented Development and Documentation From:Karen Otto <KAREN_OTTO -at- HP-SPOKANE-OM2 -dot- OM -dot- HP -dot- COM> Date:Tue, 2 Jul 1996 09:40:06 -0600
Item Subject: cc:Mail Text
We, too have an analogous situation to your OO team participation.
That's why this Learning Products department started hiring EEs as
TWs.
Our product line is intensely technical (test equipment), and new
systems are coming out every year. Each product is designed for
engineers and technicians.
Some of our typical issues:
1) A new system is just defined. We are documenting how the Test
Equipment works at the same time development of the TE is occurring,
which is also occurring at the same time our customers are developing
the products for which the TE will be used.
2) We (the company) have proprietary programming commands, and are
mostly left up to our (the writers) own devices when it comes to
checking the syntax of these commands in the manual. Therefore, we
frequently have to write programs which check every single command
that is documented in order to effectively QA the manual.
3) We have a usability evaluation/input responsibility beyond the
scope of most writing jobs. We typically find that we have a strong
influence on the User Interface design, and on the structure of the
programming commands.
4) Time to market is critical, since a significant portion of our
profit comes from being in the early part of the market. That's why we
can't compromise on item 1, and just wait until the product is ready
before documentation.
5) The systems are highly technical, with a heavy emphasis on protocol
and RF communications testing. Few engineers can design/understand
both RF hardware and protocol, but we are expected to document them
both, as well as understand just how much the user needs to know about
each topic.
It's not a bad thing, assuming the engineers hired for the writing job
have the necessary writing skills. We have thoroughly proven that not
just any engineer can do this job.
regards,
Karen Otto
(who enjoyed being a design engineer for over 13 years, but made the
change to this job, which I really love)
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-
