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: Recap of the message about screwing up From:Chuck <writer -at- best -dot- com> To:techwr-l Date:Mon, 30 Aug 1999 15:11:57 -0700
jarnopol wrote:
>
> Chuck writes:
> <snip>
> >Maybe. But I've also expressed to my main recruiter that I'm simply
> getting tired of fighting, fighting to get information, fighting to get
> cooperation.<
>
> If you are expecting to get information on a silver platter, as part of a
> normal day-to-day routine, I'd like to have some of whatever it is you're
> smoking. Unless you're working in a highly evolved company, or you have a
> higher-up who knows the difference that good documentation makes, this just
> doesn't happen all that often.
But I do expect it. That doesn't mean I've received it (at least, not
all that often, or at times, after long, patient, repeated explanations
of how important it is for technical communicators to stay informed).
Yet too many people, both programmers and "higher ups" seem to
conveniently ignore the "technical" half of "technical writer." As a
result, we're not given the same respect or regard that programmers have
(in many cases). Yet (at least in my case) I work at least as hard on
the "technical" side of things. At my school, the Technical
Communication department was part of the College of Engineering, not
Arts & Sciences, recognizing the importance of the "technical" part. I
continue to keep up with the latest in computer trends and technologies,
and have continued to take classes in the evenings to add to my
technical knowledge, even as I continue to hone my already fine writing
skills.
My main recruiter also goes through that same education process when
contacted by many companies. he belives (and I'm in the same boat) that
a good technical writer brings value to a company equivalent to that of
a good programmer.
I don't smoke anything; the only drug I enjoy is chocolate.
>
> >Heck, I even went to a job interview a few weeks ago where a newly hired tech
> pubs manager said that she had been being given information by the engineers
> without even asking.<
>
> Yea, but was it information she needed or simply what the engineers decided to
> give her? The point being, unless you know what you need, or can find out what
> you need, what you get might simply be fluff.
It was what she needed.
>
> >That's not to say that niceness isn't necessary. But I've also been in far
> too many situation where I hear about a development meeting, go there to keep
> up with developments on the product, and get asked something along the lines
> of "What are you doing here? You're the technical writer."<
>
> If this is the attitude of the company you're working for, what ARE you still
> doing there? Either they don't know the value of documentation or someone
> hasn't adjusted their attitude yet.
I parted with a company where I was in a group where that attitude was
all to prevalent. In another company (where I left to pursue some
personal goals) that was the initial attitude, and it took me months to
educate them--by demonstrating my capabilities--just how much value a
mere "writer" could bring to them; they at one later point asked me to
do the entire initial design of a new software utility that they wanted
to develop.
>
> I agree with John Posada. A big portion of our jobs is to get the information
> from the people that keep it inside their heads. If that's something you don't
> like to do, maybe technical writing is the wrong field.
If programmers want to keep critical information inside their heads,
maybe *they* are in the wrong field.
Read Alan Cooper's books ("About Face" and "The Inmates are Running the
Asylum") for some good examples of just how giving programmers carte
blanche makes for really bad results.
--
"Online help should ignore first-time users and concentrate
on those people who are already successful using the
product, but who want to expand their horizons."
- Alan Cooper
"About Face: The Essentials of User Interface Design"
Chuck Martin
writer"at"best.com www.writeforyou.com
*****LEGAL NOTICE TO ALL BULK E-MAILERS*****
NOTICE TO BULK EMAILERS: Pursuant to US Code, Title 47,
Chapter 5, Subchapter II, 227, any and all nonsolicited
commercial E-mail sent to this address is subject to a
download and archival fee in the amount of $500 US.
E-mailing denotes acceptance of these terms.