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.
Evidence is accumulating at my employment that someone might have
recognized what a time-and-money sink an ISO 9xxx certification can be,
with little actual reward. And so there's been nothing for a while; no
announcements, no meetings, no statements or updates of ISO 9xxx plans.
Thus the effort to document my job, enough to satisfy an ISO auditor,
has gone on hiatus, before it got past the planning stage.
Other than the ever-popular "in case you get hit by a bus", I'm
hard-pressed
to justify creating a central, organized documentation of:
- what it is I do all day
- how I do it.
And it has changed a lot.
Being the age that I am, I had a moment of actual thrill as I contemplated
what
my work environment now looks like.
Never mind the cube with a laptop, two tower PCs, my own hub/gateway, and
an assortment of the company's products, several of them hitched to that
hub.
No, I was thinking of the virtual environment.
I have a Virtual Machine (VM) on the build-engineer's server, where I've
moved my source documentation files, and where I run my authoring software.
Thanks to someone else on the list for describing that setup. I've embraced
it.
Now I don't have to remember to make manual backups of work that
resides on my laptop, nor do I have to leave my laptop on and connected
in order for automated backups to run.
The builds server is always on, always in one place, both physically and
within our network landscape. My VM is always loaded, and gets cloned or
snap-shotted (is that a word?) whenever I make a noteworthy change,
like OS or authoring-tool updates. Timed events (cron jobs) run when
they are supposed to, with no dependency on me, or the state of my laptop
(on, off, hung, booting, suffering through virus-scan), or the state of my
laptop's network connection.
On one of the towers in my cubicle, I have a selection of VM clones
ready to run any of the PC-loadable client operating systems that we
support.
On my laptop, I have Remote Desktop and VNC sessions to my working
VM on the build server, to two or three different test environments for
the products I'm documenting. Along with that I have an assortment of
SSH terminals connecting to those and other devices.
As long as I have the laptop, I can connect via VPN and run any of
those things remotely. I no longer bother to launch Word or FrameMaker
or the HAT locally on the laptop. As somebody mentioned, the bandwidth
needed for updating a remote desktop screen is often much less than the
interaction needed to run local applications (on the laptop) that use
remotely-stored data. Instead, the applications live and work where
their data lives, and I simply fiddle with a picture of those remote
operations. I could work from a train, or from my car, hurtling down
the highway - with my wife driving, of course.
Sometimes, I'm running several different products in HA group(s),
while remotely connected to the virtual client instances.
In one way, it's dizzying to contemplate.
At the same time, I want to briskly, gleefully rub my palms together while
uttering my best Dr. Evil laugh. World Domination (tm) at my fingertips!
OK, it's a small world under my sway, but *so* much larger than
anything that I contemplated ten years ago. Twenty years ago,
when I was already well into my TW career, the current setup
would have been entirely unthinkable. As would the superphone
in my pocket that could tether the laptop while my wife drove us
to the cottage.
Of course, all those boxes and sessions and VMs, etc., have IP addresses,
login names (sometimes several per device/VM), and passwords.
Many of them have special configurations and profile requirements.
I have text files with memory-joggers and summaries in various places
that make sense to me. The arrangement works well and efficiently
for me, day-to-day.
In some cases, I can just reuse usernames and passwords on several
machines or VMs, but in other cases, I receive an updated VM clone
from developers or testers, and they have their own naming and
authentication conventions.
Does the above describe a fairly common techwriter work environment, today?
Is there a good reason, from the writer perspective, to pull all the
documentation
for such an environment together in one place, one document? Without the
carrot/stick of ISO preparation looming?
I figure if I get killed or long-term hospitalized, I'm past caring what my
replacement does. If I get laid off, well, you can fill in the blanks
regarding
how helpful I want to be to my lower-paid replacement, or to a company
that tossed me to the curb. They'll figure it out, or reinvent it.
If I get promoted/transferred, I'll have time to coach my replacement.
Let's hear other perspectives.
</kevin>
--
__o
_`\<,_
(*)/ (*)
Don't go away. We'll be right back.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
