tatterdemalion

Be the change you want to see in the world. Find a physical copy, rip it, upload it.

There are private trackers where you can earn a currency based on seeding uptime, not actual upload. Then you can spend the currency to get more download buffer. Farm the currency by just downloading and seeding a bunch of freeleech stuff.

the code you have to review hasn’t been thought about

Isn't that just admitting that the author of the PR has not read the code they're submitting? If I caught wind of that I would reject the PR on principle without even reading all of it.

If you are competent and using an LLM to generate code you’ll put your name to, that mean reviewing a lot of code that isn’t up to your usual quality, rather than just writing it yourself, which is frankly extreme tedious, demoralising, and mentally exhausting

That's not been my experience. While there are often multiple iterations of feedback I go through with an LLM before I consider a PR ready, it's rarely a significant deviation from what I already planned out. Most often it's just basic code organization that I forgot to specify (especially if the area of code it's working on was already poorly organized), or tradeoffs I wasn't even aware of until the code was written. The amount of effort per cycle is usually very small, and I'm able to work on other things in between (like reviewing other peoples' code).

If you’re not competent, you wont catch any of that, and it’ll either just go to production, or it’ll fall to someone else to review it.

This sounds mostly like a workplace culture problem. It's always been important to have a high bar on code review to catch poor quality. Not to catch bugs per se, but to catch code that isn't properly tested.

you’re going to end up flooded with low quality commits from coworkers who’ve either given up or weren’t competent in the first place

Again, that's a workplace culture problem. You need to either stick to your principles and try to enact change, quit, or go along to get along. I'm sorry if the last option is where you're at and that does suck.

it’s much harder to train people to good practice when they’re abdicating the thinking to a machine

I totally agree. That's something each engineering org needs to reckon with, lest they burn out the devs who care about code quality.

Spending your day reviewing code churned out by an LLM, is a soulless and tedious way to spend your life.

Someone has always had to review the code. And the author has always been responsible for their PRs meeting a quality bar. I don't see how this is any more soulless or tedious than before we had LLMs. Maybe you just never enjoyed reviewing code in the first place, and now you have to do it more?

I think you're thinking about this in a very negative way when you also have the option to see it as an opportunity. You said yourself that now you're focused more on design and architecture, and most of your time is spent reviewing code. That sounds like a relatively good place to be, assuming you're happy with the quality of the code. Now you can spend more time solving new, harder problems that you couldn't before.

I know what you mean, but this is also essentially the same rhetoric that actual racists use to refute good policies like DEI. Diversity is a good thing, and I'm not sure you can achieve it by letting everyone self-police their behavior towards someone of a different race. Racism simply exists in our culture whether or not people are aware of it, so we need policies that counteract it.

Maybe a more persuasive way of saying the same thing: if you agree that some ethnicities or social demographics are historically disadvantaged and need more help than others, why would you not try to focus policy to prioritize their needs? It's similar to making policy that reduces child suffering at the expense of some freedoms for adults.

That said, I also believe it's good to try making policy that doesn't explicitly target specific races if possible. For example, strengthening workers' rights in general improves the lives of an entire economic class, and coincidentally it would disproportionately help Black and Mexican people (per capita).

I play a card game called Spitzer, where one of the rules is that the holders of the two black queens end up on a team. It is incredibly common to say things like "you beat the blacks", etc. Context is everything.

While funny, the hero could have done both: save them and register them as organ donors.

Just because someone making such an argument identifies as a utilitarian doesn't mean all utilitarians make flimsy arguments.

You are correct to point out the distinction between race conditions and data races. Rust only rules out data races.

I don't know whether the race in question was a data race or not.

I would still wager that Rust code generally has fewer race conditions than C, given that mutable aliasing can be used as symbolic prevention of race conditions, i.e. your &mut T doesn't necessarily need to hold data; it can represent some domain concept.

aren’t language specific

There are actually languages that guarantee deterministic concurrent execution, and this can rule out larger classes of race conditions than just data races. See the Bloom language and CALM theorem.

It's been replaced by the overuse of confusing foo's own [implied noun] phrases.

I could attribute the race condition just as much to their use of the C language as to AI.