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: Tech writers and engineers From:"Chuck Martin" <cm -at- writeforyou -dot- com> To:techwr-l Date:Fri, 27 Feb 2004 16:13:05 -0800
"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
> might not be necessary for a given job, its a skill that would never hurt
> to learn. If meetings are "too technical" then I would take that as a
> to learn the material and understand it. Once you understood the material,
> would likely not have problems anticipating changes or understanding how
> Furthermore, once you understood the material, you would be able to
> more effectively with engineers. You would also earn their respect since
> 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
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
quiz Wednesday night and I think I not only aced it, I was the first one
In doing this classwork, I had some inspiration on how to use the DOM and
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
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.
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!"
"All you have to decide is what to do with the time that is given you."