Web Programmer's Role

[webtea]

My job requires me to write extremely detailed business requirements and design specifications, and it's literally taken the fun out of programming. I understand the need for detailed documentation, but I'm a programmer! Shouldn't someone else be gathering all of the requirements and then my job is to translate those requirements into code? Should I be burdened with doing all the technical writing for my projects? Is it typical for the programmer to write up all of the documentation???

I'm pretty new to this stuff, but never would've gotten into this profession had I know that it'd be 95% process-laden BS, and 5% creativity. It's really boring the hell out me now.

[ghippleh]

It seems like your company could use their resources a little better... have the programmer do the programming and an intern or someone else write the manual. I'm still finishing my EE degree so I am not quite out in the professional world but this does sound quite odd that you have to do that much tech writing. On the other hand, no one knows the code better than the programmer.

[webtea]

I'm tellin' you, dude, I'm responsible for interviewing, writing up the requirements in FULL detail, writing in general terms what how I'm going to approach all of those little details, the technical aspects (what tables are going to be used, flowcharts of logic), the test scripting, and... guess what? The programming!!!!!! After that comes my documentation of user acceptance testing, blah blah blah! My company is horribly inefficient and our doc 'specialist' is a freakin' joke (has no clue whatsoever about the programming process). Just wondering if this is normal; if so, I'm seriously going to quit and use my degree toward something else. I'm not cut out to do all of this damned writing!!! I almost forget how to code after weeks and weeks of doing documentation!!! LOL

[potterd64]

different companies will operate differently. Some (or maybe most) will require the tedious detail you mentioned and others wont. Some will also have non-coders get the business requirements specifically and act as messenger between customers and developers.

I personally like being in contact with the customers directly, and find that the middle-man approach just cuts back on communication and makes things take longer. It's especially beneficial to have direct communication when the requirements aren't fully (or even halfway) understood.
My current job doesn't require a massive amount of documentation as long as the job gets done, and I communicate directly with my customers.

Anyways you could probably find something closer to what you want at another company. Or you could try and find the fun in what you're doing :o Do you at least get to design the UI?

[WebJoel]

Not all compaines operate that way. My wife is a Technical Writer, -she writes & oversees most of the documentation of the product.
Where she works they have programmers, both front & backend, that deal with other aspects, but the documentation is left to the TW.

[webtea]

different companies will operate differently. Some (or maybe most) will require the tedious detail you mentioned and others wont. Some will also have non-coders get the business requirements specifically and act as messenger between customers and developers.

I personally like being in contact with the customers directly, and find that the middle-man approach just cuts back on communication and makes things take longer. It's especially beneficial to have direct communication when the requirements aren't fully (or even halfway) understood.
My current job doesn't require a massive amount of documentation as long as the job gets done, and I communicate directly with my customers.

Anyways you could probably find something closer to what you want at another company. Or you could try and find the fun in what you're doing :o Do you at least get to design the UI?
Hi, potter, and thanks for the input. I totally agree that I should communicate with the people making the requirements --but turning all of that into a formal documentation set? That's what I'd expect our 'tech writer' (knows literally nothing) to do. Yeah, sure, I could informally gather the requirements and then pass them on to him to format and organize everything; but I have to do all that! Sorry, but I don't have a degree in tech writing or English. It takes an enormous amount of time; I literally get nothing accomplished code-wise, man. I could see where I'd be involved in the informal one-on-one part, but not after that going to my office and writing up the documentation for weeks on end. Our staff (the ones who do things 'by the book') gets nothing accomplished; we miss deadlines horribly. But they will not relent because of the bureaucracy, the people 'up top' don't get it...

Yeah, I eventually get to design the UI --after teaching myself everything over again because I've forgotten it (lol, exaggerating).

[webtea]

Not all compaines operate that way. My wife is a Technical Writer, -she writes & oversees most of the documentation of the product.
Where she works they have programmers, both front & backend, that deal with other aspects, but the documentation is left to the TW.
Hi, WebJoel, thanks to you as well for the input. I would expect a fairly-seasoned tech writer to do what I do, but we don't have one on hand. I had a course or two on it in college, but this is wayyy more than I should be doing. This is hard-core stuff! It's so non-productive. And a few of us have become totally disinterested.

[seaneak]

No matter what kind of developer you are...documentation is the necessary evil. I know... I've been on both sides. I've developed and then maintained code others have developed. I commented and documented as I developed and was totally grateful when I read why someone coded what they did (because there is ALWAYS a good reason why you did what you did..it is only fair to let the people who have to maintain your work know why).

Programmers are creative animals. Requirements can be 'excruciatingly' detailed, but once the creative juices get going....what is developed never conforms to the specs. If it does, then you just use the specs as documentation and 'tweak' them where necessary..in other words, cheat when you can.

If there are TW's to develop the docs, then they are just going to soak up a ton of time getting the information from you. They can't possibly document sufficiently what you created so that others will be able to understand it without having to come back to you sometime. So...save yourself time in the long run....just do it.

[webtea]

Programmers are creative animals. Requirements can be 'excruciatingly' detailed, but once the creative juices get going....what is developed never conforms to the specs. If it does, then you just use the specs as documentation and 'tweak' them where necessary..in other words, cheat when you can.

I read all of your post and appreciate the comments, but I find the above quote to ring especially true. I spend all of my time on this documentation, which is supposed to somehow translate into code magically, but it never works out that way. I think it's telling that trying to spec out the actual technical design is a fruitless adventure, for you realize the true design only when you're doing the actual coding. And you're right, I always tweak the documentation to match what I've coded, which is, to me, quite ridiculous. I still think the TW should be writing all the actual documentation and organizing what I've gathered informally; besides, I get paid a lot more than them. ;)

[Cstick]

Ugh, your job sounds like my worse nightmare, but don't give up your programming aspirations just yet, there are working conditions out there that will better suit you. I think Seaneak is spot on with the necessary evil comment. But there is such a thing as overdoing it and breaking down responsibility. I also do not believe completely in the whole extreme programming movement, I kind of think so called XP programmers may be glorified lazy programmers. Sounds to me like you're still wet behind the ears though. Have you seen a project through a complete life cycle yet? Is your employer perhaps weeding out the quitters?

Here's my advice for you when you are searching for your next position. Don't just go into the interview foaming at the mouth because someone is willing to hire you with little experience. Be sure to find out what you will be getting yourself into and that the environment is right for you. The person interviewing you might even find you more appealing if he knows you aren't just looking for a paycheck, but a place where you can grow.