I was talking to a Portuguese friend a few months back. He's a bus driver for those big two-level tour busses that you might see in various European tourist cities.
He told me about how one of the newer guys accidentally killed a woman. It was the woman's fault; she was on her cellphone and walked into oncoming traffic -- and he didn't stop in time (they're gigantic busses, they don't stop on a dime and if they did, people would get seriously injured). But, understandably, he was very upset by the situation.
Their bosses wanted to demote the driver; have him drive passenger vans for a while, instead of gigantic busses.
Paolo disagreed. Paolo felt that the best thing for this driver was to keep driving the big busses.
He felt that if this guy was demoted, it would affect his confidence. That lowered confidence would make it harder for him to drive anyone -- after all, these bus drivers have to gauge the safety of everyone on board against the safety of one person being an idiot. Paolo felt the demotion would make him an unsafe driver -- not the fact that he killed someone. Paolo's reasoning was, "the guy already feels terrible. That's lesson enough."
I agree with Paolo
Firing a developer for an honest mistake doesn't make that developer better. It lowers their confidence, makes a developer less sure of herself. That developer goes into the next job more cautious, less likely to speak up, more likely to not try a more advanced technique, and more unwilling to try out something she doesn't totally know. Codebases will suffer.
The developer will feel the mistake. The pain of the mistake will be lesson-enough.
The best thing you can do when a developer makes a terrible mistake is just discuss it with them:
Do you know what you did wrong?
Do you know how to do it right?
What can you do to prevent this kind of mistake in the future?
Only if that developer commits the same kind of honest mistake multiple times should you consider firing them. And only then, after carefully making sure that each time the developer was coached on what to do correctly.
I was talking to a Portuguese friend a few months back. He's a bus driver for those big two-level tour busses that you might see in various European tourist cities.
He told me about how one of the newer guys accidentally killed a woman. It was the woman's fault; she was on her cellphone and walked into oncoming traffic -- and he didn't stop in time (they're gigantic busses, they don't stop on a dime and if they did, people would get seriously injured). But, understandably, he was very upset by the situation.
Their bosses wanted to demote the driver; have him drive passenger vans for a while, instead of gigantic busses.
Paolo disagreed. Paolo felt that the best thing for this driver was to keep driving the big busses.
He felt that if this guy was demoted, it would affect his confidence. That lowered confidence would make it harder for him to drive anyone -- after all, these bus drivers have to gauge the safety of everyone on board against the safety of one person being an idiot. Paolo felt the demotion would make him an unsafe driver -- not the fact that he killed someone. Paolo's reasoning was, "the guy already feels terrible. That's lesson enough."
I agree with Paolo
Firing a developer for an honest mistake doesn't make that developer better. It lowers their confidence, makes a developer less sure of herself. That developer goes into the next job more cautious, less likely to speak up, more likely to not try a more advanced technique, and more unwilling to try out something she doesn't totally know. Codebases will suffer.
The developer will feel the mistake. The pain of the mistake will be lesson-enough.
The best thing you can do when a developer makes a terrible mistake is just discuss it with them:
Do you know what you did wrong?
Do you know how to do it right?
What can you do to prevent this kind of mistake in the future?
Only if that developer commits the same kind of honest mistake multiple times should you consider firing them. And only then, after carefully making sure that each time the developer was coached on what to do correctly.
I agree with Paolo as well. I also agree that if you keep making the same mistakes you are probably just being careless.
Thanks for sharing.