Only in the most utterly pedantic sense of the word "different" wherein you mean that by definition, infant mortality occurs early and wear occurs later. But they can both stem from the same root cause, which is a component not built with adequate tolerances. In other words, they can be the same fundamental issue, just expressing themselves at different times.

Most products don't have an MTBF. And things that do have MTBF are based on accelerated wear testing on a small number of units, and can have almost zero basis in reality. There was one model of major brand hard drive about twenty years back where a couple of RAIDs where I used to work got lost because the drives all died after such a predictable number of powered-on hours that by the time you could re-stripe the RAID, the next drive would die. They ended up making sure the drives had a high variance in powered-on hours before using them in RAIDs after that.

It's an example that proves or demonstrates a point. And the point it was proving was that the same root cause can be responsible for both catastrophic early product failures and premature deterioration-related failures.

I plug my car into the wall in order to charge it and increase range. At no point do I want to supply power back to the house and decrease my car's range. That defeats the purpose of having a car: to be able to drive around.

Cars are not meant to be temporary batteries to supplement the power from the electric company.

Wear-out failures aren't always different from infant mortality failures, though. If the defect is caused by a design flaw in a component resulting in a structural weak point, that same weak point could fail after one use or a thousand, and it could just be a ticking time bomb. Someone could get very unlucky and find one that is slightly weaker, and it could break much sooner.

Case in point, I recall a machine where some people would have to have their laptops replaced every couple of months for motherboard failures, while others lasted for years, and it turned out to be dependent on how people closed their laptops at the end of the day and whether they pressed on the bottom of the case in a particular spot that wiggled the GPU. But if you handed one that had been working for five years to someone who used their left hand under the laptop while closing it, it would be dead in two or three months. If you replaced it with a brand new one, the brand new one would be dead in two or three months. And so on.

Remember when we were all techno-optimists who thought we would end up with 401Ms and even 401Gs? We're as dumb as the flying-car believers.

Not that SCOTUS (nor any high court in the EU or other countries) has concluded this determination, but so far the general claim is that AI-generated content (images, movies, writing), while it may (or rather, does) contain copyright violations for stealing from others, it itself can't be copyright protected because no human was involved in making the final product. It is automatically public domain.

So that leaves the question - at what point does a vibe-code project be considered public domain and thus not protected by a license?

Straczynski shared his experiences working with Koenig on his FB page. A good read.

Firefox was never there for the "Good Ole Days"

Firefox was a reaction to Mozilla becoming too ambitious and too unfocused.

The Netscape/Moz split was already after things had gotten bad. Moz completely jumping the shark was already bad.

The Good Ole Days were NCSA Mosaic and Navigator 1.1. Before the AOL invasion. Before people on the internet expected you to care about their feelings, and before politicians and mega corps knew how to screw it up.

Once upon a time, having friends on irc or usenet was like the nerd equivalent of _living on a pirate ship_

(except the avg pirate was at least +1SD on the IQ scale.)

It was the last vestige of freedom.

There is no "good internet" with Tay Zonday on it. Or girls.

He was here to save our asses. We should have shown a little gratitude.

I put off going to Star Trek conventions for years. I always assumed I could go in the future and see all these people who played my favorite characters. The death of Nichelle Nichols finally made me realize that if I ever wanted to see these people while they were alive, I needed to finally do it. I finally went to my first convention in 2024. I saw Koenig, Shatner, and the crews of the other shows. It was fantastic.

I am sad I didn't go earlier when I could have also seen Nichols, Nimoy, Kelley, and Doohan. I wish I realized much earlier that they had a limited time left for me to see them myself.

Point being: if you want to see these folks who played characters you loved, don't wait! We all have a limited amount of time on Earth. If it's important to you to sit in the same room, breathe the same air, and listen to their stories in person, then do it now. Don't put it off to later.

>I find this very stupid.

I agree with you.

>Some people are good, reliable, and experienced "worker bees" who either don't want to be in management or are not qualified for it. I see no logical reason to get rid of such people, do you?

Agree completely.

>I'm not sure if "Sr. Engineer" means quasi-management at MS

It doesn't.

The people manager track and individual track are separate tracks, and both go all the way to the top. There were hundreds of Partner Software Engineers who didn't have any people management responsibilities. These engineers, because they were Partner level, had a minimum of $1m total comp some years. (The higher your level at MS, the more of your pay at MS is contingent: bonuses, stock, etc. MS has a "low" guaranteed salary and a wild bonus/stock award range, all based on your performance and overall company performance)

