17 ms·

I'm surprised they hired him after that. If it was a big enough deal that they had to make a statement saying he was no longer with the company, why would they

by joemi 4y ago

I'm surprised they hired him after that. If it was a big enough deal that they had to make a statement saying he was no longer with the company, why would they hire him after that?

ajmurmann 4y ago
To some degree this was a system or process failure. The build should have never become a beta build that gets send to the public. Many years ago I worked on an Android game where on April 1st one of the other devs swapped the game's theme for Never Gonna Give You Up as a similar prank directed at the QA team. If we had shipped this more widely, it would have been a larger organizational failure, similar to this case.
- heleninboodler 4y ago
  There's an infamous case from Adobe where an engineer added an unauthorized easter egg that caused a runtime problem and was fired for it. The firing spurred widespread shock among the employees, and management quickly rescinded his termination. He quit shortly afterward. The takeaways here are that a rash firing for this sort of thing isn't always the best course of action, and that being fired-then-unfired leaves a bad taste in an employee's mouth. Oh, and test your easter eggs.
kevinmgranger 4y ago
"Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?" It's more like the PR / social interaction version of this.
- charcircuit 4y ago
  That's an example of the sunk cost fallacy. If a business makes a $600k investment sometimes it's better to just cut their losses instead of trying to continue with something they have already invested time and money into.
  - Taywee 4y ago
    That's not a sunk cost fallacy. A sunk cost fallacy depends on expected future cost still being higher than future benefit. In that anecdote, the implication is that the employee gained insight or learned from that mistake. In fact, firing them might not be justified from a business perspective, because you're firing somebody even though they are less likely to make such a mistake in the future. It's not really logical to fire somebody for a mistake unless it's reasonable to assume it indicates ongoing liability. You have to decide and plan for the present and future, not the past.
    - charcircuit 4y ago
      >A sunk cost fallacy depends on expected future cost still being higher than future benefit. And that manifests as keeping the employee as opposed to replacing him with a more experienced person who already knows how to not make expensive mistakes. In the context of SWE, specifically with a blameless culture, these expensive mistakes aren't training for people, but training for the business as new checks and protocol get established to reduce the change of the same thing happening again. Someone making an expensive mistake is independent to whether they get to stick around. In the example this expensive training is a reason to keep the guy around.
ignoramous 4y ago
Blaming an individual for systemic failures is bad form (even for Microsoft). If you read the post, you'd see the QA org saw that Easter Egg, took it in the right spirit (like they should), and signed it okay for beta release (mistakenly, I'd presume) followed by everyone else in the bureaucratic chain that might have okay'd it as well.
- colinmhayes 4y ago
  > Blaming an individual for systemic failures is bad form I agree if the failure is actually a mistake. The developer in this scenario included the gesture on purpose. Pretty clearly shows they don't have the best judgement imo.
  - coryrc 4y ago
    It's harmless. It's funny. Some of you just need to relax and bring back some joy to programming.
    - colinmhayes 4y ago
      I'm a bit torn. Yea, it's harmless, but making your OS flip people off isn't really funny. I just feel like it would be hard to trust this programmers judgement if they thought this was an appropriate joke to make.
      - Verdex 4y ago
        It's not great, but I think the real question is twofold. Is the programmer far enough in their career to have been expected to already learn this lesson and did the programmer in fact learn the lesson. If they're young and they never do it again, then I think it would be fine to keep the hire. If they keep on doing it, then it's time to go. If they're 25 years into their career, then they should almost definitely have known better.
        gnulinux 4y ago
jaywalk 4y ago
I'm glad they hired him after that.
linsomniac 4y ago
The guy pointed out that there was a lack of QA in their beta release process. Should have gotten a promotion.
- joemi 4y ago
  If the prank was intentionally designed to point that out, then sure, I might agree. But the article does not make it sound that way.
koonsolo 4y ago
He probably learned a big lesson after that mistake. So if he was a good developer, why not hire him? The chance of him doing the same mistake is probably very tiny. I can imagine that a junior is not able to assess the risk and consequences involved.

