Waiting is the hardest part

I finished the project that's both annoying and reassuring yesterday. The deadline was Monday, but I just plain didn't have the data I needed and that was clear to my supervisors and the guy in charge of the project, so they were all pretty understanding about it. It helped overall that I was doing things by e-mail as much as possible, so it's not just my word that the source took longer than expected.

Now I'll be a bit worried for the next few days about whether someone's going to read me the riot act for how I did a bad job on it. (OK, "read me the riot act" is putting it too strongly. The worst repercussions I've had for doing a bad job around here are getting asked pointed questions that I have to fumble and stammer to answer. Either I'm better at covering my ass than I give myself credit for, or my work isn't as bad as I think, or my supervisors are really lenient and understanding. Or some combination. However, I do tend to worry about this kind of thing, even if it's not entirely rational.)

Why expect negative consequences if people are being understanding about the missed deadline? Because of all the other problems. The other guy took a while to get back to me, but I should have got in touch with him earlier than I did, and I don't have a good excuse for that. I reused a lot of estimates from the previous application. Ideally I shouldn't have, but I only worked with the information I was given. I pressed for more data, but I didn't press hard at all. And who knows what kind of mistakes I might have made that I haven't thought of. Half-assedness in general.

Still, though, I'm glad to have the project in the hands of the guy in charge. Now that I think of it, if I could make a career out of doing those things and get them down to a science, they might actually be preferable to my usual type of work. But as long as these are just a once-every-few-months thing, they'll probably always be an annoying, stressful, impossible-to-get-right hassle.

Positive thinking

I do a lot of complaining here. That's partly due to my personality, and it's partly because that's what the blog is for, and it's partly because this job is by its nature boring, so the interesting things are the problems. However, this job isn't all bad. As I have said, I do enjoy certain aspects of the work itself. Another nice thing about it is the people. I have my complaints (here, for example) but the worst interpersonal conduct I encounter here at all regularly is aimiable incompetence. Not malice or backstabbing or insanity or petty office politics like I hear about from friends or in customer service or like at my previous job (and even there, 90 percent of the problems weren't within the office), just people not thinking things through. People get along. Other tech writers share my cynicism. Our bosses understand the problems we deal with. Comparing one type of work environment to another is apples to oranges, and I know some of my co-workers, like H., have more difficulties in their niches than I do in mine, but still, I'd say that one of the best things about this place is the people.

Half-assed

Most of the work we tech writers do is on rulemakings. Not all of it, though. There are occasional miscellaneous projects, chief among them being applications to continue doing certain things. It's a "don't burden the public too much" thing; certain kinds of regulatory requirements have to be reviewed every few years to see how much time and/or money people are spending meeting those requirements.

I find working on these applications to be both annoying and reassuring at the same time, as odd as that might sound. How is that possible? Because, you may have noticed, I sometimes (often) tend to do some things (many things) in a half-assed way around here. I mean, I have my excuses, and working hard often just genuinely doesn't matter, but I have to admit that I'm not the most diligent person here. Well, part of the annoyance is that it's harder to get away with that on these applications. Only one person works on an application at a time and they're simple in theory - take the previous one and update the numbers - but require attention to detail. So I actually need to pay attention here.

Another part of the annoyance is that there's often just no right answer. I go to the people in charge of the data and they often give me results that are half the numbers used in the last renewal just a few years ago. Or twice the numbers, or four times. We'd expect some natural change, but that degree of difference is very unlikely. It's much more likely that either I'm doing something wrong now or the person who did it last time did something wrong then. And this is where the reassuring part of these projects comes up, because you know, sometimes it looks very likely that the mistake was by the person before me. Maybe they didn't keep track of their sources well, maybe they didn't count something they should have, maybe they did something they thought was more complete than the person before them but it wasn't. But whatever the case, as annoying as it makes the application I'm working on, it's perversely reassuring when I realize that the hardest part of it is probably because someone else screwed up.

Un-Substantive

There was a meeting last week about the doomed project. It didn't go well.

