HN user
It would find it clearer if:
- “up” and “down” was explained. If I bet “down” I’m betting my stock will underperform the monkey index? And if I am correct, I will make money (short the asset) or simply loose less than if I’d invested in monkey?
- loosing less money was green (win) when monkey is down even more.
That’s “Sysadmin work teaches you the value of stacks” from May 20, 2013. AI hallucinated a post named “The Stack” from August 19, 2013.
Why did you leave out the “strong opinion” part?
No because “strong opinions” mark you as “aggressively conventional”: Nobody can tell if your opinions are “weakly held”, and most people won’t try and find out.
Instead you need to find like-minded people who are willing to challenge their thinking.
The housing market is highly dependent on the job market so no, it’s not “being fussy”, it’s “I need to live here so I can have a job and income”. Unless you’re suggesting that people should quit their jobs and go get that cheap house in the middle of nowhere?
No, but I will bet you that QQQ will not loose 1.2% of its value due only to SpaceX going to $0.
There is a massive downside to premature inclusion of a stock that is initially overvalued
Define “massive”. SpaceX is only 1.2% of QQQ.
… internet fame / personal branding.
Also known as “social proof”/“social credibility”, and it’s a common mistake to assume it has no value whatsoever.
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.
I would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off.
Strongly typed and weakly typed do not seem to have good definitions.
Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
I don’t think this is anything new, really: Businesses have been running software that we’d call a “big ball of mud” [1] forever.
A common way to market to these firms is to be very easy to find when their software starts to have serious issues.
In America, at least, the school curriculum spends a lot of time talking about dictators.
I don’t think this is actually true. What’s your source for this? States set K-12 curriculum.
… deterministic processes…
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?
link aggregators
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?
Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.
I guess this just isn’t obvious to me. Where do you see the boundary between “interface to the os” and “programming language”?
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.)
The playlist is hilarious and really helps nail the feeling of driving around in circles! Love it!
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.
How did you make the illogical leap to “could not”?
Repeatedly requesting time/budget to fix an ongoing issue is a requirement of any half-decent manager. If they’re reporting issues then just smiling blankly when asked “what can we do about it?” they’ve failed their basic job duty.
But for high quality work [a code review is] indispensable.
The argument here is that all code reviews are done with attention and care, but quality of a code review is highly dependent on the reviewer and the team’s review process, and in the real world the quality of reviews pretty much follow the same distribution curve as, say, agile project management: For the time invested in reviewing, a handful of teams get excellent utility from them, most teams get little benefit, and a sad few actually cause harm.
If most code reviews provide only a little benefit at base for most teams, recommending that most teams should also delay shipping quality work is going to sound a lot like bad advice.