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: Certification/Degrees From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Fri, 13 Dec 1996 09:41:00 EST
At 08:39 AM 12/12/96 -0600, you wrote:
>If a candidate has the skills, education, background, salary
>requirements, portfolio (or whatever is handed to the interviewer) that
>are a match for the company's needs, I would say that they are quite
>Employer: Have you documented C++ code?
>Writer: No, but I am certified
>Employer: Was documenting C++ code part of the certification?
Michael, I think you've confused two things: basic competence and specific
job skills. Let's expand the interview a bit farther, shall we?
Employer: What do you know about laying out documentation?
Writer: Well, I was on a team with a layout person once.
Employer: What do you know about writing stepwise instructions?
Writer: I did that once, I think.
Employer: Have you documented C++ code?
Writer: Yes, Yes! I've done that!
Employer: Ever done anything anybody can actually read?
Writer: Uh, I think so. But boy, do I know C++!
Tragically, however, employers don't know to ask about the most basic and
important factors, such as flexibility, willingness to learn, basic
competence on computers, layout experience, understanding of human
cognition. That's our job, not stuffing C++ jargon into manuals. This year
C++, next year Java, the year after... At least, it's my job, and hopefully
the job of everyone I hire. I can learn C++, enough to write most
documentation, in a fairly short time. And besides, most tech doc'ers don't
read or write code; they write about the interface. The requirement that a
writer know a specific code set is spurious 90% of the time. It's
human-to-human interaction that's the fundamental of our tasks. Basics,
basics, basics. When you hire a lawyer, you may ask about his or her
experience in the field of law you're interested in, but you damn well, at
minimum, want somebody who knows his habeas from his corpus. The rest he can
look up in the law library.
>Do they really care what we establish for standards? They have specific
>needs, budgets for salaries, job duties, and so forth. We seem to
>forget who is hiring who!
Nope, I haven't. Remember, Michael, I'M an employer too. If another employer
wants an unproven techie who's just graduated from a vocational typing
class, then fine. But often the writing is slipshod, bunched-up, wild and
unreadable. In short, it isn't usable for the intended audience, because the
newbie doesn't have the foggiest idea how to communicate. Years ago nobody
would have cared, but in today's world the HR department wants and needs to
know what minimum standards have been developed for a profession. Run
upstairs and ask your own HR people about this. See what their position is.
Do they want to hire blindly? Or would they prefer both base certification
AND specific experience? Even samples can't substitute for this, because
much documentation is a team effort and the candidate may not have ever
touched a layout package, making the clean look of the final document seem
to be his own work when in reality it isn't.
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
FrameMaker support ForeHelp support
HTML Help Consulting and Production