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: Process kills the dot.com From:Bruce Byfield <bbyfield -at- axionet -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 26 Oct 2000 13:58:37 -0700
Jim Shaeffer wrote:
> In my opinion, focusing on "the organization and structure" seems a natural
> state.
> Many technical communicators are not in a position to add to the information
> (the gold).
With all respect, your view of the job is very different from mine.
In my view, what tech writers add to the information is their
perspective: their understanding and their knowledge of end-user
needs. If they understand enough, then their feedback about
functionality, interfaces or - in some cases - coding benefits the
entire development team. If they have to ferret out information from
a variety of sources, they may even wind up knowing more about their
subject than any other single individual.
If you don't have this understanding, you cannot properly structure,
organize or summarize the information. You have no yardstick to
measure what you are doing. Of course, you can measure your work
against an external process, but that only tells you that you are
following the process. You can only have blind faith in the fact
that following the process means that you are documenting well. And
while you may be, you are just as likely to be doing a Procrustean
job, stretching a point here or lopping off a section there to make
it fit pre-existing ideas. And the real problem is that you'll never
know.
Also: the act of reordering information, in itself, creates new
information. Consider, for example, the value of a high level
summary. By reaching for a level of abstraction that many of the
developers don't have time for, you can create new insights that you
wouldn't otherwise have. The same goes for an analogy, a chart, or
even the reduction of a process into a procedure. Thought - and
therefore knowledge - isn't a Platonic entity. It only exists (or,
at least, can only be fully perceived) when it is put into words or
pictures or some other kind of communication. In short, the act of
writing is the act of creating new knowledge.
Of course, anyone who's been around for a while has found themselves
in the position of not having enough information, cooperation or
time to understand fully what they were documenting. However, if
that becomes the rule, rather than the exception, then something is
seriously wrong. And, while I make no judgements on anyone else,
personally, I would feel dishonest if I continually worked at this
level. My ability to learn and add to the level of knowledge in the
project is part of what I bring to my job. If I continually do
anything less, then I feel that I am cheating.
> They are in the position of obtaining knowledge (usually from SMEs) and then
> transforming (organizing) that knowledge into something that makes it easier
> for the end user to also obtain the same knowledge. The technical
> communicator is not in a position to make judgements about what is valuable
> and is not in a position to increase the fund of knowledge that is
> available.
Organizing information is making a judgement. In writing a manual,
you always have to decide what is relevant for your particular
audience, and, in some cases, what you have space to mention. Also,
the ordering of information is a judgement about what is important
or useful.
> Knowledge, like mass in physics, is neither created nor destroyed by a
> technical communicator. It is all a matter of changes in form. Therefore,
> the natural focus is on the forms and the processes for transformation.
Yes, and if you don't know what you're doing, changing the form can
have devastating effects :-).
--
Bruce Byfield, Outlaw Communications
Contributing Editor, Maximum Linux
604.421.7189 bbyfield -at- axionet -dot- com
"All those people that you mention,
Yes, I know them, they're quite lame,
I had to rearrange their faces
And give them all another name."
- Bob Dylan, "Desolation Row"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn how to develop HTML-based Help with Macromedia Dreamweaver!
Dec. 7-8, 2000, Orlando, FL -- $100 discount for STC members. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Your web site localized into 32 languages? Maybe not now, but sooner than
you think. Download ForeignExchange's FREE paper, "3 steps to successful
translation management" at http://www.fxtrans.com/3steps.html?tw.
---
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.