Norman Bauman's posting, "ASJA meeting: Alternate income sources for writers when your writing work disappears," has lots of interesting stuff. (Thanks, Norman.)

But I have to quarrel a bit with this part, about tech writing:

Technical writing doesn't require specific technical expertise, said Bolles. "Anyone who has been a journalist, anyone who has worked a beat," has used the methods that is required to learn what you need to learn on the job to do writing. The only tools you need are word processing, Powerpoint and Visio, and what you haven't used you can learn quickly.

Not quite accurate, IMHO. Yes, you use your research skills and writing skills, etc., to get the technical information from various sources and then convey it clearly to users. However....

You also need some basic design skills so the documents you produce are well laid out, easy to read, & easy to follow. Helps to know some page-layout and illustration software.

And...

If you're writing software guides and help files, being able to learn about the software you'll be documenting is necessary, but not sufficient. There are industry conventions you should be familiar with ("you" being anyone doing tech writing in the computer field), both for written documentation and for help files. Structural conventions & development tools differ slightly for WinHelp and HTML Help (I've never developed a Help system for Mac software, so I don't know about that).

And...

You need to be able to use a program like RoboHelp to build the help system. You don't just write a help system, you build it: you create a navigation structure; you try to anticipate what info the users will look for, and how; you add hypertext links among various related topics; you capture and add screen-shots; you index the whole system; and you compile it. (Then you test it for broken links and other funky things, fix it, compile it, etc. And you deal with bugs in RoboHelp or whatever development tool you're using.) That's for stand-alone help. If you're writing help for an application (more typical), you also get "map IDs" (numbers corresponding to various dialog boxes & windows) from the programmers, and you associate the IDs with certain help topics so that users get context-sensitive help, and the right help topic pops up when users click the Help button in a particular dialog box. None of this is particularly difficult (although often tedious), but it's part of the job.

Also part of the job is chasing a moving target: Programmers will tweak the software and change things and will sometimes forget to tell you about the changes. You'll often just stumble across them in the next build of the software they give you. (You can help your clients out by alerting them to bugs you find in the software, as well as to typos & inconsistencies in the UI text.)

And....

If the company is big enough and the software's user base is big enough, the company might also want usability testing for the help system. Usability testing is a field in itself.

And....

In my opinion...A good Help system (or user's guide) is not just procedural. It also tells users why & when to use a certain feature, not just how. For example (she says, not so humbly), in an HTML Help system I developed this summer -- for a suite of applets that collect and analyze data from noise dosimeters, heat monitors, air-quality monitors, and the like -- very little of the help system was procedural. The software's interface was so well developed that using the software would be easy for anyone familiar with any kind of Windows program. (And that should be every software designer's goal. The only input I needed to give the client on the UI concerned terminology consistency.) A lot of the development work there went into explaining not just how to program a toxic-gas monitor, say, but when to use which settings. Lots of work also went into explaining the terminology so that users would understand the programmable settings and the data collected. (Easy to select the settings -- just pick 'em from list boxes -- but which ones do I use, when? The client said that users were sometimes technicians who knew enough to take readings but wouldn't necessarily have enough training to understand what they meant.) I learned whole new sets of abbreviations, like LEL (lower explosive limit), UEL (upper explosive limit), STEL (short-term exposure limit), and TWA (time-weighted average), so I could explain them to users. And things like this tidbit: The "combustible range" is the concentration range (of combustible gas in the air) between the LEL and UEL; it's the range in which a fuel can ignite and sustain a fire. The combustible range increases with increasing temperatures and in oxygen-rich atmospheres. So if the air heats up too much and the concentration of combustible gas goes into that range... Boom! (Hence the alarms on the monitors.)

Anyway... as long as I'm rambling... Writing about software is (to me) often quite boring, so I don't do much tech writing anymore, even though it pays better than editing. This summer's project was interesting because of what the software was about (the environmental science). (And that client has always been a wonderful client to work with.)

And by the way, "technical writing" isn't always about computer stuff. There are lots of other fields that use tech writing. And I would think that you'd generally have to know something about those fields to get those jobs. Every field has its own jargon.

Having said all that, I do think that Bolles's comment about chutzpah (in Norman's article) is still valid, to a degree. The first help system I worked on wasn't a development project; it was mostly mechanical stuff, fixing broken links and such -- in a help system that had been translated into Brazilian Portuguese... which I do not know, other than for the few phrases I learned while in Brazil for my brother's wedding in '87. (I got that job partly because my brother used to work for this client, as an employee, so colleagues of his knew that he married a Brazilian woman... so maybe they figured that if I needed help with the Portuguese, I could call my sister-in-law?) Anyway, I had my Portuguese/English dictionary, and that was enough.

However....

Norman's article said:

"You need the chutzpah, said Bolles, to be able to say, 'I know all about that. Unix? No trouble for me.' You can figure it out, he said, exuding confidence."

I would not tell a client that I knew an application or an OS or a programming language that I didn't actually know. That's beyond chutzpah; it's dishonest. I'd tell a client (or potential client) that, based on my years of experience with similar projects, I'm sure I could learn whatever I needed to know for this project, and learn it quickly. And my project history would help persuade the client that this confidence was justified.

Oh, and if you're doing tech writing, you might be asked to estimate a project fee and give a not-to-exceed figure. Tough to do if you don't have enough data, from past jobs, to draw from...

[End of sermon.]

Well, that was a long post. Sorry if I rambled too much.

--Catherine Oliver,
an English major who has edited computer stuff for about 16 years now (egads!) and occasionally written about it, too, and who now has to get off the computer and go do something productive, in Rochester, NY