I think every time I swipe I need to do at least one correction like this, where I type one similarly spelled word with as minimum an edit distance as I can think of in the moment, then do a manual correction.

Some “DEI” was high level measures like recruiting at a broader set of universities. But in the last 5 years it routinely got down to discussing the race of specific individuals in the context of whether to hire them or enter into business relationships.

So seems like all this talk by HR people didn't really change any hiring practices. It's also funny how everyone is outraged by the DEI programs, instead of the real discrimination that is happening in hiring.

If someone is racist in a manner that's outweighed 10:1 by opposite racist practices, that's something we do want to stop, but it shouldn't be top priority and definitely shouldn't be treated as the example of what racism looks like these days.

The metric-goal gets pushed down to lower hierarchy levels, and from then on, all it takes is turning a blind eye and you get the results we've seen in the court case I cited above. The smart ones just don't put it in writing.

I can't find the Microsoft thing, but apparently among fortune 500 companies only 1.6% of CEOs are black. Even double that would still be an extremely low number. So unless you think some truly cosmic random odds happened here, that 1.6% is evidence of lots of racism.

Also, the study suggests that, even with this flawed methodology, a bulk of industries are in the least discrimination category with only a 3% lower callback rate for “black sounding names.”

And the bulk are not at 3%, the bulk are between 5 and 10. 3 was the absolute lowest.

Also you didn't mention the CEO thing, does that mean my numbers were sufficient to address that worry?

The explicit discrimination in universities against whites and asians is huge in comparison: https://nypost.com/2023/06/29/supreme-court-affirmative-acti.... A black applicant to Harvard with an academic index in the 5th decile had an 800-900% higher chance of admission than a white or asian candidate with the same qualifications. This isn’t just CEOs. The pattern was similar at UNC, a state school.

The least single industry was 3%. And each single industry is a very noisy data point, based on a couple companies and needing more data points. By the time you aggregate into more solid data, like those bigger categories, it's more than 3%.

But the whole thing could use better methods and more data for sure.

> The explicit discrimination in universities against whites and asians is huge in comparison

In comparison to this specific resume effect it's pretty big, but that was just a basic example, not an attempt to list the biggest issue.

In comparison to the fortune 500 CEOs the overall effect here is smaller (no I'm not going to look at 5th decile in isolation).

Also even after this bias was applied, they're admitting a below-population-average amount of black students and a far above-population-average amount of asian students. So there's a bunch of other data necessary to properly analyze what's going on and how bad it is. Should there be a super tight correlation to academic decile? There are huge differences in school quality that muddy the signals, and those differences often correlate with race.

I'm not saying they did nothing wrong, but I'm saying it's unclear what the numbers should have been.

Made me wish for a simple VPS, an ansible script to setup nginx and fail2ban and all that shit, and a deployment pipeline that scp'd a single binary into the right place.

The better solution in my experience is to create an entirely different account to your production environments and just deploy things there to test. At least that way you're dealing with the real SQS, S3, etc, and if you have integration problems there, they're actually real things you need to fix for it to work in prod - not just weird bandaids to make it work with Localstack too.

This is what people are missing. Even those "slow" apps are faster than their alternatives. People demand and seek out "fast", and I think the OP article misses this.

Even the "slow" applications are faster than their alternatives or have an edge in terms of speed for why people use them. In other words, people here say "well wait a second, I see people using slow apps all the time! People don't care about speed!", without realizing that the user has already optimized for speed for their use case. Maybe they use app A which is 50% as fast as app B, but app A is available on their toolbar right now, and to even know that app B exists and to install it and learn how to use it would require numerous hours of ramp up time. If the user was presented with app A and app B side by side, all things equal, they will choose B every time. There's proficiency and familiarity; if B is only 5% faster than A, but switching to B has an upfront cost in days to able to utilize that speed, well that is a hidden speed cost and why the user will choose A until B makes it worth it.

Speed is almost always the universal characteristic people select for, all things equal. Just because something faster exists, and it's niche, and hard to use (not equal for comparison to the common "slow" option people are familiar with), it doesn't mean that people reject speed, they just don't want to spend time learning the new thing, because it is _slower_ to learn how to use the new thing at first.

[1] https://en.wikipedia.org/wiki/The_Secret_Life_of_Machines

    function x() {/* ... */}
    const x = function() {/* ... */}
    const x = function foo() {/* ... */}
    const x = (function() {/* ... */}).bind(this)
    const x = (function foo() {/* ... */}).bind(this)
    const x = () => {/* ... */}
    const x = () => /* ... */

That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a frustrating experience.

I can make sure my code is good before I submit it for review, not when I'm just trying to make sure my work has been saved so I can continue working on it later (commit).

But if need be, I will spam my commits locally with `—no-verify`. Once the code is ready, I reset to head and remake them as nice, conventional commits.