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.
Susan W. Gallagher writes:
> Now, I do not profess to be an awesome programmer; although I could be
> if I gave it some attention. But I can, if necessary, program my way
> out of a wet paper bag. More importantly, I know enough about programming
> to know what programmers need to know to get the job done. And I know
> what words to use to explain concepts effectively to my target audience.
I can, and have programmed my way out of a paper bag :-). It'sa
short story, but I'm pressed for time. As yet another
programer/writer (in fact these days I'm much more programmer than
writer, though my experience and skills from techwriting have been
invaluable in my work as a programmer) I can definitely say it's a
fascinating combination of skills and tasks.
> Truth be told, I like doing more than writing. I can fire up FrameMaker,
> CorelDraw, or Visual C++ and roll up my sleves and get to work. Need an
> icon? Want some suggestions about the user interface? Need a User manual?
> Online help? Web site? Sure, I'll get it done. See, I believe that it's
> my job to communicate; and *that* is my area of expertise. Those other
> things -- the pictures, the words, the programs -- those are just tools.
As a writer, my job is twofold; to learn, and to communicate that
learning via the written word. I've worked alongside writers who were
of the opinion it was the SME's job to tell only and precisely what
the end user needed to hear. I don't buy it. Writing a technical
manual is like discovering and then writing how to climb a mountain.
Until you know at least the broad strokes of the mountain, you can't
begin to guess the best route up it.