Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re: Development at the speed of thought.

by dws (Chancellor)
on Jun 07, 2002 at 19:43 UTC ( #172639=note: print w/replies, xml ) Need Help??

in reply to Development at the speed of thought.

Did you have similar moments in your career as a Perl hacker? It would be interesting for us to know “just how did you cope?”. Is it reasonable to turn away such requests or pursue them with vigor?

If you're competent you can expect a lot of "special" requests throughout your career. Pulling one off can be great for visibility, but the results can be a mixed bag for a couple of reasons:

  • If the company starts to see you as the person to go to in emergencies of a certain type, they may be reluctant to let you out of the box you're in.
  • If the company has a "sticky fingers" theory of code ownership, having your fingerprints on a bunch of solutions means you're stuck supporting them.
  • An occassional firefight is fun, but a string of them can be a real pain if you're trying to get other stuff done. And you boss can get really unhappy when his/her objectives take a hit because you're servicing other special requests.

Having survived many "special" requests, here's the approach I've settled on:

Keep Your Boss in the Loop. If you go off your boss's radar, you risk making him/her look bad. It can be really embarrasing to be a manager in a meeting with other managers and your boss, and have it come out that one of your folks is working on something you don't know about. It can make you look like an incompetent. So keep your boss in the loop. A boss who is in the loop may shut down the request, perhaps for reasons you don't have visibility on. That's life.

Let People Know the Tradeoffs. Once you have an idea of the effort to satisfy the special request, let your boss know. I've found that it especially helps to phrase it in terms of "X, Y, and Z" will be delayed for N days while I do this," since it reminds a (possibly busy and distracted) boss that your time isn't free. And let people who're depending on you for X, Y, and Z know. This gives them the opportunity to escalate, rather than blindsiding them. You may be upstream of stuff that's more important than you realize.

Leave a Solution that Doesn't Depend on You. To avoid perpetual maintenance resposibility, work the system to have people designated to take over your solution. Train them if necessary, and make sure you're leaving them with documentation that is adequate for them. Sometimes, sadly, this means not doing something in Perl when nobody else knows Perl. :(

Credit Where Credit is Due. When you do pull a rabbit out of your hat, take care to visibly thank the people who help (e.g., email to their manager(s), cc'ing them.) This keeps you from looking like a prima donna, helps encourage helpfulness, and gives visibility to others who deserve it. And what goes around comes around. I've gotten great support later from people who I've taken extra steps to acknowledge.

Write an "After Action" Report. To help keep corporate memory from forgetting the past, write a short memo explaining what you were asked to do, how you did it, how long it took, what the tradeoffs were (i.e., what projects slipped or took a hit), and what could have been done to avoid the problem in the first place. Try to be neutral and avoid finger pointing. (Think of this as something that you'd like the boss to pull out of their files when review time comes.) Get this report to your boss, and, if politically possible, to their boss. Here's a good place to thank other people who were helpful.

  • Comment on Re: Development at the speed of thought.

Replies are listed 'Best First'.
Re: Re: Development at the speed of thought.
by mstone (Deacon) on Jun 08, 2002 at 17:08 UTC

    Brilliant list.. ++.

    There's one thing I'd add to your "Let people know the tradeoffs" phase, though: Make the requestor handle the negotiations with the people whose projects are being bumped.

    'Special' projects are often a symptom of bad communication among management. Officially, management is supposed to allocate resources (including time and labor), and everyone everyone is supposed to buy into the same plan. Unfortunately, it doesn't always work that way. Personal and political issues can keep a group of managers from reaching an agreement, and when that happens, the things they can't agree on tend to get shoved under the rug.

    Asking developers to do 'special' projects is one way to shove things under the rug. In effect, a 'special' project can force the developer to make decisions that management was either unwilling or unable to.

    That's bad news.

    First of all, the developer doesn't officially have the authority or information to make those kinds of decisions. Then there's the fact that doing the project might put some other manager's nose out of joint. Remember, if all of management was behind the project, it would come to you as an assignment from your own boss.

    So don't let managers use you as the scapegoat in the cases where they can't do their own jobs. Make them do all the legwork and negotiations necessary to buy you the time and resources you need. That's what they get paid for.

    If the project is legit, the requestor will be able to buy you whatever time and resources you need, and everyone will be happy. Everyone will feel involved, and a lot of peripheral work will stay off of your shoulders. Having to get permission to cut in front of everyone else in your work queue will also keep people from deciding that you're a convenient source of free labor. Everyone involved will be reminded that lots of people want your time. That will cut down on frivolous requests and 'Spanish Inquisition' pressure tactics (having the client in the room or on the phone when making the request, so you can't possibly say no).

Re: Re: Development at the speed of thought.
by Mr. Muskrat (Canon) on Jun 08, 2002 at 01:38 UTC
    'Write an "After Action" Report'
    sounds an awful lot like an "After Action Review" or AAR as the U.S. Army is so fond of calling them.
    * Mr. Muskrat thinks that either:
    1) you are from a military background, or
    2) one of your teachers was.

    Who says that programmers can't work in the Marketing Department?
    Or is that who says that Marketing people can't program?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://172639]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (10)
As of 2017-11-23 15:50 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (336 votes). Check out past polls.