Slashdot Mirror
Technical Writers in the Industry?
kungfooswade asks: "I am getting ready to graduate soon with my CS degree but I want to hedge my bets on finding a job and will be starting a masters degree, as soon as I am done. I am considering a masters in professional writing, so I can be qualified for technical writing positions, or just going back for a masters in CS. I am curious about the following: (1) what are the general opinions of programmers on technical writers; (2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences; (3) what software is used mainly in the process; and of course (4) what seems to be the average pay? I would like to diversify my education, so that I won't be searching very long if layoffs come around. All comments and suggestions are appreciated."
Since you know how to program with your big phat CS degree, what you want to do is become what is known as an "API Technical Writer." You will make a lot more money than us people who write "point here, click there" type manuals. And I think you will be able to find a job even now because there are not a lot of writers you are bona fide programmers.
Here is some un-asked for advice.
Get a masters in CS and take professional writing courses.
That sounds like a nice basis for a serious career technical writing, I really think it will serve you better than a masters in professional writing. You will be in a great position to apply for serious positions at egghead companies that are willing to pay well.
---
I support spreading santorum
Although I've only been in industry for about 5 years, from what I've seen there are far too few qualified technical writers. I've never seen one myself. They've always either not really known what they were talking about or there was nobody at all to write the stuff and a programmer was forced to do it.
I don't know if companies try to make due without them, or if they are just really hard to find. All I can really say is that every company I've worked for has needed one, and none of them had them.
... our opinion is this.
And now, for a sig that's a complete copout.
As a programer I've learned that you cannot write and program at the same time. Some programers are good writers, but when they are writing about their program they do a terribal job. Others (like me) are bad writters all the time. Still others can't program, or don't program, but write about code very well. Therefore I like having writers who can look over my shoulder and write something useful about my code.
There are several leveal of documentation, and most people and companies forget it. There is the "Do to X, do this, then that." Then there is the level of "This is how the program works externally", and finially there is the "This is how the program works internally"
The last is aimed at programers and in most cases isn't used outside of the company. It is also the only one you have a chance of getting a programer to write, even then the source code is often a better more readable source of information. However there is much call to take this as the programer writes it, and transform it into API documentation that other programers can use, often with the requirement that critical company ideas are not exposed to those outside the company who will read this.
The first, is a step by step how to. Click on A, drag to B, or some such sequence. If the user interface was any good, and people more willing to expitiment there would be no need for this, but most people are not comfortable figguring out computers. As a programer I have a real problem with this: I'm often required to sit though hours and hours of it to learn something I could have figgured out in 5 minutes. (often I know already, but don't skip ahead in the lession, we have to teach you how to double click before we can teach you the next step)
The other is something I rarely see, but consider most important. What is the program good for, and why do it that way. When I know that information the program is obvious, and more importantly, these manuals should be easy to read so I learn all the features. For example, I have seen plenty of examples of how to do a "mail merge", but nobody has defined what that term means, or why I would want to use it, and not knowing that I ignore all the instruction on how to do it - it may or may not be useful, and I may in fact do it.
I'm sure there is much more, but I don't know much more myself. I'm not a good writer, so I stay with things I am good at.
I am a published Technical Writer ansd there is great demand in the industry. It is Tech Writers who write the "how to " amnuals, website content, etc Pls check out my website "www.dhsdirect.com" Pls note--its still under construciton, so keep checking back!
Your job has been outsourced to India already. Find something pleasant to do, like management.
(1) What are the general opinions of programmers on technical writers;
Newbie programmers look down on technical writers with distain, the same distain they have for anybody that writes HTML and calls it programming.
Experienced programmers LOVE technical writers because we hate writing the documentation and are happy to have you do it for them. We will generally bring you cheesecake.
(2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences;
It requires that you be able to work as a go-between the hardcore techs and the mouth breathing users - so you must be able to relate to and work in terms that either understands, at various parts of your work. Note that there isn't a lot of crossover between the two.
(3) what software is used mainly in the process;
Microsoft Word. And some application that converts Word docs into help files.
(4) what seems to be the average pay?
No clue, sorry.
Glonoinha the MebiByte Slayer
The opinion of a bunch of programmers should not concern you in the least bit. The opinion of a bunch of hiring managers should!
If you're going to go for a MS and you're open to non-CS degrees, consider an MBA but don't go after a writing degree. If an MBA isn't your cup of tea, go for the MS in CS.
That said, definately work on your writing skills. This will open you up to a lot of opportunities outside of writing code including sales, marketing, management, and yes, tech writing. Of course, if you want to stick to the engineering side of the world, you'll get a lot more respect from both your peers and your management if you can effectively communicate your ideas. This means being a proficient writer as well as someone who can give a presentation.
Not comfortable with writing? You can start with some classes. I would recommend creative writing over english courses since you'll actually get a lot more practice and feedback in creative writing. If you go for the MS/CS, there is nothing stopping you from taking undergrad writing courses at the same time. Follow that up with taking on some writing projects such as some documentation for an open source package -- there are a lot of HOWTOs out there that could stand some time and attention. Not sure how you can improve them? Go back and read well-received books and try to understand what it is about them that made them so accessible. (e.g. the author took the time to explain the big picture and then followed up with a good example and explained all of the commands/parameters in detail.) Of course, don't forget that with an MS/CS, you'll need to write a masters thesis that can easily turn into a 80-100 page document. (My thesis was 128 pages!)
Best of luck...
From a technical paper/book writer's point of view, our organization banged out volumes of hardcore technical papers because of two things: we had a lady who loved to drip the blood of correction on things and we had someone who loved to touch up images.
Technical writing these days is about 30% of the time spent doing the core text writing. 30% more time devoted to revision after revision getting the wording just right in certain, highly confusing areas. The last 40% of your time will be spent on graphics. Screenshots, plots, equations, photograph touchups. You will hardly feel like you are using that masters degree for its real purpose.
If you want to learn good writing, get yourself a writing spirit and stay under the wing of someone that will be a good, honest editor of your papers for free or near free. Don't get a masters degree to do it.
If you want to study advanced CS topics (neural nets, compiler/language design, advanced DSP, etc) then go ahead and get your masters. But I hope you have a use for those skills in the real world because otherwise your masters degree will only earn you a job in management.
Having worked in the industry for over 12 years, and that working with a group of professional technical writers ( all with master degrees in writting) I can tell you that most of it is pure druggery. If you like rewritting the same paragraphs over and over and then only rewritting someone elses copy over and over should you consider going that route. Why not put your energy into something like research into new computer fields such as human-computer interaction or robotics. It would seem a waste of your talent to use those skills on something like writting documents. I admire those that can sit and write the same documents again and again..but only because of the sheer determination of staying awake. All of the writers I have worked with ( which counts over 12 people...some from JPL ) really don't like doing it that much.
Remember that your time here is limited and you should find something that you really like to do. Then be the best that you can be at it. I prefer writting software and user interfaces...why? because after all these years I find that I like helping people to use computers easily. I didn't find this out overnight. Neither will you. I wish you luck and good fortune.
What I learned from writers in the industry who came to talk to our classes:
So, the bottom line is:
You may have as much trouble getting a tech writing job as a newly-minted coder would; your job might be as specialized and ever-changing as a coder's job; you're better off with an MBA; your job might be sent overseas; and, instead of using your favorite IDE, you might get to use Word, instead.
Oh, and I forgot: because there are fewer of them, and their role is often misunderstood, you will possibly be less appreciated than the programmers.
Have fun!
-->orbbro.
"It's an erotic, spectacular scene that captures the thrusting, violent, vibrant world Bohemian spirit..."
I'm currently freelancing as an editor for the official manual on a certain general code compiler that you may have used before. It's not exactly a writing job, but because the book was written by a committee a big part of the work involves rewriting sections to make sure it doesn't read like something written by a committee.
I think this work & some other random writing I've done gives me a little bit of room to reply here.
The work I've done so far has been very well received by the members of this general code compiler's list. Apparently, no one has sat down and attempted to do a cleanup of the text in years, and it shows. Parts of the text were written by people for whom English isn't their strongest language, and most of it was written by people who are more talented as programmers than in explaining complex material to a lay audience. Moreover, the writing style changes drastically from section to section, and even from paragraph to paragraph. Trying to follow such a twisted text would be difficult even if the material wasn't so advanced, so if anyone steps forward and offers to make this material more accessible to people, it seems like that person is likely to be well received.
What do you want to know? I could go into detail, but the work I've done to date has mostly been editing, not first-hand writing. It's a related task, but not identical. Basically it means looking over the manuscript, making sure that the text is understandable, consistent, and adheres to the house style guidelines. In cases where the text needs to be rewritten, I have to be careful to be sure that the edited text still expresses the same intent that the original version did (and sometimes, that means muddling through what the original intent was in the first place). In cases where the meaning is especially ambiguous, it has meant consulting with experts on the topic, either over the phone, by personal email, or by asking on relevant mailing lists. It has been a lot of work. Much more than I anticipated when I started (but then, apparently no one realized how messy the text was, how out of date in parts, how ambiguous in others...)
Well, this book is formatted in Texinfo, but that's probably a quirk of this organization. The other book I was involved with was written in Perl's POD documentation format, but again that may have just been the whim of the author's as much as anything else.
I think, more generally, that most pubishers will let authors work in the tool of their choice, provided that the end result is in a format they can work with. The books I've been involved with were edited in Emacs, Vim, and presumably similar editors; others I'm told are done in Word, other word processors, other text editors, and other desktop publishing applications.
A good source of info on this question might be the colophon page in the back of many reference books. A lot of the O'Reilly books cite FrameMaker and Quark, but these may come up later in the production process than the authorship stage, and I'm assuming that it isn't as important for you to know the minutae of how a manuscript gets typeset and printed -- at least at this point.
I'm working for a non-profit, so you may not want my opinion on this one :-)
----
Another good source of material would be the so you want to write for us section on O'Reilly's site. Whether or not you intend to actually write for them, it's a good overview of things to be aware of. Other publishers probably have similar documents, and being familiar with this kind of material can't hurt you whether you're planning to be a book author or if you intend to do in-house documentation for some company.
DO NOT LEAVE IT IS NOT REAL
I graduated with a CS degree in May 2002, and have worked as a programmer since. I like my job, and have been looking at what to do with getting a master's degree.
;-)
For the past year I have been solid against getting a masters in CS or BA. I like writing, and had a minor in Professional Writing in college, and have been considering getting a masters in Writing of some kind.
I think now, however, that getting a masters in writing would be near worthless with the career track I am on. It would just be a personal achievement, nothing more. There is no positions in the large company I work for that would help.
The only place it might help is if you are in the publishing industry... books, and magazines geared towards programmers. I think those jobs are hard to come by, however.
Anyway, I am just waiting for the energy to rebuild in me for going to school again. And I still then might not know what to get a masters in
If you can't find a job and want to go back to college to buy yourself a few years, go for it. Study something you are interested in. Don't tune your entire life to get a specific job that you may hate... do you really want to be a technical writer for the next 30 years?
Most times, the best technical people in the long run are people with interests outside of taking some magic combination of classes that will lead to a good degree. There is nothing in this world more clueless and obnoxious than a 24 year old with a technical degree and an MBA who thinks that he shits gold bricks.
Study history or botany or whatever and leverage your technical or engineering background to produce something of value.
You only live life once, enjoy it.
Conformity is the jailer of freedom and enemy of growth. -JFK
The longer you stay in school wasting your time and money, the more experience I can get without competing with you for jobs. I encourage everyone who dreams about a fulfilling career in programming or technical writing to stay in school as long as possible. I encourage everyone who actually wants to do something to drop out and start working.
./ postings and you'll see that editing and even spell-checking are what's needed; forget about anything more creative than that. Unless you want to major in BAD writing you should avoid the computer-related disciplines, because bad writing (or "writting") is celebrated in every 800-page programming book on the shelves at Borders.
Look at the
And the situation worsens when you do internal documentation, because then you don't even have market forces to consider, just a lot of guidelines and methodologies.
Programming and writing are closely related. So-called programmers who can't put a grammatical sentence together are almost certainly writing crap code; anyone so sloppy to misspell every other word can't be trusted to write an important program.
I am getting ready to graduate soon with my CS degree
You can get a degree in Counter Strike? What university is this?!?
-------
Support Indy Music. Buy
Fucking idiot. How do people like this get a job?
Edger Djikstra said the most important quality to be found in a good programmer was a mastery of one's mother tongue. He then added that this explained the generally poor quality of American programmers. LOL.
Managers think that technical writers exist so that the programmers don't have to spend time writing documentation. Managers don't consider quality documentation to be very important. Not too many salespeople complain that they can't make their quotas because the manuals suck, and not many managers would buy it if they did.
If the company is doing poorly, managers will cut technical writing to the bone. Often they're instructed to cut 10 people from 100 employees, and they tend to focus on the most easily replaceable, lowest wage earners. (It's almost axiomatic that managers avoid considering salaries and focus exclusively on reducing head count when conducting cost cutting. After all, they make the highest salaries, and a feeding frenzy of managerial job cuts could have unpredictable consequences for the first to bite).
Even when times are good, technical writers don't often benefit. When a software company is looking to expand, they tend to hire more salespeople and engineers to sell more software and improve it faster.
Damned if I know what it is. My best guess is that the industry just doesn't understand what good documentation is. Usually, the only measure of quality is completeness. If you've got an entry in the printed index or a keyword in the helpfile that covers every single feature, or API call or whatever, then supposedly you have a high-quality manual.
Which, of course, has nothing to do with the user's needs. It's not enough to talk about it. You have to put the information in a form people can find and use. It's not enough to have a keyword/index entry, you have to have the right one. It's not enough to describe every feature, you have to give a description that's readable, that explains why you're interested in the feature, how the feature relates to other features and to tasks the user might want to do.
But nobody gets this, so a lot of software products come with big fat manuals that nobody reads -- that aren't even meant to be read! They're just there so nobody can complain that everything isn't documented. And of course any idiot can write that kind of documentation.
Of course, there are companies that take good documentation seriously, and realize that it adds value to the product. They try to hire good tech writers and do good documentation. And yes, there are good tech writers out there. I sometimes persuade myself I'm one of them.
Speaking of which, anybody want to give me a job? (API writer, documented thousands them, can read every programming language you know about, and some you don't.) My big problem is that I kind of forgot to finish my BA. Which didn't use to be a fatal problem -- just a little harder to get hired at the best places. But now there's a surplus of "qualified" talent, and the gatekeepers just filter me out.
Speaking as a former QA engineer, I always considered the technical writer's job unenviable; our writers were often brought into the project relatively late, and were forced to convert ill-written, poorly maintained design documents into end-user documentation. These individuals often faced conflicting pressures from both QA, who wanted factual, useful documentation, and Marketing, who usually wanted the facts kept out of the manual.
From what I encountered, to be a successful technical writer, you must mix equal parts bullshit artist, oracle and saint, and be willing to accept mediocre pay and searing criticism. Good technical writers are definately needed in this world, but the good ones don't seem to stay in the field for long, and the bad ones get promoted to management based on their tenure.
Weapons of Mass Analysis
I've never really looked at academic programs for tech writing. They didn't exist when I was in school, and most tech writers are still people who've drifted in from other professions. I've worked with several people who've bailed out of an academic career, and only one of them was in Computer Science. (Physicists seem to be pretty common for some reason.) The fact is, technical communication is a simple, pragmatic discipline. If you want formal training in it, you might actually be better off going to a certificate program at a community college. If it's a good one, it'll be taught by serious, working writers, who will teach you a lot more than academicians.
Not to discourage you from getting that Masters. First, it always carries weight, no matter what you get it in -- you'll simply make more money because you have it. And if you're not totally mercenary, you can consider that a good masters program (and do remember that there are lots of bad ones) will teach you how to do research and explain your ideas. But for that purpose, I'd have more faith in a degree in Literature or History than one in Technical Communication.
On the other hand, you might consider simply plunging ahead. If you're conspicuously smart, know technology, and write real good, you can probably get an entry-level job right now. Pick up a few books (Joan Haxos is good, if a little patronizing) and learn as you go.
Example: I once worked for a software company that was known for hiring really, really smart people. A lot of whom were very good writers -- I'm forced to admit that many of them were better than me, in the sense that they could turn out lucid, interesting prose. But they simply didn't understand the practical problems of explaining technical procedures to people.
Once, I was tasked with documenting a package that was basically a patch on another product. There was a central engine in the form of a DLL, and installing the package meant first installing the original product, then extracting the replacement DLL from a ZIP file and putting it in the correct directory so the original product could be made to load it in place of the default engine. Should have been done with an installer, of course, but for various reasons this wasn't possible.
So, I sat down and wrote a careful, nit-picky explanation of how to do all this. I carefully explained how to extract the file on the command line using info-zip (winzip didn't have its current dominance at the time, and info-zip was easy to obtain) with enough generalities so the user could adapt the procedure to another archiver.
I was not allowed to include this procedure in the release notes. The engineers felt it made the product look bad, like we didn't trust the users to figure out a more elegant explanation.
I ended up quitting that project because I just wasn't doing anything, except repackaging the prose of the engineer who grabbed my job away from me. He was actually quite a good writer -- he just didn't understand how easily written procedures can be misunderstood. As, in fact, his mostly were.
Get a real job. Go into hands-on technology or management, and learn to understand both reasonably well. Technical writing is not something you will make a career out of. Not to mention that it's about as exciting in the long run as watching grass grow.
There no substitute is for good know of solid, grammatic correct, concise english language write skill from college. Both tech and management jobs will give you plenty of opportunity for technical writing--something that a lot of individuals tend to disregard.
Cole's Law: Thinly sliced cabbage
FrameMaker dominates a certain kind of writing because it has a lot of features you need to do that writing: conditional text, self-updating cross-references, self-updating indexes, fancy templates, etc. None of these features is particularly well-designed, but the Word equivalents are mostly even worse. Or at least they were 15 years ago, when the two programs were carving out their respective niches.
I dislike Word, but I positively hate FrameMaker. Mainly I hate its user interface, which is like the GUI version of EMACS -- it pays lip service to menus and toolbars, but it still assumes that a real user has memorized all the keystrokes. Unfortunately, FrameMaker will remain dominant in tech pubs for my lifetime. I had hopes that competing XML editors would grab away market share, but the only one that came close was XMetal, and Corel seems bent on destroying that one.
Actually, FrameMaker does a semi-decent job of authoring structured markup -- provided you have a prepackaged XML or SGML application for it to use. It comes with ones for a subset of XHTML and an obsolete version of DocBook. Anyting else, be prepared to spend money on a consultant, because developing FrameMaker structure definitions is a nightmare.
Why not document some open source projects - then you can submit a portfolio to potential employers. If you can't be bothered, then rethink going into technical writing. If you think you lack the necessary skills, then do some evening courses.
You're at the start of your career: aim high. If you aim low, that's exactly where you'll end up.
If I seem short sighted, it is because I stand on the shoulders of midgets
XML and its progenitor SGML solve a lot of problems. Using them, you can create documents where proper structure is enforced. That's damned important when you have a big document base that difficult to manage, or when you need to deliver documents in multiple versions (the C++ version of the API versus the Basic version versus the Python version..) or when you need to deliver it in multiple forms (HTML, PDF, WML, VML...). And it makes content management easier. I could go on and on.
So why is everybody still using anti-structured, closed-format tools like Word, FrameMaker, Robohelp? Bunch of reasons. The biggest is inertia. There are a lot of people with expertise in these tools, and they don't want to retools themselves. There's also the sheer difficulty of pausing the product cycle long enough to convert your document base. And the difficulty of designing XML applications (much easier than SGML, but still not easy easy).
What's really frustrating is that XML applications are exploding in everything except technical writing. The technology is just the best way to manage huge gobs of data or content. It's gotten so that when you say "XML Content Management System" people assume you're talking about web content. Which is cool technology, but not something that does me any good.
Heh! Sounds like a HCI career, right down to the pay and working conditions. Oh well, janitor has a nice ring to it.
Female + CS degree = they'll just assume that the only thing useful you'll really be able to do is technical writing and glorified secretarial work er- I mean "management." Even after you've been coding for 20 years.
Most CS people have a very difficult time working in most businesses because their limited busines fundamentals. With an MBA (it was designed for engineers originally, which you technically are) you will have the best of both worlds, and with the finance classes you may actually know what to do with the millions you make.
Or you could just hit on the new freshman and drink beers. Either way you win!
I'm with you. There is something deeply satisfying about crafting a clear, concise, easy-to-read, impossible-to-misunderstand sentence.
That's why you and I are tech writers. That is why a lot of these guys should NOT be tech writers: if they think this stuff is boring, they are fantastically ill-suited for the thing we do day in, day out. I cringe when I hear people contemplating tech writing because they think it's lucrative (ha; you're better off programming) or they think tech writing jobs are falling off the trees (HA!).
I looked into technical writing briefly and got the impression that the field is something of a clique with social barriers to entry. I was also suprised to see that some technical writing positions required degrees in English rather than a technical field. Perhaps my experience wasn't representative of the field, but it put me off a bit.
Healthcare article at Kuro5hin
(1) what are the general opinions of programmers on technical writers
Programmers think we're lowly worms unless we demonstrate reasonable tech expertise and an ability to learn fast without pestering them too much.
(2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences;
Typical process--find out about project. Read any existing docs. Talk to subject matter experts (developers, QA, support). Plan and write documents. Route for review. Edit, rewrite, review, ask questions, rewrite, edit, grouse to family about poor interface design, rewrite, test stuff, review, edit, find out about last-minute changes, slap forehead, edit, edit, edit...
(3) what software is used mainly in the process;
Usually some of the following: Word, RoboHelp, Framemaker, Acrobat. Photoshop if you do your own graphics/screen caps, maybe.
(4) what seems to be the average pay?
You'd make more money programming.
I would like to diversify my education, so that I won't be searching very long if layoffs come around.
Jack of all trades, master of none? There aren't many tech writing jobs out there, and there are plenty of hungry writers floating around. If tech writing is only a fallback for you, it will be harder than you think to land a TW job.
Pick a career path, something you will actually like, and go with it.
(1) what are the general opinions of programmers on technical writers
I've been a programmer for just over 4 years now and I've always loved having a technical writer bitch to write my docs. I'd hate to be one but it's nice to leave all the crappy work for someone else to do.
(2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences;
Can't help you too much there other than WATCH OUT I know from first hand experience that PMs sometimes don't even include your stuff in the schedule. They seem to think it will just happen.
(3) what software is used mainly in the process;
I usually see them using word and an html help compiler.
(4) what seems to be the average pay?
I think your best bet if you really have your heart set on being a TW is to get on with some big ugly firm for a couple years and then become a contractor. Contract TWs can make way better money.
I work as a techwriter in LA, been doing this for three years now (one in college, two in the real world). Go ahead and reply if you have any questions I don't address.
Technical writing is, most of all, a really easy job. Provided your work environment is up to snuff, it requires as little or as much effort and imagination as you wish to put into it. The pay's OK, especially in the short-term, and it can give you valuable career experience while you figure out what you REALLY want to do.
Good luck!
(1) What are the general opinions of programmers on technical writers; Maybe Minnesota is just full of jerky programmers but I can say even my CS wielding Oracle guru husband hates TWers. Even though his vocab is better now than when we were dating. Frankly I don't think a good, comp0etent programmer can be a writer, those skills come from two different sides of the brain. (2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences; TWing is a compendium of skills: research, organization, writing ability (know the difference between passive and active voice for example) and understanding what the heck programmers are saying while still understanding what marketing wants! (3) what software is used mainly in the process; Microsoft Word in 50% of the jobs I've held, Adobe FrameMaker for 50%, Photoshop 100% for image manipulation. Online help tool. (4) what seems to be the average pay? Anywhere from $20/hr for a newbie or someone going through a recruiter to $100/hr for someone with an established reputation.
And it is known by many names ... business analyst, communications {whatever}, web developer (who also does content), sometimes even technical writer :) And sometimes by no name at all ... I think I'm officially a "Systems Analyst".
Tools? Word, Framemaker, RoboHelp primarily. Dreamweaver is popular. Tools are relatively secondary - be flexible and adapt to whatever tool you need to use.
Programmer opinions of technical communicators? All over the map. If they are competent, decent individuals, and if they have enough contact with you, they give you the respect you deserve (whatever that may be).
Pay varies wildly, depending on where you live, what your title happens to be, etc. Sell your skills and get as much as you can.
I've been doing this for five years (as a civilian) and I love it. My number one piece of advice is: don't be afraid to take risks, and to step up to provide solutions for communication needs in whatever organization you are in. Be the "go to" person (or department) when anyone wants to communicate anything.
Good luck!
Your web site is a complete embarrasment to the tech writing industry, the graphics are ugly, your links have no content and you're promoting it on slashdot like it's "great" Published writer! Ha! I'd be embarrased of that little piece of cyber space if I were you. www.krautgrrl.com
You've heard and will hear lots of MYTHS. Like "managers don't respect them" and "they get paid crap wages" and "developers look down on them". It's all crap. A GOOD EMPLOYEE will get respect and fair pay. So, what does it take to be a good Tech writer? You need technical knowledge. You don't need to be a SME, but you do need to know your shtuff. You also need to know how to communicate concepts. But most importantly, you need to be proactive and solutions oriented. Tech writing is no longer about only writing technical documentation. Many good tech writers these days are quite nimble around XML, VS.Net/C#, Java, and such. Why? That's where the profession is going. Sure, the focus is on communicAtion and usability, but the tools no longer resemble a typewriter. So, MY ADVICE is to first determine what you like to do. Do you like heads-down programming or heads-up programming? If the former, choose development. If the latter, choose tech writing. A MS in either CS or TW will work well for tech writing. But, if you go for a MS in CS, get a certificate in TW while you're at it. Even if you decide that programming is your thang, you can still use your TW knowledge to effectively communicate to others what you are doing and where you want to be with it. - Goober (cuz life is too short to be inept)
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!
A. You don't need a writing degree to be a good tech writer. In fact, a lot of university writing programs will actually pervert you into a buzzword spewing retard. The real-world isn't nearly as neat and tidy as those writing programs.
B. The tech writing profession is filled with whiners, blow hards, and font fondling obsessive compulsives. Lots of middle-aged, barely skilled housewives and balding, beer-gutted goobers who fancy themselves as poets and artists. Unfortunately, these dipsticks DOMINATE some aspects of the tech writing world. Be careful! Don't get too close to them. They will ooze loser-juice on you. Be especially careful and wary of ANYONE who recommends you join or associated in any way with STC. That is the central command for all the incompetent, font-obsessed grammar nazis.
C. I was a tech writer for many years (I am not any more, but I am still a goober). It was a good way to learn stuff, but its a crummy career. Pay sucks, respect is low, and it can be very stressful. However, you will learn a lot. If you get into a good company and really like technology. I used my tech writing jobs as basically a form of on-the-job training. I wrote docs so I could learn how stuff was done. Then once I learned it, I stopped writing docs and went and got a more respectable engineering job.
D. As for tools. Don't worry about tools. They're a quick learn. A lot of places use Word, FrameMaker, or plain old HTML.
E. Pay will suck. Starting salary for writers is in the 20s and 30s. Salary surveys are mostly a joke right now. There are also THOUSANDS of unemployed writers right now, so its a employers' market.
Since you have programming experience, you might want to sell yourself as a "Programmer who writes." or "An engineer who writes." This is more marketable.
(1) what are the general opinions of programmers on technical writers;
:) :)
That depends on a technical writer. If I ever met a qualified one, i'd buy him/her a beer. Or a cake. Or even flowers for a woman if that wouldn't violate company's sexual harrassment policy and she wasn't likely to get offended. I hate writing, and having someone do a good job for me would be a godsend.
On the other hand, the uber-dumb hack that the management stuck me with about 2 years ago, who wasted my countless man-hours and in the end came up with an absolutely incorrect and useless thick tome, was about as needed for my job and my application as a wooly mammoth in a small china shop.
(2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences;
Well, i'm not a technical writer by job description, but had to write my own documentation (both user and progarmmer oriented). It's a very painful job unless you enjoy writing (which I don't, like many if not most programmers
You need to be able to think both on technical level, to understand the stuff you're writing about, AND the users' point of view, which often is very different. You need to be able to express yourself clearly. And of course it helps if you like to write.
(3) what software is used mainly in the process
The hack I worked with used Word. I have used Framemaker on Sun when writing procedural documentation for Ops team I was with, and <my_favorite_text_editor> to write HTML docs for my application.
(4) what seems to be the average pay?
Beats me, i only wrote as part of my other jobs. Sorry.
-DVK
"The right to figure things out for yourself is the only true freedom everyone shares. Go use it"-R.A.Heinlein
Nobody really uses Word do they? It isn't a professional application for layout or printing or documentation or XML or SGML or for God's sake anything!
Framemaker.
Or something that will handle the tasks above without lots of facilitation from a professional printer. I hate stripping out MS garbage, dare I call it a visible cruft-like substance?
Any preoccupation with ideas of what is right or wrong in conduct shows an arrested intellectual development. (Wilde)
in my department, we have a very good technical writer who checks and helps in every technical paper to be published from students or faculty. so the job can be much more than just writing help files for programs.
I'm absolutely shocked by the number of developers posting on this story, all of whom seem to have a pretty clear idea what tech writers are for. Boggles the mind. I guess the people who think tech writers are glorified key-entry operators just ignored the discussion!
What ever happened to TeX and LaTeX? Everyone knows there is nothing more superior for technical and mathematical writing!
We are drowning in information, but we are starved for knowledge. (J. Naisbitt)
Writing software documentation is easier to get in to than hardware (microprocessor)documentation, but right now, the market is tight everywhere. SW documentation also pays a lot less (about 25% less). You can make a 6-figure income as a Sr. tech writer for chip companies without having to slave 60 hours a week (personal experience). When you reach a certain level, you are paid more for what you know and the various problems you can solve, and less for what you do, depending on the industry.
There are few entry-level positions in hardware tech writing. Hedge you bets by learning how to document application programming interfaces (APIs) because you can earn a bit more $$ than the tech writers who write user manuals.
As a tech writer, the languages that have helped me the most are Javascript and C...not because I have had to program very much using them, but to catch errors in C code included in documentation or to help improve a website from time to time. HTML is not programming but a skill you should have. Regarding XML, way too many tech writers focus on creating XML docs; instead, focus on the bigger picture--does your organization need to make the move to XML? If so, why? If not, why not? What are all the prerequisite initiatives needed before moving to XML (defining documents, standardizing content outlines, defining metadata, etc.)? Writing XML docs is only a small piece of the pie. The upfront work is the most important.
Here's a list from an anonymous author about what it is tech writers do:
1.We make subject matter experts appear more articulate in customer documentation.
2.We make integrated statements out of disjointed ideas found in specs and customer documents.
3.We find flaws in content or ambiguity in arguments and find the means to resolve them.
4.We fill in gaps in thinking to help customers use our products.
5.We transform the raw material of ideas into communication that transfers knowledge.
6.We transform disorganized information into a consistent interface.
7.We have an excellent facility with language skills and apply them to all projects.
8.We make effective use of communication fundamentals to develop better documentation.
9.We have an understanding of the human factors that affect communication.
10.We stay current with practices, tools, technology, and research in our field.
11.We know and use alternative methods for reaching customer audiences.
12.We make technical documentation organization invisible to the user.
13.We remove irrelevant detail from customer documentation so as not to confuse the
reader/user.
14.We are user advocates, consultants, and advisors, with the customer's success in
mind.
15.We make suggestions for improvement; we do not demand changes without reason.
16.We try to maintain the author's style; we do not alter that style without just cause.
17.We advise where rewriting is needed; we do not rewrite on a grand scale, unless asked.
18.We use project management techniques on all major projects.
19.We are experts in the publishing process, which means we can do it quicker and right the first time.
20.We are generalists who juggle many concurrent projects, but we can also be focused specialists as the need dictates.
21.We work hard to grasp technical concepts and view the product from the customer's perspective.
22. We are technologists in our field in a variety of applications, methodologies, and tools.
23. We have the skills, experience, and knowledge to add value to any software, hardware,
or Web-based project.
24. We are the SMEs when it comes to grammar, sentence structure and context, document readability and usability.
25. We are not "formatters", "desktop publishers", "spell checkers", or "comma inserters."
The others posters who said that you'll make more money doing API documentation were right on the money, so to speak. A good technical tech writer will make somewhere around $80/hour in the Bay Area right now. That's for writers who have at least a few years of professional development experience in addition to being good writers. Writers who aren't as technical typically make $50 to $60/hour for things like user-level documentation, and it's much harder to find that sort of job right now. To give you an idea of what the market's like, a couple of years ago a really good API writer could make $100/hour.
If you really want to do tech writing as a career and want to command respect and a high salary, I'd suggest getting a programming job for a couple of years first. On the other hand, if writing is just a backup in case you can't find a programming job, then that advice doesn't really apply.
Engineers/programmers can definitely tell the difference between good and bad tech writers. In the last couple of years I worked with a few writers who used to do development before they got tired of it, and they were very good. Most of the other writers I've worked with were ok but not great. Of course, I've mostly worked on APIs, so writers without a programming background were at a big disadvantage.
Finally, make sure you really do know how to write technical documents. Take a course or two. As someone else mentioned, it's different from writing an essay, story, or research paper. I'm a very good programmer and a reasonably good tech writer, but programming comes much more naturally to me. It takes me quite a while to get "in the zone" if I'm trying to write, and I usually have to re-do everything a couple of times.
I hope that helps some.