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."
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 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.
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.
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
Are you a published writer IN ENGLISH? Is your book written in crayon? In just three sentences (or are there two? Or four?) I count two typos, three punctuation errors, two spelling errors, bizarre use of "Pls," four mis-capitalized words, and "its" used where "it's" is wanted.
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.