Which have ignorance as their root cause. Ignorance of the type of people that become ultra wealthy, and ignorance of the odds of becoming one of them.
We should “listen” to these people with the same attitude as we do”listen” to gas station lottery addicts, instead we give them WAY too much credibility.
"That guy has lots of money so he must be successful, clever, and probably correct, so I'm going to support them" is still an aspiration - and you probably should realise that there are people in dollar stores that think "One day, that could be me."
$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].
I agree you probably don't need top-dollar bay-area engineers for this, but hardcore outsourcing to a LCOL probably isnt going to work either due to novelty and generally being setup to do the more rote thing (generalizing a ton here obvi). This feels like something in the middle.
What a weird thing to say. The phrase “outsourcing to India” being used as shorthand for “you don’t need top engineers.” The nationality stereotypes are mean and degrading.
And at a macro level, often found to be accurate due to how the businesses in India operate. Poll the west's engineers: you'll find that engineering from India is not currently viewed very favorably, in general.
There are excellent engineers in India, but the system they operate in unfortunately doesn't allow them to shine.
That's fair, I shouldn't have commented that. I don't like the national stereotypes at all - I see "outsource to India" as being more about less expensive engineers than not needing "top engineers".
That said, I don't think "rewrite from one language to another" with inexpensive engineers is a pattern that works. Happy to be proven wrong.
Many of the large enterprises we work for did move software engineering work from HCOL locations in Europe or the US to India, often with disastrous results.
On Teams, channels related to AI are flooded with daily support requests from supposed engineers from India who clearly are not competent enough to set up GitHub Copilot or properly report issues they encounter during the setup.
And don't get me started on the shared libraries some teams located in India work on. If the library I need to use is full of obvious bugs where I wonder how any competent engineer could have shipped this to production, and then I see that the work has been moved to India, how am I supposed to feel about this?
> - 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.
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.
But the article is arguing it is broken. That’s the point. You can disagree but that’s very much that the author is writing about, not a curiosity, and that it’s these top models that are not custom security models.
It's like "Forklifts outperform humans in weightlifting". The problem, of course, is that a forklift is much easier to spot among athletes than an AI among CTF players.
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.
This is so important. This is your job as a software engineer. It shouldn't exist on a roadmap or get added to tickets. It should just be done in the course of your work.
If it does end up as a ticket that means you did something wrong in the implementation of a feature and that lack of quality got noticed. A business person is not qualified to weigh in on the importance of these things. All they know is "The page needs to load in $time", "The data should stay consistent", ...
You are the one who determines the how and quality maintenance is on you.
I treat it like housekeeping and treat features like hosting a party. Guests/stakeholders are people who want what you can make. The party is the feature they want.
They don't care whether it was difficult or easy for you to clean the house. They just assume keep your own house tidy ... and they know you don't when you only host once a quarter instead of once a month.
They assume you're a functional adult who manages his own space.
Tech debt is like that.
Thus - the business folk don't get a say in whether it's in the sprint - cuz it's not "the party". Instead it's your Scrum Master or whatever saying "hey kids - clean the mirrors and Jane this time you're sanitizing the toilet."
`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.
I don't usually do that right away, but I often use squash or absorb to move additional changes into a commit I already made in my stack. I think the spirit still applies if you take that course.
You can switch an existing git repo to jj by using:
jj git init --git-repo my-repo
I think (but CANNOT PROMISE) that just removing the .jj folder will bring you back, but definitely take a backup of .git before you try this in case I’m wrong.
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!
Aspirations.
reply