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.
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.
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.
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.
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.
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?
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.
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.)
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.
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?
> 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 became a cautionary tale though and would occasionally warn off the new hires who might have had an inkling to do something similar. And true to my word, I would tread very carefully from that day on with an eye to what Apple HQ would think about any of my actions — and potential consequences (intended or not).
And that is probably the day the culture died a bit. Hearing that tale, I'd stick to the specification every time. And get an email trail.
The November '97 issue of MacAddict (#15) lists a couple of the crayon picker easter eggs, though the one with engineers' names was only found with ResEdit.
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).
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.
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.
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.
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!
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 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.
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.
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.
44 comments
[ 2.5 ms ] story [ 34.8 ms ] threadFor everyone else - make sure your DB backups work. You’ll need them.
I heard once about a mechanical engineer who brought printed photos of his previous projects to the interview instead of a typed resume, to good results. Once you’ve had to interview someone, you realize many times the interviewer is as nervous as the interviewee, so breaking the ice is valuable.
https://engineersneedart.com/blog/interview/interview.html
I 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.
IMHO, this is an optimal resolution and should be applauded. Management reaped a 20-year reward and the author kept his job.
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...
I can't recall the "Hey what?" though.
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.)
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.
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?
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.
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).
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.
An employee being manipulated into loyalty and servitude through guilt. This seems fucked up...
https://www.engineersneedart.com/blog/almostfired/HSL_RGB_Pi...
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?
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.
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.
[1] https://en.wikipedia.org/wiki/Bright-line_rule