I think the general public (and by that I mean including software engineers too) overestimate the likelihood of a huge screw-up leading to being fired like they do in the movies, if the screw-up is neither (1) malicious/intentional in nature, nor (2) demonstrates that you're grossly incompetent for the job.
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).
There are, I think, different norms and risk levels in different types of employment.
Somewhat ironically, it's much easier to get fired from a minimum wage fast food service job than it is to get fired from a six-figure-salary job at Google.
This is an example of classic software engineering. It's when the person writing the code understands why they're doing it, succeeds in that, then tastefully adds a little more, and has some fun, which in turn makes the product delightful.
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.)
I'm not saying every engineer has ambitions to be in management, but your quote is just as likely someone who has become fed up with sloppy management and deliberate gatekeeping.
One of the deliberate outcomes of putting a product lead in place is to train the engineer to fully understand the product. For any vertical market or B2B product the chance of hiring engineers who understand the business domain is virtually zero so they need clear guidance to build what customers want.
To answer the author's question: because the crayon picker rules! It's genuinely useful.
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.
After having introduced an Easter egg and being called out for it, the author states:
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).
It is very likely that management weighed the author's value to the organization against the cost, real or perceived, to rectify this particular situation. An additional potential value which was ultimately realized is the author became an extension of organizational policy "at ground level."
IMHO, this is an optimal resolution and should be applauded. Management reaped a 20-year reward and the author kept his job.
Reminds me of a story (which I've heard in slightly varying versions) that happened in the early days of IBM. A man had made a costly mistake, but Thomas Watson didn't fire him, saying "we just spent all that money educating you!"
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.
> Reminds me of a story (which I've heard in slightly varying versions) that happened in the early days of IBM. A man had made a costly mistake, but Thomas Watson didn't fire him, saying "we just spent all that money educating you!"
> 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.
It does sound like the classic sunk cost fallacy. But it also implies that the would-be-fired person has become better after being "educated", and probably better than the average newly-hired person replacing them if they are fired...
When a generally smart person makes a humiliating million-dollar mistake, then you can trust that person, more than any of their coworkers, to never make that specific mistake again. That's the "expensive education" here.
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.
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.
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.
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.
I found the linked article about his interview even more fascinating!
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.
The author of this post is a regular commenter on HN, JKCalhoun. Nice post, JKCalhoun! I love the three dozen dongles hanging on the wall of Dithering Heights.
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?
Blast from the past! A handful of sacred Power Macs in my elementary school computer lab had the shareware version of Glider installed ("Glider Trial", or "Trail" [sic] as my spelling-challenged classmates called it who were unfamiliar with trialware) and every one of us jockeyed for one of these machines as we filed into the room so that we could play it. Circa 1999 I somehow got my mom to ask a hapless Wal-Mart employee whether they made Glider from Casady and Greene written by John Calhoun for Windows. We got a weird look and a devastating "no". Sometime in the next year or two my best friend and I fixed up his Grandpa's old Mac Plus which happened to have an older full version of Glider on it which made me quite happy.
Only corporate legal could freak out over the idea of hiding a single stanza of an 80 year old poem across a dozen resource names where they'll never ever be seen by the average user. If that's not fair use it should be.
You don't want to end up with a court trying to figure out whether that usage constitutes fair use. Taking a stand on whether it "should be" fair use isn't what company resources are for.
It's weird how... servile... this person sounds. They're wondered why they weren't fired, when their prank had no negative side effects and the only issue was a department head being a dick about it? hey think the lesson here was that they needed to learn professionalism? They should be bemoaning the world of power-tripping unreasonable bosses. No need to warp your idea of what's right around what someone got mad at you about.
> They're wondered why they weren't fired, when their prank had no negative side effects and the only issue was a department head being a dick about it?
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.
Carl Sagan had sued Apple the prior year for merely using his name as a project codename that was never going to be published anywhere or included in any customer product. John had placed an excerpt of a still-copyrighted text into a resource fork that would ship to customers—and in fact had already been burned to discs.
I think it would have been an overreaction to fire him, but it was absolutely within the realm of plausible outcomes.
> sued Apple the prior year for merely using his name as a project codename
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.
It sounds like they had to scrap a CD run, so it wasn't exactly "no negative side effects." But yes, it's always a bad sign when the project you were hired for is canned and you get a new manager.
It sounded like they didn't have to scrap it, but did anyway? Or at least did not feel like it had to actually be justified to him.
> 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.
> 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).
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.
The November '97 issue of MacAddict (#15) lists a couple of the crayon picker easter eggs, though the one with engineers' names was only found with ResEdit.
> It’s an embarrassing thing when you realize that those irresponsible tendencies you had in your youth are still with you. To fuck up in a professional environment like Apple is like committing some social faux pas that reveals suddenly to all the guests your poor and unsophisticated upbringing.
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?
I've never been a huge fan of Easter Eggs. From a risk management and QA point of view: there are a lot of things that can go wrong in a software project, why deliberately add something else not asked for, even if there was only a 1% probability that it would break? It just seems that the downside risk massively exceeds any potential upside. If something actually fails because of it and you have to write the postmortem, what are you going to say?
The title as expected is bait. It’s a common situation in many companies where new hires are given authority with risks/consenquences and they overstep. They’re told not to do it again. That’s the gist of it. You’re welcome.
For everyone else - make sure your DB backups work. You’ll need them.
I think the general public (and by that I mean including software engineers too) overestimate the likelihood of a huge screw-up leading to being fired like they do in the movies, if the screw-up is neither (1) malicious/intentional in nature, nor (2) demonstrates that you're grossly incompetent for the job.
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).
There are, I think, different norms and risk levels in different types of employment.
Somewhat ironically, it's much easier to get fired from a minimum wage fast food service job than it is to get fired from a six-figure-salary job at Google.
This is an example of classic software engineering. It's when the person writing the code understands why they're doing it, succeeds in that, then tastefully adds a little more, and has some fun, which in turn makes the product delightful.
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.)
One of the deliberate outcomes of putting a product lead in place is to prevent the engineer from fully understanding the product.
This is politics baked into the heirarchy, not a lack of "talent and discipline".
No engineer is the same.
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."
I'm not saying every engineer has ambitions to be in management, but your quote is just as likely someone who has become fed up with sloppy management and deliberate gatekeeping.
This is the result of advice being rejected too many times (and later turning out to have been correct).
One of the deliberate outcomes of putting a product lead in place is to train the engineer to fully understand the product. For any vertical market or B2B product the chance of hiring engineers who understand the business domain is virtually zero so they need clear guidance to build what customers want.
To answer the author's question: because the crayon picker rules! It's genuinely useful.
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.
After having introduced an Easter egg and being called out for it, the author states:
It is very likely that management weighed the author's value to the organization against the cost, real or perceived, to rectify this particular situation. An additional potential value which was ultimately realized is the author became an extension of organizational policy "at ground level."IMHO, this is an optimal resolution and should be applauded. Management reaped a 20-year reward and the author kept his job.
Reminds me of a story (which I've heard in slightly varying versions) that happened in the early days of IBM. A man had made a costly mistake, but Thomas Watson didn't fire him, saying "we just spent all that money educating you!"
People learn by screwing up, and those can be the best lessons.
I did.
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.
before the Internet (1987 or so)
The word *Internet" dates to December 1974.
It was a joke.
> Reminds me of a story (which I've heard in slightly varying versions) that happened in the early days of IBM. A man had made a costly mistake, but Thomas Watson didn't fire him, saying "we just spent all that money educating you!"
> 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.
That's a classic case of the sunk cost fallacy. Just because you spent a lot educating someone doesn't mean that you shouldn't get rid of them.
It does sound like the classic sunk cost fallacy. But it also implies that the would-be-fired person has become better after being "educated", and probably better than the average newly-hired person replacing them if they are fired...
"all that money" here refers to the money they lost due to the mistake. The sunk cost fallacy refers to money you intended to spend...
When a generally smart person makes a humiliating million-dollar mistake, then you can trust that person, more than any of their coworkers, to never make that specific mistake again. That's the "expensive education" here.
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.
It was probably not an overreaction: if they'd had to pull millions of CDROMs off the shelves, that would be a very big deal.
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.
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.
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.
If he'd actually caused a recall, he'd probably have been fired. Instead, he got chewed out. Sounds about right.
I found the linked article about his interview even more fascinating!
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.
https://engineersneedart.com/blog/interview/interview.html
I get strong "Severance" (a TV series by Apple) vibes from this story.
An employee being manipulated into loyalty and servitude through guilt. This seems fucked up...
The author of this post is a regular commenter on HN, JKCalhoun. Nice post, JKCalhoun! I love the three dozen dongles hanging on the wall of Dithering Heights.
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...
He says of himself that he "wrote games for the Macintosh." That's an understatement. The guy wrote Glider!
Blast from the past! A handful of sacred Power Macs in my elementary school computer lab had the shareware version of Glider installed ("Glider Trial", or "Trail" [sic] as my spelling-challenged classmates called it who were unfamiliar with trialware) and every one of us jockeyed for one of these machines as we filed into the room so that we could play it. Circa 1999 I somehow got my mom to ask a hapless Wal-Mart employee whether they made Glider from Casady and Greene written by John Calhoun for Windows. We got a weird look and a devastating "no". Sometime in the next year or two my best friend and I fixed up his Grandpa's old Mac Plus which happened to have an older full version of Glider on it which made me quite happy.
Hats off to you, Mr. Calhoun!
Only corporate legal could freak out over the idea of hiding a single stanza of an 80 year old poem across a dozen resource names where they'll never ever be seen by the average user. If that's not fair use it should be.
You don't want to end up with a court trying to figure out whether that usage constitutes fair use. Taking a stand on whether it "should be" fair use isn't what company resources are for.
Neither is stopping the presses for every little thing.
An accurate representation of corporate legal's general attitude, yeah... just say no to any request because that covers your ass.
I want to read more work stories of retired engineers and designers.
It's weird how... servile... this person sounds. They're wondered why they weren't fired, when their prank had no negative side effects and the only issue was a department head being a dick about it? hey think the lesson here was that they needed to learn professionalism? They should be bemoaning the world of power-tripping unreasonable bosses. No need to warp your idea of what's right around what someone got mad at you about.
> They're wondered why they weren't fired, when their prank had no negative side effects and the only issue was a department head being a dick about it?
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.
Well sure you can always do what your boss says. The part that's weird is that the author seems to think their boss was in the right.
Carl Sagan had sued Apple the prior year for merely using his name as a project codename that was never going to be published anywhere or included in any customer product. John had placed an excerpt of a still-copyrighted text into a resource fork that would ship to customers—and in fact had already been burned to discs.
I think it would have been an overreaction to fire him, but it was absolutely within the realm of plausible outcomes.
> sued Apple the prior year for merely using his name as a project codename
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.
> They're wondered why they weren't fired, when their prank had no negative side effects ...
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.
It sounds like they had to scrap a CD run, so it wasn't exactly "no negative side effects." But yes, it's always a bad sign when the project you were hired for is canned and you get a new manager.
It sounded like they didn't have to scrap it, but did anyway? Or at least did not feel like it had to actually be justified to him.
> 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.
This was the 1990s. Attitudes about work were different. This was still (mostly) the era of "If the boss asks you to jump, you ask how high."
yeah, I'm getting that, but it's sad to read the mindset still existing in 2025
> 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).
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.
I’m pretty sure the Gold Wing-riding, pipe-smoking boss is/was C.K. Haun
The November '97 issue of MacAddict (#15) lists a couple of the crayon picker easter eggs, though the one with engineers' names was only found with ResEdit.
> It’s an embarrassing thing when you realize that those irresponsible tendencies you had in your youth are still with you. To fuck up in a professional environment like Apple is like committing some social faux pas that reveals suddenly to all the guests your poor and unsophisticated upbringing.
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?
I've never been a huge fan of Easter Eggs. From a risk management and QA point of view: there are a lot of things that can go wrong in a software project, why deliberately add something else not asked for, even if there was only a 1% probability that it would break? It just seems that the downside risk massively exceeds any potential upside. If something actually fails because of it and you have to write the postmortem, what are you going to say?
[dead]
The title as expected is bait. It’s a common situation in many companies where new hires are given authority with risks/consenquences and they overstep. They’re told not to do it again. That’s the gist of it. You’re welcome.
For everyone else - make sure your DB backups work. You’ll need them.