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.
John Posada reports: <<Last week, application management did a server
refresh. This entailed deleting the dev environment and bringing
everything from the production environment down to the dev environment.
The good news is that the dev and prod environment are back in sync.
The bad news is that since I was in my own personal sandbox, so to
speak, all of my files went pfffttt. Gone. No more. Poof. and since it
was a development environment, it wasn't backed up besides the codes
being on VSS.>>
The guys who decided not to include your files in the backup should be
taken out and publically flogged--particularly if they didn't warn you
that your files weren't part of the backups. The purpose of backups is
to prevent anyone from ever having to redo weeks of work, and these
people are paid big bucks to ensure that they do this job well. (Yes, I
got burned this way a long time ago: the idiot responsible for backups
screwed up an intranet I'd been contributed to, tried to restore it,
apparently couldn't find current backups, and restored everything from
ancient backups.)
Possibly I misunderstood, but if you knew that your work wasn't being
backed up and you were the one who decided that backups were optional,
I recommend at least a good spanking <g>: Sorry to sound so critical,
but this kind of thing can be career suicide if you're working to a
tight deadline and fail to meet that deadline. Clients and employers
quite rightly don't want to hear excuses for why there's no
documentation for a project--they want your hide, whether or not you
still have a use for it.
<<At first, I was really pissed, and that lasted a few hours. Then I
started to recreate what I had, and here's the important part, USING MY
OWN DOCUMENTATION TO DO THIS. Well...let me tell you...I thought my
documentation was pretty much spot-on accurate...until now. It is
amazing what I learned through doing this. Things like poor
organizational issues, missing procedures, erroneous processes, all
kinds of things.>>
Which only goes to show that in a development environment, someone has
to take responsibility for a final reality check on the docs to confirm
that they still match the evolving reality. Moreover, they always need
revision after some time has passed because time provides the necessary
distance from your work to let you examine it objectively and with a
fresh perspective. As you noted, you learn about the product as you
write, and I've often found that what seemed like a great idea early on
suddenly seems less effective in light of this improved knowledge.
<<I do, however, now believe that everything you've ever written needs
to be reviewed periodically, and not just immediately after it's been
written. Give it a few months and then approach it with a fresh mind.>>
Every editor is amply familiar with this syndrome; most of us try to do
our second pass at least a day after the first pass, and ideally longer
if the schedule permits. Ditto for anyone who writes fiction.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
