DrWhizBang's Journal: Climbing the "dev" Ladder

I am now starting to work on my first project as a "developer" with my company. Traditionally, I have referred to my role in the company as a "script monkey" or "code cowboy", but my latest project (an installer for our company's product) turned out to be good enough and needed enough that "we" have decided to "productize" it in the next release.

That's all well and good. I expect to finally get a little more respect from all my java-coding heroes around the office. But man, oh man - the crap you have to go through to do official work in this company. Requirements documents, architecture documents, specifications, and meetings. Humbug!

I have to confess - I saw this coming. In fact, I asked for it. The truth is, you can only survive as the configuration/support guru so long before you need to feel that you've actually contributed to the project. And in time, maybe I'll grow to love process activities. But speaking as a guy that has trouble turning in his time-sheets every week, well, I think I'm going to drown.

How do you do it? How do you spend time documenting what you plan to do, while documenting what you are doing, documenting what you just did, and at the same time try to get some code done?

I'm waiting for an epiphany. Right here.