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.
> We cheer a baseball player, not because of the bat he uses, but how he
> uses that bat.
> We cheer a musician, not because of the guitar he uses, but how he
> uses that guitar.
All true, but we do applaud the virtuoso who can wield the tool with a skill and expertise that
surpasses that of the average.
> Tools don't write documents, people do. No tool in the universe can
> make up for a lack of intellectual ability. That is, if you hand a
> moron a powerful tool, they will just use it to produce garbage
Other than the fact that XML is NOT a tool, it is a technology ... and an enabling technology ... I'm
more or less on your side Andrew, with some reservations.
Does knowing PostScript make me a better writer? No, not really. Does knowing XML make me a
better writer? No, not really. However, I'm not just a writer. I'm a technical writer working in an
industrial environment where production and delivery are part of my remit.
One of my roles as technical writer, if not my one role as technical writer, is to provide the user
with the information she wants in the best way I can. This means that when I'm designing the
documentation, I have to consider all the possible ways that the user might benefit from having
access to that information, be it fully integrated into the software, through online help applications,
through electronic documents, or through paper documents. My knowledge of these technologies,
and my awareness of the tools (and their limitations in implementing these technologies) enable
me to make well-informed choices and to implement them.
XML is enabling me to create a far tighter integration between the documentation and the
software; in future it will allow me to make significant contributions to improving the usability of
software by utilising a range of media and methods of presenting user information and, yes, I am
working towards "common source" (not single source).
As with everything, you mileage varies of course ... we like our writers to be at least passingly
familiar with C, C++, possibly Fortran, HDL, VHDL, RTL, Perl, ... and any others are a bonus.
I, too, get irritated by people who place undue emphasis on tool ability. Yes, writing does come
first ... but it isn't the whole picture. By the same token, I get thoroughly cheesed off with so-called
technical writers who couldn't find their way round a circuit diagram without a guide dog and white
stick, and would believe you if you told them that interpreted languages are to compiled languages
as German is to English.
And for an honest attribute cry out ...
I might say 'element,' but the word is over-worn.
Twelfth Night, III-i
Announcing new options for IPCC 01, October 24-27 in Santa Fe,
New Mexico: attend the entire event or select a single day.
For details and online registration, visit http://ieeepcs.org/2001
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.