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'm in pretty much the same boat as you, with more practical rather
than academic writing experience. Because of this I took a certificate
program at a local college that was offered in response to a growing
need. The program had been running for only a year before I started,
and I took half the courses (the more useful ones) before it got to
the point the material lagged behind my growing practical experience.
As others have indicated, hands-on experience with the user concerns
and technology of your chosen field is instrumental to gain immediate
success. This is what makes certifying writing ability so difficult.
How you write changes as you get to know what your customers need.
While different industries may share similar processes and tools,
there is enough variety for a generalist to become totally lost, and
fall into developing a specialty.
I've learned a lot from the members on this list. Sometimes I feel
completely overwhelmed by the more experienced, in their perceived
ability to extract information from a stone. (Incidentally, "How would
you get info from difficult engineers?" was the most common interview
question asked of me.)
That said, our industry is expanding from writers knowing as much as
their SMEs into becoming engineers of information management and
processing. Some may say this has always been the case.
Lately in my work, I find I add the best value by providing and
supporting templates, automating workflows, and training engineers to
communicate more effectively. I can then duplicate myself as a writer
and enforce consistency in where information is stored, and improve
style and quality of the documentation.
More than a general "here's what a tech writer does" course, of which
the STC and some independent consultants offer as "Tech Writing 101",
you may want to explore the variety of training options in specialties
related to your field. For instance, I have been interested in taking
courses in API and SDK Development, interpreting schematics and UML
diagrams, advanced XML processing, and interviewing SMEs for fun and
profit.
I'll let you know if my impression changes after a few more years in
the field. I look forward to future reports on your own search.
Cheers,
-Tony
--
Tony Chung: Creative Communications
Cell: +1-604-710-5164
Email: tonyc -at- tonychung -dot- ca * Web: http://tonychung.ca
Skype: tonychung.ca * GTalk/MSN: tonychung -dot- ca -at- gmail -dot- com
Twitter: @techcom * Facebook: http://www.facebook.com/tonychung.ca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
