---
title: "Guest Post: A Week in My Life as a Technical Writer (with some humor)"
date: 2012-03-17
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2012/03/17/a-typical-day-as-a-technical-writer-in-india/
---
# Guest Post: A Week in My Life as a Technical Writer (with some humor)
[![](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/orangebar.png)](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/2009/04/orangebar.png)

![Akshay Bardia](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/Akshay-small.jpg)

Technical communicators work odd hours of the day as we cater to clients in different parts of the world. So, you could find yourself yawning on the Tokyo shift, worrying about the traffic on the way back in the normal shift, or dozing off during the West coast shift.

If you are doing the early shift, while your friends are busy snoring you can start by logging on to the computer, browse around without looking over your shoulders, and check last night's scores.

If you walk in with others on the normal shift, you can boot the computer, and while waiting (this could take a while), make small talk with the guy on the next desk, exchange gossip, prod the computer, read the paper, prod the computer some more, and then mull over what to order for lunch.

And if by a happy chance you find yourself coming in on the late shift, you can skip everything and directly proceed with lunch.

So, how you begin the day depends on when you come in ... if you come in that is. The nature of work allows a lot of us to work from home, so ideally you will be working from your bed, trying not to burn breakfast, watch TV, and have a conference call -- all at the same time.

Most of the technical communications clients are in the IT industry, so chances are you will be frowning at a bug rather than trying to fix an oil leak.

Right, to work then…

Pretty standard stuff. Like in any industry, the first thing is to check and reply to your email. The replies are pretty standard too -- requesting data … again, trying to explain to the Japanese end user that *‘Pramod'* is not a new feature in their software but the name of a person who designed it, setting up meetings with clients, trying to push back deadlines, apologizing for the cross-culture gaffe in your previous email, etc.

With the email out of the way, now we focus on the actual work.

As mentioned, we work with new technologies, mostly from the IT sector. In order to document or communicate effectively, we need to be familiar with the technology. So you will almost always find yourself testing the things which you write about. Yes, playing around and exploring the products is a major part of our work, so don't panic if you see blue smoke coming out of your computer, and don't get swept away by the current while working for the navy. (Defense departments are one of the major clients that require documentation.)

In effect, we are beta testers for the products too, and this means that most of the *communication* part of our work consists of telling the designers, coders, and engineers that their things don't actually work.

Putting in that kind of effort usually calls for a break. Which some of us spend by solving word puzzles and honing our language skills; others debate on the headlines while I try to shoot pigs with angry birds.

After playing around with the software (or whichever product or service we are documenting), it's time for some research. This is quite unadventurous -- you won't be hunched over in the lab mixing compounds or running tests on the semi-conductors. Research mostly involves tracking down the experts and extracting information from them. (This is more like an interrogation since subject matter experts are harder to track down than most KGB spies and have all the eloquence of a whale speaking in Greek.)