An Interview About Technical Writing

Approximately how much of your time is spent traveling – whether for your job or for other professional opportunities?

Zero. I’ll sometimes go to a conference, but that’s an exception. I don’t know many technical writers who have huge traveling burdens — unless you’re a contract technical writer and you’re traveling between sites.

Do you focus any of your time and/or career goals on publishing, presenting, and or attending/speaking at seminars, conventions, and other outlets?
I publish a lot on my blog. And through that I often get invited to speak. I’ve given quite a few presentations (quite a few for me, anyway). And I really like my blog. I feel like I haven’t posted much lately, but it does keep me engaged, it makes the work fun, and I can’t imagine what my career would be like if I didn’t a blog. It gives me an outlet for expressing what I’m experimenting with and reading.

How has the work on your blog and podcasting helped – or hindered – your personal and professional interests?

My blog has never hindered my professional growth (unless I stay up late spending too much time on a post). But really, having a blog helps me because it forces me to keep up with the latest news and trends. It gives me an outlet for my creative expression, which is important for me because I like to write, and I don’t always get the opportunity to itch that creative drive at work. The blog is an outlet for that. It keeps me creatively satisfied and also focused on the career.

My podcast is especially helpful to me in getting to know other people in the field and interacting and learning from them, so it’s fun. It makes it a lot more engaging. It also helps brand me as an expert, which helps position me for jobs if I’m looking. My wife is also a blogger, so it’s an activity we do together.

Does your blog at all affect your relationships with your co-workers and supervisors?

Sure. I mean, I imagine a little bit. There’s an increase in communication. Two of my colleagues are also bloggers: gryphonmountain.net and blog.paulpehrson.com. We are also engaged in the STC together, so it makes it a little more fun. There’s more camaraderie, more interaction, and more passion behind what we’re doing.

What is your definition of “technical writing”?

One definition I’ve heard is that technical writers help non-technical people understand technical things, which is partly true unless your audience is technical. In that case, you’re helping technical people understand technical things.

My dad tends to think of me every time he reads poor instructions, so in the general public eye, technical writers write instructions to help people learn how to use software, gadgets, or other technical things. That’s pretty much how I see myself and the profession: helping people understand and learn how to use all the technology that’s coming out. We live in an age where there are new web apps and other software developed daily. Somebody has to help people learn to use the new technology. That’s how I see my role as a technical writer: helping people learn new technologies.

What changes have you seen occur in the field over the past five years –- and perhaps what are your projections, if any, for the field for the next five years?

There’s been an emergence of DITA (Darwin Information Typing Architecture). DITA is an XML structure that you apply to your writing, which if you do, you can then transform it into PDF, HTML, and other formats using something called the DITA Open Toolkit. This allows you to single source your material. DITA is a huge buzzword. I’m not really into DITA since I don’t have a huge use for it in my work, but a lot of people do and they’re really excited about it.

I do single source, when I have that requirement — and I can do that all through MadCap Flare. MadCap Flare now publishes in DITA, so that gives you more possibilities. One project I would really like to try, speaking of DITA, is to author content in Flare, export it as DITA, and then import the DITA topics into WordPress and see if I can make like a website-looking help file. But I’m still working on that.

Another trend I’ve seen is the de-standardization of help authoring tools. RoboHelp is no longer the main online help tool. There is really no single tool. There are several major players — RoboHelp is one of the players, and Flare and Author-it and maybe even Doc-To-Help — but really, there’s no single tool — it just depends where you are.

I’ve seen people grow less and less patient with long manuals. I don’t think people want long manuals anymore. People expect to learn by playing around with the application, and maybe reading a help file when you need it. I don’t know if it’s always been that way, but I definitely don’t see much emphasis on long manuals anymore.

As far as where the field is going, I see more talk about wikis. But whether a wiki would work for you is very project specific. Unless you’re working in an open source or community environment and have a lot of contributors from people in different locations, or unless you have just an environment where tons of people want to contribute, I don’t see wikis as taking off. But wikis definitely have an appeal. We use social media within our team. We use Twitter, we have a team blog, and we also have a team wiki. The tools are excellent tools for collaboration. Whether they’re going to make the help documentation space take off is another question.

As far as trends into the future, I tend to emphasize video tutorials and quick reference guides as the main products I produce, rather than reference manuals. Even if you can single source a reference manual for five different audiences, to me it’s still a manual. In my experience, people like short formats and they like videos. So those are two formats I’m pushing. But at the same time, I still write the online help, and if you write it in a help authoring tool, you can single source it into a printed output. So really I produce all of the main deliverables: the online help, the printed reference guide, the quick reference guide, the video tutorial.

As far as other trends, I don’t know. Some people talk about round-tripping from DITA to wiki and back and so forth, but I don’t think that’s common.

Which three skills do you believe are the most important in order to find success as a technical writer?

The ability to write is key. If you can’t write, it’s like being a football player with a poor ankle. It’s going to nag you and bring you down.
Another key skill is having a technical ability. If you can figure out how things work, figure out how to learn new software applications, that’s key, because most of your job involves that. You have to figure out both what you’re documenting as well as the tools you’re using to write and publish those instructions.

Finally, having some people interaction skills is also useful. Your ability to interact with project managers, quality assurance engineers, developers, and other people on your team is highly important. I don’t know how you develop those skills, but definitely don’t neglect them.

Madcap Flare Adobe Robohelp

This entry was posted in beginner tips & careers, general on by .

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, DITA, and more. If you're trying to keep up to date about the field of technical communication, subscribe to my blog. Email

2 thoughts on “An Interview About Technical Writing

  1. Pingback: An Interview About Technical Writing – Technical Communication Center

  2. Pingback: STC Rocky Mountain Chapter - Newsletter » Blog Archive » Interview with Ruth Gaulke, President, STC RMC 2009-2010

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>