It has not been a fun weekend. Friday morning I was rudely shoved out of denial1 that I was sick. The sinus headache that woke me up before the alarm went off was so excruciating, I had to put an ice pack on my head2. I had a deadline, a document that needed to be in a draft suitable to email to a person responsible for training some customers by the end of the day. So I couldn’t take a sick day, I needed to work from home.
Many of my work projects can be handed off to colleagues in my department, but this one isn’t one of those. I started out in technical writing without formal training in the field. Oh, yes, I’d had lots of writing, communication, and journalism classes, as I kept changing majors. And I’d been actively writing (and studying writing) since I’d made the decision when I was six to be a writer34, but I was hired as employee number 6 in a small startup. Tech writing was only one of my duties, and I approached it by asking the question: if I had to use this, what would I want to know? Then I played with the software and the hardware until I knew everything5, and wrote it up.
When we started hiring people with prior experience in tech writing (as the company grew), I learned that many tech writers were very uncomfortable writing about hardware, for instance. And if they had their druthers, avoid understanding programming logic altogether. To be fair, in well designed consumer products, users should not have to understand programming to use the product. But many of the products I’ve supported over the years have been enterprise, server-side applications and the platforms and hardware they run on. My users are usually administrators and installers, not end-users.
The upshot of all this is, within every tech writing group/department6 I’ve been in, I’ve been the hardware guy. The person assigned to write installation guides and the other super-techie docs no one else wants to do. This product is one of those.
And we’re still in the process of changing our production tool. I and the other Principal Tech Writer are still configuring the new repository, stylesheets, and support tools while we’re working. And this particular deliverable type is not fully defined and developed. So I’m also having to work on that end at the same time. All with an insanely short delivery time.
In addition to being the hardware/operating system/programming guy, I’m also the fix things guy. If I had a dime for every time a co-worker has said, “If you can’t figure it out, I don’t know who could” when we’re talking about software misbehaving, I could retire to the Bahamas.
That’s really just another manifestation of my study-it-until-I-understand-the-inner-workings trait. While in an ideal world, a user shouldn’t need to understand programming logic to use a consumer software product, in the real world, understanding that logic can help. Particularly if you can also grok the fundamental paradigm of the product7, you can figure out how to make it do things the designers didn’t plan on, and you can diagnose problems they never anticipated.
Related to that, I’m always the one who figures out how to use new systems, implement them, stretch them to meet our needs, and so forth.
I like doing all of these things. I like explaining. I try to teach my co-workers how to do all the things I do. Tasks that they have to do frequently they learn. But there is always a lot of stuff that folks only vaguely remember I showed them. And the whole “think like a programmer” or “think like a troubleshooter” thing seems to be something you either have a knack for, or don’t.
Which means I’m always going to be “the only one who knows how to do that” guy.
And that’s not fun when you get so sick you have to cancel the monthly writers’ meeting and the game I run, but you still have to squeeze in work from home time to make the deadline.
1. These symptoms are just hay fever because we’ve had really high pollen counts
2. And took cold tablets and went back to sleep for a bit…
3. I asked Mom where books come from, and she found a great explanation of the publishing industry in some sort of kids’ encyclopedia during our next visit to the library, and I was hooked!
4. And I made my first fiction sale at the age of 16, so I was a pro long before I got into tech writing.
5. Relatively speaking. It also helped that my other duties included testing the software and hardware.
6. Although I worked at one company for over 20 years, over the course of that time I had 6 different supervisors, as the company grew, shifted direction, grew some more, shifted direction, was split in two, et cetera.
7. For instance, the paradigm of the now nearly-gone word processor, WordPerfect, was the typewriter and how a typist used it. Text and commands for formatting are processed linearly, much like a mechanical typewriter. The paradigm of MS Word, on the other hand is a mutated cascading stylesheet8.
8. Yes, I know Word has been around longer than CSS. Of course I do. I’ve been using Word (and supporting other people using Word) since before Microsoft released Windows. But that’s the paradigm9.
9. Mutated. Because while it gives the illusion of having taxonomic behavior, it also works as a reverse taxonomy, and occasionally as a non-Euclidean hierarchy. But that’s a story for another day.