Advent of Technical Writing: A Day in the Life

This is the fifth post in the Advent of Technical Writing series, wherein I will share something I have learned from my experience as a technical writer. My experience is primarily in software technical writing, but what you read may apply to different fields, too. View all posts in the series.

You may be wondering: what does the average day in the life of a technical writer look like? What do you do? What do you spend a lot of time working on? If you are entertaining a career in technical writing -- or are generally fascinated by what technical writers do -- this post will provide context on the day-to-day in the role. Of course, everyone's role is different. I will document mine.

The high-level

My job is Technical Marketer for a computer vision company. On the average day, I am striving toward helping to increase adoption for our products, which range from hosted solutions to open source utilities. I work with teams on product announcements, write technical tutorials that show how to use our products or solve specific computer vision problems, coordinate open source documentation across different projects, and more.

There are two categories of days in my work: those in which I spend most of my time writing, and those that are spread out across all of the other technical marketing tasks that I work on.

The days when I write more

Every week, I align on the topics that I should write about with my manager. This may be blog posts, documentation pages, product announcements, or everything in between. This conversation usually happens on a Friday. We go back and forth about the key initiatives that are being worked on in the company and industry trends to inform what is a priority for the next week. These discussions are crucial for both ideation and alignment. By the end, I usually have a few topics to write about and know which are more or less important given our priorities.

I start writing when I feel most equipped to write a piece of documentation. For new products that need to be documented, I often have to ask questions. I write these down, then ask them to the relevant parties. I take notes. I ask more questions. It is important for me to know as much about a product as possible. How we want to position it. The usage we want to encourage. How much the product is going to cost (if anything). For whom the product will be available. How the product integrates with other products.

When I am writing a blog post that requires code, I work on an example. If I encounter issues while working with an API, I share the feedback with the team. Again, I may ask questions to other developers about the code I have written and an API. The more information I have, the more equipped I feel to write about a topic.

Then, I get to work writing. I usually prepare outlines in the afternoons which I will then turn into full posts in the morning. These outlines usually start as a few bullet points or headings that I have written out. I will refer to any information that is documented in messages and the product itself as I work. During these times, I can be heads-down for hours writing different pieces of content. This is the time in which I feel the greatest state of "flow" per se. I am focused on writing.

The job of a technical writer involves going back and forth between documents, products, examples, and code to produce content. Thus, when I say "writing", I mean both writing and doing all of the reference work I need to prepare a post.

In a day, I might write two or three blog posts, or a few pages of open source documentation.

The days when I write less

A technical writer doesn't write all day, every day. My role involves other responsibilities that are related to marketing but are not explicitly writing. Today was one of the days when I write less.

I started today by working on a documentation project. This project is going to span multiple days. I reviewed some work I did at the end of last week to get started, reviewed code snippets, ensured all code had the right import statements (a potential "gotcha" in the content I am writing right now), and created visualizations.

Visualizations are important but they take a fair bit of time to create. I usually create visualizations after writing some content. By "create a visualization," this meant using an open source software package I co-maintain at work to show computer vision model predictions in different ways. I sometimes create visualizations and think "this could be better." Today was one of those days. I created multiple different examples, striving toward the one that best illustrated what the functions I was defining do.

Later in the day, I moved on to more administrative tasks. I invited team members to our Google Search Console accounts for technical documentation that I just set up. I filed a few PRs to add code search and custom open graph images to our documentation sites, features available in the mkdocs software on which we depend for Python documentation. I went back and forth on one of these PRs because there was a dependency issue we had to resolve.

Then, I had content to edit. Release notes came in for a project that I reviewed and polished. I used this as an opportunity to ask questions about the project, knowing that I will have more documentation to write about the feature when it has been released. After editing those release notes, I edited a README for a new section in an open source project. I provided feedback and suggestions, with some additional writing tips for the edification of the person whose work I was reviewing.

I coordinated other pieces of content, too. A colleague reached out to ask if we could meet to discuss writing a blog post. When we meet, I will do what I can to help turn the idea into a reality. I provided some notes on an existing piece of content, deferring to our marketing lead to do the final review because it was getting toward the end of the day and we wanted to publish the content today.

And then there were all the other little tasks that I had timeboxed for today that I don't recall.

While today was one of the days I wrote less, I have a documentation site to finish, a blog post to write, and significant revisions to make to a piece of documentation that is now outdated. I love writing, but the balance between the days when I write a lot and the days when I don't write too much is helpful. Writing all the time can get tiring.

I love the part of my role that involves helping others write content. It is not only my job to write content, but to help others do the same. Empowering my team members to write -- brainstorming ideas, making them feel comfortable with the process, providing feedback -- is one of the most fulfilling parts of my job. I am excited to help get some posts across the finish line over the next week written by colleagues who are contributing to our blog for the first time.