Knowledge

The whole certification thread on TechWr-L has me thinking that much of the certification opposition is unfounded. That is, most voicing opposition are doing so from a very subjective if not emotional standpoint. I’m neither for nor against certification at this time. I want to see what STC comes up with. So far, I think they’re on a pretty good path.

Rather than drone on about certification (you can read about that elsewhere), I’d like to focus on some of the myths about technical communication that tend to be touted as truth.

1. You can’t define what a technical writer does. This is flat out laughable. Look at your job description. If it’s not accurate, fix it. Look at the BLS job definitions. Look at any resume.
2. It’s impossible to objectively evaluate a technical writer. This is also laughable. My management experience says otherwise. I worked very hard to develop objective criteria for evaluating both hard and soft skills surrounding a technical writer’s performance. It’s possible, and it’s a worthwhile exercise. And for those tech writers out there who haven’t experienced an objective review, let me know how I can help you and your manager remedy this.
3. Technical writers get no respect. Ah, what I like to call Rodney Dangerfield Syndrome. Respect doesn’t come with a title, folks. It’s earned. Come to the plate ready to play ball. Not all pitches will be easy lobs down the middle. Adjust your stance and swing only at the good pitches.
4. The technical writing field is too broad for certification. I have my doubts about that. Colleges somehow have degree programs for it. And I can’t imagine project management being any less broad, yet PMI somehow is able to settle on tried and true criteria for success.
5. Technical writing tools and practices change too frequently. Well, yes, in part they do, and this is a good thing. Would you prefer a stagnant career? Aspects will change, but fundamentals will not. People will always need to know what something is, how to use it, why to use it, etc. There will always be a core need of providing the right people with the right information in the right manner at the right time. That you use RoboFrame 2056 or MadWorks ePublisher-It X8 to create your documentation, or that you do so using the Socratic method or rhythmic breathing is fairly irrelevant in the grand scheme of things if you fail to deliver quality information.

I’m sure I’ve missed a bunch. Feel free to add more myths in your comments!

{ 18 comments }