There are many odd and often frustrating aspects inherent to the sort of technical writing that I do. One of the more difficult to explain is that there is no connection between how much I'm working and how much it appears I am producing. Often there is a negative correlation.
There were many terrible aspects to my first job (balanced by an amazing degree of sociability and fun with some wonderful colleagues, and a lifetime sense of joy that whenever things seem really awful at work I just have to remember my time at Wang and suddenly I'm deliriously happy at how much better things are). I worked for Wang in the early eighties, when they were growing too big for their administrative britches and attracting a lot of Ambitious People. I left a year before they began to implode, but the signs and portents were internally obvious even then. As my department grew (doubling and redoubling in size), it attracted administrative overlords who tried to define writer productivity with metrics. That was my first experience with the word "metrics" and it explains why I run away screaming when the word is used in my presence. So, for example, if a 300 page manual came up for revision and somebody updated a few references in the Introduction on the specific instructions of a developer, they would be measured as having produced 300 pages (in two days) for this essentially trivial task. If I wrote a complete manual from scratch with no developer draft or input other than some invalid specs and a beta version of the actual application I was documenting, I would also be measured as having produced 300 pages (in two years).
I never developed much respect for management by metrics. And, to be honest, even at Wang they didn't really use these metrics to evaluate your performance. Nonetheless, you start to feel as if you need to be noting Milestones all the time so that your management can report to their management. I get why, but it's exasperating.
At Wang I spent nearly four years as the sole writer for what was essentially a database manager, working closely with a small group of developers. I was very proud of my work on that project, at least as proud as of any work I've done since, but it got no particular notice in my department. Shortly before I left I picked up a small project that the marketing department had requested: A booklet summarizing all the available documentation we produced in a particular area. I actually enjoyed this filler project, and it involved more conceptual work than you might think at first, and I even got to work with a designer. So we produced this pretty little booklet, in two weeks, and everybody just loved it and I got all sorts of kudos and attention and praise. And it was, quite literally, about one one-hundredth of the amount of work I'd put into the database document which was mostly ignored by everybody but the actual customers. But the booklet was cute and available and visible internally throughout the company. There's a lesson somewhere here about how to get ahead in a big corporation.
My point is: The real work of my job, the stuff that means the most to a user in the field, is slow and tedious and time-consuming and conceptual and ultimately, in the very very long run, results in lovely feedback. But there are long, long periods when you see nothing you can report in a metrics or productivity chart. Even the feedback from the field is not easy to measure (but you can believe that I keep a file of every complimentary thing said about my documentation and send that along to my boss -- that's something I learned to do years ago).
One thing I took away from that first job (I learned so much about corporate survival by swimming in that muck) is that it's a good thing to have a whole bunch of small easy maintenance projects that take very little real conceptual work, because you can point to them as evidence of how very very many projects you are doing. It's a game. But it frees you to do the real work, which is what your customers need, and it's a rare environment where you are allowed that time.
At SGI, by the end, I found myself in a position where I was responsible for maintaining a huge existing document set (nearly all the IRIX documents), for an operating system for which there was not a lot of new development. So every release there would be a few things, scattered throughout the documents, and I would get to report on having updated, oh, four or five documents when I'd done hardly any work. Ok, I did have the years of experience and knowledge of the document set by that time, but my point is I had METRICS, unrelated to the actual amount of work I was doing. Most of my real work was on a couple of smaller, more difficult projects, that were harder to account for in terms of getting things out the door.
At Red Hat there are many small, almost administrative things my department does: editing release notes, addressing small bugs and updates, general maintenance of old documentation. I mention now and then that I feel guilty that I'm not helping out with these things. But no, they say, they hired me to catch up on some big documentation issues, to write some books from scratch. And so I wind up feeling unproductive. It's neurotic, isn't it? But nobody seems to be complaining.
I was thinking about this issue because today I got a document out for first review. There was one small new section that I had a heck of a time figuring out. I was reading internal documentation in the Linux code, I was reading small things people have posted on various web sites, I was poring over a bug report -- all to determine out how you might use the bind option of mount to replicate the functionality of context-dependent path names. (Oh, do you not know what a bind mount or a CDPN is? Well neither did I!) Remember, I'm not actually a system administrator and have no sysadmin experience at even the most basic level of mounting file systems -- much less mounting file systems by binding them to previously mounted file systems so that the same code will mean different things on different system architectures. So I spend a couple of days on this alone, on simple research for one small thing, and what do I have to show for it? What can I report in a status report? How does my manager justify me? But at the end of it all, I wrote something that a developer approved without a single technical correction -- which, in fact, saved the company a lot of this guy's time and salary when he is under serious deadline pressure on something else. Is there a metric for that?
That was just one section of the document I got out for review today. It's been a long time since I've sent out a review draft. But now there's something that the project leaders can see, that will reassure them. And I can feel that it was a productive day, even if it wasn't nearly so much work as so many many other days which contain no milestones.
Are all jobs like this?