A Day in the Life of a Technical Writer at Global Software Company

First and foremost, it depends where you are in the publishing cycle. If you are at the beginning, I'll start from the beginning of a publishing cycle.

For example, consider an app that has two versions. It might have been released in 2020, and then you have versions for 2020, 2021, and 2022. If you're making the new one for 2023, at the beginning, you basically want to understand what changed.

So, what you do is, as a writer, you collect what are called release notes or "what's new" notes. This helps you understand what has changed in the app. I'm talking about everything that's changed, every last thing. You want to document every change so that the instructional book doesn't become unusable.

You want to know what's changed, and you might think that's a simple task, but it's so hard to get people and all these details of what has changed. They're often so busy fixing things that they don't write anything down. Typically, they don't remember, or they have to dig through a bunch of tasks to figure out what they did or what is different.

So, you need to know what's changed. From that, you make release notes. That's usually for your legal team and your user audience, so they know about any new tools or cool things they can find. They can then find instructions for how to use those cool, nifty things. Apps don't just sit there; they are always changing and getting better.

If you have a problem, customers usually write in. You can fix problems with the app that customers find, and then customers want to see that those problems were fixed. So, that's what you write in the release notes. Usually, writers write a big, formal list of everything that's changed.

From there, you can check the areas of the application where the user interface text is new. Developers usually write a draft of placeholder UI text, and then you go in and refine all of that. From there, you create all the tasks in your web help.

Your web help is a detailed book, or technically it's an information map. There are a lot of different formats you can use for this, but web help is something you can access online and it has a navigation panel. It's like an online book, but it's more of a web of information if you want to get technical.

Based on everything that's changed and everything in the app, you can now provide detailed instructions or tutorials on how to use a new tool and add it to your book or map. In my current role, all of that takes about four months to do. Depending on how much has changed, sometimes it's a little, and sometimes it's a lot, but you try to make it all happen.

Then, you announce your next release, publish all your content online, and launch the app. The build gets published publicly, and depending on how your company sells applications, the next improved version will become available in their marketplace for purchase or to upgrade. That's kind of an overview of the software development life cycle.

A day in the life as a tech writer is really hard to pin down because it depends on where you are in the publishing cycle. Every day is different; I've never shown up to work and had a day be the same. You just have to be prepared, organize yourself, and roll with changes.