That's a pretty unrealistic attitude and one that's bound to lead to resentment and all of its associated problems. Most modern managers realize that allowing workers to handle personal tasks at work usually makes them more productive and more loyal.
Besides, much of the time it isn't strictly personal. Many of my colleagues and co-workers use gmail or yahoo mail for their professional mailing lists because it's easier to handle the high volume, thread-based correspondence and its accessible from anywhere.
I offer this adivce as a technical writer who's worked in the software industry for over 20 years -- you have a lot to learn -- but a degree in CS is a great starting point.
First, yes, sometimes being a technical writer is a lot like being Rodney Dangerfield -- we don't get no respect! Unless, of course, we work hard to earn it! While many developers look down on technical writers as subhuman -- or at least less than intellectual -- when you prove that the emphasis in your job title is on *technical* rather than *writer*, you start to garner respect from the development staff. (Most of whom hate to write and welcome the help.)
Respect from users is a different story! It isn't enough to create just a "point-and-click" guide, nor is it enough to just document everything. One must seriously consider (and often research) the tasks that a user is expected to perform with the software and specifically direct the writing to assist in the accomplishment of those tasks. Occasionally, it may even be to the user's advantage to leave some information *out*!
You must have an eye for design, an interest in cognitive science, a sincere interest in presenting the product in a good light while supporting the users in their endeavors, thick skin, a sense of humor, and a willingness -- if not eagerness -- to learn something new every day. Additionally, you must be willing and able to "turn on a dime" as priorities in this industry change rather quickly.
It helps if you enjoy jigsaw puzzles -- and I like to equate technical writing to assembling a jigsaw puzzle. You take disparate bits of information and assemble them into a cohesive whole! If that doesn't sound like fun, don't *even* go there!;-)
There are many interesting Web sites directed at technical writers -- Google and learn!
There are a couple of whitepapers on writing API documentation on my web site at:
http://members.cox.net/susanwg/
And I will be speaking on API writing at the September 22 meeting of the San Gabriel Valley CA chapter of the Society for Technical Communication. Go to www.stc.org for more information about the society and what it can offer you.
There is a technical writing mailing list, subscribed to by several thousand technical writers world-wide. The list has been active since the early 90s and archives are available. To find out more about the list -- and to view the copious amounts of extremely useful information on the list's Web site, go to www.raycomm.com (you'll be redirected to the techwr-l site). You can even sign up to request a mentor there.
You need only subscribe to the list for a little while before a tool war erupts!;-) In general, Word and FrameMaker are the most prevalent tools in the industry. Followed closely by RoboHelp for creating online help files and Web Works Publisher to convert FrameMaker docs to either online help or HTML.
Tool wars, punctuation wars (should the semicolon be allowed in technical documentation?), whether a dialog box "opens" or "appears" or "displays" are all subjects that have been done to death on techwr-l. If you couldn't care less, you probably are not technical writer material!;-) Technical writers, in general, obsess about the details!
As far as salary is concerned, the STC does a salary survey every couple of years. You should be able to find that information at stc.org.
And as far as getting a masters degree -- you would do better to take on an internship position, as real-world experience is far more valued by most hiring managers (which I have been from time to time).
Slashdot Mirror
That's a pretty unrealistic attitude and one that's bound to lead to resentment and all of its associated problems. Most modern managers realize that allowing workers to handle personal tasks at work usually makes them more productive and more loyal. Besides, much of the time it isn't strictly personal. Many of my colleagues and co-workers use gmail or yahoo mail for their professional mailing lists because it's easier to handle the high volume, thread-based correspondence and its accessible from anywhere.
First, yes, sometimes being a technical writer is a lot like being Rodney Dangerfield -- we don't get no respect! Unless, of course, we work hard to earn it! While many developers look down on technical writers as subhuman -- or at least less than intellectual -- when you prove that the emphasis in your job title is on *technical* rather than *writer*, you start to garner respect from the development staff. (Most of whom hate to write and welcome the help.)
Respect from users is a different story! It isn't enough to create just a "point-and-click" guide, nor is it enough to just document everything. One must seriously consider (and often research) the tasks that a user is expected to perform with the software and specifically direct the writing to assist in the accomplishment of those tasks. Occasionally, it may even be to the user's advantage to leave some information *out*!
You must have an eye for design, an interest in cognitive science, a sincere interest in presenting the product in a good light while supporting the users in their endeavors, thick skin, a sense of humor, and a willingness -- if not eagerness -- to learn something new every day. Additionally, you must be willing and able to "turn on a dime" as priorities in this industry change rather quickly.
It helps if you enjoy jigsaw puzzles -- and I like to equate technical writing to assembling a jigsaw puzzle. You take disparate bits of information and assemble them into a cohesive whole! If that doesn't sound like fun, don't *even* go there! ;-)
There are many interesting Web sites directed at technical writers -- Google and learn!
There are a couple of whitepapers on writing API documentation on my web site at: http://members.cox.net/susanwg/ And I will be speaking on API writing at the September 22 meeting of the San Gabriel Valley CA chapter of the Society for Technical Communication. Go to www.stc.org for more information about the society and what it can offer you.
There is a technical writing mailing list, subscribed to by several thousand technical writers world-wide. The list has been active since the early 90s and archives are available. To find out more about the list -- and to view the copious amounts of extremely useful information on the list's Web site, go to www.raycomm.com (you'll be redirected to the techwr-l site). You can even sign up to request a mentor there.
You need only subscribe to the list for a little while before a tool war erupts! ;-) In general, Word and FrameMaker are the most prevalent tools in the industry. Followed closely by RoboHelp for creating online help files and Web Works Publisher to convert FrameMaker docs to either online help or HTML.
Tool wars, punctuation wars (should the semicolon be allowed in technical documentation?), whether a dialog box "opens" or "appears" or "displays" are all subjects that have been done to death on techwr-l. If you couldn't care less, you probably are not technical writer material! ;-) Technical writers, in general, obsess about the details!
As far as salary is concerned, the STC does a salary survey every couple of years. You should be able to find that information at stc.org.
And as far as getting a masters degree -- you would do better to take on an internship position, as real-world experience is far more valued by most hiring managers (which I have been from time to time).
Hope this helps!