As I've said, we got back many times as much feedback on an informal review as we expected or wanted. Because of this, we now think the project will take longer than the last estimate. We (and by "we" I mean H., who did all the talking for the group in last week's meeting) asked our supervisors for more time. They did let us push back the deadlines somewhat, but not as much as we think we need.

During the meeting I kept on thinking "yes, but..." as H. talked. Nitpicking. Not substantive disagreements, but places where I would have said things differently, whether for diplomatic reasons or more strict honesty or some other reason. For example, she said that more than two-thirds of the 350 comments we got were substantive. Really? Well, OK, it's technically accurate. If we do something in five different places and a reviewer didn't like it and changed it in each of those places, that's arguably five different substantive comments. If two different reviewers asked slightly different questions about the same part, then that's two substantive comments, even if in the end we only make one change to that part. That's a bit misleading, though, because those situations are rarely hard to handle. We know what to do about things like that, it's just a matter of exactly how to do it. So there's "substantive" meaning "we need to do something about it individually", which really does describe more than two-thirds of the 350 comments (and for that matter probably nine-tenths of them), and then there's "substantive" meaning "we don't know what to do about it yet", which probably describes about a tenth of them.

The thing is, in my opinion it would be disastrous to give our bosses the one-tenth figure. Because the real problem, at least in my opinion, isn't the comments. It's the known unknowns. The changes that keep being asked for. Interpersonal conflicts on a 20-person team. The problems that looked minor at first but now seem bigger than everything else combined. It's ridiculous how things keep on getting thrown in or we have to backtrack on things that we thought were settled. Every deadline and milestone in the timeline so far has been the most optimistic projection reasonable (and, sometimes, plainly unreasonable from the start) and has been missed. Last week, we tried presenting more realistic timeline. Our bosses said no thanks, they prefer the most optimistic possible option. So instead of the additional nine months we asked for, we got something more like four months.

This is not the main reason I call the project doomed, but it certainly doesn't help.

"Version control" is a four-letter word

The title of this post was said to me in a phone call yesterday morning by a team member, as part of apologizing for making version control harder. (See previous post.)

Version control is a very frequent problem. Pretty much no document is written by just one person at a time; there's one specialist editing their part, the economist adding comments to every bit asking for details on costs and benefits, and me trying to correct people who think the a in "preamble" is capitalized. Documents are stored in a server everyone has access to. All tech writers and I know at least some RDMs would prefer people to work in server documents. It's just one document, it's simple, you can see what everyone else has done, there's no risk of changes being lost due to working in different versions or someone having problems with their own computer. The only problem is that when one person is in the document, no one else can be. If someone else tries to open it, it's locked for editing, and they can only do so in "read-only" mode. But it's very rare that multiple people would need to be in the document at the exactly same time, so it seems clear to us that working on the server document is much better.

Not everyone bothers, though. Some people try to work in server documents but give up at the first sign of it being locked for editing, while other people clearly don't even try. In either case, they save a copy of the document somewhere else and make their changes in that. Then it's my job to combine the original document and their version. Microsoft Word has a tool that does this relatively easily, but depending on the document (over a hundred pages, comments and tracked changes by over a dozen reviewers, including some that might be in both versions and some that might not...) it can still take a fair amount of work.

I don't like this partly because it makes more unnecessary work for me, of course, but it also multiplies the risk of mistakes and means that one reviewer can't see what the other has done. Unfortunately, we often can't just tell people to do things our way. My attitude towards version control on the doomed project has been fatalistic most of the time: the project is such a mess that it would be impossible to get everyone to do things the smart way, so trying would be a waste of effort; I'm just making sure I get the time I need for the extra work.

Yesterday, though, it occurred to me that this problem is just a technical one. Why can't two (or more) people work in the same document at the same time? Because that's just how Microsoft Word works. There's no reason it has to be that way. It would be technically difficult but we're just talking about a new kind of computer program, not faster-than-light travel or anything. Multiple people writing a text document together one paragraph at a time is basically what a chat program is, so someone just needs to figure our how to edit previous lines. (It helps that, for this kind of project, you rarely want to delete anything entirely until others have had a chance to review it. Hitting the "delete" key actually just results in text in a different color with strikethrough formatting.) Once you can do that, adding formatting for formal documents should be easy. Or even if that is too technically complicated, something else seems almost as good and much simpler: a server document that can be opened by multiple people and periodically automatically updated. People might not be able to see changes as they happen, but if the document gets updated every two minutes, or even every five, it would still work pretty well as long as the people aren't trying to work on exactly the same part of it.

