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."

Comments

API Techcnial Writer

[szucker]

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.

Not enough of them

[Anonymous Coward]

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.

As a programer

[bluGill]

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.

Re:As a programer

[Glonoinha]

Dude there is a reason you are not doing documentation, and 'because you are a programmer' isn't it.

That said, I blew my chance of moderating this so I could reply.

Re:As a programer

[xanthan]

You're right about the varying levels of documentation. However, I disagree with your assertion that a good programmer cannot be a good writer. The best programmers I have ever worked with were all good writers.

Bottom line: if you can clearly articulate what it is you're saying, you can clearly articulate what it is you want your program to do, which in turn means you'll be able to write a clear and easy to follow program. Writing well has a lot more to do with thought process than it has to do with grammar. Think about it in terms of software engineering and programming -- you can teach a monkey to write code (and many monkeys do).

That said, it *is* difficult to write a lot while coding a lot. This has a lot more to do with focus on your job than it does your skillset.

OP: My opinion

[Glonoinha]

(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.

From a MS/CS and a published writer...

[xanthan]

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...

Technical Writing....

[axoi]

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.

Does it Matter?

[orbbro]

I just finished getting an AS degree in CS, and I added on a certificate in professional writing, figuring, like you do, that I could leverage my background as a writer and offer diverse skills to a potential employer.

What I learned from writers in the industry who came to talk to our classes:

1. "Technical Writing" is now more appropriately called "Technical Communication" and includes, beyond the stereotypical software manual: business & marketing communication ("marcomm"), information design, corporate training & curriculum development, online communications, single-sourcing (think XML!), and even, by some definitions, web design. See the Society for Technical Communication for more info.
2. If you want to succeed in the world of private industry with a "soft subject" degree such as tech/professional writing, you should take a handful of writing classes to brush up on your skills, but skip the MS degree and get an MBA. Most job titles like "technical writer" are being phased out for titles like "project manager" or "business analyst." In short, your writing skills are going to be put to use secondary to your people management and other "soft" skills.
3. Tech writing in the tech fields -- engineering & CS -- is being outsourced and shipped overseas just like the tech jobs. You might be better off learning Chinese, Hindi, or Russian if you want to do serious tech writing for IT in the next decade. That's where all the "how to use your cell phone/PDA/laptop books are being written. Red Flag Linux HOWTOs, anyone?
4. The job market for tech writers is almost worse than that for high tech, because tech writing for IT is dependant on the success of IT companies. When you're an IT company that's on the ropes, the first thing you forego in getting the next product to market is high-quality documentation (if you were planning to use it in the first place). Half of the ~600 self-identified tech writers in the Portland, OR area are currently un- or under-employed in this market. Yes kids, that's 50%.
5. Salary: While the bestest writers can command near 6-figure salaries or more, they're working 60-80 hours per week, just like the IT people with those salaries. Writing has a lot in common with coding, in a way -- lots of prelim. design and planning, lots of computer time, and lots of "debugging" (except it's called revision). And there are few if any shortcuts to making a good end product.
6. Tools: because you asked. RoboHelp, Adobe FrameMaker, and, sad as it is, MS Word, are the main tools for the job. Knowing XML, HTML, Dreamweaver, Flash, and the like can also be helpful, depending -- this field is as specialized as the computer world. The technologies you know define your job. For more ideas, check out the trainings offered at a local tech. comm. consulting firm.

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.

Re:Don't bother.

[shaitand]

Notice to managers, we are sorry but we have to let you go, you have outsourced YOURSELF to india.

College isn't boot camp

[duffbeer703]

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.

Wow!

[schnits0r]

I am getting ready to graduate soon with my CS degree

You can get a degree in Counter Strike? What university is this?!?

As a writer

[fm6]

Some programers are good writers, but when they are writing about their program they do a terribal job.

I don't think that programmers simply lose their writing skill when they try to document their own software. The problem is that "good writing" and "good technical writing" are two completely different things.

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.

Drudgery is FUN!!!

[fm6]

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.

For some strange reason, I actually enjoy that stuff. No, I take that back -- it isn't strange. It's the satisfaction of recrafting an explanation until it can't possibly be misunderstood. Which is probably similar to the pleasure a programmer gets from crafting code that couldn't possibly work any better.