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: Programmer/Writers? From:Sara Stewart <sara -at- sara-stewart -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Sat, 24 Jan 2009 16:50:16 -0500
Finally, a thread I can actually comment on somewhat knowledgeably...
I'm inclined to agree with Geoff Hart: "[A] technical communicator must
understand both the subject and the audience sufficiently well that they
can bridge the gap between them. When the audience is composed of pure
geeks, the communicator must speak geek fluently and well; when the
audience contains few or no geeks, the communicator must have the common
touch and speak the language of the masses."
At least in the market niche in which I'm working, it's important to
have a "beginner mind" at all times, so that you don't wind up falling
into the "Comprehensible Only If Known" problem.
I'm nobody's idea of a programmer, but I can follow a lot of of the
source for the applications I document. My coworkers seem almost
completely unaware that I can. It just doesn't come up. Most of the
other technical writers I've ever worked with have been even less
programmery than I am.
On the other hand, I suspect that our differing experience has something
to do with the market segment in which one is working. From what
Technical Writer and Gene Kim-Eng were saying, it sounds as though they
work in large enterprise settings with a much more stereotypically
"corporate" environment than I do. I've consulted for some larger
companies, but mostly I've been working for businesses with 25 employees
or less. I also don't live in a country currently strangling under a
crushing recession, either.
Which brings me, at last, to my next point: I'm also skeptical of the
merging of programming and technical writing because in my experience,
programmers who write documentation generally do a lousy job at it, and
(because they'd rather be coding) tend to be lackadaisical. I've worked
for a number of lone programmers who either had done documentation and
found that it wasn't what their users wanted and needed, or hadn't
documented anything because "documentation isn't really necessary, and
who wants to spend time writing that crap anyway?" and then found that
their users wanted it, and "Meh, I listed the features on the website"
wasn't good enough.
If people out there are bridging the two solitudes, great, but I don't
think the role of the pure technical writer is quite vanishing yet. (On
the other hand, I'm also in a position where the company I work for
doesn't have enough work for a full-time writer, so I do a fair bit of
testing, so what do I know? :) )
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
