(But this does not discount the fact that basically all CPUs treat them both as one cycle)

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.

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).

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 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.

That being said, these days I use Clojure for both (I use babashka to run scripts: https://babashka.org/)

The troubles start when you try and solve the whole thing in one step, using just regular expressions, or parsers.

Regular expressions are good at tokenizing input (converting a stream of bytes into a stream of other things, e.g. picking out numbers, punctuation, keywords).

Parsers are good at identifying structure in a token stream.

Neither are good at evaluation. Leave that as its own step.

Applying this rule to the example in the article (Advent of Code 2024 Day 3), I would still use regular expressions to identify mul(\d+,\d+), do(), and don't(), I don't think I need a parser because there is no extra structure beyond that token stream, and I would leave it up to the evaluator to track the state of whether multiplication is enabled or not.

By manually batching the deletes, you are telling the database that the whole operation does not need to be atomic and other operations can see partial updates of it as they run. The database wouldn't be able to do that for every large delete without breaking its guarantees.

The problem is when the market widens again and you look at every interview opportunity with jaded eyes and can't identify good from bad anymore.

I don't think it's true that interviewers are in general incapable of identifying skills in others that they don't have. That would be like me being unable to acknowledge Da Vinci's genius because I can only draw stick figures.

A lot of these comments make interviews out to be a battle of wits where you are trying to best your interviewer: If you identify a gap in their knowledge, show them up (and that's what they are doing with their questions). My approach is that the interviewer is trying to find out what it would be like to have me as a colleague. Bringing up things because you think your colleague won't know them and then not explaining them is just obnoxious.

There are bad interviews where all these tropes play out. If you went in with a positive mindset and still left with a bad taste, then count yourself lucky because you don't want to work there.

But it feels like if you go in expecting an idiot interviewer who can't see your genius and, even worse, wants to show you how much cleverer they are than you, one way or another you won't have a good interview experience, and you'll be left convinced that the grapes are sour.

https://github.com/zed-industries/zed/blob/12b12ba17a380e321...

So if selecting all matches requires calling this function for each match then I guess it's accidentally cubic?

I also spotted two linear scans before this code (min by key and max by key).

It seems like a combination of the implementation being inefficient even for what it was for (and that this was known), then it was used for something else in a naive way, and the use of a bad abstraction in the code base came at a performance cost.

I don't think this is a case of Rust either demonstrating or failing to demonstrate zero-cost abstractions (at a language level). A language with zero-cost abstractions doesn't promise that any abstraction you write in it is magically going to be free, it just promises that when it makes a choice and abstracts that away from you, it is free (like with dynamic dispatch, or heap allocation, or destructors, or reference counting, etc).

The idea that your word is taken more seriously as an EM rather than an IC when it comes to (for example) needing to test more.

I have to admit that this may have been one of the reasons I felt the need to switch to a management role myself (I was an IC that had recently been promoted to a staff level role and subconsciously I felt like I lacked credibility and hiding behind a title would help me get some). In practice that turned out not to be true -- I didn't need to do that at the time, and now as an IC in a different company, my thoughts and feedback are taken seriously at an organisational level and by my peers.

The fact that you have to stack rank and pick an under-performer every half is just broken. I know it's a sad reality of performance management in a lot of places but it's not a universal truth that you will have to do that as a manager. Statistically, you can't avoid having difficult conversations about real performance problems, but there are companies where managers don't have to have the "everyone else on the team did better than you this half" conversation or the "I had to pick so this half you got the short straw" conversation.

https://en.wikipedia.org/wiki/Session_type

I think one difference is that session types capture which state a process/co-routine is in after receiving a sequence of messages whereas this system does not, it captures how one can respond to each state in isolation (e.g. I don't think you can statically capture that once a door is closed and locked you can only receive the locked state from it and respond by unlocking it).

https://godbolt.org/z/Pa6cqd1fb

But the funny thing is, I tried it on my machine, and guess what, the "unoptimised" version is consistently between 4 and 5 times faster than the hand-optimised variants:

https://gist.github.com/amnn/4be5c05975c250d0ea88b62c03f1719...

So that's fun.

The analogy would be for WhatsApp to make it take artificially longer to send messages on Android 4.4, which I think people would have a problem with but they have no good reason to that.

I can't speak for Telegram, but in the case of WhatsApp, they decide to deprecate particular SDK versions when the usage of those SDK versions drops below a threshold, and it's against their interests to do otherwise, because they lose market share and they are making a tradeoff between engineering support costs and users.