stanleydrew

This is quite a list, thanks!

It's pretty clear that Google (and other tech companies generally) wasn't prepared to be a "publisher" of images and text, generated by its models. Tweaking the search algorithm to favor a certain viewpoint was already a suspicion of many partisans, but this takes it to a whole new level.

I do feel like it's unfortunate that the conventional understanding of these models now is that they are for "searching" or "q&a" which makes users inclined to believe that they should be omniscient oracles.

> I just generally feel that perhaps this article and what you are referring to have something very specific in mind when you talk about webhooks and what they're used for.

I'm not the author or GP but I think you're right and can give my two cents. The specific thing these authors have in mind is a SaaS that offers an HTTP API to manipulate data and a set of HTTP webhooks to notify users about changes in the data. *If* the only thing SaaS users do within their webhook handler is make an API request back to the same SaaS, then the argument is there's a bunch of unnecessary work to shuffle bits back and forth across the internet when the SaaS could just offer to run a function.

> I'd just argue that there is a much broader set of use cases out there for webhooks...

Agreed, which is why there are many commenters here who are confused. The "webhooks suck" take is overcooked without context.

> Shouldn’t the results I get from a paid service at least be better than a bad StackOverflow suggestion that got down-voted to the bottom of the page (and which would probably come with additional comments and suggestions letting me know why it was ranked lower)?

I don't know why you would expect this, when the model is likely trained on StackOverflow material (or similar publicly available code examples).

You don't. You just harness what they have and direct it while you can.

But one way to try is to wholly hand off greenfield projects within your company. The whole idea of a "startup within a company" is fundamentally flawed, but you can attempt it anyway.

> but I would hope they aren’t doing work the DB is already doing for you.

Sadly this is very much a thing that ORMs do all the time.

Is there reason to expect the writer must be fair and balanced?

My understanding is that Zelle transfers are just settled by ACH under the hood, which is the same system that settles checks.

However there is possibly some new "real-time payment" feature of the ACH network that could be equivalent to wire settlement, but I'm not sure Zelle actually uses it.

Parent has already explained, but here are the steps.

1. Deposit check 2. Funds are made available to you 3. You withdraw the funds 4. The check is later marked as fraudulent and the payer bank attempts to claw back the funds, with your account balance at zero

I think you may be misinformed about "electronic money transfer" at least in the United States.

As far as I know the only way to execute an immediately-settled electronic transfer is a wire transfer, which is inaccessible to lots of people and has an associated fee for nearly everyone else.

Ah yes, "you're holding it wrong."

I don't expect you to back off of your take, but you should really consider how and why you came to this conclusion.

If I put two different marketing messages on two different billboards to test whether one is more effective than the other, is that unethical non-consensual experimentation? If not, how is it different from A/B testing?

But that's not within your control. To use iMessage with Android users you'd need to convince them to use an iMessage client. Usually that means buying an Apple device, but with Beeper Mini the burden was reduced to an app install. But you still need Android users to take affirmative action for you to use iMessage with them.

Blue-bubble envy is real. I myself am a green-bubbler but every once in awhile I feel this tinge of "otherness" when I see "Loved an image" in the group chat.

Calling run-of-the-mill pump and dump schemers "smart money" offends the sensibilities. It's "smart" only in the most anti-social sense of the word, like believing it's "smart" to act in bad faith as long as you get some benefit from it.

> Why not?

Is this a serious question? For one thing, every founder will obviously know whether they are in-person or not, so it's not even possible to do a single-blind study.

That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly

This is a decent rant, and I mostly share your frustration.

But At least GCP and AWS have certificate authority products which essentially do work the way you want them to:

https://cloud.google.com/certificate-authority-service https://aws.amazon.com/private-ca/

Azure may well have one too, I just don't use their service.

This isn't a good analogy. Copyright is a real thing, and getting explicit consent from your contributors to use their copyrighted material is an important defensive measure.

I don't think the author misunderstands what the compiler is doing, just saying that it's probably unexpected behavior from the perspective of the program's author.

Parent comment didn't claim they were new to TW.

Seems you didn't get to the end: https://go.dev/blog/compat#go2

> you don't need all your data engineers to know how to draw conclusions from the data.

I'm not sure this is accurate. To the extent that a data project is underspecified (which, let's be honest, all projects are) then the engineers will end up making some decision somewhere that may have an impact on what's available for analysis.

If the engineers have some understanding of project motivation and hypotheses then they'll make better decisions.

Yeah I don't generally disagree, but the coordination usually has a more specific goal with more specific actions. Like, let's spend a bunch of money to buy ads supporting some legislation so that we can get lower taxes.

Let's use our influence over corporate decision making to try to get people to use buildings in order to prop up commercial real estate asset prices feels like a bank-shot at best.

Yes, this reads exactly like it was written by someone who's never had a leadership role, and probably doesn't want to hold such a role, but deigns to know exactly the motivations of people in those roles.

This isn't particularly well-argued. Just a lot of handwavy grievance about "elites" as though there's some kind of coordinated conspiracy.

This argument makes sense if you don't consider the large portion of the population for whom credit cards are unavailable.

It's of course not the same. But technical interviews aren't always just about "does this solution you wrote actually work." A good interviewer will be paying attention to how you solve the problem and how you communicate the choices you make along the way. Good naming is part of good communication.

Selling part of your company to venture capitalists is a status symbol, and lots of people will chase the status symbol even when it's not required and they don't have a plan for how to spend the money should they get it.

> I've experienced many times how highly skilled software engineers groan and sweat when they encounter shell scripts. I don't understand why, but it seems like people with a CS background are never really taught shell scripts and have come to irrationally fear them. It's sort of taboo.

It's not a lack of being "taught" shell scripts. It's the fact that shell programming constructs aren't well documented, your "standard library" is basically dependent on whatever binaries happen to be available on the filesystem, error handling is almost non-existent, etc.

It's very easy to write a bad shell script that "solves" a problem as long as a bunch of assumptions aren't violated. In my experience, senior software engineers are extremely averse to hidden assumptions and very concerned with reliability of the systems they build.