Re: Technical skills for writers

[Chris Kowalchuk <chris -at- BDK -dot- NET>]

Some comments sparked by Ginna Dowler's remarks:

> Joe, Chris and other use phrases like "technical knowlege" and
> "technical background" without ever defining what they mean.
>
Not sure if you meant Chris me, but I have written on these topics
recently, so I would be happy to define what I mean. What I mean is
someone very much like yourself (judging from the rest of your post).
I'm not talking about people with advanced Engineering degrees etc. I am
talking about people with enough technical aptitude and interest to
actually learn about what they are documenting. Nothing more. No
particular credentials required. More might certainly be helpful, but
Ginna is right, we are paid (presumably) for our documentation
expertise, not because we are programmers or engineers etc.

I agree with Ginna that the specialized niche of the writer is in fact
writing. Right up there with writing should be clear-headedness, and an
ability/willingness to go the extra mile and ensure that you generally
understand the technologies/processes you are documenting. When
documenting electronic equipment, for example, I don't feel that I need
to be able to design a circuit, but I find it helpful to be able to read
a schematic diagram at least well enough to have a general idea what is
going on, and under the guidance of an electronics engineer or
technician, be able to follow the workings of the circuit, with
reference to the diagram. I did not take any technical course, nor do I
have a drafting certificate, or a degree in electronics. I did read a
few books on the subject, and always take advantage of any opportunity
to allow an "SME" to explain to me what they are doing, how, and why. I
would take this same approach no matter what technology is involved.
There is very little out there for which you can't develop a general
understanding, given a few days reading and research. Consider as an
analogy the difference between active and passive vocabulary. The expert
in the field has the active vocabulary, the writer, I feel, should try
to develop a passive vocabulary if possible. Once can acquire enough
skill to read some well-structured C code and at least have a clue what
the programmer was doing, for example, without being able to write
anything terribly clever with it oneself.

Some might consider this a waste of writing time, but I find it the best
thing for having thorough product documentation that both designers and
customers are happy with. In a different thread, someone referred to the
good old days when engineers etc. did most of the product writing. In my
opinion, it was during that period that technical writing developed its
reputation for being convoluted, dense, and incomprehensible. The
average (and I don't mean every!) manual written by such experts was
chock-full of technical information, presented so densely and in so
disorganized a fashion, that it did almost no good for anybody. This was
writing done by persons for whom writing was not a priority. On the
other side of the coin, today we often see manuals that are beautifully
organized and formatted, but convey next to no information, on the
(facile) assumption that if you put anything too complex in there, the
poor dumb user couldn't understand it, and wouldn't read it. That's
going too far the other way, and is a trend that ought to be checked.

In my opinion, the most well-rounded and generally useful technical
writer is one for whom writing is a vocation, and various technical
subjects are an avocation. Don't ask me which subjects. Anything under
the sun. Whatever interests you. Whatever would be helpful in your
current endeavors. Don't get a degree, read a book. Talk to people. Be
interested.

Chris Kowalchuk


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=