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 Writing Skills From:Kelly Hoffman <kelly -at- NASHUA -dot- HP -dot- COM> Date:Fri, 10 Feb 1995 17:20:23 -0500
Mean Green Dancing Machine (aahz -at- netcom -dot- com) wrote :
> > my ability to program in C turned out to be crucial in writing
> > the manual, in large part because I was able to get the
> > programmer to change the product design in certain ways that made
> > it easier to document.
Matt Harmon <mh1704 -at- ACS -dot- APPSTATE -dot- EDU> responded:
> Meaning no disrespect but, shouldn't a good technical writer be
> able to get around any aspects that make a product difficult to
> document?
Of course. However, for software, it's almost always true that
"easier to document" means "easier to use." As tech writers, we
should be user advocates: Anything that improves the usability of the
software is a good thing, despite the fact that a side benefit is to
make our own job easier. ;-)
(In past jobs, I worked with some programmers who balked at making a
change simply because it would make the product easier to use, but
were perfectly happy to make a change that would make *my* job easier.
It seems they were more comfortable when I offered the "ulterior
motive" explanation. Go figure.)
kkh
--
Kelly K. Hoffman Hewlett-Packard, Network Test Division, Nashua, NH
kelly -at- nashua -dot- hp -dot- com "Reading the manual is admitting defeat."
