The first time I was almost fired from Apple
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).
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.
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.
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.
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.
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.
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.
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.
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.
The joys of learning how tech works in the real world.
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.
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...
I became a cautionary tale though and would occasionally
warn off the new hires who might have had an inkling to do
something similar. And true to my word, I would tread very
carefully from that day on with an eye to what Apple HQ
would think about any of my actions — and potential
consequences (intended or not).
IMHO, this is an optimal resolution and should be applauded. Management reaped a 20-year reward and the author kept his job.
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.
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).
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.
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.
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 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.)
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.
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.
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.
Not to dismiss the importance of a strong Product lead, but often the role is a permanent stopgap for engineers who lack the talent and discipline demonstrated in this article. (Easter egg aside.)
This is politics baked into the heirarchy, not a lack of "talent and discipline".
I 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).
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 had devs who told me they don’t care about product features. "Just tell me what to do, it’s my job to implement."
No more extra miles, not a single one.
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.
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?
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.
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.
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.
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 think it would have been an overreaction to fire him, but it was absolutely within the realm of plausible outcomes.
sued Apple the prior year for merely using his name as a project codename
This just highlights the fact that you can be sued for anything. For example, you could be sued for the same thing (even though CDs were destroyed) based on information from this blog.
They're wondered why they weren't fired, when their prank had no negative side effects 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.
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.
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.
The versions of these color pickers that were included in builds of Copland contain the strings "Hey what?" (for the HSL picker) and "Scheherazade" (for the crayon picker). Might those have been some of yours?
https://rezmason.net/chattin_with_jkcalhoun/copland_colorpic...
Hats off to you, Mr. Calhoun!
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).
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 need a way to express ourselves
why not start digging your grave right now? it’s more efficient.
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.
[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.
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.
https://www.engineersneedart.com/blog/almostfired/HSL_RGB_Pi...
It also manages to give controls "breathing room", yet not waste too much space on margins and paddings.
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.
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...
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 heard once about a mechanical engineer who brought printed photos of his previous projects to the interview instead of a typed resume, to good results. Once you’ve had to interview someone, you realize many times the interviewer is as nervous as the interviewee, so breaking the ice is valuable.
I 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.
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.
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.
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.
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.
For everyone else - make sure your DB backups work. You’ll need them.
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.