Ivan Walsh

Ivan Walsh is a technical writer based in Shanghai, China. Ivan provides documentation services to a range of clients across Asia and the Middle East. Read more at: www.ivanwalsh.com

Ivan was kind enough to play the interview game with us and provide personal experience, perspective and useful tricks for the technical writing community. We hope you enjoy reading him as much as we do, thanks Ivan!

What are the three things you love the most about being a technical writer?

Maybe a little background on how I got into this field would put things into perspective. I started as a programmer many years ago and found that, while I liked coding, I often ended up as the intermediate between the software team and the client. I’ve always had fairly strong verbal skills and, being Irish, have a natural predisposition to chat to people anyway. These communications skills helped in the transition to tech writing, which brings me to our first point.

1. Technical writing is about learning.
If you want to succeed in this field, you need an appetite for learning; a real hunger to know and understand how things work. I’ve always had a keen interest in technology and my career over the past 15 years has allowed me to satisfy my own intellectual curiosity. There is always something new to learn. It really isn’t enough to have to document an application. At some point, you have to want to help the reader genuinely understand how this works. To share what you’ve learnt and hope this makes their experience of the product that little bit better.

2. Technical writing is about organization.
Most tech writers are fastidious and like to organize bits of information. For example, while I would never say I’m the greatest writer in the world, my editing skills are quite good. Without really trying, I find errors in text, layout, and typography that most people don’t see. Distilling random bits of information into a more organized format can brings its own reward.

3. Technical writing is about teaching.
One of the misconceptions about Technical Writing is that it’s a solitary profession. While there are phases when I need to close the door and write for the afternoon, an equal amount of my time is spend talking to developers and clients (i.e. understanding the application) and holding workshops and sessions where we discuss the results. So, the role of a tech writer is as much about sharing information as it is about writing.

If you were going to a desert island and were only allowed to bring DocBook, DITA, or nothing at all, what would you choose and why?

I saw Tom Hanks in Cast Away and I believe his life would have been considerably easier if he had built his raft based on the founding principles of DITA.

Ok, maybe not, but I gained considerable exposure to DITA when working for a large US technology firm and, after some initial skepticism, was impressed with the end product.

The XML tool, in conjunction with DITA, enabled us to create chunks of text that could be exported to different platforms quite successfully. While there was an initial learning curve involved, it proved to be a more flexible and pragmatic solution than writing the documents into other tools.

During your typical documentation project, which tool or software do you use the most, which one do you prefer using, and which one do you wish existed?

1. Microsoft Word: most clients generate their documents in Word, so updating and developing documents is generally in this package. I’ve learned how to get the most from it and use macros to automate manual tasks. I’ve recently made an aim to use Google Docs as much as possible and see if I can perform my word processing tasks over the web. I’m about to buy a netbook and this will save me the expense of getting Microsoft Office installed. So far I’ve been impressed with Google Docs, especially so of the round-tripping to Word.

2. Camtasia Studio: a lot of my work involves online documentation and preparing tutorials. I try to convince (i.e. persuade) clients to use video to accompany the print manuals and use it to demonstrate how their products work. We create product demos and promotional material with Camtasia and it really is a joy to work with. Camtasia Studio beats the opposition hands down.

3. Speech recognition software: the amount of typing I do would be seriously reduced if I could find reliable speech recognition software. I’ve tried some products without success as I had to decipher what the product showed me and gave up.

If you had a magic wand that could change one thing about the documentation reviewing process as you know it, what would it be?

My father worked in the auto industry for many years. His company heard something interesting about their rival’s quality control process. Instead of checking the cars at the end of the production cycle, they were checked as early as possible. At each phase in the production cycle, the car was assessed and sent back if defects were identified. The rationale was that detecting errors early in the cycle disallowed other defects from arising.

I mention this as I’m surprised that document reviews occur so late in the development cycle. If smaller, more focused reviews occurred earlier, I believe the product and documentation would be delivered to a higher quality and also faster.

Do you have a fun anecdote to illustrate life without a magic wand?

A junior tech writer joined us a few years back. He liked to impress us with the speed in which he could docs out the door. A fatal flaw in this industry, by the way. He used the Autocorrect function in Word for finishing his words automatically. This makes sense to a point. Unfortunately, a document was later retuned by a client asking who was the IT Mange referred to in the document. Somehow ‘Manager’ and ‘Mange’ were switched in the auto-correction process. I think the moral was to slow down and check the documents by hand. Word lacks divine abilities.

How does online collaboration work in your documentation projects? Do you have a favorite LiveTechDocs feature?

Companies are always looking for ways to reduce costs, especially in today’s economic climate. Recently we completed a project for a US non-profit where we used open source and freely available tools, such as Google Docs. While there was a few teething pains, we managed to write the documents online, use the platform to review and add comments without the overheard of using Microsoft Office applications.

For the organization in question, online collaboration meant they could keep their team in the field AND get the material delivered on time.

As software products become more sophisticated and development teams are increasingly distributed across the globe, collaboration is becoming the norm and not the exception.

Products live Skype, Google Docs and LiveTechDocs enable companies to make these advances and distribute information secure and efficiently.

Is being a technical writer in China different in any way than, say, in the United States?

Yes and no. I still have a lot of legacy clients from the US and, from their point of view, nothing has changed. From my office here in Shanghai, I can deliver material to clients over the web.

In China, Technical Writing is gaining recognition as they move further up the value chain. US companies are out-sourcing their tech docs here to cut costs and avail of other incentives.

Chinese companies are starting to target the US market. Many of these have been setup or funded by US investors and demand high-quality documentation to accompany their product sets. They know the integrity of their products will be damaged by ‘chinglish’ user guides and garbled text. So, there is a culture change here.

It’s a good time to be a tech writer here in China. Long may it last!