1. What advice do you have for me in beginning my preparation for this career?
Take some technical courses (computer programming, engineering, chemistry, biology) along with your writing courses.
Read some journals (Communicator, say).
Talk to Tech Writers (or Technical Communicators, as the field is starting to be called - includes technical editors, illustrators, and so forth).
Never ever say, ‘I can do this, writing isn’t that hard - ANYONE can write.’
2. What qualifications would you consider “must haves” for this career?
Good grammar and a love of writing.
A willingness to put yourself in someone else’s shoes (be an advocate for your reader).
A fundamental urge to be helpful or to teach. Good technical writing helps people, or teaches.
A good comprehension of some kind of science or technology is helpful. Doesn’t have to be a particular field, but there are amazing overlaps.
3. What was your career path?
Geoghrapher (international business geography). That has rolled sideways into technical writing, and I’ve just come full circle by moving into Internationalization as a specialty, applying my cultural geography master’s degree to my writing career. FINALLY!
4. What ethical issues have you encountered in your profession or position?
Conflicts between meeting the deadline and meeting the needs of the users, mostly. Sometimes conflicts between doing what I’m paid vs. doing what the client wants (but hasn’t agreed to pay for). And the eternal ‘should I write something that is cr*p just because the client likes it that way, or should I fight to produce better product despite what the client wants?’
And my current favorite: Is it really cultural imperialism to write documentation ‘for translation’ - does it assume that people from other cultures cannot figure out the differences in what I wrote (before it has been translated), or am I, by modifying my language use ‘for translation’, really saying that I am better than they - that I can see clearly into their culture, and they cannot see clearly into mine. (this one does not actually come up as a working question, but a philosophical discussion - the client gets what they ask for, period, and if that means Internationalizing the content, I don’t ask if there are any post-modernist cultural anthropologists in the user base.)
How was the dilemma resolved?
Almost always, the client wins. And usually, the deadline wins. Though when I’m doing a really good job, I work out a compromise - results that aren’t complete cr*p, and that serve the users needs well, even if not my ideal, on time, on budget.
5. What are the upcoming issues in the field of technical writing/editing?
-Whether to move over to all HTML help, and dump Winhelp entirely.
-Internationalization (see above ethics issue) and writing for translation. Many multinational clients out there want both their software and their documents localized, which means internationalizing them first.
Lots of other issues, about involvement in the design process for user interfaces, usability testing of documentation, and so forth.
6. What do you enjoy about being a technical writer/editor?
Teaching, writing, helping, figuring out what the users need and getting it for them. Having the users say, ‘I don’t even need training, the user guide answered all my questions.’ 
Working with teams that appreciate what I do, with clients that ask for me again, and with project managers who budget appropriate time for my work. Being part of a good team is very satisfying. Being able to put out a quality product is great.
7. What do you dislike about being a technical writer/editor?
Working with people who think I’m an input device - give me a functional spec, and I type, and that’s all there is to creating training manuals or online help. No thinking involved. No analysis, no figuring out how best to present the materials to suit the user’s needs. No budget for doing so, either time or money. No knowledge required - anyone can write, for pity’s sake. You’ve got 5 days to turn this out-of-date 150 page functional spec into an accurate 16-chapter user guide. With appendices and a comprehensive index.
Or with people who think I have some kind of technical psychic foreknowledge. We ran out of time in development, so you have to start writing the manuals for a system that doesn’t function yet - and the FRS hasn’t been updated, BTW. Or, the client keeps changing the spec, but you need to start writing now if you want to get the user guide done in time for installation (nothing like hitting a moving target!).
Or with people who think I’m completely new to the whole magical world of technology… the ‘wow, you actually understood my technical information’ response. After editing a white paper, the author said, ‘wow, you fixed that up so well, it’s like you even understood the technical stuff!’ Um, that’s because, I’m, like, you know, a technical writer… :smack: Boy, where do you even go with that one? (I replied calmly that I understood the info because I’d actually TAKEN a Unix Admin course, thank you very much.)
Fortunately, the vast majority of my experience has been with teams who value me and my skills, wish they could give me more time than was budgeted, are helpful and informative, and appreciate my input.
