Through my blog, I receive a lot of questions from users.
I’ve seen the same questions numerous times, so I’ve decided to compile a list of answers to those questions and add a link to them on my contact page.
These are the 10 most frequently asked questions about technical writing:
In general, learn markup and style languages more than a specific tool, since languages have a more widespread application than specific tools. The most useful markup and style languages are HTML, XML, and CSS. You can find resources to learn these languages online.
For specific tools, look at http://indeed.com for technical writer jobs in your area. After analyzing the job postings, try to identify a common trend in the tools required. Learn those tools. You can also review commonly used tools from previous WritersUA tool surveys.
In general, learn these four types of tools:
Even if you don’t know the exact tool the job requires, your proficiency with some of the above tools will give you credibility that you can learn the company’s specific toolset.
If you’re in a position in life where education fits easily into your schedule, go for it. For example, if you have the time, money, and are interested in a degree, take advantage of the opportunity. Once you settle down in life with kids, a job, and other commitments, it can be really hard to get that masters degree in tech comm.
However, a technical communication degree or certificate isn’t necessary to get a job in technical writing. If you’re not in a life situation where education fits easily into your schedule and pocketbook, don’t worry about it. Few professional technical writers have degrees or certificates specifically in technical communication anyway.
Instead, focus your efforts in developing a strong portfolio with examples that demonstrate your knowledge and skills. (By the way, even if you do pursue higher education in technical communication, you will still need a portfolio to get a job.)
For more information, see the following:
If you don’t have any experience, volunteer your technical writing skills with an open source application, such as WordPress. For example, you could rewrite or add information in the WordPress Codex. Alternatively, you could create instructions for a product you use, such as your phone or camera.
The exact product doesn’t so matter much. Interviewers will be interested to see your writing style, your ability to articulate complex concepts, your mastery of advanced tools to author the information, your sense of organization and detail, and more.
For more information on landing a technical writing job, see my series on How to Get a Job in Technical Writing.
No, technical writing isn’t boring. It actually taps into quite a few creative skills, but that creativity isn’t creativity so much in writing. It’s more like creativity in problem solving, layout and design, finding ways to illustrate concepts, and in thinking through ways that people might use the product.
In addition to using these creative skills, you’ll be immersed in an environment full of interaction designers, engineers, quality assurance testers, project managers, analysts, corporate communications teams, and more. In short, IT departments can be energetic, cool places to work.
At the very least, give technical writing a try. If you find it boring, switch to something else.
For more details, see the following:
Most tech writers don’t have a specific background in technical writing. You will be a good tech writer if you have any of the following qualities:
I use an open source tool called Jekyll. This is a static site generator that helps you build HTML quickly and push out websites. If you’re interested in this approach, you can try the free Jekyll theme I developed specifically for documentation projects.
You could purchase academic versions of the software for usually half price or less. For example, you can buy an academic license to MadCap Flare for $500. Most Adobe products have similar academic discounts.
If you consider the cost of software to be equivalent to buying books for class and paying tuition, the cost is more understandable. (Note that academic software restricts you from using the software commercially.)
You could also download trial versions of the software. The trials usually end after 30 days, so you have a limited opportunity to learn the software during this time. You could reformat your computer every 30 days and install new trial versions, but doing so would skirt around the idea of a trial, in addition to being a major pain.
You could try using open source substitutes, but I don’t recommend this method, because usually employers look for knowledge of specific tools, usually industry standard ones. When you invest so much time and energy in learning a software tool, you want this time investment to have a significant return.
Employers want prospective employees to know industry standard tools such as Photoshop rather than Gimp, Microsoft Word rather than Open Office, Camtasia Studio rather than Camstudio, and so on. However, if open source is your only option, it’s better than nothing.
If you’re new to the field, you probably won’t find a remote technical writing contract. Usually you need more experience before employers will trust you to work from home. Even so, many employers want you to be on site at least part of the time.
Technical writers do a variety of tasks, including some or all of the following:
Sorry, but I usually don’t have the bandwidth to respond at length for this. However, you could probably find a technical communicator willing to respond if you asked around on Twitter and included the hashtag #techcomm. If someone does respond and is interested in posting their responses as a guest post on my blog, I would love to do that.
Getting your first job as a technical writer is usually the hardest job to get, but the jobs once you’re established in the field become much easier. Follow these seven steps to get a job as a technical writer:
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), 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.