It's really not that simple.

Numerous times I've seen promotions going to people who were visible but didn't do the actual work. Those who share the achievements on Slack, those who talk a lot, get to meetings with directors, those who try to present the work.

For the vast majority of people and cases, it really is that simple - but like I already said, "the process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is". There are exceptions to every rule, but for most people, it really does come down to some self reflection:

1. Do I consistently deliver more (in output, impact, or reliability) than peers at my pay level?

2. Is my work visible and tied to meaningful business outcomes, rather than low-impact tasks?

3. Am I known as dependable and easy to work with, especially under pressure?

4. Would the company feel a real loss-operationally or financially-if I left?

5. Have I made myself clearly more valuable to the organization than what I currently cost?

> It’s a bad time to move away from tech

Working at big tech these days I see EMs and directors playing with AI, building tools, contributing to codebase through AI agents. Today when there's less hiring and building the org, becoming EM doesn't mean moving away from tech

> The ladder is very competitive

Just like on IC path. You think that being a great builder will move you from staff to principal role? Nope. It's about setting direction, aligning people, finding opportunities. A set of skills that's very close to what managers do.

> The pay is lower

When you compare EM against staff engineers. Is EM and staff the same level? In some companies, yes. In some companies, EM is at senior or between senior and staff. So yes, on average it will be lower than staff, but EM is not a promotion, it's a change of career path.

In any case, if someone's wondering whether they should try EM role given a chance, I still say: go for it. Going back has never been easier, a lot of companies now cuts manager roles and allows people to move back to IC, so if you have a chance to become EM and are curious about it, give it a try.

It’s totally different. People have to obey laws and contracts because there are consequences if they don’t, there are fines, arbitrage, courts.

What happens if AI agent you run causes a lot of damage? The best you can do is to turn it off

I imagine most countries will regulate it as gambling. Some already do – Netherlands fined Kalshi or Polymarket (don't remember which one) for operating without a gambling license. I guess US will be one of the last ones to do it (certainly won't go for it under the current administration)

Any pledges/values/principles that are abandoned as soon as it becomes difficult to keep them, are just marketing. This is just the next item on the list.

IMO Facebook has a bigger problem - I’m a millennial, far closer to a middle aged man than to a teenager, and I don’t want to be on Facebook because it’s so full of garbage. There’s just nothing interesting except for Market.

Surely there’ll be a follow up to TikTok and other trendy apps, but Facebook is where I should want to be, and I don’t

I'm a millennial too, and I log into Facebook like once or twice every 3 months. I don't use it as much as I used to.

Do these skills actually provide much value? Like, how much better are they than something that I could tell Claude to generate based on a single API doc from Slack/Trello?

Zero. If a skill actually provides value, one of two things happens: it gets absorbed into Claude Code (or similar) within a week, or a company packages it up and charges real money for it. The "free skill that gives you an edge" window is essentially nonexistent. By the time you find it, everyone else has it too. You're better off learning to prompt well against raw API docs than chasing a library of pre-built skills that are either trivial to recreate or about to be made redundant.

From my experience, most are just some high level instructions on how to use CLI tools installed on the system. A lot of the CLI tools they're calling out to have 0 reputation on Github or don't work at all.

I've had more luck writing my own skills using CLI tools I know and trust.

That's a big part of the reason skills are exploding, people use them as stealth marketing in addition to being a malware injection vector.

Skills is actually what also Claude code uses internally, it's cool because the llm will load the whole context on how to use it only on demand and keeps the context cleaner.

>Do these skills actually provide much value?

IMO, yes. Gemini et. al. out of the box are good at composing, but are entirely passive. Skills enable you to - easily, with low code/no code - teach your AI to perform active tasks either upon direction or under any automatic conditions you specify. This is incredibly powerful. Incredibly dangerous, too, but so is a car when compared with a skateboard.

My understanding is that it's just an abstraction layer that feeds right into the context window. Might as well just feed it into the prompt. I think cursor even proved that skills aren't as good as direct prompts (or something to that extent, can't remember exactly)

GitHub is the new Internet Explorer 6. A Microsoft product so dominant in its category that it's going to hold everyone back for years to come.

Just when open source development has to deal with the biggest shift in years and maintainers need a tool that will help them fight the AI slop and maintain the software quality, GitHub not only can't keep up with the new requirements, they struggle to keep their product running reliably.

Paying customers will start moving off to GitLab and other alternatives, but GitHub is so dominant in open source that maintainers won't move anywhere, they'll just keep burning out more than before.

It's all cool as long as you keep all of this up to date, and that requires a lot of scrutiny and discipline.

Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.

> 3 different sources of truth about ownership

I see only 1.

Admin, access <> ownership.

I always thought of this as authority, accountability, and responsibility of a thing. Ideally one group or person has all three. In practice you’ll have many entities with some combination of the three.

I am sure mere access does not imply any kind of ownership.

Isn't the point that this is the source of truth?

If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.

From my experience, there is always a parallel process. But if you make the system painless enough, most of it will be in there, yeah.

> When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.

For this to work, you’d need to also rotate the secret, or ideally issue one for each person (so that others don’t have to update their configs).

...but sometimes you can’t reliably automatically rotate the secret, because they could have used it for something in production.