Scott, just to clarify, technical writers are not needed to interpret documentation for internal use. The documents they write are for shipping with the product. Hence, these documents are supposed to make the end users (advanced, intermediate, basic) comfortable with the product that is bought. Be it a developer, manager, or Jesus, he still is essaying the role of a product/technical documentation specialist by interpreting the product to the user. There is no such thing as a Technical Writer, it is only a role one essays.
how true 
Same here…
sample softwaretechnical documentation
I completely agree, exept I would probably be getting just as mad as the engineer.
Technical writing is a real job, and one that demands research skills. You do what is necessary. If you don’t know the product, you play with it until you do know. If you can ask someone, do, but as another writer here pointed out, you should have some information in advance or you’ll just overwhelm them. The best technical writers are the ones who are very organized and methodical in their research, and then translate that naturally into language.
Well, talking about my experience as a technical writer, i found that you can really write a help document just by exploring the program yourself if the program not that difficult. But, if the project’s level is high to be easily understood, i think it will be better either to start reading document analysis or any docukent related to the software, or you might sit with the developers and start to understand from them every single details in order to know how you will address the audiences.
Life’s a lot easier if I don’t have to deal with the engineer. I usually get all the available documentation–requirements, design, UAT, etc.–and then check the current application build and figure out how it actually works.
I’m a technical writer for very complex server/client networked products and there’s often no way I can sit down and see the whole system work because 1) they never give me a whole system to play with, and 2) it’s too complex to start out with nothing to read first. The engineers are no better off; each writes his or her own piece and sometimes has no clue how the other plug-ins or components use the data down the line. But that’s not as bad as the fact that often, when I ask, “So when would I customer use this feature, and what for?”, I get “I don’t know. I was told to build a [blahblah] service to handle [IETF spec] protocol…”
I envy tech writers who do refrigerator user guides…
Scott S. McCoy wrote, “Most work I have seen done by those in the technical writing trade has been generally inadequate and unnecessarily verbose.”
Scott, I’m a technical writer in the software industry. Unfortunately, I have to agree to some extent with you. Unlike other professions, technical writing is not regulated, and enforcement of standards is not possible. Some ‘technical writers’ leave much to be desired. On the other hand, look around, and you will find some excellent tech writers.
I disagree with Sandeep, who wrote, “Tech writers looking for developers/engineers for help are kidding none but themselves…” These people love talking about their work, in my experience. Usually, they are extremely busy people, and if managers do no allocate time for them to interact with the tech writers, the time they do spend will be in addition to their other duties.
Wes James highlighted a common problem with documenting complex software. Everyone knows his or her bit in detail, but not the whole picture. Often, I find that different people give me conflicting information. That’s where technical writers add significant value to a company–we ensure that the ‘story’ that the end users receive is complete and consistent.
That make sense. Developer like me would be proud to see that documentation.
Documentation is used here to mean hard copy, online documents, online help, quick start guides, and other written instructional information. The need for documentation is often an afterthought when designing products. Product development engineers are so enmeshed in creating the product that they feel its use is intuitive or self-evident. This assumption is usually not the case. In many respects, documentation compensates for the lack of intuition. It permits understanding the product and provides a quick source for looking up specific details that are not immediately obvious to the user.
Let’s face it - no one reads technical writing unless they have to!
A good tech writer starts by being a busybody and an eavesdropper. I consider it a good day if at the end of the day, during the information gathering phase of the project, my feet hurt, and my conputer is cold. Take an engineer (or two) to lunch. Find the most egotistical one of the bunch, get his/her thoughts on the projects overall, the players, and management, and drill down from there. I’ve seen too many tech writers sit on their rumps waiting for information to be tossed to them, or whining because they “have to” play with the software themselves.
Technical writers are, in a sense, teachers. You’re teaching not only yourself but your readers about the product.
Technical Writing is not rocket science nor will it ever become rocket science. It requires a great amount of patience, endurance, perseverance, and initiative on the part of the writer, but ultimately it can be done. Like I always say “mind over matter”. Welcome to the real world, and indeed Tech Writing is part of the real world!