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.
I mentioned I have similar text files strategically scattered.
On a server that runs one-or-more VMs, or that has a cache of VM clones,
I'll have a text file with the VM passwords. Inside each VM is a text file
with login/user names and passwords for what runs inside the VM or for what
that VM is intended to connect to.
Some parts of the whole orrery are now stable, and are also backed up to IT
servers nightly, my documentation source and tools VM, for example.
Others are fluid, and might last only for days or weeks as my current
projects progress and demands change.
I'm a lone writer at this office. Other writers at other company locations
support unrelated product lines, and are in different reporting structures.
If somebody who replaces me after a lay-off has something to say about how
I organized my work and my working environments, let them jabber, the
scabs... :-)
If somebody who currently works here wants to know about my stuff, I'll
overshare at the drop of a hint. I'm still only partway up the learning
curve with this VM stuff, but it's become really impressively versatile in
recent years.
On Wed, Jul 11, 2012 at 4:35 PM, Julie Stickler <jstickler -at- gmail -dot- com> wrote:
> I self-document things for a number of reasons.
>
> Mostly for myself. I will work on projects, get away from them for a
> while, and then when I come back I can't remember why I did things.
> And it saves my own time if I don't have to reverse engineer things.
> Or maybe there's some problem I need to solve and I can't remember
> what solutions I've already tried? So then I can avoid trying things
> and then remembering that solution X, Y, and Z didn't work the last
> time either...
>
> I once inherited a VM library from a product manager who left the
> company. I knew the most of the logins (VM, Windows, product, etc.)
> but at some point I needed to do something in Oracle, and had no idea
> what the Oracle admin ID or password were. I e-mailed the product
> manager who created the VMs and he didn't have any idea either. Ever
> since then, there's a text file in each of my VMs with all the
> passwords. Because I don't really care if someone can get into my
> test machine, but I sure as heck care if I lock myself out!
>
> I document things for other writers. To let them know where things
> are, why design decisions were made, how the pieces of a complex
> project fit together. I've written plenty of training for other
> writers in my same group, so that we can all follow the same
> processes. It makes it easier to pick up a project if the files have
> the same naming conventions, directory structures match, etc.
>
> And then there's the fact that where I live, the world of technical
> writers is a small community. So even if I'm laid off somewhere, you
> never know who eventually replaced you. And what they might say about
> the state that you left your files in. I got internally transferred
> once, and the writer who took over for me told me how nice it was to
> work on my projects, because everything was not only clean and well
> organized, but I'd left enough breadcrumbs for her to pick up where I
> left off.
>
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
