red tape and red ink.

I hoped that when I finally started working out in the computer science industry, to avoid two things: customer service and paperwork. For the most part, I've escaped dealing with customers. I do have to talk to the customer every once in a while, but after a couple of years serving dinner to a lot of entitled people, it's not so bad. Now I don't have to worry about snobs so much as people who don't know much about their own jobs and know even less about mine.

But the paperwork, ah, the paperwork, is something that I have not avoided. Documentation seems almost the very essence of professional computer science. And I totally agree that it needs to be done in a lot of cases. We write documents to make sure that both the customer and ourselves understand what the software needs to do. We write documents to thoroughly plan out how we're going to make the software do what it needs to do. We write documents that plan out how we're going to test to make sure the software does what it needs to do. All of those things are good ideas, because in the end, you wind up with a better product because you took the time to think about it before you actually created it.

I just hate doing it.

I just finished up writing a software requirements specification (SRS). This document is the one where we say what we're going to do, the customer agrees, and everyone's happy. It's necessary so that there is no misunderstanding on what the customer wants and so that if they change their minds later, we can ask for more money. It's a tedious task to write one of these, mostly because it gets me thinking about the project, but I'm not allowed to really work on it yet, because the customer hasn't even signed off on the requirements. Writing a software design document is even worse for this, because you have to write down all the technical details of what you're going to do, but you still can't actually do it. Writing a design document made me finally fully understand the phrase "chomping at the bit."

It's not just me. I don't think there is anyone here who likes doing all this paperwork, all this nitpicky detailing about what we're going to do and how we're going to do it without actually being able to do anything. We are eager dogs dancing at the front door while our owner finds the leash and puts on his coat. We're dorks, we'll admit it: we just want to write code.

When a document is finished, it has to be reviewed. This means that several other people who are involved with the project, whether it be on the testing or financial or customer side, have to read it and make suggestions or ask questions to improve the document. Again, I think this is a valid exercise, because you get other viewpoints, and I honestly don't mind reviewing someone else's document. But I dread having my own document reviewed. It's so...demoralizing. It's like turning in a term paper and rather than just returning it with comments, your teacher gets five other teachers and they all pick at it line by line. By the end of it, you just feel kinda worthless.

I can't tell how much of my experience of the review process is because I'm new. I've only written two documents, and each time you go to one of these reviews, you get more of a feel for the things to look out for. My coworkers have always been encouraging and so while I still feel like a completely schmuck, I feel like that's probably okay at this point. It's definitely a learning process, and I try hard to remember that as I endure another verbal red-inking.

Eh, it's better than waiting tables.