Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)


My email address is Spam me harder! *moan*

Journal of scrottie (4167)

Wednesday April 05, 2006
10:51 AM

Really super extra ultra simple project management

[ #29223 ]

Are you now or soon to be managing a programmer? If you are, the chances are that you're too dumb to even realize that this is what's happening, but let me extend the benefit of the doubt. For example, if you've hired a contract programmer to do something, you control the paycheck, and that's a plenty big bargaining chip with which to throw your wieght around, and you're therefore managing them. Here's a really extra simple guide that even your likely feeble brain can handle. Let us proceed.

1. Give him/her (the programmer) specifications. A programmer without specifications cannot help you with your problem.

2. If you forgot to ask for something in the specs, it's your damned fault, so if you fuck up and forget to ask for something that you consdier critical, apologize profusely and hope the programmer can schedule you in again soon.

3. Programmers put status in CVS logs (or whatever version control system is in use) and if you're really lucky, in emails to you. If you can't understand the status reports, and a few attempts at clarification don't help, or if you have to take liberties in interpretation of the status reprot that the programmer won't sign off on, then the complexity of the situation is too much for your puny intelligence, and you'll simply have to do without status reports. This is your fault, not theirs.

4. Do not attempt to call your programmer on the phone, or to ask for permission to call. There is no reason to talk on the phone except to change the specifications, and changing the specifications amounts to cancelling the project. Changing the specifications tells the programmer that there is no actual, definate goal being worked towards, and instead, merely work is being done for no reason. Since there is no success case in this situation, the programmer will wisely decide that if the project is doomed, it might as well be doomed through lack of effort rather than wasted effort, and will proceed to bill you for the motions that she would have gone through where she to actually particate in your game of Follow the Leader.

5. This is the hardest of all of these instructions: Resist at all costs the overwhemling temptation to hire a programmer who is even stupider than you are in hopes that you'll be able to communicate with them. It's natural and necessary that your programmer will have to condescend to you. The largest impedement to success is your own ego. Quite simply, once you deliver the specifications, you're in the way. Hire someone with a history of overwhelming idiots like you and forcing success out of projects, and them let them do exactly that. Remember that if you ever find yourself saying "there's no way they could be so smart as to know this thing they're telling me", then you've either fucked up this most important point and your project is doomed, or else you fucked up the previous point and your project is doomed.

Way back when, people would pay top dollar for technical work coordinated by large research firms. Sperry Rand would send some extremely knowledgeable people out, and they would try to talk down to your level, you would try to speak up to their level, and if you paid enough money and did exactly what was asked of you, you might have a working solution. Now days, Bubba, or just as bad, Bubbles, thinks they can domineer the technical talent and still arrive at a solution. Ha!


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.