I wouldn't say it's an optimal resolution, because it was a complete overreaction by management in the first place. The optional resolution would have been that the author was gently but firmly told "that isn't acceptable here, don't do it again". There was no need for his manager to tear him a new one over such a minor incident.
That's why it's often critical to implement systems to second-check important stuff.
If I may lapse into garrulous-old-fart mode: Soon after I made partner in my BigLaw IP firm, as the resident software(-adjacent) geek I was tasked by the management committee with overseeing the firm's docketing operation: Six very nice people (ladies of varying ages, as it happened) who for many years had opened all our incoming mail from courts, agencies, etc., and logged future deadlines into our by-then antiquated, home-grown, pre-PC calendaring system, still running on a mini-computer.
The proximate cause of my tasking was that the other partners were getting increasingly frustrated by the human-origin calendaring errors that kept showing up in lawyers' tractor-feed greenbar printouts. If we'd blown a court deadline, we likely would have gotten zero sympathy from the court, the client, and our malpractice-insurance carrier.
The first thing I did was implement a Navy-nuke system in which every deadline entry got second-checked. That produced some grumbling among the docketing staff because it made extra work for them.
(We mitigated that by eliminating some calendaring tasks that no longer made sense, such as logging every date, in ink, into a bound ledger book, which no one had looked at in years — I called it our WORN drive: Write Once, Read Never.)
I reassured the staff that no one would get fired for making a mistake, because we all do that. But they very well might get fired if their mistake got out the door because they'd bypassed the second-checking system.
Happily, the rate of calendaring errors showing up on lawyer greenbar printouts dropped to essentially zero. No one had to be fired, and several staff members said that they liked the second-checking system.
(Soon after, we switched to a then-modern, PC-based system.)
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.
But they didn't have to, and a bit of thoughtful consideration would have (and presumably did) make that clear.
This is less of a "caught driving drunk" situation and more a "caught driving with one taillight out" situation. You want to make sure it doesn't happen again, but there was no real danger from this single instance.
