Guest Post: A Week in My Life as a Technical Writer (with some humor)
The following is a guest post by Akshay Bardia, a technical writer in Mumbai, India.
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.)
Once we have the information, it needs to be decoded, quite literally. It must be turned from technological and management mumbo jumbo to simple English.
This taxing task means that we have to break for lunch. I make maximum use of the lunch hour by tuning in to my favourite sitcoms.
Now, we put together the deliverables, which vary from process flow charts to marketing collaterals. It takes roughly a third of the time to gather and understand the information. It needs to be very clear and unambiguous. The more ambitious of us will find it hard to refrain from using metaphors or inserting a stimulating sonnet, but the managers expect us to leave delivering the jargon to them and get on with telling the people what it actually means.
When the deliverables involve diagrams, avoid using wavy brush strokes and subtle colours. What is required are straight lines and in-your-face banners. The key is to remember that this is not going to be put up next to the Mona Lisa at the Louvre but at a manufacturing plant whose supervisor admires blueprints and not the works of the Renaissance.
Once that's finished, all that is left to do is to generate the output. When generating online outputs, you will inevitably find some bugs. These must be fixed, and though bugs are like cockroaches, they never really go away for good (this does not mean you can call the nearest pest control service).
Generating deliverables usually requires us to be proficient with a variety of tools used to create them and the products themselves. Which means you can expect to attend a lot of seminars, orientations, and training sessions. It's good to have team members on these sessions, so they can explain what was being said when you were busy doodling on your notepad. It is more often than not a relaxing break.
The final part of the working day is spent in implementing feedbacks from peers and clients. This is sometimes more difficult than actual writing. The clients will often tell you what they don't want but rarely what they do want. It can also be frustrating to decide at length whether there should be a hyphen between sub and menu. When you have spent an hour amending the sentence, someone will suggest deleting the paragraph.
This is the cue to sip some tea, munch a few biscuits, and head home.
Akshay Bardia lives in Mumbai, India. Despite his lightheartedness with this post, he works hard as a technical writer for ibruk Consulting. Anyone wanting to read more from Akshay, please find your way to http://ibruk.wordpress.com, where he posts frequently, and also to http://akbd.wordpress.com, which is a home for mindless ramblings.