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.
Michael Priestley wrote...
> Imagine if somebody walked up to you and said they were going to create a
> complex piece of software based on an environmental report you just
> published using FrameMaker, but had NO idea how to use FrameMaker or even
> what it could do (and had no intention of learning). Would you trust this
> person to write such a piece of software?
That's an absurd comparison and your translation is incorrect. A more
appropriate translation would be:
"Imagine if somebody walked up to you and said they were going to create a
complex piece of software based on an environmental report you just published
using FrameMaker, and they had no idea how to program or read (and no intention
of learning)."
> My point being: someone's credibility should not be gauged by their command
> of irrelevant knowledge. Knowledge of the audience's domain is what's
> important for a writer, not knowledge of the programmer's domain. The only
> exception to this is when the audience's domain is programming.
I could not disagree more. It is foolish, even dangerous, to think there is
"irrelevant" knowledge. If you're documenting some product or technology, you
should know as absolutely much as possible about it. There is absolutely no
excuse for technical ignorance. Credibility as a technical writer absolutely
hinges on a person's ability to consume, digest, and accurately explain
technical concepts.
Regardless of whether you are writing for programmers or monkeys, you should
have detailed technical understanding of what you're documenting. It is
*completely impossible* to document a product or technology intelligently if
you do not understand how it works or how it was built.
> That said, I agree that developers are more likely to respect you if you
> have a clue about what they're doing. I just don't think it's fair or
> logical.
Its absolutely fair and logical. Why should *anybody* trust you as an author if
you are unwilling to become an expert about your subject matter. Would you
want to read a history text book from and author who said "oh, I don't really
need to learn about all those wars and stuff. I'll just make sure we use the
correct fonts and tables."
If you are unwilling to talk tech with engineers, do not be surprised if they
are unwilling to talk doc with you.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by SOLUTIONS, Conferences and Seminars for Communicators
Publications Management Clinic, TECH*COMM 2001 Conference, and more http://www.SolutionsEvents.com or 800-448-4230
---
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.
