obeattie

He speaks Finnish too (though I believe with an accent). https://youtu.be/Pt-X82HZlOU

It’s helpful to put this issue into perspective. But dismissing issues as not worth caring about on the grounds that there exist larger problems is fallacious and, to me, quite a dangerous way to live life.

“Why worry about your town’s water quality when some countries don’t have access to clean water?”

“Why go to the dentist for a cavity when some people have no teeth?“

“Why campaign for animal rights when there are some many human rights abuses going on?”

In principal, neither do I. What I take issue with is crafting elaborate but completely false bios to make these sound like real artists. That seems slimy to me.

At Monzo we stuffed cards into envelopes by hand, printed mailing labels on thermal printers using slapped-together Python scripts, and filled up mailboxes in the local area every night. We kept doing it pretty much like this until we were sending out several thousand cards per day.

https://monzo.com/blog/2017/06/09/journey-of-a-card/

You are right about performance, but does it really matter?

It feels like this is the sort of tool one needs (very) infrequently, and those cases don’t seem like the sort of thing where seconds really matter. I think it’s plenty good enough.

I prefer to focus on how grateful I am that the author has made this and published it for free.

Without understanding the minutiae of this, couldn’t someone just write a program that we can pipe any output to, which strips colour commands from its input before writing it back out? Does such a program already exist? That wouldn’t require every program to add support for an environment variable.

TIL. Such a useful tip, thanks.

We have very different expectations. I'd be pretty annoyed if I couldn't browse and sort my photos by date taken.

I think Notion might actually work best in personal/small environments, and this seems like a smart move to encourage more of that kind of use. My exposure to it is at a large company, where it really does not work well.

You just typed your comment into a <form>

I’ve been thinking about going the other way a bit recently: having bots consume input from and add their output to a Google Doc.

There are so many processes in most businesses which involve many humans collaborating on templatised documents. Google Docs/Sheets fits into these workflows very well, but there’s often scope for some partial automation in there too - pulling information from databases and outside sources and keeping it in sync, etc. Developing custom web apps for each case is too much effort for too little reward, takes users out of a familiar (and well-liked) interface which updates in real-time, makes you reimplement permission models, etc.

Not something I’ve explored properly yet so I don’t know if the APIs are rich enough to make this easy, but I would really like to give it a look.

That post, which was very popular, immediately came to my mind too.

It also feels like the logical next step to the very widespread testing found in countries like South Korea.

I think the parent is talking about compilation speed not runtime speed.

I don't think an equivalent of the Current Account Switch Service exists in the US, which is a shame.

But I don't think this is crucial. We had around 5,500 switches via the Current Account Switch Service in May, but added around 200,000 new customers.

Many millions of dollars per year. I care about how my providers behave when they have issues, and I can't see why you think it's not at all relevant.

I mean, I care. All else being equal I’m not sure why you wouldn’t want good communication to your customers.

I really don’t get this. There’s a huge number of complaints about poor communication from companies like Google and AWS during every outage. Yet they remain seemingly indifferent to how much customer trust they are losing, and the competitive edge the first one to get this right could gain.

The question of whether the driver should have had their hands on the wheel (clearly they should have) is distinct from the question of whether the Autopilot should have avoided this crash.

The amount of fraud in the system is eye-watering. Everyone pays the price of that whether they realise it or not.

Yes, though your bank has to also support it.

https://www.amazon.com/gp/help/customer/display.html?nodeId=...

CVCs cannot be used for recurring payments (beyond setting the subscription up) and merchants/acquirers are forbidden from storing them at all.

It’s definitely a thing in Europe, but many merchants don’t bother to support it. Large ones like Amazon definitely do though, as do all merchants who use Stripe.

This isn't new and has existed for nearly 20 years. Visa's implementation is called VAU (Visa Account Updater[1]) and Mastercard's is ABU (Automatic Billing Updater[2]).

Issuers (banks) have to provide the details of these new cards to Visa/Mastercard, and the systems are certainly capable of updating the details of debit cards. It sounds like TD had a bug where they sent updates for cards which they shouldn't have. ie: TD broke their own rule about only enrolling credit cards.

Card details which do not automatically update are really frustrating for customers – especially on services like Uber. In nearly all cases the customer is going to go and give the merchant their new card details anyway. My understanding is that if card is compromised (as opposed to being lost) then banks should not provide the new details. There isn't really much _additional_ privacy or security risk here beyond those posed by merchants/acquirers holding onto card details already – provided banks do it right.

Though zooming out a little, long-lived payment tokens shared among every merchant a user shops with being the way things are still done is crazy. How long it has took to roll out EMV (chip cards), especially in the US, shows how hard it is to effect change in vast, three+ sided marketplaces like card networks.

[1] https://developer.visa.com/capabilities/vau

[2] https://developer.mastercard.com/product/automatic-billing-u...

Disclosure: I work for a bank.

My understanding was that in At-will states, an employer-employee relationship could be terminated without reason or notice unless there is a contract in place that says otherwise. My (naïve) presumption was that companies would want to put these kinds of contracts in place for their senior leadership.

I knew that – for better or worse – this is common for many employees in the US, but had always assumed that companies would want more security with their senior leadership. Thanks; TIL.

"We currently depend on the continued services and performance of our key personnel, including Benjamin Silbermann and others. Mr. Silbermann’s employment, and the employment of our other key personnel, is at will, which means they may resign or be terminated for any reason at any time."

Genuine question: is it normal for the CEO of a company in the US to have no notice period?

if someone doesn't know what a cartesian product is (high school level math), perhaps they shouldn't be allowed near a database...

This is such an intellectually snobbish position to take. I can tell you that I didn’t know this term when I first interacted with a database, and if someone had told me the above, I would have just felt stupid and given up.

The fact you learned what a Cartesian product was at high school shouldn’t preclude someone who hasn’t from trying to build stuff and experiment with tech. Not everyone learns things the same way, or in the same order, and that’s okay.

I did read the article and I don't find what the author thinks is a "nice illustration of a cartesian product" easy to grok at all. Similarly, I think I would have found the the diagrams further down hard to understand versus a Venn diagram.

But that wasn't my point; if other people find these illustrations helpful, that's awesome and I wouldn't want to stop someone inventing something new and useful. My point was that I violently disagree with one-size-fits-all proclamations like "Say NO to Venn Diagrams."

Honestly, if it were not for Venn diagrams, I may have never learned how SQL joins work. It might not be perfect, but if you'd tried to make 16-year-old me understand relational algebra in order to grok how the joins in his Django site were working, he'd have given up before he began.

That's not to say that other ways of illustrating things don't have merit, but broad statements like "say NO to Venn diagrams" just aren't helpful. If people find Venn diagrams a useful tool (and their proliferation indicates they do), I don't see the harm. They didn't stop me going deeper on stuff like relational algebra when I was ready to.

The real issue is that this is more nuanced than is appropriate for one-size-fits-all advice. "Everyone should use a monorepo" isn't helpful, but neither is "everyone should not use a monorepo."

Sadly, this article falls into the same trap.