What I’ve learned in a week (and a bit longer than that)

After the great response to my previous post, I should probably write another post about something else that tech writers are doing wrong. And although there is a part of me that would love to write a purely contrarian article for the hell of it (“Structured writing: Threat or menace?”), the responses to my post were so intelligent and reasonable that I need to focus on positive contributions.

What’s good about conferences

I still think that conferences (or as Sarah O’Keefe points out, the conference tracks) are most useful to beginning to mid-level techcomm..ers? Techcommites? Techcommrades? Anyway, that’s who I think would get the most out of seminars about theory and practice. But as Larry Kunz points out, there’s also the opportunity to learn about new tools and processes, and I really can’t discount that.

Even though I’m not likely to use the latest version of Flare, for example, I still read about it and note the interesting features. Even if I don’t use a particular tool, I find it useful to understand what tools are available and what features they offer. This lets me compare those tools to the tools that I am using. Now I can argue that the tool I’m using is better suited for my purposes, or I can see where it’s falling behind (and that I need to start filing feature requests).

Tech writing classes, and how little I know about them

I’ve taken one tech writing class, and it was something about documenting object-oriented programs. I took this not too long after I started working as a tech writer. It was a short class, and it was useful because I learned that I could probably do this technical writing thing. But this was when UC Extension was still figuring out whether there was a market for these courses, and what they would look like, so it was most likely an experiment, or prototype class.

But I was able to learn on the job because I got lucky: A doc team wanted an inexperienced person with some writing ability that they could turn into a useful employee. I don’t see many openings like that now, so it’s much more difficult for a prospective tech writer to fall into a career like I did.

Things I look for in a tech writer candidate

The basic list is: writing ability, organizational ability, ability to interview SMEs, curiosity, and someone who is part graphics designer, web designer, information architect, and tech support.

Did I have those skills when I started? HA HA HA. No. Not at all. I started with decent writing skills, an analytical approach to writing that has served me well, and the ability and interest that allows me to learn new software fairly quickly.

But I was terrible at interviewing other people, and I wasn’t allowed to work with graphics until I proved that I could edit line drawings without screwing things up.

Information architect? Oh hell no.

Tech support? Eh, well…I had done enough work on my own computers that I learned some basic troubleshooting principles. But I learned that through years of trial and error (do not ever, EVER stop fdisk before it’s complete).

What I recommend for new or prospective writers

I’m always impressed by someone who can create a decent illustration. I use Snagit to take and edit screenshots, and it has the benefits of being inexpensive and easy to learn. So learn to crop images, both by reducing space at the edges and learning what you can cut out from the “meat” of the image (there’s often a lot of space that you can remove without removing the meaning of the screenshot). Learn how to add callouts that explain and don’t distract from the image.

The ability to create and edit videos is also very useful. I’m still learning that, but I managed to create and edit four videos last week. Creating voiceovers when I had a cold was a questionable decision, but these videos are short, and they have a limited lifespan.

But graphic design ability is just one example. And if you’re focusing on API docs, it’s slightly less important (but still useful, and I think that needs to be explored some more).

Finally: Stubbornness

Don’t get discouraged easily. Some SMEs are practically ninjas (*cough* product managers *cough*), who will dodge, weave, and disappear in a puff of smoke and a cloud of bovine excrement. (And some PMs are freakin’ awesome and bend over backwards to make sure the docs are brilliant.)

Let me tell you a story: When I was about three years into my career, a senior writer gave me a review, in her role as acting manager. She told me that she didn’t think I had the interest or ability to become a successful tech writer.

I wasn’t sure what to do. I thought I was creating decent work, and I had even won two STC awards shortly before that review. But I still had to ask myself whether she was right, and whether I was really suited to be a tech writer.

And I couldn’t think of something that I’d rather do, so I stuck with it. I left that job (for many reasons) and dove into a new one. The doubt still creeps in every so often, but not as often, or as strongly, as it used to.

So be honest with yourself, and don’t give up because of a bad interview, an uncooperative SME, or a bad review. Tech writing isn’t an easy job (or else I’ve been doing it wrong), but it’s still an expanding field where there’s a lot of room to search for answers to the big question of user education.