Jenk

$165k won't get you far on salaried engineers. There's every chance that 1 engineer, assuming Anthropic employs them, is on $500k or more. Assuming average of $336k in that pool of 50 engineers, then for 11 days for 50 engineers you've spent $710k[0].

Salary info: https://www.levels.fyi/companies/anthropic/salaries/software...

[0]The maths I used (posting because I'm tired and prone to mistakes):

    $336,000 / 260 (working days of the year) = ~$1,292.
    $1,292 * 11 * 50 = ~$710,769

- Not sure what they're called, but I've seen a lot of fully automated outdoor "locker stations" for packet deliveries

Drop boxes!

I was part of a team prototyping these some 20 years ago. I highly doubt we were the only team doing so, but we were certainly unaware of any commercially available/deployed stations at the time. I was writing the software, in particular the orchestration of the locks and event bus for the transmissions.

Lots of fun from trying to fathom how undocumented solenoids operated, to trips to various countries for remote and environmental testing, and destructive tests simulating someone driving a truck into an installation (i.e., by deliberately driving a truck into one!)

The nerdiest moment was taking a mainboard model that we were getting intermittent faults with and recreating the exact environmental conditions to recreate the problem. This involved incubating the mainboard in a sealed environment chamber to control temperature, humidity, and atmospheric pressure. The fault was bit-flipping because electrons were jumping rails when the microchip(s) were cold and damp.

https://www.thek6project.co.uk/the-crowns-on-k6-telephone-bo... there's a note about Hull's phone boxes at the bottom of this page.

If the title simply said "AI is out-performing humans at CTF" then none of this confusion exists. Nothing is "broken," we don't need to be superfluous with "frontier," and the point is still there.

I've found the first, and most important, step for any team or organisation to eliminate concerns with NFRs, "tech debt", and whatever else it may be called, is to stop giving it a name.

I'm being completely serious. By giving it some kind of distinct name, you are giving license to it being ring-fenced and de-prioritised by someone who doesn't (but, arguably, probably should) know better.

Quality matters. It hits your P&L very quickly and very hard if you don't maintain it. So it is as important as any other factor.

Ditto, launchpad.net is also extremely flaky.

I do trunk based dev. My colleagues prefer git. I still prefer to use jj.

It doesn't need you to think that way at all.

`jj new` simply means "create a new commit [ontop of <location>]" - you don't have to describe it immediately. I never do.

I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.

No that is correct when in colocate mode (which is the default mode). Simply removing the .jj folder will "de-jj" the repo entirely, but will leave you in a headless state. Simple to fix with a `git switch` though.

If you are _not_ in colocate mode, the .git folder is located _inside_ the .jj folder. So worth checking!

This is literally jj's schtick and reason for existing, so I wouldn't be surprised if you decide it is not the tool for you.

You don't replace. jj is backed by git anyway.

Tbf you wouldn't use/switch to jj for (because of) those kind of commands, and are quite the outlier in the grand list of reasons to use jj. However the option to use the revset language in that manner is a high-ranking reason to use jj in my opinion.

The most frequent "complex" command I use is to find commits in my name that are unsigned, and then sign them (this is owing to my workflow with agents that commit on my behalf but I'm not going to give agents my private key!)

    jj log -r 'mine() & ~signed()'

    # or if yolo mode...

    jj sign -r 'mine() & ~signed()'

Claude's settings don't appear to be in sync with the published settings schema[0].

[0] https://www.schemastore.org/claude-code-settings.json.

Or a colon:

    Windows Subsystem for: Linux

I switched to Jaq[0] a while back for the 'correctness' sake rather than performance. But Jaq also claims to be more performant than jq.

[0] https://github.com/01mf02/jaq

Yes but it is easy to abuse/misuse IME, in that I think it requires one to maintain your own sense of discipline for the principle separation rather than the library/framework guide you into it. The threshold between UI and state management is comically easy to confuse.

Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.

Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.

The humans operating the LLM are accountable.

Except your team is full of occasionally insane "people" who hallucinate, lie, and cover things up.

Wait.. are we talking about LLMs or humans here?

I stand corrected. It makes sense that it is a chroot/rootfs rather than fully independent VMs.

re: side-by-side running, I always get socket and/port port problems when doing that. Without having looked into it at all I figure it is NAT collisions.

Every time you run `wsl --install <distro>` you are creating a new VM. Every time you run `wsl --unregister <instance id or name/>` your are removing a VM.

It is these two operations at the heart of OP's app.

    diff --side-by-side

Unfortunately not. Git clean still tries to, well, clean it. Unless I goofed it, which is a >0 possibility, I will happily concede.

Since using jj I'm on the lookout for some kind of setting that will exclude the .jj folder from the repo _and_ any operation including git clean, without having to add it to the repo. I.e., make it completely invisible to git including `git clean -xdf`!

At the moment I'm making do with aliasing `git clean -e .jj`

In the 20 years I've worked in software. I've never even seen a shop that works this way. From 20 person teams to 10,000 employee companies. Maybe I've been lucky. but to me it reads as a straw man. Something to punch against that doesn't really exist

30 years ago it was the norm. It really is true that the industry (standard) has shifted a lot in that time.

But I work at a place like this right now. I was hired by the new CTO to help them change this, having spent the previous 20 years actively avoiding places just like this.

Project-based planning by a roomful of not-technical people: Funding, scope, design, shape of team, deadlines, tech stacks, vendors etc. all "locked in" before any engineer is even approached, let alone asked for input.

I cannot overstate how uncanny it feels to be working here - like I have actually time travelled back to the 90s.

Frameworks are a category of development tool. Things that developers utilitise to be productive.

They licensed Brassic, it was filmed for Sky One, not Netflix.

I've worked at many big banks and corporations. They are all held together with the proverbial sticky tape, bubblegum, and hope.

They do have multiple layers of redundancies, and thus have the big budgets, but they won't be kept hot, or there will be some critical flaws that all of the engineers know about but they haven't been given permission/funding to fix, and are so badly managed by the firm, they dgaf either and secretly want the thing to burn.

There will be sustained periods of downtime if their primary system blips.

They will all still be dependent on some hyper-critical system that nobody really knows how it works, the last change was introduced in 1988 and it (probably) requires a terminal emulator to operate.

It started long before that. Cloud meant they were under drastic threat of being abandoned, because the cloud was (and still is) dominated by linux compute.

DotNet were shook, and shook bad. They went all out to make their runtime "cross-platform" because they faced an existential thread from lamdba+node.

The rise of the MBP also saw their dotnet ecosystem under thread from the other end of the stick - the developer end. Visual Studio cannot run on macos, so competitor IDEs that can were rising in their numbers. Hence the push for VSCode to try and claw back some IDE market.

It was the correct paradigm all along

Debateable.