Re: Tech writers and engineers

["Chuck Martin" <cm -at- writeforyou -dot- com>]

"Andrew Plato" <gilliankitty -at- yahoo -dot- com> wrote in message
news:230444 -at- techwr-l -dot-  -dot-  -dot- 
> Ignorance is not an asset.
>
> Yes, knowing how to code would make you a better technical writer. While
it
> might not be necessary for a given job, its a skill that would never hurt
you
> to learn. If meetings are "too technical" then I would take that as a
challenge
> to learn the material and understand it. Once you understood the material,
you
> would likely not have problems anticipating changes or understanding how
things
> work.
>
> Furthermore, once you understood the material, you would be able to
communicate
> more effectively with engineers. You would also earn their respect since
you
> had taken the time and effort to learn what they were doing.
>
> So, yes - you need to be as technical as possible.
>
> You cannot accurately document a technology you do not understand.
>
Wow, I agree with Andrew.  :)

I might expound a bit though:

While ignorance is not an asset, everyone is ignorant. Yes, yes you are.
Because no one can know everything.

Once you accept that you're ignorant, you can then take steps, if you so
choose, to reduce your ignorance. In terms of technical communications, you
can reduce your ignorance on technical subjects, maybe even those that
directly relate to your job. The more you can reduce your job-related
ignorance, the better job you can do.

Interestingly, that applies to pretty much every job, including (as it was
put in a local STC chapter presentation last night) C-level jobs. Even the
best programmers more often than not keep MSDN Library open in the
background and have well-thumbed reference books scattered about on their
desks.

You don't know how technical you get get until you try it. Heck, many
technologies are "just" another language. I'm taking a class this semester,
unhelpfully titled "Advanced Internet," that uses one of the Deitel books
and covers JavaScripting, web servers, PHP, Perl, and more. We had our first
quiz Wednesday night and I think I not only aced it, I was the first one
finished.

In doing this classwork, I had some inspiration on how to use the DOM and
JavaScript to possibly write code to provide What's This?-style help for web
pages and web applications. This is an idea that I'm probably going to have
to put on the back burner for now because (a) the class is already going on
to other subjects, (b) I just started a new contract where I'm probably
going to be putting in lots of overtime to get a 200 page User Guide
rewritten in about a month, and (c) I have to get my WinWriters (y'all are
going, aren't you?) presentation finished by next Friday. But it's well
stuck in my brain and I think I have a good idea how to write the JavaScript
code to do it.

You can pretty well document a technology you can't understand, at least
*how* it works, although probably with lots of help and feedback from the
rest of the development team. What you can't do, at least not well, is
document the *why* it works, conceptual information that users often need to
make decisions using the product.

-- 
--
Chuck Martin
User Assistance & Experience Engineer
twriter "at" sonic "dot" net      www.writeforyou.com

"I see in your eyes the same fear that would take the heart of me. The day
may come when the courage of Men fail,  when we forsake our friends and
break all bonds of fellowship. But it is not this day! This day, we fight!"
                    - Aragorn

"All you have to decide is what to do with the time that is given you."
                    - Gandalf