TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> Before this thread goes do far off the rails to be considered TechWr-L
> CHAT, I do have a question that I'd like to discuss:
>
> Are Technical Writers valid anymore?
Only if they are well formed.
> Before you get out your
> flamethrowers,
> hear me out:
>
> How many of you still research and write all your own document content?
I do. I get very little content spoon-fed to me. And that which is needs to be massaged A LOT to turn it into meaningful English. Projects that spoon-feed their tech writers are probably not very satisfied with the pubs department. If you don't research and write your own content, you should start looking...
> How much of your work involves rewriting material supplied to you by
> developers (hardware and/or software)?
Very, very little. Other writers I know and respect might get specs, but turning specs into docs is not a cut-and-paste exercise. Generally speaking, the writers who think it is are not writers I respect. Producing doc is a matter of deciding what information is important, and presenting it well. Specs have nothing to do with that.
> How much of your work involves setting up your own user simulations and
> documenting the best case scenarios on behalf of your users?
I'm lucky to see real user scenarios. I have to set my own up and drive the software. Likewise, I drive the API in order to document it.
> I ask this because I have never been a core technical writer. I'm a
> programmer who knows how to write English. Sadly, where I would really
> enjoy building and implementing documentation systems that make it easier
> for developers to supply core content and writers to fix the content so
> that it's useable, there isn't much of that type of work around, except as
> a short term external contractor.
I created our own custom documentation delivery system, which requests raw XML from the server and transforms it to HTML on the fly in the client. (The only other doc system I know of that does this is Saxonica documentation.) This gives us dynamic docs that can respond to user profiles, system state, and external inputs. Part of my job is maintaining that. I also implemented a tooltip extension that gives us formatted HTML in tooltips (in Flex), and I implemented embedded docs in GUI elements such as screens and dialog boxes. If you want to get into a blend of doc and programming for the long term, maybe you should look for embedded doc opportunities. Maybe a startup would be good, but you really need to know your pubs chops for that... They will say "We need documentation for this product" and leave you to whomp it up. Not easy if you don't have much pubs experience. OTOH, large companies often have pub tools departments... Learn
XML publishing if you haven't already.
I don't know that this group has slowed down because of changes in the pubs kingdom, but I do think tech pubs is changing significantly... In one sense you might say it's due for a correction. Creating pages is NOT what the job is about any more -- that aspect of tech pubs is becoming a mere commodity. Any product in the developed world, and software/hardware especially, is primarily an exercise in information management. Contributors are information professionals. Tech pubs sits on one end of a vast information spectrum. It's up to tech pubs professionals to extend their reach into other "wave lengths" of this spectrum and add real value there.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help: new website, content widgets, and an output that works on any screen.