There would probably be a lot of money in such a program. (Unless it already exists and I don't know about it, I guess.) I doubt my organization would use it even if it existed - too hidebound, too much training and upgrades required, a little behind the times in IT - but I'm sure there would be a market for it at places that are just a tiny bit more tech-savvy than here.

Catharsis

I discovered the Bastard Operator From Hell a few months ago. It's fun stuff. It's like Dilbert, but British (well, apparently by a New Zealander, but he and/or the character moved to London, but either way "color" is spelled with a u and "magnetize" with an s and there seems to be more swearing than in most American media), and in the form of short stories rather than comic strips, and the main character has Dilbert's approximate job but a personality more like Catbert.

It's cathartic; the whole point is that this is what system administrators feel like doing to the gullible, irritable idiots that take up so much of their time, but they can't, because it would get them fired, so they imagine deleting the files of people who talk back and tricking morons into electrocuting themselves like the BOFH does.

My job isn't that bad, but sometimes there are moments.

Also, part of the problem with that attitude - this is a problem because this fact means the revenge fantasy doesn't quite happen, but also why it festers into resentment rather than becoming something you can address head-on - is that problems at work are rarely caused by people who are extremely egregiously stupid or malicious. Sure, no doubt in some jobs you really do encounter people who don't realize you can't wash a computer with soap and water or who will blatantly try to screw you over, but in my job, most of the infuriating mistakes come with full, self-deprecating apologies... which is very cold comfort because the same thing is going to happen every two days, but I can hardly be so ungracious to the person trying to apologize to me, now could I?

Obligatory meetings

Every two or three months there are meetings at my office for the entire department, about a hundred people. These meetings are pointless, and were exercises in misery until the organizers got more strict about time limits.

Incompetence at public speaking doesn't help, of course. Each of thse meetings has about half a dozen speakers, and about half of them or fewer are competent at it. Oddly enough, one-time speakers generally do better than the regulars, maybe because if you speak in public annually or less you'll prepare for it, whereas if you do it more regularly you won't bother to, even if you really should.

Besides that, though, the meetings themselves are pointless. It's not like an hour or two every few months is a huge ordeal, but given that we're going to have them, why have so much pointless stuff in them? Meetings start with announcements of arrivals, departures and commendations for either going above and beyond on specific projects, or general milestones of years of working for this agency. It's nice to know that kind of thing, but the solemnity of such ceremonies is spoiled somewhat when people don't bother to show up for them. Really, call me rude and insensitive, I know lots of people care about things I don't care about and vice versa, but at June's meeting nine people were recognized for something or other and at least three of them (my notes are vague) didn't respond when their name was read because they weren't there. So how much am I supposed to care about that stuff if the people in question don't show up and the presenters don't know about it until they call the name and see no response?

And then there are presentations on what certain groups are doing. For every meeting, two speakers from certain project teams, sub-departments, low-level offices or whatever are selected to give five-minute presentations about what their group is doing, with PowerPoint slides. They stand up, click through slides, and talk in layman's terms about what they're doing and why. I'm pretty sure management asks for these presentations just out of a general belief that it fosters a sense of community or something. Again, this seems like it might be interesting, but isn't worth the time of everyone in the room.

Finally, we get to announcements that actually matter, like changes of policy in higher levels of government. For example, a January executive order increased scrutiny of regulatory burdens on the public, and at the June meeting an economist stood up and talked a bit about what that has meant for our agency and what it probably will mean, now that we have a few months of experience with it. No announcement is of interest to everyone, and anyone who does need to know about this kind of thing needs to know in more detail than can be covered in a large meeting and probably has already heard before the quarterly meeting anyway, but still, this is useful stuff I'm glad to hear about.

I probably couldn't get away with walking into an hour-long meeting 45 minutes late, though.