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.
>I would recommend against volunteering to write and format developer
docs.
>Presumably your job is to write and publish customer documentation,
which has (or
>should have) a completely different focus from developer
documentation.
Whoaaaaa. Not all technical writers write only customer documentation.
While I wouldn't recommend that tech writers WRITE the developer docs,
I do think it's a good idea to volunteer to edit them. And edit for
content, organization, and style as well as for grammar and spelling.
This could have several benefits, but primarily the ones below:
- You get to work with the developer on HIS/HER turf. It will serve
you well, later.
- You get to show the developer that things like organization, voice,
etc. really do improve the quality of the document.
- It buys you an early place on the development team.
- It helps you understand the technology.
>You don't want your focus on producing information to help users work
effectively
>with your product to get pushed aside while you do developers' work.
Usually, your user documents are not well-defined at the point you'd
be helping with the developer docs anyway.
>Product managers should own the requirements specs -- what the
product should
>do. Developers should own the design specs -- what the product
actually does and
>how it does it.
"Owning" is different than helping. "Ownership" is a very quirky
concept....usually designed to assign responsibility, especially blame
when it blows up. Many companies are moving more to a team approach,
anyway.