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).
Work long enough and a person will screw up. That's how things go. And if you never screw up, then you're not really pushing yourself. Personally, I've deleted customer tables, updated the whole table when meaning to update one record, even shipped our private key once. There are probably even more I can't remember, and others from people that I helped fix (one time a boss locked us all out of the db - only fix was restoring lol) In all cases I became a better engineer by owning the mistake quickly, fixing the issue, and then putting processes in place to avoid it in the future. I think it shaped who I was to be a better engineer, manager, and owner.
The only time I've seen people fired on the spot is when they lie. After seeing someone fired, I asked one of the owners at an old company I worked at why that was the line. He responded that even the best performers make mistakes, but if he couldn't trust someone, he couldn't work with them. This was many years ago, and as I've grown in my career I have found it to be a pretty good line to draw.
> A young executive had made some bad decisions that cost the company several million dollars. He was summoned to Watson’s office, fully expecting to be dismissed. As he entered the office, the young executive said, “I suppose after that set of mistakes you will want to fire me.” Watson was said to have replied,
> “Not at all, young man, we have just spent a couple of million dollars educating you.” [1]
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.
Depending on which country, there still are mechanisms in place to fire people for what's called "culpable reasons" where I live, but there's a mandated layoff period (15 days here) after being fired to leaving the company. You get paid a certain fraction of what you'd otherwise be paid during that period and so on.
So yes, they can fire you if you (maliciously) screw up, but it's not like they just escort you out of the building on the spot.
Egregious cases can lead to immediate dismissal, you also don't have to let anyone continue working even if you still pay them if they are on the notice period (the notice period is for both sides, honestly - for employer to have chance to find/train replacement, and for let gone employee to find new work).
There's a bunch of cases that can lead to immediate dismissal though in most EU countries, starting with illegal activity, some things that are borderline (disallowed in law even if sometimes tolerated by employer - for example being drunk on the job or otherwise under influence by ones own action, not accident), or explicit action against the company.
> 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
I’ve done some volunteer mentoring for a while. Fear of getting fired for small things is very widespread among younger generations right now. As far as I can tell, some of them build their mental model of the office from a combination of movies, Reddit posts, TikTok rage bait, and stories on social media. They’re so convinced that every corporation is an evil entity set on destroying their lives that small mistakes are catastrophized into career-ending moves.
The saddest part is when they make a small mistake and then let it snowball into lies and manipulation to cover it up. In the program I’m familiar with I don’t recall any stories of people being fired for singular honest mistakes, but there have been plenty of stories shared where people made a mistake and then caused far more problems by lying about it or even doing things like trying to attack and discredit people who witnessed the mistake as a defensive measure.
A large part of it stems from layoff culture. None of us know if this is going to be the last day at work. Is it rational? No, layoffs typically hit randomly and with little predictability, but that's not salve to those who worry about their jobs
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.
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.
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.
That's the rationale, but most of the firings of fast food workers I've seen are not related to hygiene but rather due to scheduling and attendance issues. And very often because of management lack of planning.
It is not that easy, actually. There is remote possibility for it to happen, but it is not likely nor easy. You need to break quite a few rules and also be very unlucky too.
I've made my fair share of mistakes at my current employer. Took down business critical infrastructure, dropped productions tables, accidently placing test orders for clients and not getting them cancelled quick enough
Not once have I ever been reprimanded for my actions (Out side of being the butt of a few jokes and having to write a few "sorry" emails), they aren't something to be proud off but I'm definitely a better developer now because of these mistakes.
Mistakes happen, that's life, important thing is how you deal with the issues.
After dropping the production table, I had the fun job of restoring the backups and then having to scour through logs to rebuild any missing information between the last back up and the incident. I have never felt anywhere near as sick in my life, that was a fun Monday.
When I dropped the table and realised what I had done I went to my boss with my tail between my legs and just said "I fucked up", he didn't get angry and just said well get to work fixing it and so I did.
You're not really a sysadmin until you take down prod and not really a network engineer until you cut off your arm (drop a router connect with no way back in) or cause an STP storm. I'm sure there are more examples...
The joys of learning how tech works in the real world.
in one of my first jobs we used to call that "the kalidas problem", after an old indian legend about the great playwright kalidas being a fool in his youth, and cutting off the branch of a tree while sitting on it. https://www.indiaparenting.com/the-legend-of-kalidas.html
My team is in charge of infrastructure so most of us do everything. Sometimes I get to take down prod AND cut myself off from the network in one move.
Why is every service on this site alerting? All I did was plug something in. Maybe that cable wasn't labelled correctly after all, proof is in the results.
This kind of thinking is super destructive too because you'll just panic, turtle, and stop communicating which makes it impossible to get anything done.
I made a somewhat similar blunder to the original poster at a job some years ago. I got a dressing down from the CEO and that's it, went back to work and never heard of it again. As far as I can tell it had no effect on my career at that company.
In the software engineering industry, what I have seen is people not afraid of being fired due to a mistake, but to be afraid of the cost of their mistake in their next performance review. Make two mistakes (not necessarily in a row) and you are putting yourself in a dangerous corner (e.g., you may be considered to be lay off in the next round of lay offs).
> 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.
While I agree in principle, in this particular example the author was a new-ish hire who included an easter egg for no particular reason, which included copyrighted content that required all the existing CD's to be destroyed.
Great share! What do they say, "You can't make an omelette without breaking eggs". I think people can go through life trying to never make mistakes and ultimately I think that just holds them back.
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.
This is also a much better way of handling the problem than OP's blunder on the article.
Berating in an office might teach one person. Not berating and admitting process failure in public can be educational for the whole company.
Reminds me of Gitlab's database deletion thing a few years ago. Not only they spent money educating the one engineer, by making the story public they also educated their other employees, and dare I say the whole industry. I still hear people referring to that story from time to time.
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.
Depending on the mistake it could also mean that they are more likely to make the same mistake. Especially after the memory of the event fades, they may regress to the old way they acted.
You may want to refresh yourself on the definition. Sunk cost is resources already spent, which cannot be recovered - the inability to recover it is what drives the reluctance in the case of the fallacy.
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.
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.
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 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.
Having worked in both situations (product person vs no product person), this reads like fiction to me.
Most PMs I worked were nowhere near being able to guide anyone, especially on B2B domains. I had to train a lot of them just to do basic follow up stuff, and honestly the vast majority was below expectation, and mostly just receiving requests from customers and giving opinions on designs.
And even in the best cases, an understanding of the product filtered by a product lead was nowhere near as good as actually having engineers who care, dogfood, talk with customers, read feedback, design solutions and verify them with end users.
IMO the concept of product leads, PMs, etc, is ok, but the implementation is always lacking. It's always a "creative type" that is stifling creativity of engineers while not really adding a lot of value.
I much prefer the concept of "Product Owner" of Scrum: someone that brings the tasks but isn't really dictating taste (except via feedback) or removing the creative part of engineering work.
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).
I have worked as an engineer on a product that didn't have a dedicated product lead and it was extremely hard to deliver new features without understanding the complex business side of things. Working without a dedicated product person to explain the business sounds hell to me.
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.
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.
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.
> "the product is simply too large for any one person to "fully" understand. Humans have a finite context window too."
Not personal towards you, but we're gonna wheel that one out again? Bullshit.
We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
> We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
Always was it so; the play remains the same, only the names are changed.
But that doesn't challenge the validity of what pjc50 wrote: literally nobody has time to count the transistors on a modern CPU (exceeds maximum human heartbeats), nor even the much easier task of skim the lines of code in say Windows 10 and the bundled drivers and apps.
We have division of labour because we need it, we have abstractions because we need them.
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.
As an embedded developer I do this regularly and encourage others to do the same. I bring a binder, each page has a large photo of a project or PCB and lists the core technologies involved.
I also bring a small case with a few previous projects from other jobs, ones that I can legally share outside an NDA, and a power supply.
It's been critically handy in some situations when I'm asked if I've worked with a certain technology, chip, protocol, etc. I can either flip to the page with a relevant project and start pointing (which also jogs my memory), or plug in the related device and fire it up. It definitely gets their attention and stands out.
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.
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.
Yes but they did illegal things that materially increased the value of the company, they didn't send employees off to mug people in alleys just for the fun of it.
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.
Wait, that is him? JKCalhoun? I probably should read more closely.
Jeez JKCalhoun is one of my favorite commenters on HN. He is very knowledgeable about Apple stuffs and I knew he probably worked in Apple for a long, long time just by reading his replies. He is one of the people that I look up to (i.e., when I don't feel burned out).
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.
It sounds like he thought it was fair use and their lawyers were less confident in that assessment. Technically at that point it's up to management about whether the cost of remastering / producing outweighs the EV of that easter egg, but they're not gonna be happy about having to make that tradeoff either way. And really, from stories 20 years ago with substantial adrenal and emotional impact, I figure the story is about the clearly recalled emotional beats than a technical analysis of costs.
Yeah. I see what you are saying. I think the reason I am embarrassed about it is not that I am averse to offending upper management (my corporate overlords) but that I offended on petty grounds. An Easter egg is kind of an ego thing and I think that is what was embarrassing.
The continued death of easter eggs is sad. I get it for certain classes (or scales) of software, but I still think there's a place for easter eggs that are small enough to be vetted as clean and security-conscious. Nothing says security-first principles can't be applied to the implementation of an easter egg that is internally proposed through a formal process, and documented where necessary for the customers who would care.
The loss of easter eggs is the loss of part of the "charm" of computing. A loss of a reminder that (For now) software is produced by humans, with emotion and love for the craft. I suppose that's changing with LLM assistants and vibe coding. Who will be the first to prompt a coding LLM to include an easter egg? It's probably already happened.
I remember that crayon picker very well! I was always intrigued that it had a slightly different visual style than the rest of the UI, but I would never have guessed it was created by the author of Glider.
In hindsight, this is a really well-designed UI. It's skeuomorphic in that it resembles physical crayons with some 3D shading; but at the same time has a flat layout -- the crayons are in a regular grid rather than a realistic 3D perspective. Good combination of attractive, clear and usable.
Having a zero Easter Egg policy is simply the only thing that makes sense, because there's no guarantee that something slipped in by an individual employee who thinks it's funny or tasteful... is actually funny or tasteful.
That’s why we love Easter eggs, they’re a sign that the software is built by a small enough team that those cover-your-ass processes haven’t been put in place.
As an indie dev, if users trust my taste enough to use my software, then I can follow my taste as well when it comes to Easter eggs.
And it’s why most attempts to do cutesy Easter egg style things by bigger companies tend to just sound lame and fall flat.
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!
It was flat, yet designed well in the sense that one can tell which things are clickable, which areas scrollable, etc. Contrary to many modern flat UIs that don't even show the scrollbar upfront so you just have to "feel" when something is scrollable or not, don't distinguish between links and buttons, and so on.
It also manages to give controls "breathing room", yet not waste too much space on margins and paddings.
> 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.
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.
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?
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).
I was a manager at Apple in 1990. It was very hard to be fired from Apple in those days, because they were very buttoned up about labor law. There were layers of corrective action you would have had to go through.
I left Apple in 1991 because they disbanded the testing department, sending a clear signal about not wanting there to be people who lived and breathed testing. I am probably the only person in that building who still has an active career as a tester, today.
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 think maybe we can introduce a law saying that any X% portion of poetry or book (e.g. 20% for poetry and maybe 200 words for a book) is in the public domain immediately following its publication IN ONE QUOTE.
But it probably introduces other complexities such as how to define one quote. Ah, wish we could advance from rule of lawyers to something better. What is it? I have no idea.
I took an IP law class in grad school. I asked the professor a question about making a more clear rule about how much is use of a copyrighted work is fair use or something along those lines. (I think I had some vague idea about using information theory to quantify it though I didn't say that.) The response was some argument against "bright-line rules" [1] like what I was proposing. I personally can see how bright-line rules can be bad in some contexts, but I don't think copyright is one of them. Legal clarity would be very helpful here in my view.
this story plus the one that jobs asked to end all Easter eggs, just show that this one guy was picked to serve as the example (because nobody would be reading memos, but water cooler talk about the guy who got a dress down would spread like wild fire)
interesting that management choose the guy that, by his own words on this post, took everything without complaining. and that to this day still believes he was the only one screwing up on weird Easter eggs at the time.
> 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.
I can't grasp your overall thesis here, except maybe some general notion that the world of software is one of class warfare?
That's definitely very arguable overall, but I don't think the specific points you make are correct.
Jim Carlton's book on Apple ("the inside story of intrigue, egomania and business blunders") is a great read. It feels a bit strange now as it was written in the period the OP talks about, when Apple was on death's door, rather than the world-striding colossus it is now. But I think it describes very vividly the environment where easter eggs like the OP describes were more common.
There were definitely plenty of bored, checked-out engineers -- often between projects with few responsibilities, or "on the beach" in Apple parlance. But those weren't the people shipping stuff. There were also engineers who loved Apple's products and culture (maybe to a dangerous, cult-like degree), who wanted to contribute and to add their personal stamp as a mark of pride.
There's nothing stopping someone who is checked out from still delivering what the business wants. This is especially true in a time period when the business may not want much for the reasons you and the article already stated.
You mean the classic easter eggs from the 70s and 80s? There were no corporate drones writing software back then. I learned to program in 1980 and have been doing it for a living since 1990.
Most programmers were enthusiasts working for themselves or for small companies. Microsoft was like 20 people including non technical staff? Apple was tiny too. They tended to be independent minded, anti establishment types, completely unlike today's crop of youth who spout hustle culture and corporate jargon. Go look at pictures of what teams at Apple, Microsoft, or Atari looked like. It was a very different time.
For comparison I guess look at the top scientists at OpenAI or something, do you think they're bored and disaffected while doing some of the most impactful work of their time?
> There were no corporate drones writing software back then
Sure, but there were a lot of army-of-one jackasses who were their own cult of personality equipped with their own brand of "jargon" that became what we have today. Does it really take so many years to deprogram a corporate drone who refuses to acknowledge that label?
I too worked at Apple during this period (Dec 95 to May 96). It does not surprise me that code was released without anyone asking or looking at it from a product standpoint. Management of Copland for example (the new OS from hell that was eventually canned, leading to the purchase of NeXT and the return of Jobs) was a complete utter shitshow, leading me to give up and quit (leading to me spending my life going d'oh).
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.
Dude I think the whole "we're going to fire you" thing is weird on Apple's part. Look at how good the color picker became once it became yours. A bunch of resource string names should not be a big deal.
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).
Work long enough and a person will screw up. That's how things go. And if you never screw up, then you're not really pushing yourself. Personally, I've deleted customer tables, updated the whole table when meaning to update one record, even shipped our private key once. There are probably even more I can't remember, and others from people that I helped fix (one time a boss locked us all out of the db - only fix was restoring lol) In all cases I became a better engineer by owning the mistake quickly, fixing the issue, and then putting processes in place to avoid it in the future. I think it shaped who I was to be a better engineer, manager, and owner.
The only time I've seen people fired on the spot is when they lie. After seeing someone fired, I asked one of the owners at an old company I worked at why that was the line. He responded that even the best performers make mistakes, but if he couldn't trust someone, he couldn't work with them. This was many years ago, and as I've grown in my career I have found it to be a pretty good line to draw.
> A young executive had made some bad decisions that cost the company several million dollars. He was summoned to Watson’s office, fully expecting to be dismissed. As he entered the office, the young executive said, “I suppose after that set of mistakes you will want to fire me.” Watson was said to have replied,
> “Not at all, young man, we have just spent a couple of million dollars educating you.” [1]
[1] http://the-happy-manager.com/articles/characteristic-of-lead...
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.
Depending on which country, there still are mechanisms in place to fire people for what's called "culpable reasons" where I live, but there's a mandated layoff period (15 days here) after being fired to leaving the company. You get paid a certain fraction of what you'd otherwise be paid during that period and so on.
So yes, they can fire you if you (maliciously) screw up, but it's not like they just escort you out of the building on the spot.
Egregious cases can lead to immediate dismissal, you also don't have to let anyone continue working even if you still pay them if they are on the notice period (the notice period is for both sides, honestly - for employer to have chance to find/train replacement, and for let gone employee to find new work).
There's a bunch of cases that can lead to immediate dismissal though in most EU countries, starting with illegal activity, some things that are borderline (disallowed in law even if sometimes tolerated by employer - for example being drunk on the job or otherwise under influence by ones own action, not accident), or explicit action against the company.
Yes, however those are quite critical scenarios and not firing someone because management feels like doing so.
> 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
I’ve done some volunteer mentoring for a while. Fear of getting fired for small things is very widespread among younger generations right now. As far as I can tell, some of them build their mental model of the office from a combination of movies, Reddit posts, TikTok rage bait, and stories on social media. They’re so convinced that every corporation is an evil entity set on destroying their lives that small mistakes are catastrophized into career-ending moves.
The saddest part is when they make a small mistake and then let it snowball into lies and manipulation to cover it up. In the program I’m familiar with I don’t recall any stories of people being fired for singular honest mistakes, but there have been plenty of stories shared where people made a mistake and then caused far more problems by lying about it or even doing things like trying to attack and discredit people who witnessed the mistake as a defensive measure.
A large part of it stems from layoff culture. None of us know if this is going to be the last day at work. Is it rational? No, layoffs typically hit randomly and with little predictability, but that's not salve to those who worry about their jobs
They've often only had part time jobs for small business owners, which is a situation more prone to getting fired for minor faults, or owner's whims.
I agree with your post in general, but let's not whitewash corpos.
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.
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.
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.
That's the rationale, but most of the firings of fast food workers I've seen are not related to hygiene but rather due to scheduling and attendance issues. And very often because of management lack of planning.
It is not that easy, actually. There is remote possibility for it to happen, but it is not likely nor easy. You need to break quite a few rules and also be very unlucky too.
I've made my fair share of mistakes at my current employer. Took down business critical infrastructure, dropped productions tables, accidently placing test orders for clients and not getting them cancelled quick enough
Not once have I ever been reprimanded for my actions (Out side of being the butt of a few jokes and having to write a few "sorry" emails), they aren't something to be proud off but I'm definitely a better developer now because of these mistakes.
Mistakes happen, that's life, important thing is how you deal with the issues.
After dropping the production table, I had the fun job of restoring the backups and then having to scour through logs to rebuild any missing information between the last back up and the incident. I have never felt anywhere near as sick in my life, that was a fun Monday.
When I dropped the table and realised what I had done I went to my boss with my tail between my legs and just said "I fucked up", he didn't get angry and just said well get to work fixing it and so I did.
You're not really a sysadmin until you take down prod and not really a network engineer until you cut off your arm (drop a router connect with no way back in) or cause an STP storm. I'm sure there are more examples...
The joys of learning how tech works in the real world.
> cut off your arm
in one of my first jobs we used to call that "the kalidas problem", after an old indian legend about the great playwright kalidas being a fool in his youth, and cutting off the branch of a tree while sitting on it. https://www.indiaparenting.com/the-legend-of-kalidas.html
My team is in charge of infrastructure so most of us do everything. Sometimes I get to take down prod AND cut myself off from the network in one move.
Why is every service on this site alerting? All I did was plug something in. Maybe that cable wasn't labelled correctly after all, proof is in the results.
This kind of thinking is super destructive too because you'll just panic, turtle, and stop communicating which makes it impossible to get anything done.
I made a somewhat similar blunder to the original poster at a job some years ago. I got a dressing down from the CEO and that's it, went back to work and never heard of it again. As far as I can tell it had no effect on my career at that company.
In the software engineering industry, what I have seen is people not afraid of being fired due to a mistake, but to be afraid of the cost of their mistake in their next performance review. Make two mistakes (not necessarily in a row) and you are putting yourself in a dangerous corner (e.g., you may be considered to be lay off in the next round of lay offs).
So, actions have consequences, you say?
> 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.
While I agree in principle, in this particular example the author was a new-ish hire who included an easter egg for no particular reason, which included copyrighted content that required all the existing CD's to be destroyed.
... in a company that had a culture of easter eggs. the context is relevant.
Great share! What do they say, "You can't make an omelette without breaking eggs". I think people can go through life trying to never make mistakes and ultimately I think that just holds them back.
Only those who will risk going too far can possibly find out how far one can go. -T. S. Eliot
People who actually do things make mistakes. It's the ones who never screw-up you should scrutinize.
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.
[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.
This is also a much better way of handling the problem than OP's blunder on the article.
Berating in an office might teach one person. Not berating and admitting process failure in public can be educational for the whole company.
Reminds me of Gitlab's database deletion thing a few years ago. Not only they spent money educating the one engineer, by making the story public they also educated their other employees, and dare I say the whole industry. I still hear people referring to that story from time to time.
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...
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.
Depending on the mistake it could also mean that they are more likely to make the same mistake. Especially after the memory of the event fades, they may regress to the old way they acted.
"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...
You may want to refresh yourself on the definition. Sunk cost is resources already spent, which cannot be recovered - the inability to recover it is what drives the reluctance in the case of the fallacy.
If considered an "investment" (will produce value if retained) it's not a sunk cost.
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.
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.
I think you're missing a key point here.
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.
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".
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.
Having worked in both situations (product person vs no product person), this reads like fiction to me.
Most PMs I worked were nowhere near being able to guide anyone, especially on B2B domains. I had to train a lot of them just to do basic follow up stuff, and honestly the vast majority was below expectation, and mostly just receiving requests from customers and giving opinions on designs.
And even in the best cases, an understanding of the product filtered by a product lead was nowhere near as good as actually having engineers who care, dogfood, talk with customers, read feedback, design solutions and verify them with end users.
IMO the concept of product leads, PMs, etc, is ok, but the implementation is always lacking. It's always a "creative type" that is stifling creativity of engineers while not really adding a lot of value.
I much prefer the concept of "Product Owner" of Scrum: someone that brings the tasks but isn't really dictating taste (except via feedback) or removing the creative part of engineering work.
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).
I have worked as an engineer on a product that didn't have a dedicated product lead and it was extremely hard to deliver new features without understanding the complex business side of things. Working without a dedicated product person to explain the business sounds hell to me.
The argument here is that we should shouldn't isolate engineers and dismiss them mere thing-doers.
Having someone to discuss the business with engineers is important, that's clearly not the thing being criticised here.
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.
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.
Unions and worker-owned co-ops are the way out of corporate exploitation and layoff hell.
This is the result of advice being rejected too many times (and later turning out to have been correct).
Probably someone who burned out and found the work not enjoyable. I wouldn't blame him as long as he delivers.
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.
> "the product is simply too large for any one person to "fully" understand. Humans have a finite context window too."
Not personal towards you, but we're gonna wheel that one out again? Bullshit.
We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
> We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.
Always was it so; the play remains the same, only the names are changed.
But that doesn't challenge the validity of what pjc50 wrote: literally nobody has time to count the transistors on a modern CPU (exceeds maximum human heartbeats), nor even the much easier task of skim the lines of code in say Windows 10 and the bundled drivers and apps.
We have division of labour because we need it, we have abstractions because we need them.
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
As an embedded developer I do this regularly and encourage others to do the same. I bring a binder, each page has a large photo of a project or PCB and lists the core technologies involved.
I also bring a small case with a few previous projects from other jobs, ones that I can legally share outside an NDA, and a power supply.
It's been critically handy in some situations when I'm asked if I've worked with a certain technology, chip, protocol, etc. I can either flip to the page with a relevant project and start pointing (which also jogs my memory), or plug in the related device and fire it up. It definitely gets their attention and stands out.
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.
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.
Selection bias. Lots of other companies did borderline illegal or fully illegal things and they are gone: https://en.wikipedia.org/wiki/List_of_corporate_collapses_an... (although many of these are incompetence collapses).
Yes but they did illegal things that materially increased the value of the company, they didn't send employees off to mug people in alleys just for the fun of it.
Neither is stopping the presses for every little thing.
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!
Wait, that is him? JKCalhoun? I probably should read more closely.
Jeez JKCalhoun is one of my favorite commenters on HN. He is very knowledgeable about Apple stuffs and I knew he probably worked in Apple for a long, long time just by reading his replies. He is one of the people that I look up to (i.e., when I don't feel burned out).
Sheherazade, definitely me from my "The Tale of the 1001 Arabian Nights" period.
I can't recall the "Hey what?" though.
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.
Never forget, Sagan sued them again over "BHA"
> 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.
It sounds like he thought it was fair use and their lawyers were less confident in that assessment. Technically at that point it's up to management about whether the cost of remastering / producing outweighs the EV of that easter egg, but they're not gonna be happy about having to make that tradeoff either way. And really, from stories 20 years ago with substantial adrenal and emotional impact, I figure the story is about the clearly recalled emotional beats than a technical analysis of costs.
I honestly don't know to this day if they had to scrap a run. Certainly there was the potential though.
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
Yeah. I see what you are saying. I think the reason I am embarrassed about it is not that I am averse to offending upper management (my corporate overlords) but that I offended on petty grounds. An Easter egg is kind of an ego thing and I think that is what was embarrassing.
The continued death of easter eggs is sad. I get it for certain classes (or scales) of software, but I still think there's a place for easter eggs that are small enough to be vetted as clean and security-conscious. Nothing says security-first principles can't be applied to the implementation of an easter egg that is internally proposed through a formal process, and documented where necessary for the customers who would care.
The loss of easter eggs is the loss of part of the "charm" of computing. A loss of a reminder that (For now) software is produced by humans, with emotion and love for the craft. I suppose that's changing with LLM assistants and vibe coding. Who will be the first to prompt a coding LLM to include an easter egg? It's probably already happened.
I remember that crayon picker very well! I was always intrigued that it had a slightly different visual style than the rest of the UI, but I would never have guessed it was created by the author of Glider.
In hindsight, this is a really well-designed UI. It's skeuomorphic in that it resembles physical crayons with some 3D shading; but at the same time has a flat layout -- the crayons are in a regular grid rather than a realistic 3D perspective. Good combination of attractive, clear and usable.
Having a zero Easter Egg policy is simply the only thing that makes sense, because there's no guarantee that something slipped in by an individual employee who thinks it's funny or tasteful... is actually funny or tasteful.
That’s why we love Easter eggs, they’re a sign that the software is built by a small enough team that those cover-your-ass processes haven’t been put in place.
As an indie dev, if users trust my taste enough to use my software, then I can follow my taste as well when it comes to Easter eggs.
And it’s why most attempts to do cutesy Easter egg style things by bigger companies tend to just sound lame and fall flat.
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...
It was flat, yet designed well in the sense that one can tell which things are clickable, which areas scrollable, etc. Contrary to many modern flat UIs that don't even show the scrollbar upfront so you just have to "feel" when something is scrollable or not, don't distinguish between links and buttons, and so on.
It also manages to give controls "breathing room", yet not waste too much space on margins and paddings.
Those were days too old to be good.
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 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.
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 can't say. I am decades removed now from responsibility for that component. (And retired as well.)
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).
I was a manager at Apple in 1990. It was very hard to be fired from Apple in those days, because they were very buttoned up about labor law. There were layers of corrective action you would have had to go through.
I left Apple in 1991 because they disbanded the testing department, sending a clear signal about not wanting there to be people who lived and breathed testing. I am probably the only person in that building who still has an active career as a tester, today.
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 think maybe we can introduce a law saying that any X% portion of poetry or book (e.g. 20% for poetry and maybe 200 words for a book) is in the public domain immediately following its publication IN ONE QUOTE.
But it probably introduces other complexities such as how to define one quote. Ah, wish we could advance from rule of lawyers to something better. What is it? I have no idea.
I took an IP law class in grad school. I asked the professor a question about making a more clear rule about how much is use of a copyrighted work is fair use or something along those lines. (I think I had some vague idea about using information theory to quantify it though I didn't say that.) The response was some argument against "bright-line rules" [1] like what I was proposing. I personally can see how bright-line rules can be bad in some contexts, but I don't think copyright is one of them. Legal clarity would be very helpful here in my view.
[1] https://en.wikipedia.org/wiki/Bright-line_rule
That would upend the entire copyright-royalty framework under which modern music sampling exists (since lyrics are one thing to be sampled).
I'm NOT saying whether that's good or bad - but those benefitting from status quo would vigorously oppose it.
I hear being unfortunate enough to be in an elevator with Steve Jobs was enough to get you fired from Apple back in the day.
I want to read more work stories of retired engineers and designers.
this story plus the one that jobs asked to end all Easter eggs, just show that this one guy was picked to serve as the example (because nobody would be reading memos, but water cooler talk about the guy who got a dress down would spread like wild fire)
interesting that management choose the guy that, by his own words on this post, took everything without complaining. and that to this day still believes he was the only one screwing up on weird Easter eggs at the time.
FWIW, Jobs wasn't with Apple at the time of this story (1995)
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...
> 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?
Thanks. I am surprised though at how many of the responses here are critical of my feeling guilty. Kind of back-handed insults? :-)
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 can't grasp your overall thesis here, except maybe some general notion that the world of software is one of class warfare?
That's definitely very arguable overall, but I don't think the specific points you make are correct.
Jim Carlton's book on Apple ("the inside story of intrigue, egomania and business blunders") is a great read. It feels a bit strange now as it was written in the period the OP talks about, when Apple was on death's door, rather than the world-striding colossus it is now. But I think it describes very vividly the environment where easter eggs like the OP describes were more common.
There were definitely plenty of bored, checked-out engineers -- often between projects with few responsibilities, or "on the beach" in Apple parlance. But those weren't the people shipping stuff. There were also engineers who loved Apple's products and culture (maybe to a dangerous, cult-like degree), who wanted to contribute and to add their personal stamp as a mark of pride.
> those weren't the people shipping stuff
I find this very hard to believe.
There's nothing stopping someone who is checked out from still delivering what the business wants. This is especially true in a time period when the business may not want much for the reasons you and the article already stated.
You mean the classic easter eggs from the 70s and 80s? There were no corporate drones writing software back then. I learned to program in 1980 and have been doing it for a living since 1990.
Most programmers were enthusiasts working for themselves or for small companies. Microsoft was like 20 people including non technical staff? Apple was tiny too. They tended to be independent minded, anti establishment types, completely unlike today's crop of youth who spout hustle culture and corporate jargon. Go look at pictures of what teams at Apple, Microsoft, or Atari looked like. It was a very different time.
For comparison I guess look at the top scientists at OpenAI or something, do you think they're bored and disaffected while doing some of the most impactful work of their time?
> There were no corporate drones writing software back then
Sure, but there were a lot of army-of-one jackasses who were their own cult of personality equipped with their own brand of "jargon" that became what we have today. Does it really take so many years to deprogram a corporate drone who refuses to acknowledge that label?
Sometimes it's not secret at all. I've long wondered who Seetharaman Narayanan is.
Easter Eggs make products cool. Corporations are not.
I too worked at Apple during this period (Dec 95 to May 96). It does not surprise me that code was released without anyone asking or looking at it from a product standpoint. Management of Copland for example (the new OS from hell that was eventually canned, leading to the purchase of NeXT and the return of Jobs) was a complete utter shitshow, leading me to give up and quit (leading to me spending my life going d'oh).
Everyone that bought even a share of AAPL and sold before … last year … is going d'oh.
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.
some of us have a soul
some of us need a way to express ourselves
why not start digging your grave right now? it’s more efficient.
“someone added an Easter Egg”
Dude I think the whole "we're going to fire you" thing is weird on Apple's part. Look at how good the color picker became once it became yours. A bunch of resource string names should not be a big deal.
intresting info
[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.