I have always liked to write and I am a very organized person. All of these traits are great for tech writing. I started as an entry-level tech writer and worked my way up through the various levels until the last four years I managed a couple of documentation departments. Two years ago I became incorporated. I now have a consulting firm that does Technical writing for other companies.
We document computer software applications for companies who either create the software applications in house or purchase them and wanted additional documentation. They may want additional documentation for training purposes, or they may have felt that the existing documentation was inadequate.
We provide documentation in the form of user manuals, on-line help, reference guides, quick start guides, etc. We also document business processes to help companies identify their process flow. This also helps provide internal training documentation for their employees. The software applications that we document can be run on a mainframe, PC, or midrange computer and written using a variety of word processing, desktop publishing, or help authoring tools.
For example, I use Microsoft Word 97 for most documentation tasks. If the company wants a full manual design, with several colors, pictures, etc. I would use PageMaker or FrameMaker.
For on-line help authoring there are a lot of choices, but I prefer RoboHelp for strictly on-line help. If I were asked to create on-line help, a user manual, and possible text for the company's website, I would use SolutionSoft's HelpBreeze because it lets me create one file that can be used to do all the different documentation tasks.
I've been asked many times about the stresses and rewards of a Technical Writer.
The biggest headaches (i.e, anxieties and stresses) are project schedules! Documentation seems to usually be an afterthought for most companies. As a technical writer, we're always playing "catch-up" with the programmers. They're schedules run over, but the deadline never changes. So, as a writer, we're given less time than ever to create the documentation. In the "perfect world", the first draft of a user manuals should be finished at the same time as when the software is sent to Quality Assurance for testing. That rarely ever happens. There have been times I've actually documented an entire system, from a design document and notes from a programmer. I NEVER saw the product working. The programmer then used my documentation to write the system.
Go To Page: 1 2
| Here's the follow-up discussion on this article: | View all related messages |
For a complete listing of article comments, questions, and other discussions related to John L. Hoh, Jr.'s Technical Writing topic, please visit the Discussions page.