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.
Oops! This was meant to go to the list, not just Tim.
> I've seen such "guidelines" before. To my mind, they're of
> little value
> without some greater detail.
> [etc.]
They have to be vague, because every client and environment is different.
An example: When I'm writing articles for a magazine, rule 1 (doing my best)
means making sure everything is accurate, that I haven't misrepresented
anyone, I've gotten the article in on time, and that I'm satisfied with the
tone and direction of the article. When I was working for one company, rule
1 meant satisfying the president and the developers in terms of content, and
making sure the manuals were well-organized and readable. At another
company, doing my best meant keeping my head down and just surviving the
day.
> What is "your best"? Does doing "your best" require you to
> stay current with
> the latest research into usability, or just to stay sober
> through the day
> and not make too many spelling errors?
Everyone has their individual limits on talent and time, as well as
workplace circumstances. *My* best means keeping my tool knowledge as up to
date as possible, building learning time into my schedule whenever I can.
It means pointing out UI errors to developers when possible. It means
listening to customers when they say they have problems finding information
and fixing it when feasible.
Someone else's best may be more ambitious than mine, or less. The point is
that if you know you can do better (again, given circumstances -- I'm
getting to that), do it.
> Is it incumbent on you to never
> question a boss's order?
I covered that in rule 4. If you think you know a better way, bring it up
diplomatically. Maybe there's a good reason why they don't want you to do
it a certain way. Maybe not. But yes, if you have a problem, you question.
You attack it from all sides (diplomatically and on record). But
ultimately, he's the boss. Either you adapt or leave. (Lord knows I've
done both.)
> Manuals should be
> judged, not on
> whether the boss is happy with it, but on whether it does the job, as
> expressed in specifications agreed upon before writing
> begins. Manuals, like
> pig feed, pumps, and software, should be judged on
> functionality, not on
> speed of production or the degree of management satisfaction.
> [etc.]
I don't disagree with you in the least. But I think everyone here agrees
that (a) sometimes the powers that be need to be educated, (b) educating
them takes time, and (c) in the meantime, you have to eat.
And bear in mind that I didn't say these were the *only* rules, but the
*essential* rules (more to the point, they're *my* essential rules). I
think they do a good job of balancing personal satisfaction and
responsibility with workplace reality.