There are level 70 people who are not people managers; the job title changes to "Distinguished Engineer" somewhere up there, and somewhere past that becomes "Technical Fellow".

There is a level floor for being a manager; but (effectively) there is no level ceiling for being an individual software engineer.

IIRC, When I left, they wanted people to be Senior level before being people managers. But there were more senior level engineers than senior engineering managers...

Here's some quick lingo: an "M1" is a manager who only has engineers reporting to him. An M2 is a "manager of managers", e.g. an M2 has M1s that report to him - and may have 1 or 2 engineers engineers or support staff. There are also M3s, but M1 vs M2 is the main useful cutline.

MS generally wants an M1 to have at least 5 people reporting to him, but not more than 15. So the "span" is pretty narrow; MS R&D is pretty management heavy, with an M1 typically having around 8 people or so.

(I was an M1 for a few years, then went back to being a normal engineer with no people management responsibilities.)

Being an M1 at Microsoft is kind of a dual mandate: you are given a staff of engineers to go work on a problem that is (was?) too big for one person. The M1 has engineering & product responsibilities (e.g. make sure the right thing gets built on time and works correctly). The M1 also has people management responsibilities (coaching people in their careers, rewards and promo justifications, delivering bad news, etc)

Good M1s wrote code and reviewed code, but also burnt a lot of time in meetings ("what are the other parts of the company that are near me doing?") and individual meetings ("i have 8 people who report to me and I need to have a dedicated meeting with each of them every week to see how they are doing, give them career feedback, etc)

M2s rarely wrote code. They would occasionally write code for some demo or prototype, and then show it to people. If the idea had legs it would get spun off to underlings to flesh it out.

I say all this in past tense because I don't think how it was in 2022 necessary holds in Oct 2026. I know that I am not developing software or managing software engineers the same way now as I was even at the beginning of 2026. AI has changed all of it.

Interesting... I didn't consider that angle.
Thanks!

An article says:

>Employees at internal levels 64 and below received one week of base pay per six months of service, for example, and employees at levels 65 to 67 will receive two weeks of base pay per six months of service, according to offers reviewed by Business Insider.

Within MSFT, here's what those "levels" mean for software dev positions:

68-70: Partner & Above [entirely different comp structure; limited quota]
65-67: Principal
63-64: Senior
61-62: Engineer 2
59-60: Engineer

When I left in 2022, you unofficially had a limited amount of time to make it to the senior band. The "up or out" philosophy very much applied to junior engineers; if you didn't have the potential to make senior engineer (because you hadn't made it yet after x years), you were managed out.

People who made it to Principal could park their careers at the principal level and stay there indefinitely, so long as they were providing good results (but were still subject to random layoffs not based on their own performance)

The VEOs and other "voluntary" downsizing plans have been targeting older, higher-level folks. Yes, those folks are more expensive. They are also more male, more American, and more white.

>I believe the future will include AI but it will be small models that are self-contained and that people have on their own equipment and not not spending vast amounts of money on paying for tokens to third-party companies

Why do you think there will just be one picture of the future?

For sure, self-hosted models will be part of the future (even if they are illegal). But I think paid services will also be part of the future.

Self-hosted and unencumbered workflows are a key part of the future for freedom / autonomy reasons. And for some, economic reasons.

But paid services and private models are also going to continue to exist.

Right now, 99% of humans don't even self-host their own _email_. Not only do they not run it on their hardware/environment, they don't even manage the service on other people's infra. They have no involvement whatsoever in their email service.

Some businesses are going to choose to pay an AI subscription, just like some businesses use cloud services today. In both cases, operating local IT infrastructure isn't their core business.

But again that's backwards. I let my AI coding assistant write tests exactly so that I have a reproducible, deterministic ground truth that I can inspect for logic errors. If you let the AI do the testing directly, it's a toss-up if today it feels like it or it decides that your desired result is "everything green" so it'll just give you that answer without actually testing anything.

LLMs obviously aren't human. But that's not the point. The point is that you don't need to know a programming language to program a computer.

For example: Especially in the early days of smartphones, there were mountains of small tools that did something that's essentially a simple script. Egg timers, remind-me-tomorrow apps, tons of stuff that's basically a wrapper around a web search, and so on. Almost all of those are today something ChatGPT can do, and are easy enough to describe.