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