Re: Opinions on Online Tech Writing Courses
Problems with content create enormous problems with customers and support. Problems with design cause only internal headaches.
Fixing design errors is a fairly mundane, brainless task. I could get an intern, teach them the DTP application and template, and let them loose. Or, I can stay a couple of extra hours and do it myself.
I agree that fixing design errors is a mundane, brainless task and that is exactly why I don't want to do it. I feel the same about housework.
However, fixing erroneous information because the writer did not understand
the material can be quite a headache. And if those types of errors get out to the customer, you end up with credibility issues, additional support costs, and possibly lost business. Even if there is a thorough review to catch those errors in the beginning, rewriting takes longer than arrowing through a document and applying styles.
Inaccurate, unclear documentation goes out to customers all the time. The problem is usually caused by the writer's inability to write clearly, not by his lack of technical knowledge, which is easily overcome.
And, if you are in a rather
fast release cycle, having someone who can produce creditable documentation without spending an enormous amount of time doing research is a bonus.
You seem to assume that a person who does not have experience in the technology will not be able to figure it out and write about it. I am a freelancer who has worked at many different companies. When I start a new contract I am not only in a state of complete ignorance about the company's product, but I am also just about overwhelmed by all the acronyms. Even having experience in a particular technology does not help much. Knowing about switching, for example, does not help me understand wireless intelligent networks, which does not help me understand synchronous optical networks, which does not help me understand mobile IP. When I think back to my first technical writing job, in which I had no techwriting experience and no technical knowledge yet still managed to write accurate and easy-to-understand documentation, I have to say that the most useful-for-my-career knowledge I got from it was document design, not technical knowledge.
You also seem to assume that good document design is about paragraph styles. I have to conclude that you don't know much about doc design! :-)
You will remember that my original post described a sample document. When you, as the employer, review the sample document, you will of course also review the content as well as the design. You will notice if the candidate has formulated his or her thoughts well. If the procedures in the sample document are not easy to understand, don't hire the candidate! Obviously, if the person can't write clearly about a subject he knows well, he's never going to be able to write well about your company's product. But if he has written well about the subject, you can be sure that he will do a pretty good job with yours.
That said, there are plenty of people, many on this list, who bring both types of knowledge to the profession. Those are the people I seek out when looking.
However, I also realize that not every situation is the same, and that there
are times when tool knowledge may be more important than subject matter knowledge.
We all gain knowledge as we move up in our careers. To expect just the right kind of knowledge in potential candidates is unrealistic and, I am sure, somewhat depressing for newbie writers looking for their first job. If subject-matter knowledge were more important than document design-- which is really not the same thing as tool knowledge--and, of course, the ability to write well, we wouldn't need SMEs. We might not even need techwriters--the SMEs could do it all. If I hire a technologically inexperienced person, I know that I will have to do some patient hand-holding at the start, but it won't last long. If I hire an experienced person and then discover hours before release that all the x-refs in her doc were hard-coded and are now outdated, I am going to be, well, not patient at all.
Is that wishy-washy enough?
Jason
P.S. Here is the typical type of question to use to determine if the writer
being interviewed has both types of experience: "What font would you use to
explain the difference between AH and ESP tunnels?"
I have no idea, but I am sure I can find out quickly enough by doing a bit of reasearch on VPNs!
~~~~~~~~~~~~~~~~~~~~~
Lyndsey Amott
www.docsymmetry.com
Winnipeg, MB R3G 2J3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web. The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.
References:
RE: Opinions on Online Tech Writing Courses: From: Jason Willebeek-LeMair
Previous by Author:
Re: Opinions on Online Tech Writing Courses
Next by Author:
Re: Opinions on Online Tech Writing Courses
Previous by Thread:
RE: Opinions on Online Tech Writing Courses
Next by Thread:
Re: Opinions on Online Tech Writing Courses
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads