Help Me

I've just found out that basically I'm not allowed to code by myself. No, it's not PairProgramming. For any project that takes more than a few hours, I have to write up a BigDesignUpFront (BDUF) document and have it approved by a supervisor before I may do any actual coding. I feel like I'm in detention or something. While waiting for these letters of approval, I'm encouraged to complete some training exercises that are both tedious and below my level of expertise, i.e. I'm being "trained" in a programming language in which I've been programming production code for over a year. Every facet of this job seems to imply that I don't know what I'm doing.

Something's got to give. I want to find a better job, but TheJobMarketSucks. So how can I possibly climb out of this mess and find work in a house that does ExtremeProgramming?

I feel for you. I have only one recommendation: just do what you think is right and ought to be done. Disobey and ignore decrees from above (politely, of course). Keep doing that until they either give up on you (you win) or they fire you (you also win). If it sounds pat, well, what can I say, I've done this in the past. -- AlainPicard

Is there any way that you can have fun in your own little way? For example, when doing the training exercises, try to hunt for some new tidbit about the language that you didn't know. If you're stuck doing BDUF, be the best BDUF'er that you can possibly be. Make a game of trying to predict the code as accurately as possible. Or, what about this: Go ahead and write some prototype code however you like, then look at the results. Toss in some improvements and submit your findings to approval. Maybe they will have some valuable insight?

Sure, these are not the optimal ways to do it, but you might as well enjoy yourself.

Once you've got that part mastered, take some snapshot metrics of how much time you're spending in process overhead. Show it to them some time and ask them if the process is saving more time than that. If they say yes, try to see how. If you still disagree, patiently repeat the steps and wait until one of you has a change of mind.

Also... when you submit the idea that the process has too much overhead, be sure to try to give an alternate solution. They definitely aren't doing it just because they don't like you - they see some kind of value in it. Try to figure out what that value is, and then demonstrate another way that has that and more.

Maybe you will each get mutual benefit through all of this.

What do you think? (Besides "Easier said than done." I'm already well aware of that. ;)).

What would happen if you just coded anyway?

How often does your supervisor actually decline the design doc? If it's just a rubber stamp thing, then maybe you can do your programming first, and when you're finished, write up a quick 'Design Document' which basically describes what you've already done. Then you just pass the doc to your manager. When he/she rubber stamps it, you hand over the code by the end of the day. People will be in awe of how quickly you can program. Or better yet, you can start coding on your next thing, and you'll be one step ahead of the supervisor. But then, requirements are gonna change, so this is a bit of a dream...

How do you know how big a document is expected? Is the request explicit as to document size, or are you perhaps exaggerating a bit because you don't like to write descriptive prose?

Be happy you have a job!