Re: TWs and Creativity [Was: Odd Survey....]

[Dan BRINEGAR <vr2link -at- VR2LINK -dot- COM>]

This is a long summary of a really long response: to make sure there's no
misunderstanding, I want to point out that I don't disagree with Steve on
any fundamental issues in his post 8-)

>Date:    Fri, 1 Aug 1997 13:21:47
>From:    Steven Jong <SteveFJong -at- AOL -dot- COM>
>Subject: Re: Odd Survey explained [LONG]
>
>Dan Brinegar wrote a long and eloquent piece on creativity and technical
>writing <snip>.
>

Steve, first off, thanks for writing! Because I was ranting, and because
I assumed my intended audience had a greater knowledge of my agenda than
they do, I failed to cover some some basic issues, and created some
unnecessary ambiguity, and a disagreement where it doesn't really exist.
Our argument as techwriters and communicators is not on the *goals* we
have for ourselves and our customers, the only debate which I can see as
material is about *execution*  (No, I don't mean capital punishment
<giggle>). And such debate is a Good Thing.

Mea Culpa!

("My Fault!" for those of you following another thread 8-)

>To summarize, Dan wrote that breaking down tasks
>into the smallest, simplest components possible, and then making people
>repeat those tasks endlessly, results in a kind of soulless consistency.
>Creative people, Dan said, would flee such an environment,
>robbing it of any chance to be innovative <snip>

[Correct me if I'm wrong, this is where Steve disagrees-djb]

Oh, dear, it's not "soulless consistency," I see or fear,
but rather a "soulless inflexibility" resulting from a limit to creativity
and discretion.

I think we're confusing "consistency" with "routine."

Steve sez:
>Consistency is the very hallmark of every
>definition of quality I've seen

Of course, that's why we use methodologies such as Information Mapping (tm)
or Structured Publishing.

Consistency and the elimination of ambiguity are the first lessons of
technical communications (Rule #1: "Dear Mom...", and Rule #2: "Your
customers could die if you screw this up and they don't understand what
you've told them.").

If every application, help system, or document we were to produce
required the customer to learn all-over-again how to use it, we'd very
frankly be failing our first duty and screwing our customers. (These
rules apply to engineering and technology-type industries, and not to
"pure art.")


[NOTE: My full reply to Steve is larger than your average TECHWR-L
digest of a year ago, so I will refrain from posting the whole thing to
the list itself: If ya wanna see the whole thing, check the "Going to
Rome" pages at <http://www.giaco.com/~vr2link/Going2Rome/>,
pending permission from others quoted here, of course.]

[Disclosure: There's a lot about *the Business Case* in the full reply, and
it may not appear readily applicable to techwriting, but I have to
rub-it-in (the business case, not any doctrnal error on Steve's part)
to get around to showing that it applies to techwriters, too.]

________________________________________________________________
Dan Brinegar, Acting Chief Deputy Assistant Going2Rome Evangelist
To comment on  or participate in the "Going to Rome" project, send email with
"G2R" in the subject line to <mailto:vr2link -at- giaco -dot- com>.

See the  project under construction at:
<http://www.giaco.com/~vr2link/Going2Rome/>

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html