A reader asks for advice on how to get training in technical writing. Jara writes,
I am so glad that I found your blog. I truly need an advice. Initially I got accepted as computer science and business major, however I did not see myself stimulated by it.
So I changed to International Relations and Development studies, something I always wanted to study.
But now, I am faced with few job prospects. Even though I left to work as a reporter in the UAE. I love writing. But it is quite a competitive, still market and I wanted to go back to Canada, one year in the UAE was way too much for me.
Now I want to pursue technical writing as a career. I am motivated, since I am a hybrid between science and arts, and it will enhance my pay.
But I want to be trained as a technical writer, I have about 4 computer science credits, I know rudimentary computer science concepts, though C ++ is something I can vaguely recall.
I really need your advice on this.
Are there any internships for technical writing positions? What can I do? And what are the computer software programs I need to know?
And I am a fellow blogger as well.
My best regards :)
Jara, thanks for writing. It's good that you have skills in both computers and writing. That combination provides a great foundation for a career in technical writing. You don't have to be a computer programmer to land a job as a technical writer, unless you plan to write documentation for programmers. However, any programming knowledge comes in handy.
To get training in technical writing, you have several options:
Any of these options can work well to move you forward into a career of technical writing. I took the first route: on-the-job-training. I'd been a writing instructor at a university, then a copywriter, and I wanted to move into technical writing. I landed a job as a technical writer at a financial company, and learned their style guide and methods. It was an excellent way to gain experience in technical writing.
Many companies want to hire candidates who already have experience in technical writing. It can seem like a Catch-22: you need experience in technical writing before you can get a job in technical writing; but the only way to get experience in technical writing is to have a job as a technical writer.
Actually, the Catch-22 situation is somewhat of a myth, one that many can't see past. You most likely learned to write before you landed a job as a reporter. And how did you learn to write? Did the skills come only from on-the-job training? No. Most likely you wrote in your own spare time, developed writing skills, and then submitted some impressive writing samples to an employer, who hired you.
Technical writing can be the same way. If you want to learn technical writing, do technical writing. If you need a project, I recommend writing documentation for WordPress. (If you're interested in that, I'll give you more specific suggestions on areas that need better documentation.) Documenting WordPress may not interest you, but there are a hundred other applications you can write help for. Open source apps are the ripest.
As you tackle an actual project, you'll be faced with stylistic questions. You'll have to decide how to approach it, the language and format. I recommend that you open a sample how-to guide from some application you're familiar with (even Microsoft Word), and try to imitate the style. Number the steps. Include screenshots where the steps are confusing. Chunk the material into tasks. See my post on the complexity of simplicity for some standard techniques.
You'll also need a mentor, someone who can review your content and give you feedback. Here's where the STC comes in. The Society for Technical Communication (STC) most likely has a chapter in your area. Go to the next local STC meeting or contact the local president. Ask for a mentor to provide feedback on your technical documentation.
In a thriving chapter, many people will be more than willing to volunteer. Take your mentor's advice and shape your samples into professional-looking work. If you can produce several samples of help material for different projects, that alone may convince a hiring manager that you have experience in technical writing.
One thing I haven't mentioned is tools. This is where it gets a bit controversial, but I'll tell you what I use. I author almost everything in Madcap Flare. Using Flare, I generate both webhelp and a Word output, which becomes a printed PDF manual. I mainly use SnagIt to capture screenshots, although sometimes advanced tweaking requires me to use Photoshop. If I plan to make video tutorials, I use Camtasia Studio. Learning at least Flare and SnagIt will take you a long way.
If you know the specific job you want, you can inquire about their toolset. Maybe they're die-hard RoboHelp users. If so, learn RoboHelp. Maybe they do everything in Microsoft Word. Fine, master styles and templates in Word. Perhaps they've moved to DITA. In that case, get to know an XML editor and the DITA Open Toolkit. Or maybe it's a Framemaker shop. So dig into that.
Some employers require you to know their tool before they'll consider you. Realize that "knowing" a tool has gradations of interpretation. With some tools, I can say that I "know" them, although I only know them as a novice. With other tools, I'm an expert. There are gradations of ability for every tool, so even if you only figure out Flare enough to create a basic online help file, you can still say that you "know Flare."
It's a bit ridiculous for an employer to expect each candidate to have an expert level of knowledge in every tool (e.g., AuthorIt, RoboHelp, Doc to Help, Flare, DITA, Framemaker, Word, Captivate, Camtasia, Photoshop, Dreamweaver, and others). It's more important that you're able to learn the tools the company wants you to use. You'd think this characteristic would be a given, but many technical writers get unnerved if forced to learn a new tool.
Readers, if you have advice to add, please do so in the comments below.
For more information on technical writing careers, see this post by John Hewitt on the Technical Writing FAQ.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.