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