by joemi 4y ago

I'm surprised they hired him after that. If it was a big enough deal that they had to make a statement saying he was no longer with the company, why would they hire him after that?

ajmurmann 4y ago

To some degree this was a system or process failure. The build should have never become a beta build that gets send to the public. Many years ago I worked on an Android game where on April 1st one of the other devs swapped the game's theme for Never Gonna Give You Up as a similar prank directed at the QA team. If we had shipped this more widely, it would have been a larger organizational failure, similar to this case.

heleninboodler 4y ago
There's an infamous case from Adobe where an engineer added an unauthorized easter egg that caused a runtime problem and was fired for it. The firing spurred widespread shock among the employees, and management quickly rescinded his termination. He quit shortly afterward. The takeaways here are that a rash firing for this sort of thing isn't always the best course of action, and that being fired-then-unfired leaves a bad taste in an employee's mouth. Oh, and test your easter eggs.

kevinmgranger 4y ago

"Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?" It's more like the PR / social interaction version of this.

charcircuit 4y ago
That's an example of the sunk cost fallacy. If a business makes a $600k investment sometimes it's better to just cut their losses instead of trying to continue with something they have already invested time and money into.
- Taywee 4y ago
  That's not a sunk cost fallacy. A sunk cost fallacy depends on expected future cost still being higher than future benefit. In that anecdote, the implication is that the employee gained insight or learned from that mistake. In fact, firing them might not be justified from a business perspective, because you're firing somebody even though they are less likely to make such a mistake in the future. It's not really logical to fire somebody for a mistake unless it's reasonable to assume it indicates ongoing liability. You have to decide and plan for the present and future, not the past.
  - charcircuit 4y ago
    >A sunk cost fallacy depends on expected future cost still being higher than future benefit. And that manifests as keeping the employee as opposed to replacing him with a more experienced person who already knows how to not make expensive mistakes. In the context of SWE, specifically with a blameless culture, these expensive mistakes aren't training for people, but training for the business as new checks and protocol get established to reduce the change of the same thing happening again. Someone making an expensive mistake is independent to whether they get to stick around. In the example this expensive training is a reason to keep the guy around.

ignoramous 4y ago

Blaming an individual for systemic failures is bad form (even for Microsoft). If you read the post, you'd see the QA org saw that Easter Egg, took it in the right spirit (like they should), and signed it okay for beta release (mistakenly, I'd presume) followed by everyone else in the bureaucratic chain that might have okay'd it as well.

colinmhayes 4y ago
> Blaming an individual for systemic failures is bad form I agree if the failure is actually a mistake. The developer in this scenario included the gesture on purpose. Pretty clearly shows they don't have the best judgement imo.
- coryrc 4y ago
  It's harmless. It's funny. Some of you just need to relax and bring back some joy to programming.
  - colinmhayes 4y ago
    I'm a bit torn. Yea, it's harmless, but making your OS flip people off isn't really funny. I just feel like it would be hard to trust this programmers judgement if they thought this was an appropriate joke to make.
    - Verdex 4y ago
      It's not great, but I think the real question is twofold. Is the programmer far enough in their career to have been expected to already learn this lesson and did the programmer in fact learn the lesson. If they're young and they never do it again, then I think it would be fine to keep the hire. If they keep on doing it, then it's time to go. If they're 25 years into their career, then they should almost definitely have known better.
      - gnulinux 4y ago

jaywalk 4y ago

I'm glad they hired him after that.

linsomniac 4y ago

The guy pointed out that there was a lack of QA in their beta release process. Should have gotten a promotion.

joemi 4y ago
If the prank was intentionally designed to point that out, then sure, I might agree. But the article does not make it sound that way.

koonsolo 4y ago

He probably learned a big lesson after that mistake. So if he was a good developer, why not hire him? The chance of him doing the same mistake is probably very tiny. I can imagine that a junior is not able to assess the risk and consequences involved.