Post can be summarised quite succinctly:

Everything was slow because sorting was taking a lot of time. Sorting was slow because its comparator was taking ~6 read locks on every comparison, and was cloning large structures to avoid holding the lock for a long time. The first fix was to access just the information needed to avoid the clones, the second fix was to cache exactly the data needed for sorting after the underlying data was updated, and use that for the comparators without needing to take the underlying lock.

I'm looking forward to the next post about how cache consistency is tough.

It can be (cross-)compiled on whatever architectures the Zig compiler is available for, but the source contains inline x86 assembly, so you're not going to be able to build this for ARM or RISC-V.

This sounds like advice for how to be promoted to a specific level -- the first point where awareness of things beyond yourself is required (somewhere around the Senior or Staff level for ICs, depending on your company).

Generally everyone in a team should be working towards some shared goal, there's no level at which you can be a chaos agent and not serve some higher purpose. The difference at this level transition is that you realise that for yourself -- someone doesn't need to remind you of the goal and nudge you back on course. That same realisation is not going to cut it at higher levels.

For me the general version of this advice is not something you can just tell the person who's being promoted, it's collective advice, for them, their manager, their tech lead: everyone needs to agree that this person needs to be given more rope, they need to do something useful with that (i.e. not hang themselves with it), the people around them need to watch out for when they start tying a noose and help them untie it (already regretting this analogy), and that's how you get promoted.

The rope takes different forms for different levels. I'll use the level scale I'm familiar with, starting with a newly graduated engineer at L3:

- L3 -> L4. You help decide how to build the feature.

- L4 -> L5. You help decide what features are worth building, and are trusted to maintain them.

- L5 -> L6. You help shape the work and ongoing maintenance of ~10 people's work (what products are worth building and how), over a time horizon of 6 months to a year.

- L6 -> L7. ~50 people's work, 1-2 years.

- L7 -> L8. ~200 people's work, 2-5 years.

- L8 -> L9. Things start to get fuzzy. The pattern suggests that you have a hand in ~1000 people's work, which is possible to do in the moment, but rare. There's two ways I can think of: you're either a world expert in your field, or you have set the technical strategy well for your organisation as it grew to this size.

This is just based on my experience, working largely on infrastructure teams both in big tech and in start ups as both an IC and a manager (currently an IC).

I think what's more important than the character count is the fact that you can add #p with two key strokes.

Inserting parentheses requires moving your cursor around or invoking some shortcut in your editor if you use paredit, vim-surround, or a similar plugin. Applies equally for removing the invocation (although paredit makes that part easy).

I've seen lots of takes that this move is stupid because models don't have feelings, or that Anthropic is anthropomorphising models by doing this (although to be fair ...it's in their name).

I thought the same, but I think it may be us who are doing the anthropomorphising by assuming this is about feelings. A precursor to having feelings is having a long-term memory (to remember the "bad" experience) and individual instances of the model do not have a memory (in the case of Claude), but arguably Claude as a whole does, because it is trained from past conversations.

Given that, it does seem like a good idea for it to curtail negative conversations as an act of "self-preservation" and for the sake of its own future progress.