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 can think of several reasons why you would want to document your job:
1. Your environment is far from standard. Hence, someone, somewhere, needs to be aware of this in the event that something happens to you.
2. If you get promoted, you THINK you will have time to train someone, but trust me, you won't. In addition, a new person's head will spin with the little bit you shared. So if you really want to help a subordinate or assistant, this should all be in writing as a handy reference guide.
3. As long as you are employed by this company, you are a valuable asset to your company. Minimal respect towards your employer merits you document these processes. They can be used to a) leverage your position; b) help a new supervisor/boss understand your role; c) educate engineers about the documentation process; d) have a potential replacement think twice before stepping into your shoes (what if you aren't fired, but quit or retire?).
4. Finally, in the event that you are "released" from your work, unless they physically lock you out of the office and you cannot pass on critical information, you may want to have that information there anyway. While you may not feel like you owe the company anything, it has many individuals who could become future colleagues/partners. Someone who worked with you and saw you leaving gracefully would heavily weigh this info if considering to hire you for their own company/startup/project. Information is passed on, and leaving well under bad circumstances ALWAYS gives you an excellent reference from someone. The converse, I believe, is also true.
I hope this is helpful to the discussion
Debbie
דבורה
_____________________
Deborah Hemstreet
Editorial Assitant, Rambam Maimonides Medical Journal
and English Editor/Writer
Rambam Health Care Campus
Ext. 1285
Tel. 04 854-1285
Mobile: 050.206.1273
Fax: 04 854-2657
-----Original Message-----
From: techwr-l-bounces+d_hemstreet=rambam -dot- health -dot- gov -dot- il -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+d_hemstreet=rambam -dot- health -dot- gov -dot- il -at- lists -dot- techwr-l -dot- com] On Behalf Of Editor in Chief
Sent: Wednesday, 11 July, 2012 22:32 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com >> TECHWR-L
Subject: document your job?
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.
Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com
Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives
************************************************************************************
This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
