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: You Don't Need to Know How From:edunn -at- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 25 Jul 2001 17:45:13 -0400
Maybe I'm just grumpy, but this entire thread is starting to irritate me. (not
you bryan, the thread <g>)
bryan -dot- westbrook -at- amd -dot- com wrote:
>>I've spent hours staring at electrical
>>schematics to make sure that every component, every switch, every wire, and
>>every connector pin was covered in a troubleshooting procedure.
And so have I, but even this depends and does not always apply. If you are
writing troubleshooting procedures for electrical components, often you only
have to troubleshoot as far as the card or assembly.
But lets get this straight everybody. I think everybody is in essence agreeing
with each other. It's just that we don't seem to be able to see through the
smoke generated by misinterpreted posts and ill-informed attacks. I think it's
the abuse of "YOU NEED TO KNOW..." similar to the posts that answer an honest
question with "Only sniveling pathetic writers that I can't stand obsess about
[fonts/design/process] etc. Here's why you're wasting your time...". It's
unlikely many list members have more than inkling about my work environment and
accusing or comparing someone to the dregs of the profession without knowing the
background to the question is just unprofessional. While these posts rarely name
names, it's worse because everyone even remotely interested in a helpful answer
takes offense.
It has now been said dozens of times and I don't think that anyone disagrees
with the following statements:
1 - Know your audience.
2 - To effectively document you must understand/learn at least as much as your
audience is expected to (plus a little more for good measure).
3 - Any technical communicator, given the time and resources, who doesn't desire
to learn as much as possible about what they are documenting is probably in the
wrong profession. Any technical communicator that refuses to learn to the level
of point 2 should be fired on the spot.
4 - Get all safety critical content 100% right.
5 - Within budget and project scope do your best to create a document that is
100% correct and inclusive technically, well laid-out and designed, and whose
production process is well defined so that those who come after you can maintain
it.
If we can agree to the above, I would suggest we all agree to the following:
Accept the fact that not everyone is involved with the same projects at the same
level as you are. Also we are in diverse fields.
Accept the fact that if someone says they are in API documentation and need
intimate knowledge of a programming language that THEY DO. They are not saying
that everyone does and slighting you for your lack of that knowledge.
Accept the fact that if someone says they are only documenting the interface and
how it functions and have no need for any knowledge of the programming behind
the scenes that IS ALL THEY NEED. They are not slighting your in-depth knowledge
in some area.
Accept the fact that you should make some effort to avoid giving anyone the
impression you are slighting them.
Don't try to put everyone into the comfortable little box you've defined as YOUR
job. Firstly, sometimes it seems it's a rather cramped little box and I'm not
sure we can all fit. And secondly because our profession and craft includes
hundreds of little boxes that don't intersect and many large boxes that can
cover a lot of ground.
To stretch an analogy, the highest salary earners occupy both the largest and
the smallest boxes. Accept this opposing truth.
Eric L. Dunn
"It has been said that the opposite of one great truth is often another great
truth."
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Learn about tools and technologies for user assistance developers at
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
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.