What kind of technical writing job should I get into?

If you’re looking for a technical writing job, it’s easy to get overwhelmed with all the possible job requirements. The truth is there are many types of technical writing jobs, and each has its own requirements. For that reason, there is no need to study all the requirements for every category of technical writing job. Picking a target type and working towards that kind of job can save you from being quite so overwhelmed and may get you a job faster.

While I’m not an expert in most of these, I can give you my take on what kinds are out there.

Keep in mind, I’m not going into subject areas much here. There are specialties in semiconductors, robotics, medical, networking, and more where I have no experience.

Basic technical writing

I call this basic, because it is not as technical as the next category. You won’t need to know any programming or have API experience or other really technical experience to do this type of writing. On the other hand, it’s not content writing either. Content writing is more like creative writing, mostly requiring writing skill and some interest in the topic. Basic technical writing requires some knowledge of, or interest in learning about, a technical subject, whether computer parts or bicycles, medical tools or washing machines.

It also requires some familiarity with certain tools. The most common writing tool used here is Microsoft Word, but might also include Photoshop, InDesign, Illustrator, and more. It would be good to know Google Docs as well, as it is used increasingly instead of Microsoft Word.

To prepare for these jobs, have a good writing portfolio using the tools listed above, as well as anything else you often see in job descriptions. Again, if the job description mentions reading code, DITA, or APIs, you are looking at a technical technical writing position, not a basic technical writing position. You can often get trial versions of most of these kinds of software, so pick one at a time (such as InDesign), and take a few weeks to learn it. YouTube videos and online tutorials may help, as well as anything already installed with the program itself. Then make a portfolio item using that tool and add it to your LinkedIn profile and your list of Technical Skills on your resume.

From what I can tell, basic technical writing pays about half of what a technical technical writer can make. For many, however, this is still plenty.

Technical Technical Writing

At my company, this is called Technical Writer Technical. These require more expertise in a technical subject, as well as a number of technical tools. For software companies, they usually want applicants to have programming experience or the ability to read code, or API and SDK experience. They also ask for specialized tools for the writing itself. There are different approaches to the writing workflow, and this determines which direction you might want your studying to go.

Since I mostly know the software industry, I cannot speak much about requirements for hardware technical writing.

DITA / single source / topic based

DITA stands for Darwin Information Typing Architecture. All sections of documentation are broken into these topics:

• Concept
• Task
• Reference
• Glossary

For this reason, another name for this is topic based technical writing.

One of the main tenets of DITA is that every topic should be reusable. In this way, everything written should be able to be used as needed in different articles. That’s why another name for DITA is single source. You write a piece of information once, say a concept. Then everywhere you need to introduce this concept, you can use the same concept topic you wrote earlier.

DITA is written in XML. The best free resource I have found for learning DITA is the free course at https://learningdita.com/. If I remember right, it took me 2-3 weeks to get through the course.

XML may be a bit cumbersome, but most people use software that writes the XML for them. FrameMaker is very popular, as is Oxygen XML, XMetaL, Easy DITA and a lot of others. To learn one of these, I first recommend you go through the above DITA course, and then see if there is a free trial version of FrameMaker. The last I checked, FrameMaker was the most popular on job descriptions, so I’d start there. Then try to write a tutorial using the software. Make sure you put that tutorial (in several formats) on your portfolio website. There are lots of YouTube videos and other resources online to get you started. There may be built-in resources to help you learn it as well.

After FrameMaker, maybe try some other kinds of software, so you can put that you have experience with it on your resume and LinkedIn too.

A note about Madcap Flare

MadCap Flare is an impressive software program that uses XML and is topic based. It has a lot of the important concepts of DITA, but is technically not DITA. My experience with it is that it is easier to use than FrameMaker, and can import DITA files. Here’s an article if you want to know the differences: What is DITA and How Does it Differ From MadCap Flare?

I recommend you get a trial version of Madcap Flare and write something for your portfolio website. Then add this experience to your resume and LinkedIn account.

As long as the subjects are technical enough, DITA and Madcap Flare technical writing can pay very well. It usually depends what you’re writing about. Both of these can be used for many subjects, both very technical and less technical. Of course the technical, such as software documentation, tends to pay more. If you are documenting software, make sure you learn a programming language. I have more about that in the next section.

Docs as code

The idea behind docs as code is that technical writers should use the same workflow and tools that software developers use. It is especially important that technical writers can at least read and understand a programming language at a basic level.

Other common tools to learn for docs as code are git, Markdown, HTML, basic command line navigation, Visual Studio Code or Atom, static site generators such as Jekyll or Hugo, and maybe GitHub.

If you don’t already know a programming language, you can learn one online or with a phone app. I recommend Sololearn (sololearn.com). For a beginner, Python is probably the easiest to learn and is in very high demand. You will notice it listed in job descriptions for technical writers often along with Java, C++, or JavaScript. But Python is the quickest to understand, and for most, I would recommend you start there.

You can learn Markdown in an afternoon. Learn it and put it on your resume, LinkedIn, and demonstrate something with it on your portfolio.

HTML is a little harder, but you can learn it in two or three weeks. Sololearn is a good place to learn it, but there are thousands of excellent HTML tutorials online for free. You will especially need to learn how to write tables for technical writing, since Markdown is really lacking in this area.

Learning git is required for docs as code work, and here is a very thorough and well written tutorial for git. You will not have to learn all of this to be very successful with git. If you get through the section on Merging (about half way through), you will do fine. Often for difficult git questions, people search the internet anyway.

To learn to use GitHub, you’ll need to create a GitHub account. To learn it, you can see many tutorials online as well as YouTube videos. It’s not hard to get started if you already have some git knowledge.

One benefit of learning git is you will already have begun to learn command line, since command line is a big part of git usage. In fact, navigating git and the directory structure for the files, is probably the main skills you will need for the command line.

The websites for Visual Studio Code and Atom have great tutorials already, and both programs are free. Use those tutorials and learn one of those programs, at least at the basic level. Learn how to write Markdown in one of them and see the output formatted correctly.

Static site generators all have websites with tutorials as well. As I said, Jekyll and Hugo are common, but there are others as well. Try installing one, and getting it to work. Create a page with Markdown and get it to publish. That’s a good start.

Docs as code tends to pay very high, since special knowledge of software development is required.
Docs as code is what I use for work, so you could say I am biased in this direction. Since it is not so strict with its format, like DITA is, I feel I can be more creative in the whole process. I’m sure DITA lovers, however, feel it has many advantages as well.