I get the question a lot. It’s a common ice breaker and small-talk component, after all:

“What do you do?”

When I say “I’m a technical writer!” the look of confusion is unmistakable. And I don’t blame them! “Technical writer” isn’t a job title you hear every day, and it covers a lot of different things.

The short answer is: “we make complex information understandable.” Shocking, right? When I talk to people about what I do, I run into these two assumptions most often: 

• The stuff I write is incredibly complex, highly technical, and hard to understand.
• The only thing I do is write.

What I actually do¹ looks more like this:

• Identifying gaps (missing information).
• Organizing information (where documents are stored, how storage is organized).
• Updating older documents.
• Asking developers and other subject matter experts (SMEs) for information.
• Writing new documents.

Settle in while I tell you a story to illustrate my point.

Before I changed careers, I was a quality assurance tester in the video games industry (another role that was often the subject of incorrect assumptions…but that’s a story for another time).

90% of what we did was proofreading and copyediting. Since we were proofreading video games, we often needed instructions for viewing all the text (alternate endings, unlockable events, things like that). So I also discovered how important it was to have documentation we could understand and that was up-to-date. Encountering outdated documents and emailing the development team for clarification and updated information was a regular occurrence. Getting answers…that was not as regular as we would have liked.

I often found myself taking on the additional responsibility of updating my assigned project’s documentation and keeping it all organized in SharePoint. Moreover, I liked doing it–and whenever my team thanked me for making their job easier, that was the best feeling in the world. The evolution from that to technical writing was natural for me.

The first piece of technical writing I did was step-by-step instructions for loading online manuals on the Wii NDEV hardware (the developer kit [devkit] for the Nintendo Wii).

The instructions that came with the NDEV were complex and difficult to follow, but we were testing one of the WiiWare launch titles–that was a big deal! Online manuals were a requirement for WiiWare titles, so we needed to figure out how to load the manual on the NDEV so we could test it like we tested the WiiWare game it was for.

If you’re at all familiar with video games, you’re probably used to turning on the console, loading a disc (or cartridge, if you’re old school), and pushing a couple of buttons to load the game. That’s the intended end-user experience, and it’s meant to be easy. The NDEV was a different animal that didn’t even resemble retail Wii consoles. It only worked by being connected to a separate computer and entering commands using a dedicated SDK (software development kit) app.

I spent a long day holed up in a very small, poorly ventilated, closet-sized room with the NDEV, the instructions, and the files for the online manual. I was on my own–there was no SME I could email to ask for clarification, and access to the NDEV hardware was strictly controlled. It was up to me, a lot of trial and error, and meticulous notetaking to figure it out. But I did it!

Once I figured out the process, I wrote a single page step-by-step guide for loading WiiWare online manuals on the NDEV, in friendly language that I knew my coworkers could understand. 

I printed out a copy of the guide and taped it to the computer next to the NDEV–putting a copy in the most relevant and easy-to-find place. This saved time and frustration each time we needed to load the online manual to confirm bug fixes and allowed anyone on the team (with access to the NDEV) to do it.

That’s the essence of the writing part of technical writing–gaining understanding of complex information and writing it in a way that’s easy for users to understand. That last part is crucial; you need to know who your audience is and write in a way that suits them. It’s not about your own ego or trying to show off. It’s about your readers and what they need, even if it’s not what you yourself would prefer. 

I’m sure the fine folks who created the NDEV and associated SKD could use them without much difficulty, and the NDEV instructions were probably written by developers for other developers. But those instructions weren’t friendly to the average game tester and created a barrier between the user (testers) and our ability to do our jobs efficiently and consistently.

Good technical writing removes barriers. It meets the reader where they’re at and gives them the information they need to do what they need to do as quickly and easily as possible. That’s the sort of technical writing I love to do.

---

Sources and comments:

• ¹ At least, that’s how my career has progressed. There are lots of other things technical writers do, but these are the things I’ve done the most (and where my strengths are).
• ² RedBees. NDEV 2.1.
  25 June 2018. Accessed February 17, 2025.
  https://wiki.raregamingdump.ca/index.php/File:Ndev-21.jpg