I know little about Apple, but have quite a bit of experience with how software products get "designed". Goofy and offensive things happen when corporations decide not to pay attention to customers.

The decision to ignore customer and focus on market wow is not the software design team. It is a systemic and structural thing.

Weird sentence given that three staunch supporters of liquid glass are still in that team, including Lemay. I highly doubt it's going anywhere, hopefully it gets a few more improvements before it will be replaced for The New Thing in MacOS 29.

There are lots of things (well, in iOS) that I think are a big improvement, like menus spawning from the button you tapped instead of a bottom sheet popping up from the bottom of the screen. And the nested list menus are very nice.

But completely eradicating toolbars and replacing them with a fade that still doesn't allow buttons legible in all cases was clearly a mistake. And it's something they're backtracking on!

I have two favorite bug stoies. The first is from a printout from the run of an IBM 360 assembly language program when I was just learning. Someone asked em why their program failed to run. I glanced quickly at the front page of the printout and it said "Too Long". So I told the person that was the problem. Something was too long. He looked at me very strangely, so I looked back at the page a little more closely, only to notice "Too Long" was in the name field of the person running the program. He was Vietnamese and his name was Too Long - literally. There is a powerful lesson (at least one) there.

The other happened when I was implementing some AppleTalk protocols - NBP to be exact. (Don't ask). I would capture the working packets then compare all the checksums, headers, constants, length fields in the packet my code generated and fix any problems. I was stuck on one failure. I just could not see any difference as I went through byte by byte, time after time. It was late and time to go home so I decided to print off each packet on paper and compare them later - certain I was missing something. The problem was instantly obvious. One printout took a page, the two pages. I had been appending junk data in the packet. Sigh

I wouldn't have a clue how to recall any details about the bugs I've seen. I don't put much emphasis on past events. Looking forward is what I find to be a far more valuable use of my mental energy. I have vague recollections of debugging some doozies, but that is where the recall ends. It is clearly something you are passionate about, which no doubt keeps it something front of mind for you, but for many of it is just part of the job; like asking someone at McDonald's how their favourite burger flip landed.

You could say that I'm not the one of the for the job, which is a fair take, but if we reason through this some more, would we not conclude that there is no such thing as a good canned interview question? Given that no two people are the same, good interview questions can only be established in the context of who is being interviewed.

Remembering and being able to tell the narrative about how I figured out why something that people like to do is a really bad idea is very helpful to convince people not to repeat the mistakes of the past when they aren't receptive to "trust me, this is a bad idea and we shouldn't do it" or "if you do that, let me know when you undo it, otherwise don't call me"

Personally, I don't have any skill at giving this kind of story time interview question, so I don't. But it does seem concerning to me if someone has 5-10 years of software experience and can't articulate any debugging stories. How were you working where you never ran into a problem that took you/your team 2 weeks of pain to figure out?

Whereas with directing my attention to looking forward to the future I don't see the same issues turn up ever again. I learn from my mistakes. Now that I am multiple decades into my career, I see almost no bugs turn up at all. That doesn't mean I will never encounter a bug again. It is inevitable that I will. But they will be novel when I do. Novel still doesn't mean particularly interesting, however. The burger flip landing a new way never seen before still isn't likely to register.

> it does seem concerning to me if someone has 5-10 years of software experience

Is that where you are at in your software career? I can attest that I saw a lot more bugs when in I was in that stage. One is still quite green and learning a tremendous amount even 5-10 years in. However, that was a long time ago. I've forgotten the details by now. This tune might change for you as well as you progress further.

Or maybe not. Everyone is different. You do seem passionate about bugs. I, on the other hand, hate them, so I lean heavily into processes to avoid them to the greatest extent possible.

So I have to debug other people's libraries and operating systems. And other people's networks. Turns out other people often make similar mistakes. Some people say 'select isn't broken', but lots of things are[1]. Most of my debugging stories would tend to be centered around a problem that my team found/uncovered, not one that we created... although certainly I did make some bugs in my youth (definitely none lately!).

I put 5-10 years there because someone under 5 years of experience could maybe not have ever run into a troublesome issue, or they always had a senior to do the hard stuff. Between 5 and 10 years, maybe they find their first tricky bug. After 10+ years, you've got to have run into something.

[1] Here's some war stories:

I fixed an interop issue between OpenSSL and Microsoft schannel where rsa dhe would fail if the generated public key had leading zeros; OpenSSL would encode it in fewer bytes and schannel would return 'out of memory'. The RFC was vague. People had observed the failures for years, but I had to fix it. At the time, it was considered a reasonable optimization to generate a dhe keypair and reuse it for the lifetime of the server process... If we generated a problematic keypair on a given server, windows clients couldn't connect at all. Now, if I run into an issue and a working trace has structures of nice power of 2 lengths and a broken trace has one a little smaller, that's where I dig.

I found (but didn't make a patch) a bug in Firefox where POSTs to an http/2 server with tls 1.3 early data enabled would stall for about a minute when there was no connection to reuse. Fixing it was out of my league, but I was able to get it fixed by giving a clear bug report. This one was fairly new when I saw it, but there was a much less clear bug open against Thunderbird caused by the underlying issue. Not sure what I learned here really other than if you're expecting data sent to the network and it doesn't happen, it's usually an application problem... and clear bugs with clear logs help get things fixed.

I fixed an issue with FreeBSD where it would send the whole sendq when it received an icmp needs frag message, even when the maximum mtu sent in the icmp was the same as or greater than the current path mtu. This was happening when a Linux router was using large receive offload to aggregate inbound packets on a flow and then they were too large to forward; that bug was fixed long before I experienced it, but the router in question never got updated. I could not get ahold of the operator for them to fix the broken machine, but I was able to get a patch into FreeBSD so that the broken router(s) only impacted our customers that were behind it. ... this is another indication that PathMTU is hard, but also it helped me tune methods of sampling packets from production. PS, pathmtu issues are their own repetitive problem space.

That one time FreeBSD broke syncookies, so connections got reformed after close, and the tcp state was unsynchronizable between peers so they kept sending challenge acks... and IIRC, they broke it a second time, too. But maybe it was just we ran into it in a different context.

I've recently found some issues leading to out of order packet delivery with FreeBSD's dummynet traffic shaping; again, other people already experienced it, but nobody wrote a good bug report or submitted a patch, so I guess I'll have to do it, if it's still broken when I have time for it. This one is probably not going to be a repeating bug... not a lot of traffic shapers, but maybe there will be something learned about scheduling i/o

What processes could I use to avoid bugs like these? Hoping things magically get fixed in an update does sometimes work, and sometimes the bug becomes less relevant as the industry moves on (ecdhe has almost completely replaced rsadhe, but it hadn't at the time that my customers ran into the bug).

Been there, but then I soon learned to reduce dependencies to essentially none. Those that do make the cut need to be of high quality such that the authors of those libraries are also as perfect as you are. There is absolutely no need to depend on code written by those with <=10 years under their belt. The world is full of developers with 20+ years of experience.

> After 10+ years, you've got to have run into something.

Sure. And after 10+ years of flipping burgers, there will have been some pretty sweet lands. Who is going to remember, though? It is fine if you do. Everyone has their thing. But I'd say it is not exactly among the most memorable of events. It is not like time spent with your child, or something that actually has some kind of meaning. You even say you are semi-retired, so you must agree that things on the job don't really matter. If it did, why not dedicate every possible moment to it?

It has always been normal for certain fruits and vegetables, such as apples, pears, potatoes, etc. to be stored for months in a cellar. In the old days, you simple could not get a fresh apple outside harvest time.

Your concept of "dead food vs live food" seems rather questionable.

If anything the modern cold chain and globalized food supply and just the abundance of food in general means we have more access to fresh food than our ancestors even though they farmed and we mostly don't.

Mainly because the distinction you are making doesn't actually exist.

An apple doesn't "lose" anything by being stored. There are no preservatives, just refrigeration. The apple will proceed to go bad just as quickly once taken out of storage, and it will be just as nutritious as if you had eaten that same apple fresh off the tree.

You can also take that same apple that's been in storage for a year, press the juice out of it, put a culture in it, and it too will grow and be filled with living cultures. The year-stored apple is no less "living" than the milk that you also had to inoculate to turn to yogurt.

In fact, the list of edible things that will not be filled with living cultures, hours after you add a culture to them and then keep them warm for 10 hours, is very short.

"It's not at absolute zero, therefore there's some chemical process going on, therefore we don't know if it's causing significant portions of cancer"?

The number of things you can say that about is frankly infinite. You have zero reason to believe that any of the "chemical processes" that happen to an apple (or any food) in long term storage have anything to do with cancer.

This is a great example of correlation not equaling causation. You might as well say that writing years starting with a "2" could cause particular risks that account for a significant portion of cancer because of the different motions of our hand affecting our lymphatic system etc etc.

Irresponsible fearmongering with no foundation whatsoever.

Bad science is building hypothesis and promulgating it publicly alongside zero evidence whatsoever.

The discussion is about stored apples specifically causing increased cancer rates, paired with an arbitrary woo categorization of "living" vs "dead" food. OP wondered why this did not occupy a larger portion of public discourse. Again, this hypothesis exists alongside humans writing more years whose first digit is "2", as evidence-supported cancer progenitors.

> Some nutrients change, these changes could affect satiety which could affect obesity

Yes, if you walk back the "living vs dead" woo concept and expand the scope to more varieties of foods than just apples and more processing methods than passively storing otherwise intact fruit, then you exit the zero evidence crackpot zone.

Lots of crackpot woo theories are similarly half a step away from real evidence-supported theories. Another example would be biodynamic agriculture, which looks a lot like organic and integrated farming practices right up until you get to the part about burying ground quartz stuffed into the horn of a cow so you can harvest cosmic forces in the soil.

Don't be sorry! Instead of apologizing, all I ask is that you notice, read, and internalize the part where the objection is to "and therefore that's why cancer rates are increasing".

I am on the last of my onions from last year.

People have been doing this for a very long time.

Same for many root vegetables.

Hate to say it, but it's because it comes across as unscientific woo

We can measure the differences between an apple freshly picked and one preserved for a season. We can objectively see how the sugars and carbs and calories change, if they do.

Maybe there's some yet-to-be-discovered process in our bodies that deals with preserved food differently than fresh food, but if that is the case it's more likely because of the preservatives than the food being "dead"

This isn't new: One of the early (pre-US) exports of the colonial US was apples back to Europe. They store and ship well.

https://www.youtube.com/watch?v=ZuwC3ESdwZA

Milk is also probably the best example of dead vs. live except you have it backwards. The milk sold in stores deliberately kills off the good bacteria to greatly extend shelf life and prevent food borne illness (pasteurization). Your point is more consistent with raw milk.

There is a strong distinction line the ability to think (intelligence) and the ability to reason. (just ask google!).

There is lots of "intelligence" in this discussion. Reasoning? Not so much. Some how - and perhaps this is partly from how I phrased things - there was some impression that I meant storage of food caused cancer! But apples are indeed affected by storage. Just ask google!

And "just ask google" is the problem. You may be intelligent, and your comments may be perceived as intelligent, but does that mean they are reasoning? Nope.

And for all the people out there wanting to know whether you will have a job, and what the future with AI will be:

If you are only intelligent you are out of luck! If you can reason, there is a huge opportunity! Just ask google.

And another question, perhaps the most important. Can you determine that a recipe is flawed? In immediate terms, if I tell you to feed your sour dough starter every day, can you determine why, how or if that might be bad advice?

My conjecture is that there are at least three types of intelligence, as outlined above. And you have to remember that AI is by definition "artificial". Not in the sense of being unnatural but in the sense of artificial sour dough bread. It is not the real thing. (at least for two out of the three definitions of intelligence).

This is not to argue that AI is not useful and extremely beneficial in some contexts. Unfortunately our whole system of education has trained us to be "follow the recipe" kind of people. Uh Oh! So if your only skill and ability is to follow recipes, you might want to focus on developing your other kinds of intelligence.

Recipes of course have evolved too. Old roman recipes were merely a list of ingredients. Water, flour, salt, yeast.

Written steps came after, then photos, videos, gradually replacing hands on training / kneading.

There are now recipes as code running sour dough assembly lines. Certainly capturing much more detail in technique than even a well made video. But I bet there is still human QA at the end judging "is this bread what folks expect?"

I suspect that in order of complexity you'll get "can I attempt to follow each step", "can I follow the intention of each step and understand if I've failed to meet it" (mitigated by using more specific and detailed steps) "can I follow the intention of the recipe itself - can I add or modify steps that are missing to give the ideal form of sour dough" (maybe you show a machine what good bread looks like, moisture content, crunch?) Those mostly overlap with the 3 you've called out. But I'd add "why would anyone make bread?" Why the heck are we still mixing flour and water together. Why does this recipe exist? Great crusty sourdough requires them all.

My fear in your above example would be that we offload more and more of the "know the recipe" intelligence to computers and humans are slotted in as replaceable manual labor and are left arguing with a computer about whether the starter needs to be fed or not (or whatever equivalent scenario).

Self-correcting agents are already here: https://jdsemrau.substack.com/p/hyperagents-and-self-correct...

Me? Unlikely. Ever.

> Can you make sour dough bread? Not so easy.

After a couple tries, probably.

> Does following a recipe require “intelligence”?

I don’t think so. A computer program is not too different from a recipe. A recipe is an algorithm. Cooking recipes tend to be badly specified ones in natural language, but algorithms just the same.

See, I’m absolutely incapable of “following recipes”, especially cooking ones. I can much more easily learn the principles behind sour dough making and then apply them. I think that requires intelligence, much more than following the algorithm.

for i = 0 i < 10 i++ if i = 7 printf("hello 7") else printf("who are you");

But with a more pictorial presentation, it is easier to read the program.

for i = 0 i < 10 i++ if i = 7 printf("hello 7")

I'm just wondering - if we had a more pictograph based programming language would it be easier to understand?

https://scratch.mit.edu/

Then fall down and appreciate that you did not end up in that situation. And tell everyone you know not to apply or work there.

You're going to find many red flags for any job, perhaps severe flags.

But you need a job.

Or you have to roll the dice because you have deep knowledge of the red flags for your current job.

Who finds 10/10 perfect jobs via an application process?

Note: I probably shouldn't be commenting since I don't need to apply for jobs and conditions here are likely different from yours.

Early in your career it can be hard to distinguish the two, but once you've joined a company where there really were "red flags" you quickly learn to differentiate.

Many people are reading the author's interview uncharitably as simply misunderstanding how to answer non-technical question, but I have absolutely been through loops (thankfully rare ones) that did have a "let's press on sensitive issues and see how tough this candidate is" round (one place brought in a consultant who bragged about his experience working with hardened criminals and terrorists to build out a true psych profile on candidates, I declined after learning he had had some "trouble" at a previous high profile job)

Sounds like you've never worked for a truly toxic org, which is great. But, especially if you're interviewing with smaller startups (as the author mentioned), there is a lot more variance and some truly messed up teams (and some truly remarkable ones as well) out there. I've noticed that HN increasingly doesn't have people that work at startups any more, so many people are probably less familiar with what's out there.

Maybe I'm wrong, but given the type of company it was (and likely, the C-suite people), I guess that they were doing something similar. I assume that they really did want to know about the person's non-worklife stuff.

I would consider that crossing boundaries. It's also possible that some of the questions might have been illegal (in the US).

I've interviewed at dozens of companies, received and accepted or rejected at least 20 job offers in my life, and rarely encountered true red flags. This is very different than saying it's a perfect 10/10, all life is about tradeoffs. What GP is saying is that "there are things that are not worth any tradeoff, and you'll know them by ... ", which is good advice, esp for young people, who might be willing to make uncomfortable personal sacrifices to obtain a job.

We may be there someday, but we're not there yet.

If they're hiding the many red flags, that's the biggest red flag of all!

I’d like some clarity. :)

I hoped to avoid anyone wasting effort trying to help me.

But yes, you can always be unaware of being a jerk.

  Meekness is weakness.

  Don't be beta'd into submission.

Here is a fun thing.

Write a bunch of JSON. A lot. Now write a lot of JSX. Then convert the JSON to JSX. Then convert the JSX to JSON. I was surprised by how much easier it was for me to reason in JSX. I use threejs and react three fiber (r3f). Again the JSX type of representation easily wins out for me. I don't really understand why. Maybe JSX ends up being more pictorial - as in a picture is worth a thousand words?

So I'm not sure I even care of about React. I just reason better with JSX than with all the other crufty things (template, html, htmx, etc). And yes, find all of them including React crufty.

producer => provider => consumer.

What happens when providers are the gateway for the providers and consumers? When the providers own the market place for both producers and consumers?

1. A producer grows a potato 2. The provider buys the potato for $0.10 3. The provider sells the potato to the consumer for $600.00

This is the system we have now. The wealth goes to the corporations and wealthy stock owners. $599.90. Well, okay, they end up paying $.90 for packaging and to buy politicians.

The number of people who can afford a potato gets smaller and smaller, so fewer and fewer potatoes are sold. For more and more money. Because there is so little demand for potatoes, then potato growers have excess capacity so they get paid less and less. They go out of business.

Is this a problem? What are the long term effects? Guess we will find out.

Urushi is transformed by curing in a warm and humid environment to something that is food safe and not toxic - for example Japanese rice bowls. Then there are they myriad decorative techniques such as Rankaku - using quail egg shells for decoration.

I've recently seen the word "entanglement" in a completely different context. But Urushi entangles you in nature and your environment in way that is utterly breath taking. For example: https://www.sothebys.com/en/buy/auction/2019/modern-masters-...

[edit for grammar and clarity]

That video is not online AFAICT, but there is another one about another artist, which includes some footage of an urushi workshop preparing the stuff, and her using it: https://www.youtube.com/watch?v=xeult7lZtbg

[1] https://www.vam.ac.uk/exhibitions/urushi-now-contemporary-ja...

I grew up playing in woods thick with the stuff and never had a problem. Then I had a hell of a reaction to it in high school, and it’s been cruel to me since then.

https://www.wsj.com/style/eat-poison-ivy-oak-immunity-3207ec...