I think it is, because it suggests that a development arc either has maxed out, or is now subject to a different dynamic.

Apple has a team of at most 12 people working on TCP/IP and IPv6. It's arguably one of the most important parts of the software stack. But, it's late stage mature code. Netflix had 4-6 people working on TCP flow control. Google had a small team, based in Japan, doing IPv6 for android. If a team has 100+ members and they can go, it poses "wow, at scale, how many people do you need to do things" questions when things as mission-critical as the entire IP stack can be done by less than 10 people.

Maybe I'm in an odd corner, but I find this thing fascinating. When they laid off the adsense sales and support staff because AI can do it cheaper, I found that fascinating too.

(I don't work for Apple, Google or Netflix, and my numbers are approximate based on bar conversations with some of the people in each team in each company. Consider them Fermi numbers)

I’d be careful not to conflate criticality with complexity.

The TCP/IP stack is extremely well defined and covers a finite problem space.

Products higher up the software stack tend to balloon in complexity as they reach into concrete use cases. I’m sure there are plenty of overweight teams, but most products can’t survive with 4-6 people.

TCP/IP is so well defined because the engineers on these small teams are the ones publishing the standards. It isn't like they are simply reading a spec out of an existing document and coding up a conformant program.

> standards. It isn't like they are simply reading a spec out of an existing document and coding up a conformant program.

Err, yes - that’s what 98% of modern TCP/IP development work is. There aren’t frequent new RFCs for TCP - it is established, standardized, and stable.

The other 2% keeps engineers fairly busy, I imagine. Custom congestion control algorithms come to mind

Yeah, but even so, that pales in comparison to Joe Product Manager saying "the new French tax code dropped last Tuesday" or "our biggest competitors just signed an agreement that they will implemented a new standard they're proposing and we need to get onboard".

Non-technical stuff is crazy complex compared to purely technical stuff, which tends to be a lot better defined.

> Apple has a team of at most 12 people working on TCP/IP and IPv6

Do you know who they are and how to reach them? I have filed 3 or 4 bugs with proper reproducers through Apple's feedback assistant over the years and till this day those issues haven't even received a single comment nor any acknowledgement that the report has been read.

Perhaps write it up as an open letter/blog article and link it here??

I prefer just getting those bugs addressed. A lot of times writing these blogs and open letters just brings some attention to the blog/article and the real issue never gets addressed. Plus at least 2 of these would involve me sharing internal details which I prefer doing only through the official bug reporting channels.

If you file something through FA, the advice in the community lately has been to re-file the bug against every beta of the OS and every new version of the OS until it's resolved. If you have any new information at all, re-file the bug with the new version. Apple's bug triage team doesn't route things that are old/ancient/sitting in the system forever. Your bugs probably haven't reached the team yet.

Thank you. I'll try that with one of the bugs and see if it gets any attention and then do it for others.

Post the FB numbers and perhaps some helpful readers may be able to take a look?

I wonder if this will work - buy a couple (even 1 share should do, now that I think of it) shares of apple, write a letter to investor relations saying you're a shareholder, you've found bugs, you've filed them, nothing's been done, this is very disappointing, etc etc

edit: added the stuff within brackets

Based on past experience, trying to leverage acquaintance from conference and meetings into a support case exchange terminates the friendship. So I am sorry but I decline to try and bridge this gap. I really am sorry, it sucks you can't get to the back end engineering staff.

> because AI can do it cheaper

I'm interested to see how this works out in the mid-longer term to see where it tracks on the graph with "Cheaper" on one axis and "Better" on the other (where '0' is in the centre of the "Better" axis, not at the bottom/left).

Building an AI stack to perform some task can often be budgeted as capex even where it would be opex if humans did it.

Capex tasks can be considered to be either "Cheaper" (as they're investments, not expenses) or "Better", since they create long term value on top of the short term, depending on how you want to define your axes.

When doing this budgeting, moving items from opex to capex in this way is mostly based on belief structures, as it's too early to tell if the capex generates lasting value or not. Short term, though, it tends to be good for the stock price regardless.

Opex to capex is a reverse machine that goes ping.

And so the pendulum swings.

And while it swings, people get promoted or move to another company.

This underrates contributing size a little because there's a lot more who occasionally contribute in the layers above or below - like if you're working on cellular modem performance you also care about TCP behavior, or someone working on video streaming is going to want to tune networking themselves.

Yes because the more that news says “Layoff” the more they can create the perception that the market is terrible and trick employees into accepting lower wages.

It's a much larger layoff. My friend's three VPs (heh) were all laid off in Fitbit. Entire orgs were wiped there.

With the number of VPs sending emails, I think it's much larger than "hundreds".

I'm hearing they laid off thousands today actually but it could be my friend has the number wrong.

At least in my area it's 10%.