Except there is! On average, McKinsey-lead businesses perform better: https://archive.is/HLA3s

But the argument I used for advocating Docker in environments where people were not fans of it was that the Linux container had become the de facto standard unit of deployment. There is so much tooling written under that assumption, and if you want to use any of that tooling, you need to package your deployments as Linux containers, even if you want nothing to do with Docker otherwise. That's why it had so much momentum.

Then a fourth point I think you're missing is that the concepts used by Docker are relatively simple. Before I understood what Linux containers were, I used to think things like, "Why would I care about Docker when I can isolate my processes with Linux users, cgroups, namespaces, etc." What I didn't know at that time is that "Linux users, cgroups, namespaces, etc." is exactly the thing Docker was giving a friendly UI to.

If the component removed is a human, the situation is worse. Then you're creating an incentive to hide mistakes and assign blame to others. This makes it even harder to improve the system properly, because then the information you need to improve the system no longer gets to you undistorted.

That's why we have to design systems that don't assume components are perfectly reliable, and ensure any human components that we're not out to get them, we're out to create an environment where they will find it hard to make mistakes.

This is the sort of thing that's difficult to argue economically for studying with proper randomisation and everything, but an observational study can be made on open source repositories (even in projects where the main contributors are on a corporate payroll) fairly easily with LLMs these days. I wish I had more time to pursue things like this...

Comments URL: https://news.ycombinator.com/item?id=50179162

Points: 4

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=50172832

Points: 1

# Comments: 0

My main concern is that the tall glyphs for less than < and greater than > will disambiguate badly with actual Unicode left 〈 and right angle brackets 〉.

Edit: I also realised just now the ASCII hyphen-minus - is quite long with this typeface, which makes it ambiguous with the longer dashes. (It looks freakin' great in pure ASCII environments, though!)

Last I looked into it, using other harnesses with a subscription was a TOS violation that Anthropic seemed to take quite seriously (with automatic rate limiting etc.)

But as the author says, under a heavy-tailed distribution (which service times typically have) the mean is dominated by the high percentiles!

What I'm looking for is an exit rule, like the one speculative traders have to tell them when to withdraw from the market. A speculative trade is based on a bunch of assumptions about how the future will go. As soon as there's evidence those assumptions are not satisfied, the speculation goes invalid and the trade should be called off to avoid expensive losses.

Likewise, I want a way to back out of advice/treatment as soon as it's apparent it's not doing the thing it's supposed to do. But doctors hate getting that question, and often outright refuse to answer it. I get that it's a very difficult question and they would have to spend more time than they like to come up with a sensible answer. But I think that's only part of it.

Sometimes, it seems like the advice they give or the prescription they write is for just about anything that could plausibly be used as an active placebo. Then they hope the problem will resolve on its own, and I'll credit the doctor for it. A typical tell for when this happens is when they have two roughly equivalent alternative treatments they could prescribe[1], and they choose to start with the one that would take four months to evaluate, rather than the one that would show effects in three days.

[1]: That's another question I like to ask, and they hate to answer: "If this turns out to not work, what would be the next thing you'd want to try?" Maybe they have a good reason for refusing to answer it. Or maybe they don't have a plan in mind, but are improvising as they go.

Or none of the above is true, and what they really hate is the implication that they don't know what'll fix the condition, and are making a qualified guess. But they are!

Sorry, this triggered my fact-checkitis. I opened Wikipedia's list of presidents of the US and ran this in the web developer console:

    Array.from(document.querySelectorAll(
        '#mwgA tr > :nth-child(3) span[data-sort-value]'
    ))
    .map(x => x.getAttribute('data-sort-value')[0])
    .reduce(({total, firstHalf}, c) => ({
        total: total+1, 
        firstHalf: c < 'N' ? firstHalf+1 : firstHalf
    }), {total: 0, firstHalf: 0});

    Object { total: 47, firstHalf: 31 }

    65 % ± 13 %

I didn't expect it, but we might actually have reason to believe US presidents more often than not do have names starting with letters from the first half of the alphabet.

Edit: But I just realised English letter frequencies have 54 % of the probability mass in the first half of the alphabet, so that's probably a better null hypothesis than the even split. It's also compatible with the actual presidential statistics.

I think you overestimate the level of DBA skills smaller startups have in house.

If you have found a way for a company to hold off on taking on customers until they can afford a proper DBA, I'd love to hear more about it. But it sounds backwards to me. In my experience, it typically goes the other way around: only after taking on enough customers to be decently profitable can a company afford a real DBA.

Until then, the choice used to be between managed database services or striking luck with a developer that had some database interest. These days, it's between managed database services, striking luck, or giving the developers access to an LLM. The LLM doesn't replace DBA skills that used to be there. There weren't any DBA skills there to begin with.

However, these days, I notice my DBA skills atrophying because LLMs have encoded most of the answers and diagnostics I need in their weights. Coupled with something like Nix, spinning up new servers including backups and everything, it's easier easier than ever to run your own production database instance.

I have to admit my experience lies mostly in Brood War, and surely "the game responds intuitively to user inputs" is not one of the ways you'd describe it? That game is notoriously clunky in how it handles user input, both in terms of selection limitations, unit path finding, etc.

Don't get me wrong. I love Brood War. It's the only competitive video game scene I've really cared about. But I love it for its clunky user experience (which requires mechanical mastery in addition to a sound tactical mind), not because it's so smooth.

Comments URL: https://news.ycombinator.com/item?id=50051511

Points: 1

# Comments: 0