No, it would still be an overreaction in that case. When someone makes their first mistake, even if it's an expensive mistake for the company, you don't start with the kind of berating that the author related. Certainly you might have to escalate to that level of intensity if the person doesn't improve, but you don't start there.
The (business) reason you don't punish people for a mistake as a general policy isn't that you're being a forgiving soul and giving them a second chance. It's because humans have a natural unavoidable tendency to eventually make certain errors in certain roles, and it's counterproductive to punish the poor soul that happened to make that mistake. It could've been anyone else, and you're punishing the one who has the best experience for avoiding the same mistake in the future. You should instead use their experience to design a process that catches those mistakes.
That rationale goes completely out the window when you're talking about lapses in judgment that the average employee would absolutely not make, like a random unauthorized Easter egg that could put the company in legal jeopardy. It's like if a surgeon brought his Playstation to the operating room. It's not a case of "we just spent $cost training him" anymore - that was never even part of his job description in the first place, nor something anyone would have expected him to even try. There was simply no reason for it; it was just an employee fooling around and planning to apologize for it afterward. (!) At that point you're dealing with something that's much closer to an insider threat than a human error.
So, as a matter of general policy, firing him for that would have absolutely made sense. Of course individual cases may warrant different reactions, but the general reasoning for blameless mistakes simply would absolutely not have applied here.
It's really, really important to understand the context here. From the article:
> I was hired on at Apple in October of 1995. This was what I refer to as Apple’s circling the drain period. Maybe you remember all the doomsaying — speculation that Apple was going to be shuttering soon
Everyone in the company was presumably on edge, and expensive mistakes were starting to border not on career ending, but on _company_ ending. The difference between firing someone for making expensive mistakes and laying them off is nearly immaterial, IMO.
I get that in cases where, like, you accidentally drop a database table. Deliberately adding unauthorized code to a build in 1995 was much less OK than that. Regardless: he wasn't fired.
I really think these reactions come down to people not having working in shrink-wrap software in the mid-1990s. You weren't missing much, though.
I think the argument here is that the dressing-down is done in hindsight, which the developer didn't have. It's not fair to vary the punishment by the cost of the mistake, if the person didn't intentionally make the mistake (and thus didn't take the cost into account), as that's just revenge.
What you want instead is corrective action, which is achieved fine by saying "this cost us $X million in recall costs because we don't want a copyright infringement lawsuit", and then counting on the employee to now know not to make that mistake again.
You could, I guess, argue that if you yell at an employee, they're less likely to make that mistake again, but then you'd have to be yelling at them for every mistake, since they didn't know which mistakes would end up being costly (otherwise they wouldn't make them).
What's weird is that even this developer seems to disagree with people here. It's not complicated, I don't think: we just have a rooting interest in IC developers, and in Easter eggs. I'm really only here to keep saying that 1995 was nothing like 2015, nothing at all like it.
I agree with you on that, I'm just saying that yelling at people is rarely productive. Even firing should be something that's done after multiple issues, not because of one mistake, even if it's sizable. That's just my opinion, though.
I'm 100% on the same page with the "don't freak out at the early-career developer who accidentally drops a table" people; seems like a good management lesson (it also makes me glad I don't manage people). I just read this thread and the Jamiroquai and Sublime started playing in my head and I was teleported back to cubicle culture, which I am here to report is totally different than modern dev culture. :)
Yeah, we really had to make sure software didn't have too many backs back when we'd have to issue a patch release a year later. I'm not sure I miss it.
