> I remember him explaining how many CDs would have to be destroyed (had they already been created?) and the cost of those. I think I weakly explained that I had assumed that there were no copyright conflicts but he wasn’t hearing it. After that half-hearted defense I let him berate me and more or less accepted whatever fate was coming my way.
There are plenty of companies where your boss being upset with you can lead to you being fired irrespective of whether it's logically justified. The author doesn't seem servile so much as green (which they admit and talk about quite a bit).
> No need to warp your idea of what's right around what someone got mad at you about.
Part of being an adult is the ability to mentally square how the world ought to be with how it actually is. It is perfectly reasonable to acknowledge that a decision you made wasn't optimal in retrospect even if it was the theoretically-correct one. This isn't "warping" anything as much as it is getting on with your life.
Copyright infringement lawsuits are a real thing and can include both the offending company (Apple) and all parties identified as potential violators.
In other words, management may have saved this guy's ass from being named in a very costly lawsuit.
I think it would have been an overreaction to fire him, but it was absolutely within the realm of plausible outcomes.
This just highlights the fact that you can be sued for anything. For example, you could be sued for the same thing (even though CDs were destroyed) based on information from this blog.
I heard once about a mechanical engineer who brought printed photos of his previous projects to the interview instead of a typed resume, to good results. Once you’ve had to interview someone, you realize many times the interviewer is as nervous as the interviewee, so breaking the ice is valuable.
I became a cautionary tale though and would occasionally
warn off the new hires who might have had an inkling to do
something similar. And true to my word, I would tread very
carefully from that day on with an eye to what Apple HQ
would think about any of my actions — and potential
consequences (intended or not).
IMHO, this is an optimal resolution and should be applauded. Management reaped a 20-year reward and the author kept his job.
People learn by screwing up, and those can be the best lessons.
In one of my early jobs, I spammed a bunch of the company customers, trying to promote my music. This was before the Internet (1987 or so), and before spam, so I was a “proto-spammer.”
It became a watershed in my life, and I took my work and career, very, very seriously, after that.
The word *Internet" dates to December 1974.
> People learn by screwing up, and those can be the best lessons.
Precisely.
Had the author been fired for his actions, the only people who could learn from the situation would be those employed at that time. As each cycled out of the company, this lesson would be lost.
By addressing the error in judgement while retaining the author, the organization ensured the lesson would be passed on to each new generation of engineers without having to prescribe the policy dictatorially.
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.
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.
The versions of these color pickers that were included in builds of Copland contain the strings "Hey what?" (for the HSL picker) and "Scheherazade" (for the crayon picker). Might those have been some of yours?
https://rezmason.net/chattin_with_jkcalhoun/copland_colorpic...
Hats off to you, Mr. Calhoun!
Not to dismiss the importance of a strong Product lead, but often the role is a permanent stopgap for engineers who lack the talent and discipline demonstrated in this article. (Easter egg aside.)
This is politics baked into the heirarchy, not a lack of "talent and discipline".
I had devs who told me they don’t care about product features. "Just tell me what to do, it’s my job to implement."
The article covers this but I think it's worth saying again: this was a different era in software development. In 1995 "shipping" meant literally "shipping": they had to produce real inventory, and then get it out into a bunch of different distribution channels. A problematic Easter egg caught too late could ultimately require an actual physical recall.
It's not surprising people freaked out over it.
Hard disagree. It reveals to management their own failings at setting expectations. Perhaps their heads were too far up their own asses to actually bother engaging with their team.
I know easter eggs are a tradition, but let's be honest. They're also a passive aggressive response to feeling bored and without a sense of direction. Why is that anyone's fault but management and ultimately the executives for yanking their attention away from actual work?
And that is probably the day the culture died a bit. Hearing that tale, I'd stick to the specification every time. And get an email trail.
Most huge screw-ups happen to well-intentioned, knowledgeable software engineers, who simply made an honest mistake.
The correct way to handle it, on the company/management's perspective, is not to fire the person who made the mistake, but to allow them to correct it (perhaps with help from others). And that is indeed what happens in most cases. There are certainly poorly managed companies who would fire someone in these scenarios, but they should be less common than otherwise.
I'm not going to name any names: in the late 00s/early 10s I worked in one of the highest-profile, high-growth tech startups of its era, and I've personally made a blunder that corrupted literally millions of user records in the database. This incident was known internally as one of the most disastrous technical things that happened in the company's history, among a few others. The nature of the product was one of very quickly updating data, and updates were critically important (e.g. is affected by user spends) and hence restoring from DB backups of even the night before was unfeasible. There was irreparable damage where a whole team of us had to spend the next few weeks painstakingly hand-fixing data for users, and coming up with algorithms/code to fix these things as users use the product as they go. As you expect in this anecdote, I did not get fired, I was part of the team that worked tirelessly following this incident to fix user data, and I continued to have a good, growing career in my remaining time in this company (the next few years).
brogdan•2h ago
For everyone else - make sure your DB backups work. You’ll need them.