HN Reader

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).

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.

This is an example of classic software engineering. It's when the person writing the code understands why they're doing it, succeeds in that, then tastefully adds a little more, and has some fun, which in turn makes the product delightful.

Not to dismiss the importance of a strong Product lead, but often the role is a permanent stopgap for engineers who lack the talent and discipline demonstrated in this article. (Easter egg aside.)

I 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

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.

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...

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.

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.

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’m pretty sure the Gold Wing-riding, pipe-smoking boss is/was C.K. Haun

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.

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...

> 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.

Who is this Honda Goldwing riding (pipe clenched in his teeth) OS manager from Apple? I'd like to check out this YouTube channel.

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?

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.

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.

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 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.

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...

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).

> It’s an embarrassing thing when you realize that those irresponsible tendencies you had in your youth are still with you. To fuck up in a professional environment like Apple is like committing some social faux pas that reveals suddenly to all the guests your poor and unsophisticated upbringing.

Hard disagree. It reveals to management their own failings at setting expectations. Perhaps their heads were too far up their own asses to actually bother engaging with their team.

I know easter eggs are a tradition, but let's be honest. They're also a passive aggressive response to feeling bored and without a sense of direction. Why is that anyone's fault but management and ultimately the executives for yanking their attention away from actual work?

I've never been a huge fan of Easter Eggs. From a risk management and QA point of view: there are a lot of things that can go wrong in a software project, why deliberately add something else not asked for, even if there was only a 1% probability that it would break? It just seems that the downside risk massively exceeds any potential upside. If something actually fails because of it and you have to write the postmortem, what are you going to say?

Easter Eggs make products cool. Corporations are not.

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

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.