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: This too is technical communication From:John Posada <jposada01 -at- yahoo -dot- com> To:Lauren <lt34 -at- csus -dot- edu>, 'Gene Kim-Eng' <techwr -at- genek -dot- com>, techwr-l -at- lists -dot- techwr-l -dot- com Date:Wed, 6 Jun 2007 15:41:38 -0700 (PDT)
> interview, but it doesn't seem bad as personal state of mind when
> approaching project.
Any state of mind where you think of yourself as an idiot cannot be
good.
We don't gather information by being an idiot, by being clueless, or
by being any combination of those terms.
We gather information by being the complete opposite...with
knowledge, with a thought-out approach, and with training.
If you are taking the poisition of "Golly, Mr Developer...I'm just an
idiot, so let me sit at your feet as you puke information on me.",
then it is only chance if you get what you need.
Instead, you should know what you are after and not complete the
investigtion until it is clear.
How do you know what to ask for when you don't know anything about
it?
That's why you hire experience...with experience comes that skill
(and BTW...part of the answer is knowing something about the
technology and knowing how to do research before meeting with the
SME...put its only part of the answer).
>
> I have only been on one technical writing team and the entire
> environment is
> different from what I know. I imagine that a manager would have
> reservations about seemingly self-deprecating comments made by
> employees.
> Negative personal comments can reflect on the entire team.
>
> Knowing a user still requires some process to get from not knowing
> to
> learning and then to knowing. Technical writers are not born
> "knowing."
> How could it be possible that an interviewee would "know" the new
> situation?
> What is that person's learning process? I would be concerned with
> somebody
> that came in saying they know everything when they are new.
> Wouldn't that
> attitude present the risk that the person may assume too much?
>
> Lauren
>
>
> > -----Original Message-----
> > From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com
> > [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On
> > Behalf Of Gene Kim-Eng
> > Sent: Wednesday, June 06, 2007 11:02 AM
> > To: techwr-l -at- lists -dot- techwr-l -dot- com
> > Subject: Re: This too is technical communication
> >
> > I would be very unhappy with any writer working for me who
> > described his or her role or the job description of a technical
> > writer in this manner. The role of a writer is never to "not
> know"
> > something, and any suggestion that it is, even on a "let's
> pretend"
> > basis, is a bad idea because inevitably somebody will forget the
> > part about pretending. The role of the writer is to *know:*
> >
> > To know about the product and its underlying technology
> > To know about the user
> > To know what the user is likely to know and to not know
> > To know what the user will need to know
> >
> > It is far more productive to present yourself as someone who
> > knows these things than as someone who doesn't know
> > something, either for real or pretend. Of course, you need to
> > make sure you really *do* know them.
> >
> > Gene Kim-Eng
> >
> >
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Create HTML or Microsoft Word content and convert to Help file
> formats or
> printed documentation. Features include support for Windows Vista &
> 2007
> Microsoft Office, team authoring, plus more.
>http://www.DocToHelp.com/TechwrlList
>
> True single source, conditional content, PDF export, modular help.
> Help & Manual is the most powerful authoring tool for technical
> documentation. Boost your productivity!
>http://www.helpandmanual.com
>
> ---
> You are currently subscribed to TECHWR-L as jposada01 -at- yahoo -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
> http://lists.techwr-l.com/mailman/options/techwr-l/jposada01%40yahoo.com
>
>
> To subscribe, send a blank email to
> techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
>
>
John Posada
Senior Technical Writer
"They say everyone needs goals. Mine is to live forever.
So far, so good."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-