Would I like technical writing?
Before you invest time, and possibly money, into getting into a technical writing career, you should first decide if it’s the kind of job you would like.
Keep in mind you probably won’t identify with everything in these lists, but if technical writing is a job you’d like, you may see some familiar patterns here.
Questions to answer – The big 3
There are lots of possible questions to answer to know if you would like technical writing, but I think these might be the big 3:
- Technical: Are you interested in technical subjects?
- Writer: Do you enjoy writing?
- Teacher: Do you find it worthwhile to explain things to people?
Technical
You are interested in all kinds of technical areas, maybe researching things that interest you, or reading books in technical areas.
You like to do some technical projects just for fun. Do you like configuring your computer OS? Ever tried writing your own program? Do you like setting up smart home devices? Have you taken things apart just to see how they work?
You are your own technical support. If you have a computer problem, you don’t call support, you figure it out yourself. If your wireless stops working, you fix it yourself. You fix all your smartphone issues, and maybe those if you’re friends or family’s as well.
You like news articles or TV broadcasts about new technology. You like to keep up on the state of autonomous vehicles. You think AI is cool. You like reading about new inventions. Cutting edge technology will always be fascinating to you.
You like researching all kinds of things. You don’t just read about new technology, but sometimes read more deeply about it because you want to know how it works – How are robots made? How does AI work? Could it ever be self-aware? What would it take to establish a colony on Mars? If someone asks you the time, you want to tell them how to build a clock.
You might be a fan of science fiction. I could be off on this one, but I’ve found that science fiction and cutting edge technology look a lot alike, which makes both exciting. Anything futuristic is fun. Therefore, you might like science fiction movies and books. You may sometimes hope you live long enough to see…the metaverse, house robots, flying cars, etc.
Writer
Writing has been an interest of yours for a while now. I had an 8th grade teacher who encouraged me to write, and that’s where my interest started. You might have similar stories.
You write a lot of lists. You may be the kind of person who has lots of lists for things. You like having your thoughts organized, as well as your schedule.
You write instructions for your future self. Once you figure out how to do something, especially something technical, you like to write down how you did it so you know what to do next time. You have lots of these sets of instructions written somewhere.
You like to read or write in your spare time. You may have an interest in writing a novel, or maybe you already have. You may read yourself to sleep at night. Even when you read a book, you might wonder exactly how it was written, and wonder if you could do the same thing yourself. You may write a blog, or lengthy social media posts.
You get satisfaction from a well written paragraph. I mean the kind of feeling you get after you have written, rewritten, revised, and edited your own work until it’s as good as you can get it. Reading something that you’ve written well just feels good. It feels like a worthy accomplishment.
Teacher
I didn’t just add this because I was a high school teacher for so long. I really believe a technical writer is inherently a teacher at heart. As such, you are good at explaining things to people, and you get some satisfaction from it.
You want to pass it on. If you learn something new, you probably can’t wait to tell someone what you learned. My father used to joke about a kind of person that if you asked them what time it was, instead, they would tell you how to build a clock. That’s pretty extreme, but maybe you’re a bit like that.
You love teaching people things. My father used to joke about the kind of person that if you asked them what time it was, they would instead tell you how to build a clock. You might be a bit like that. You like explaining things to people. Maybe you were the one who helped one of your siblings with homework. Perhaps you want to be the one to teach your own child certain things. I taught both of our boys how to read.
You are good at explaining things to people. You may find in conversations, when someone doesn’t understand what one of your friends is saying, you know how to say it so it makes sense to everyone. Maybe you did this in school, interpreting what the teacher said to your friends.
The day-to-day job
Another way to know if you would like this job is to get an idea of what it looks like on a daily basis, and decide if that sounds good to you.
Every company is different, but here are my observations:
- Meetings
- Planning
- Research
- Writing
- Iterating
- Revising/editing/proofreading
- Training/learning
Meetings are important as a technical writer, because you’ll have to talk to people to get the specific needs they have, any due dates or launch dates, pain points customers are experiencing, short term and long term goals they have, and more. You may also need to meet in order to have them review what you’ve written if they don’t seem to want to do it otherwise. You’ll probably also have regular meetings with your manager, as well as product managers, or other stakeholders just to see what’s coming soon or how you help them with known pain points.
You’ll find yourself doing more researching and planning than writing. You may need to research technologies that are new to you, terms you’ve never seen before, or more depth on the product you are writing about. If the project is very large, you may write up a formal documentation plan, or proposal, that you later share to get agreement from all stakeholders before moving forward to the work. For that you’ll need to plan a timeline, who signs off as an engineer, product manager, technical program manager, solutions architect, legal, etc. How will you do the navigation? Will it be on page or several? How will the information be organized? Will other pages need to be updated as a result?
Write your first draft, knowing it won’t be pretty, and probably will have plenty of mistakes. That’s what first drafts are for.
After your first draft, you probably want to have an engineer or other technical person look it over to see if it’s accurate. It may be that when you revised something, you interpreted it incorrectly, and now it’s inaccurate. Perhaps there have been changes to the product and the document is no longer correct. I have had instances where the person who gave me the original docs to work from had errors in what they gave me as well. You at least want to make sure that everything is technically accurate.
This may take several iterations. They add some notes and you try to make the changes. You ask again if that was what they wanted. Sometimes you may go back and forth several times before everything is correct and is easy to read. Iteration and revisions are often done at the same time. You will revise your work again and again. I read through each page a number of times, looking for things to change, ask questions about, or remove altogether. You will check your work with a style guide to make sure it lines up. If you have an editor on staff, they may read it as well.
If you can, and your company is supportive, you should also spend regular time learning. You may take online courses, go to conferences, or just read up on new technology or trends related to technical writing. This is a job where to keep competitive, you should keep learning.
The good and the bad
Every job has positives and negatives. Here are some for the technical writing job. So what do you want first, the good news or the bad news?
Positive
- The pay can be quite good. In fact, if you have an English, Literature, or Journalism degree, it’s one of the highest paying jobs you’re likely to find.
- Tech companies sometimes have a higher caliber of benefits compared to other companies.
- The job is often much less stressful than other jobs, especially compared to programmers or engineers.
- You usually have a good work life balance as a technical writer.
- You get to learn about new technologies before the rest of the public, which can be very cool at times.
- It’s remote work friendly, and lots of remote jobs are available if you want them.
- You can choose your hours at many companies, which is nice if you don’t like to wake up early, or like me, you do.
Negative
- It can be very difficult to get your first job, which is why I write this blog.
- Often people won’t understand what you do. That includes those you work with.
- Often documentation will be an afterthought at your job. That means sometimes documentation may be requested just days before the product launches. At times they may even forget documentation altogether.
- Some subject matter experts may be slow to respond to your questions, or may not respond at all. Chasing them down can get frustrating.
- Some engineers might wonder why they even hired you, since everyone can write, right?
One neutral item I’ll add is that you will probably be multitasking in your job. I’m sure it’s not universally true, but I think it’s common to work on more than one project at a time. I tend to work on 3-5 at a time, with each in various stages of the process. It might add to some stress, but it also keeps things from getting boring.
You can always do more research into whether you might like technical writing or not. YouTube is a good resource. Reading job descriptions can also give you an idea of what’s involved in the job. Reading comments from reddit in r/technicalwriting might help as well.
What should I study first?
If you want to get a job as a technical writer, you will have to get technical. Since I’m often asked what to study first, I’ve put together some guiding principles so you can figure out where to spend your time learning the technical subjects.
I won’t tell you what to study first, but I’ll give you what you need to make that decision. As usual, I’m assuming you want to document software using a docs-as-code approach, which is where my experience lies.
For minimum requirements to get a job as a technical writer, see the first section of Getting experience – Part 1.
If you have a technical background
If you have a degree in computer science, or you have been a software developer in the past, you don’t need as much practice with the technology as you do writing and thinking like a technical writer. What would probably help you the most is a technical writing certification. It may be from a college or other institution. A certification will demonstrate to employers that you not only know something about writing, but that you have the skill to write technical documentation. It also proves you are interested in technical writing as a career. I mention this because some employers will assume that since programming pays more, you will end up doing that instead of technical writing. Completing such a certification shows you are serious about this profession.
If there are some items you don’t know on the list below, go ahead and learn them as well.
If you don’t have a technical background
This is for all of you with a BA in English, Art, Social Science, etc. You will have to put a heavy emphasis on learning the technology to get into technical writing. Here’s what you need to learn.
List of technology to learn to be a technical writer
- A programming language – just the basics
- Git
- Command line
- HTML
- Markdown
- Web API documentation
- OpenAPI specs
| Technology | Difficulty | Estimated time to learn | Notes & resources |
|---|---|---|---|
| Programming language | Hard | 2-4 months | Only at a basic level. Here is some guidance on learning a programming language. |
| Git | Medium | 1 month | Learn this through githowto.com. Out of the 51 lessons, the first 28 will be the most useful. |
| Command line | Medium | 2-4 weeks | Depending on your OS, go to YouTube and type of the the following:learn command line for Windowslearn command line for Mac OSlearn command line for LinuxThere are a lot of good videos out there. |
| HTML | Medium | 3 weeks | There are probably a million HTML tutorials online. Learn the basics, plus how to create tables. |
| Markdown | Easy | 2 hrs | This is really easy. Learn it with Markdown Live Preview. |
| Web API documentation | Hard | 3 months | See Documenting APIs from Tom Johnson. There are several Udemy courses on this topic you can buy as well. |
| OpenAPI specs (Part of web API documentation) | Hard | 1 month | Only 1 month if you already know web API documentation basics. See Step-by-step OpenAPI code tutorial. |
In order of importance (just the numbers)
If you use my spreadsheet for job results in my area, you’ll see a number of jobs results for each skill.
- API = 26
- HTML = 23
- Markdown = 22
- Python = 20
- Git = 15
- OpenAPI = 2
Notice that rather than include “programming languages” in the list, I listed “Python” instead. The reason is because if I wrote “programming languages,” phrases like “know a language such as Python” would be excluded. If I did not put it in quotes, it would look for the words programming and language, but not necessarily together. Anyway, Python comes up the most often in the list when they ask for experience with a programming language.
In order of importance (my view)
Here’s my view of what is most important to study. You’ll notice some differences. This is a bit subjective, but I do have reasons. The reason I did not put APIs at the top is because although API documentation is listed fairly often, it is less common for it to show up in actual interview tests. In all the companies I’ve interviews with, I think they tested me on APIs twice. None of those were FAANG (Facebook, Apple, Amazon, Netflix, Google) companies, by the way. Whereas, all the FAANG companies, and several others I’ve interviewed with, had me read code in a programming language and tell them what it does.
What do employers tend to focus on the most in interviews? What’s highest on their list? Here is an estimate from my experience in the San Francisco Bay Area, interviewing at many of the top companies, including most of the FAANG companies.
- Programming language
- Web API documentation
- Git
- Command line
- Markdown
- HTML
- OpenAPI specs
Some things to keep in mind
You may imagine that you want to spend all your time at the top of the list and work your way down, but remember, Markdown only takes a couple of hours to learn. In that case, even though it appears much further down, you probably want to get it done early in order to add it to your resume soon.
Something else to consider is that learning some of these subjects can get tiring after an hour or so. You need breaks so your mind can remain fresh and you don’t get burned out. That’s why you probably want to be working on 2-3 of these items at a time. When you get tired of learning programming, you can play with Git for a while. And then maybe HTML. This way you learn more in less time, and don’t get burned out on any one subject.
You should also know that if you start learning API documentation in any depth, you will learn the command line and possibly Git along the way, since these tools come up frequently when working with REST APIs.
If you want to read more about what you can expect in a technical interview, read The technical writing interview – Part 2.
Happy learning!
