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 agree with Candace. Technical/non-technical is not the primary
True. The essence of the job is the drive to communicate, not the need to
fiddle with gadgetry. I've known good engineers who loved to communicate,
and LibArts like me who didn't. One of my heroes is James Burke, the British
journalist who does Connections. Two others are deceased but still
influential: Isaac Asimov and Carl Sagan, both scientists who could make the
>I also think the job market is a big factor. People I wouldn't want
>to hire are getting positions, because employers a) don't have enough
>qualified candidates or b) aren't willing to pay enough to attract
Or c) don't know what constitutes a good practitioner.
><RANT> Lastly, I think tool proficiency has given some people
>(technical and non-technical) an unrealistic perception of their own
I share this rant. The tool vendors have convinced many borderline
practitioners that all it takes to succeed is their tool. Unfortunately,
employers who should know better have taken up this chant, too. I think it
comes from a very human need, even in business types, to get quick solutions
to problems they consider petty and easily solved. Most of us consider other
professions' problems to be easily soluble. Software bugs, for instance, are
easy to squash, because *I* don't have to step on them.
Sadly, what this mindset has led to is a cadre of communicators who aren't
very well versed in fundamentals, preferring to substitute the experience of
the tool vendor for their own hard work in learning what they should know.
We see the unfortunate results here on this list, with common questions
about "Such-and-So miracle tool won't compile my help file. It says
something about a graphics problem. What's wrong?", a problem that anyone
who knows the subject well could correct in a matter of minutes.
We're doing both the profession and the newcomer a disservice, I think.
We're allowing a generation to develop that sits like baby birds with their
mouths open, hoping that some newer tool will make their lives easy and
productive. Many buy PageMaker, but never learn the layout principles that
have been developed over centuries. They buy PhotoShop, but don't know what
bitmapped graphics are like. They buy RoboHelp, but don't even know that the
help compiler is identical for every tool. Many newbies don't even know
there *are* such fundamentals to learn. Nobody's told them. All they have is
the mailings from the tool vendors, who never let on that they're hiding
fundamentals, not teaching them.