Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: OT - How to deal with coders who don't do what they should

by dug (Chaplain)
on Mar 30, 2002 at 20:57 UTC ( #155487=note: print w/ replies, xml ) Need Help??


in reply to OT - How to deal with coders who don't do what they should

Lemming makes a very good point that if the first reaction is scream and curse and yell that it's probably a good idea to meditate on your response for a bit(which you obviously realize, or you wouldn't have posted a Meditation).
It really depends on what your relationship is with the offending coder. If he reports to you, you have a couple of options.

  • Teach him. Do code reviews on *all* code that is going to be pushed into a production envionment. It's your job.

  • Fire him. If you've repeatedly tried to teach him, and it hasn't worked, he's probably not right for the job. This could also mean firing him from his current position and moving him into another that he's better suited for.

If the offender doesn't report to you, it's more a question of how you want to deal with your personal working relationships, and I don't have any advice there. <grin>


Comment on Re: OT - How to deal with coders who don't do what they should
Re: Re: OT - How to deal with coders who don't do what they should
by oakbox (Chaplain) on Mar 31, 2002 at 08:01 UTC
    Having your own mistake pointed out to you is extremely embarrassing. There are three possible programmer reactions:
    1. Programmer gets a sick feeling and immediately tries to fix the problem . . . perhaps even before fixing the process that made the mistake in the first place.
    2. Programmer takes a look at how the mistake got in the code and modifies the process to keep it from happening in the future.
    3. Programmer denies responsibility for the mistake and chalks it up to 'bad requirements'.
    The thing is, number 1 is just as unhealthy to the long term as number 3. That's the preaching of Demming, fix what's causing the problem, not just the problem itself.

    So, to be more specific, point out what went wrong, what you wanted to happen, and take time together to go over the requirements again to make sure that they are clearly understood. Make a better 'beta' process and don't rely solely on the person who wrote the code to tell you whether or not it works. Users are more creatively stupid than programmers, you have to let them practice THEIR expertise :)

    I hope that wasn't too far off-topic.
    -oakbox

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://155487]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2014-12-22 10:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (116 votes), past polls