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:Certification From:Rick Lippincott <rjl -at- BOSTECH -dot- COM> Date:Wed, 3 Jan 1996 15:46:53 EST
Certification is a touchy and emotional issue, but one that we will likely
have to face in the future. Personally, I haven't yet firmly made up my mind,
and likely won't until the issue is more clearly defined.
But I do see problems, and one of them is the type of certification. Yvonne
DeGraw pointed out that requiring "clear writing" would exclude technical
illustrators or multimedia communicators. There is another huge problem that
we've overlooked: hardware vs. software. The expertise required for one type of
tech communication is far different from the knowledge required for the other.
A hardware tech writer might need to know things such as tensile strengths,
metallurgy, non-destructive inspection, high-voltage or high-temperature
effects, corrosion control, torque values.... whew, the list goes on and on.
It's quite likely that the hardware tech writer does -not- need any programming
skills, nor the slightest clue how to read code.
So, you've got two possible answers to this problem:
1) Certify to minimum standards to meet the Lowest Common Denominator of tech
communication; or
2) Create separate classes of certification for hardware and software (and
whatever else might be needed).
Item #1 has already been suggested on this list, but met with some objections
because a "minimum" certification is of no value.
Item #2 hopefully will meet with a lot of resistance. I'd hate to think that
I need -two- certifications to guard against job uncertainty. And from my
personal experience, it was quite hard enough overcoming management
preconceptions when I tried to move from hardware to software documentation,
I don't need limitations of a certification label. If I hadn't been able to
move from hardware to software in '93 and '94, I would probably no longer be
a tech writer. (And, I'm doing quite well at the software, thank you.)
Another issue that Yvonne raised was "cutting edge" technology. If it's been
around long enough to have standards, it's not cutting edge. I agree. If there
was a certification test today that included DTP skills and some knowledge
of code, many of us would pass in a flash. But ten years from now, of what
value is it to show that in 1996 I passed a test that showed competency in
FrameMaker on Windows 3.1, and C++? (Ten years from now? It should be at
least C++++ if not D, or possibly P.)
So, in a worst case of the above, every couple of years I've got to sweat
through at least two tests to maintain my two certificates. I'm really not
terribly excited about this.
Larry Kunz said that there is no STC "proposal" to make a college degree part
of a certification requirement (in fact, no STC proposal exists at this time,
if I read Larry's post correctly.) I don't think I'd favor a degree as a
requirement. I've seen a number of persons come directly from "the field" and
turn into outstanding tech writers, with no formal education beyond high school
or some technical training in the military. Judith Blackbourn appears to be
an example of this happening.
In conclusion, I've got to agree with a point made by Angela Howard. It seems
the extremes are to produce tightly-controlled, limiting certificates (that
may stifle creativity and our ability to move from job to job), or to produce
a very generic and minimal certification (which is of nearly no value). The
tough part of the process is to find something in the middle that will work.
If I have any bright ideas, I'll toss them out but right now I'm drawing a
blank.
Rick Lippincott
Boston Technology
Wakefield, MA
rjl -at- bostech -dot- com