Stories
Slash Boxes
Comments
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)

scrottie
  scott@slowass.net
http://slowass.net/

My email address is scott@slowass.net. Spam me harder! *moan*

Journal of scrottie (4167)

Thursday March 23, 2006
02:03 PM

How to Manage Your Programmer So He Can Manage You

[ #29083 ]

While you're worrying about managing your programmer, your programmer is pulling his hair out trying to manage you.
You're screwing everything up just like every employer or client, and every project is a failure.

Here's how to do it right.

1. Keep a Log and Keep Score

You're probably like every employer, and you
don't listen to a thing your technical
staff tells you, even when things go wrong
exactly like predicted, and then you probably
blame them for the failure.
Well, stop it, you fucking idiot, and here's
how.
Keep a log of every warning you're given;
record the recommended actions to avoid the
problem and the chances the problem will be
encountered if the actions are and aren't taken.
If you're doomed regardless, don't blame the
programmers -- you decided to proceed on a
fool's errand, not them.
If you ignore warnings and fail to take
actions and bad things consistently happen,
then you shouldn't be asserting domance like
the high-school bully you are.
Shut the fuck up and let your programmers work.

2. Commit to Your Priorities

Is it good? Quick? Cheap? Don't bitch that features aren't being added fast enough and then bitch about the bugs and then bitch about the cost. You pick your own priorities and your programmers will follow. If you make them guess what your priorities are, and keep them guessing, you won't get what you want at all.

3. Let them help solve your real problem

If you decide that you need an X to do Y and ask them to build an X for you, you're probably doing it the dumb way. Programmers are problem solvers, not discount construction workers. They don't specialize in doing huge amounts of work quickly. That's a losing battle. Instead, they specialize in doing things the smart way that eliminates work. Involve them in the processes of identifying the real problem, identifying possible solutions, and picking among them. We don't care if you want to waste your own time but we're sick to death of the legions of idiot clients wasting ours. And when you get what you want, which always turn out to be not what you wanted, blame yourself, not us, unless you headed this advice, and even then, it was a calculated risk and you improved your odds, so shut up. We're not happiness experts, just problem solvers. If you really just need a valium, see a shrink, you hysterical ninny.

4. Don't make us beg for authorization

To dodge accusations of operating out of control and to help keep you aware of what's being done and why, we'll often ask for permission to do things. Most of the time, you can ask them if it's a major decision and they'll say no, so you can say yes. If you had a family meeting every time you needed to refuel your tank, you'd give up driving by now. It's little wonder that the best programmers gave up working for clients doing programming. Your stupidity, ignorance, and domineering attitude endangers every project you come near when you can't grant simple requests without a powerplay and show of force. Highschool jocks make the worst managers but always seem to get the job. This letter really should be addressed to CEOs. Remember, you aren't qualified to make technical decisions, so your options are to cancel the project and abort operations or else sign off. Don't pretend like things can move forward without you signing off on small requests.

-scott