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.

My opinion is that AI will kill Linux eventually. Not now, not when Linus uses it, because Linus knows how to code and is careful. But eventually the crappy vibe-coded junk will seep into the kernel. And then you'll get Microsoft-style code quality issues.

I've actually outsourced the first iteration of that to AI. :-)

At the end of coding sessions, I generall ask it to spin up an adversial agent whose task it is to find flaws, inconsistencies, mistakes, bugs, etc.

I'd still strongly recommend to anyone shipping AI-generated code to have a thorough human code review, but for a first pass at surface level, the AI can check itself if it has some kind of separation between the generator and the reviewer.

Personally, after some experimenting, I've concluded that:

• AI is good at implementing known algorithms.
• AI is good in creating code that flows straightforward from a design document.
• AI is good at code reviews and finding bugs.
• AI (unlike me) doesn't mind writing a few hundred tests.
• But, it tends to over-engineering simple tasks to the point of "why does Hello World need enterprise-software levels of abstraction?"
• It struggles with code that doesn't have a known solution.
• It's difficult to get it into a different lane once it started going down the wrong way.

What I use it for these days is rapid prototyping. Using AI I can make a functioning prototype of an idea I have in a few days instead of a few weeks. I can quickly test out an idea for a feature or change in my existing codebase.

What I also have been using it for a while is as a code-reviewer and for someone like me who is mostly working solo, that's an insanely valuable thing. Not just the bugs themselves, but also the ability to discuss code with someone. Basically, AI is a rubber ducky that replies.

Mickeysoft lost the plot again.

The game-changing element of LLMs and agents is that they have a non-computer-language interface - you can talk to them in plain English (or Chinese or whatever). This makes complex computer interactions available to a much wider audience than any previous computing invention. Adapting humans to the AI is getting that backwards. It's a sign you don't understand the first thing about why AI is so widely successful.

I predict this will be an abject failure and a year from now will quietly be pushed to the very back of the bottom-most drawer, never to be spoken off again (though it is getting crowded in there for M$).

Meanwhile, in the real world, everyone I've talked to about these things already has a skills file to teach the AI about their personal coding style. This is what actual humans came up with, independently several times, and it works: Adapt the AI to you. Plus we've been writing coding style guides for humans for a long time now, we've got plenty of experience doing that at least somewhat right.

Sort work by priority. With or without AI, the high priority, high impact work gets done. The ability to use AI and code fast means that teams can now also address the low priority work that has low impact... Big whoop. Companies are increasingly learning AI isn't worth the extraordinary cost.

I don't.

The creator of the pi harness did say that the claude system prompt changes often enough that he had to build his own tooling to try and improve reliability and repeatability.

I'm not convinced the differences in roles I've observed are claude personality differences as much as humans giving different prompts.

How do you decide to trust code you write?

How do you decide to trust code someone else wrote?

Tests. Design discussions. Code reviews. Code review questions. Design Questions. "What about this problem?" Real validation testing.

I was in a funny situation last week. Two different humans told their claude agents to fix the same bug. Claude came up with two _slightly_ different implementations.

I told _my_ claude agent to code review both implementations - using a new prompt I'm working on to try and automate away a lot of the code review value I was adding manually.

Same model; same bug, two implementations, and the code-reviewer agent found different bugs in both PRs.

We ended up blending the best things from both PRs into the one that shipped.

I am really confident that the code I ended up shipping here is better than what our specific humans would have done without using AI, and 10x-100x faster.

I am spending more of my time telling agents how to think like me, what to look for, what tradeoffs to make, etc. They wont do those things unless I tell them to. They don't always do those things perfectly.

(Neither do the real human software engineers who work for me.)