So as many of you know, I suck at updating lately. But the (partial) reason for that will soon be explained. Also as many of you know, I am a technical writer by trade, meaning my job is to spend long, laborious hours writing documentation that no one will ever read because documentation is boring. Truly.

All this information? BORING.

Sometime in the middle of last year, I decided I wanted to extend beyond my little literary fiefdom and learn something new, another skill set that I could use to make my job at <Fortune 500 Company> even more enjoyable – and profitable, if possible. As part of my job as a tech writer, I often had to document things in the user interface (UI) that made absodamnlutely no sense whatsoever. And whenever I questioned someone about why it looked like that or behaved that way, they most said “Eh, that’s the way it was designed/coded/why are you asking me, book nerd?” If you go through that enough times, you start thinking some pretty egotistical thoughts. Thoughts like “This sucks” and “It shouldn’t take 3 pages of documentation to describe a feature that takes 28 seconds to perform” and “I could TOTALLY design this better”. It’s that last one that got me.

After talking to my boss, we both concluded that it’d be a good idea if I learned the role of Systems Engineer, which is equivalent in our company to “business analyst” or “the person who finds out what the software ought to do, then designs it so that it actually does that very thing”, but that doesn’t fit easily on business cards, so “Systems Engineer” is the title of choice. The job of the systems engineer is to design software features, host collaboration team meetings between customers and internal personnel, serve as the subject matter expert for the assigned feature, and generally do a ton of cool stuff that technical writers drool over in their sleep. I apprenticed under another SE for awhile, and then later got handed my own project to work on by myself. Good times.

What I’m starting to learn, though, is that when you’re the giver of information rather than the receiver, the people you formerly considered to be knowledgeable and intelligent turn out to be…less than that. Sometimes they are dumber than a box of…dumb, boxed things. (Sorry folks, I’m still getting back into the swing of blogging again. The analogies will flow again.) Basically, my job is to write the specifications, and the developers (the guys and gals who do the software coding) use those specifications to code the software. But all too often, an exchange like this occurs.

I’ll write a specification that says, for example, “The window will be blue with a gray border” or whatever. The developer will then come to me and say “So Damian, I was about to code this window but I don’t know what color to make it.”

Me: “Make it blue, with a gray border, per the specification.”
Developer: “Hmm. I didn’t see that in the specification. Is that a new requirement?”
Me: “Um…no, it’s been in there the whole time.”
Developer: “Are you sure?”
Me (looking at him like he grew iPods out of his neck): “Yeeeeeeeah, I’m sure. I wrote it. So…yeah. It’s in there.”
Developer: “Well I didn’t see it. It sounds like an enhancement request to me.”

The words “enhancement request” are like a Get Out Of Jail Free card mixed with a lottery ticket dipped in gravy  for developers, because it means they didn’t misinterpret the design or just straight-up miss it the first time around – it means it’s new shit. It means they don’t necessarily have to code it without approval from the project manager. And I am not that person.

Me: “It’s not. It’s been on page 23 since June.”
Developer: “Really?”
Me: “YES. Are you looking at the most recent version of the specification?”
Developer: “June 7, right?”
Me: “Um…no. November 8. And the requirement is in there.”
Developer: “Oh. Guess I must’ve missed that. OK…well, what color should the border be?”
Me: “I will kick you.”

I’ll keep you posted.