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.

Akshay Bardia

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.

Madcap Flare Adobe Robohelp

This entry was posted in general on by .

By Tom Johnson

I'm a technical writer working for The 41st Parameter in San Jose, California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), API documentation (code examples, programming), and web publishing (web platforms, interactivity) -- pretty much everything related to technical writing. If you're trying to keep up to date about the field of technical communication, subscribe to my blog either by RSS or by email. To learn more about me, see my About page. You can also contact me if you have questions.

11 thoughts on “Guest Post: A Week in My Life as a Technical Writer (with some humor)

  1. Fer O'Neil

    I like the part about generating deliverables–this helps establish the need for continuous professional development in our discipline and companies.

  2. Raj

    Another post that tries to make a big deal out of the profession. A little bit of care could have made this post much more interesting and clean.

    1. Akshay

      Thanks for taking the time to read, appreciate your feedback. In retrospect I do feel, it comes out that way but it was just me trying to induce some humor.

  3. Pamela Clark

    I like this comment: “When you have spent an hour amending the sentence, someone will suggest deleting the paragraph.”

    I’ve had that happen. :-)

    1. Akshay

      Yes I think as writers pretty much everyone must have gone through that. I think it’s an extension of Murphy’s Law. Thanks for reading the post.

  4. Liz Miller

    Akshay, because I am a contract technical writer and paid hourly, I can’t get away with any form of goofing off or using my clients’ resources for recreation. So it was fun and interesting to get a peek into a “captive” technical writer’s world. Also, I loved reading how similar your work day in India is to mine in California. I really enjoyed your numerous and very witty descriptions of the many tasks we share. I hope you continue to do lighthearted creative writing in the future.

    –Liz

  5. Akshay

    Thanks Liz, am really glad you enjoyed it. The work can sometimes get dreary, and I will be coming up with more of such descriptions. Once again glad that you could get a laugh out of it. Cheers.

  6. Avadhut

    Hi Akshay,

    I read your post till the end. Very interesting read :)

    I’d like to know the tools you use for technical communication.

    Regards,
    Avadhut

Comments are closed.