> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
The article discuses that specific subset of users who are into puzzle solving, so we should ground this discussion around that point and not fall into the “tool x is good/bad” pointless debate.
> … discretionary friction; designers or product folks adding features or complexity.
This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
>> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
I think it’s fine if that’s your hobby, but I agree that in a professional context one should be much more critical of their tools. Even asking “why do I need a tool for this at all?” will reveal shortcomings in processes, data structures or other tools that will reap much greater rewards if effort is put into fixing those instead of optimizing use of a quirky tool.
Just to be clear, software development itself is not deterministic, though? The software developer pushes a given business process from less-deterministic toward more deterministic? When we say we’ve “abstracted LLMs out of a process” we’d also say that we’ve abstracted software developers out that process as well?
Why can’t my firm react if we find out we’re being undercut by a competitor? Or are you saying that we “know” only in a theoretical, “we can’t prove we’re not being undercut” sort of way, but without “proof” we can’t take action?
This is definitely manageable: canonical meta tags and other metadata; update the URL to a canonical permalink that encodes the language preference; a banner that informs people that there is an alternate version, etc.
Isn’t the client-side case something like “the banking app you’re entering your account password into is the binary the bank created and not a compromised binary that will drain your bank account”?
Why is attestation always bad, all the time? When two people interact there’s a trust/risk calculation on both sides. Isn’t attestation just a means of reducing risk for both parties? (We can debate who should control the attestation process and how it should work but your point 1 suggests that there is never a good form of attestation.) What would we do instead?
> Overall the evaluation of success was one of the most challenging parts of the project. As a developer, I’m used to building features that either work or don’t and there is often an objective way to measure how well a feature performs. For messy real world data it was hard to evaluate how good or bad the pipeline was. Furthermore, it was easy to start optimising for a specific parameter or route and find later that this work led to severe degradations in other areas.
> Verification becomes hard to reason about because there is no ground truth for points of interest, there are no red/green unit tests for taste. I’m sure these are familiar challenges to data scientists and that there are frameworks and evals for working on them. This will require more iteration and manual overrides. Hopefully with feedback and collaboration from the community. But for now I’ve shipped V1…
I suspect LLMs may be able to help us quantify our taste because they can keep track of so many data points all at once, where we have to lossily abstract these details away.
But the larger point still stands: Limited liability was granted “on the front end” without the entity needing to demonstrate a minimum amount of capital. You’re only pointing out that in the U.S. that it’s possible that “on the back end” the owners of the entity might become personally liable.
> [L]eadership thinks (likely correctly) that implementing them would just hurt company’s bottom line.
Exactly. There's little "win" here for the business, especially when the simpler "just cap at n requests" solution exists. Pursuing this solution:
- introduces more technical complexity (increased cost of developing, testing and maintentance)
- forces overage costs onto the vendor, who will then... increase prices to cover these costs, which upsets customers and makes the company less competitive.
- doesn't improve cost prediction (since n requests can be costed out a $/request quite easily and reliably)
(The cynical will say something about "the business has an incentive to _not_ fix this issue because they get paid for overages", but this assumes that Cloudflare has the, "monopolistic" market power to make customers unhappy and still charge whatever they want. In this case implementing billing caps wouldn't do anything because Cloudflare could just... charge whatever they want.)
Counterpoint: I’ve had recent support calls with two large corporations, both with humans. In both cases the humans lied about what could be done to address my issue.
In one case I was literally repeating back to the human what I’d just been told, and getting them to confirm that what I said was correct. First bill arrives and I find out the truth.
Second case I was told I’d have to cancel and create a new account to add a service. I decided to keep my existing account and learned that there is a web page where I can easily self-serve and add the additional service in one or two clicks. (I assume like the human actually made more money for “new account signups”.
My point is that the feeling of being a valued customer is really independent of whether you’re interacting with a human.