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: Respect From:"Eric J. Ray (remote)" <ejray -at- raycomm -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 24 Aug 2001 06:52:46 -0600 (MDT)
On Thu, 23 Aug 2001, John Posada wrote:
> I had a developer, in a meeting, say "Give it to Johnny...he'll break
> ANYTHING!"
That's even better than the "Just STOP! ;-)" message I
got the other day after another "Er, well, I was trying to
do Foo, and it crashed" report I made.
> I hope we're not just finding errors, though that happens. By putting
> it on paper, the logic (or faulty logic) of a sequence is examined.
> By documenting an awkward process, the emporer is shown to have no
> clothes. More than once, we've encouraged development to change a
> process because once they saw it on paper, they saw how bad it was.
> Fixing errors doesn't add value, the errors only took it away.
> However, materialy changing the steps that a user performs DOES
> increase the value of the product. I'd guess that falls under
Again, I think we're both saying the same thing. If a process
or sequence has faulty logic or could confuse users,
it's in error. If you point it out and get it fixed, you're
adding value.
> usability testing. Does usability testing increase product value? Is
> it is possible to write solid documentation about an application that
> DOESN'T include this?
Solid documentation? No. Documentation? Absolutely yes. And
you and I both could name 100 examples of documentation that
doesn't include this.
> > If you want to call the process you describe the act of
> > writing, I can go for that. But it's not the typical
> > narrow definition of _writing_.
>
> As far as my way not being true writing, I cannot think of any other
Didn't say it's not "true writing". I just pointed out that
there's a lot in your process that doesn't look much
like what most people think of as pure writing, and someone
who doesn't know better could well assume that a technical
writer's job encompasses only the writing and not the
vast extent of other stuff.
> way TO write. Are there those that passively write something and if
> they see it is difficult to document because it is difficult to
> perform, that they don't let anyone know, but just put words on paper?
Yes, there are. And they are 90% of the reason we're
_having_ this discussion.
If developers, development managers, managers, and others in
our organizations hadn't already been trained to doubt the
value of a tech writer by "tech writers" who do precisely
what you describe, we wouldn't see the "I don't get no respect"
thread pop up every month on this list.
*** 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
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
---
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.
