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.
Your point aside, that particular example is not the best since it's a lot easier to quickly land a customer in the hospital as a random fast food worker than as a random software engineer.
The expense and time required to hire a well-paid, highly qualified engineer is much bigger than to hire someone to do a burger-flipping job. Firing is writing off these expenses.
In most European countries it is certainly hard to fire people on a whim like in US and countries with similar weak labour laws.
I have seen often enough puzzled looks from team managers from such countries, when leeding European teams for the first time, and routinely get a NO for whatever crazy requests they happen to do.
> 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
I've seen this misconception perpetuated by management even in countries with very strong worker protection laws. Works particularly great on people who already have strong work ethics and internal fears, it stokes that fire. Employees would work as if any failure could lead to termination, especially in emergencies. Those managers use this as a "motivational" tool (as much as a hammer to the face can motivate you). They can squeeze more results out of their teams and maybe edge out a promotion.
It's illuminating to see when the people understand the pressure is many times fake, that even the internal SLAs are more relaxed than what they fear.
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).
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.
[flagged]
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.
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).
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.
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.
Also, there was at least one scientific graphics package from the late 1980s (I used it under BSD4.3 on microvaxen[0]) that not only had a crayon-based color picker, but used it for a simple calibration mechanism, since you could just buy a cheap box of crayons and adjust the screen colors to match. So there was at least one contemporary existence proof of "Crayola probably isn't going to go after you for this".
[0] I've forgotten the name; the main thing I remember is that your window was dimensioned in 0.0-1.0 floating point, not pixels. Some searching suggests it might have been PHIGS or GKS... and turns up a Tugboat article about FoilTeX using crayola color names similarly in 1992, so it was a more popular hack than I realized at the time.
We used to have to physically fly out a technician to each of our customers office to install software updates and fixes. Those bugs were very expensive to patch!
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".
I think that's far too cynical.
Usually what you end up with is a "three blind men and the elephant" situation; the product is simply too large for any one person to "fully" understand. Humans have a finite context window too.
So ending up with a product manager who is standing far enough away to see the whole elephant, but not in detail, while the engineers have detailed views of their part of the product but not the whole thing, is a reasonable position.
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.
I completely disagree, but your experience may vary. I am not trying to take away from that.
I am merely saying that maybe there should be a stronger discussion than just dismissing engineers as mere "thing-doers". I also accept that there are many people here who are exactly that, and I and they should find it shameful.
We can't control that, but maybe we should try harder to do instead of being lazy and assuming market forces are the boss... maybe we are the boss (we are).
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).
In the days of the rampant layoff culture, where your competence, experience, or output quality no longer matters because someone sorted an Excel spreadsheet in a particular way and had you at the bottom 10% — it should be a miracle when companies are getting this much.
No more extra miles, not a single one.
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.
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.
An accurate representation of corporate legal's general attitude, yeah... just say no to any request because that covers your ass.
Neither is stopping the presses for every little thing.
Legal troubles are exactly why you have a legal team. Uber didn't ask for permission, neither did OpenAI. Now they're worth billions. Microsoft and Apple do their own fairshare of probably borderline illegal things too.
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!
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
What could possibly be more threatening, especially in a time of dire straits for a business, than a "lowly dev" who has an opinion and has visions of more and better?
Let's get real.
Who is more directly in charge and knowledgeable of a product result than a developer? If you are not heads-down and working than you are (intentionally or not) misrepresenting your product and a fool. This has always been true and nobody knows it better than the investors. Do you think we're stupid?
>This has always been true and nobody knows it better than the investors. You think we're stupid?
Erm, ehh... n-nooo...
Yes.. y-y-yessss
This world is in the shitter and for what?
Far too many people with their mouths "occupied" to see things for what they are and say it. Don't make me say this in a more vulgar way.
Do you seriously think that people are investing in "AI" because they think AGI is just around the corner? Fuck no! They invest because everyone else does and they think they can time the market (and many reading this right now probably will).
Tangent, but for all we whinge about flat UIs and pine for the bezelled good old days, that colour picker from the oldest good old days is really bloody flat!
https://www.engineersneedart.com/blog/almostfired/HSL_RGB_Pi...
Question for OP: can you explain why the colour picker component takes so long to load in MacOS? There’s a noticeable delay of 1000-2000ms every time I click a button that brings it up.
> 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
Who is this Honda Goldwing riding (pipe clenched in his teeth) OS manager from Apple? I'd like to check out this YouTube channel.
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 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.
I want to read more work stories of retired engineers and designers.
> 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?
They're also a passive aggressive response to feeling bored and without a sense of direction.
That's a very pessimistic view! You don't think they can also sometimes be a sign of pride and investment in your work? Especially the ones that involve showing the names of the developers when you press a secret key.
Nope, I see it as accurate once younger people take off their rose-colored glasses of a time they never lived in.
I hope someone from the past reads this and confirms. If there was ever a time for them to be real, it's now.
I do agree that pride despite everything else is a factor, but let's not pretend like the past embraced that beyond trying to "team build" or whatever vague and ineffective nonsense.
"Buy the ticket, take the ride."
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?
I started at Apple a few years after the original author, and by then the policy on Easter Eggs was that they were allowed within reason, but had to be declared internally, so they could be tested. There were even "official" Easter Eggs that listed all the engineers in the team.
There were lots of Easter Eggs in Apple products: https://www.mackido.com/EasterEggs/
I believe they were prohibited (at least officially) starting with Mac OS X.
In addition to genuine Easter Eggs, there were numerous instances of "products with attitude". One good example are some of the error messages that MPW C produced: https://www.cs.cmu.edu/~jasonh/personal/humor/compile.html
I snuck what technically might be a copyright violation into the EXAMPLES section of the say(1) manpage.
“someone added an Easter Egg”
[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.
