Shanghai Tech Writer

A few weeks ago, I wrote a post titled “Typical Day as a Technical Writer.” It was a deceptive title because I didn’t actually write about my typical day as a technical writer. I was writing about another blogger/technical writer I read about and his typical day. But since then, my post always shows up on the first page result when googling “technical writer Shanghai”! I don’t know why the SEO ranking just shot up for that post and I sincerely apologize. It is not my intention to deceive the curious readers because I’ve been meaning to write a post about my typical day as a technical writer! So finally, here it is. I have renamed the other post to just “Typical Day.”

My Typical Day as a Technical Writer at NISH:

• Check for new emails. First thing in the morning, I check my mailbox for new messages. Most of the new messages are from our corporate office in Austin. We are 14 hours ahead of them, so while we went home the previous day, their day just started. They were busy resolving and addressing some of the issues we had in Shanghai.
• Fix and validate CARs. CARs, or corrective action requests, are software and documentation bugs that people have found and reported. Some are CARs that I need to fix while others are CARs I need to validate. I go through the CARs to see what the bugs/issues are and what I need to do.
• Attend documentation meeting. Meet with other technical writers to get status reports on everyone’s projects as well as receive any announcements and updates on department-wide and company-wide issues.
• Attend project meetings. Meet with the development team to find out project updates, changes and new features, to-do tasks, and issues to resolve.
• Meet with developers and content experts. If there are any changes or new features added to the product, I meet individually with the content experts to learn more about the changes.
• Play around with new features. I come back to my desk to explore the new features, how the changes affect the software as well as any documentation impact.
• Research online. I spend a good deal of time researching because the products I write about are highly technical and require basic engineering concepts and understanding, which I lack.
• Install, uninstall, and reinstall software application. Being a part of the software development process means we constantly have to reinstall the software to see the new changes.
• Troubleshooting.There’s always something that doesn’t work the way it’s suppose to. I spend a good amount of time figuring out what the problem is and reporting the issue/bug to the project owner.
• Provide feedback about software usability. Technical writers are the best “Beta users”and “guinea pigs” to experiment with new applications and products. I provide valuable feedback to developers on their product’s usability.
• Meet with lead writer/group manager. Once a week, I meet with my lead writer and manager to go over the status of my project, report any issues and difficulties I have, and receive suggestions/feedback about my work.
• Hold productivity forum meeting. Everyone shares tips, tricks, and anything useful to improve productivity at work.
• Eat lunch. Most of the time, I eat with my colleagues at the communal canteen for the whole office park. Sometimes we go out to nearby restaurants for group lunch. Occasionally, we order takeouts and deliveries.
• Check project schedule. I work on multiple projects with several deliverables (help files) simultaneously. It’s important to stay on top of the schedule for all the tasks and reviews that needs to be accomplished in order to meet project deadline(s).
• Write new feature documentation (NFD). New features are documented separately and go through several series of reviews before being integrated into existing help.
• Go through tutorials to confirm accuracy. It’s important to go through the tutorials several times to make sure the content is logical, accurate, and that no steps or information are left out.
• Send NFDs or documentation for review. Every documentation goes through a series of review before the final product is released.
• Report any bugs found in software or documentation. There are always bugs and errors found in software and documentation, whether my own projects or other people’s projects.
• Enter edits from reviews. After receiving reviews back, I need to enter all the edits. I might need to meet with content experts again to clarify a few details or missing information.
• Peer review other technical writer’s documentation. Every technical writer at NI has a peer reviewer and lead reviewer. We help peer review each other’s documentation. Sometimes I need to learn other people’s products before I can review their documentation.
• Attend various training. There are several trainings throughout the week ranging from new products/features to leadership training to technical training. Sometimes I help out with English training for the developers.
• Visit the snack table. After working intensely, I take a break and grab something to eat from the snack table.
• Compile online help. Most of my documentation is written in HTML, XML, or FrameMaker. I need to use various tools to compile all the project files including graphics into one help file.
• Use, modify, or give feedback about internal tools. LabVIEW is a graphical programming language that is NI’s flagship product. We’ve created several internal tools using LabVIEW to accomplish and simplify many documentation-related tasks. Sometimes these tools break or don’t work well. I provide feedback and suggestions for improving the tools as well as create/modify the tools for my own use.
• Add new topics to our internal help manual. All the technical writers at NI add topics to this help file explaining various procedures and instructions on our daily tasks. Basically, it’s our manual for writing manuals! Yes, we’re pretty geeky like that.
• Review miscellaneous documents. Occasionally, I receive requests to review various documents, presentations, and articles written by developers and other departments.
• Write documentation plan. When I start a new project, the first thing I need to do is to write a documentation plan. This includes all the necessary information we need to know (product, industry, audience, users, type of documentation, risks, time frame, deadlines, etc…) before we start writing the documentation.
• Plan parties and events. I’m the social dictator for the technical communications group, so I plan all the social activities such as group lunch, outings, quarterly parties, and fun team-building activities.
• Attend deck parties. Every few weeks, the entire R&D team goes up to the roof of our building for some beer, snacks, and socializing.

Wow! Now that I’ve written all this down, it looks like I do a lot of things, but not all in one day. This is more like a typical day / week / month as a technical writer at NISH.

Technical writing, despite people’s misconception, is not just about writing manuals and help files. Writing is part of the job but not all of it. As you can see from my typical day at work, I’m involved with many aspects of the software or product development process and cycle. We provide a lot of valuable feedback to a product’s usability. We also perform a lot of tasks that require more than just good writing/communication skills. Interest in technology, ability to multi-task, capacity to learn a lot of material in a short amount of time, critical and problem solving skills, excellent research skills, attention to details, good communication skills . . . these are all skill sets that are required of a technical writer.

Are you interested in becoming a technical writer? NI R&D Shanghai is looking to hire more technical writers to join our team. You can visit the job posting in a previous post.

(2 votes, average: 4.5 out of 5)

 Loading ...

  Subscribe to RSS feed       Subscribe via e-mail