kaizendad

This is sure to put them ahead of Apple Pay, Samsung Pay, Google Pay, Zelle, and Venmo. Everybody will be excited to use the payment system that charges them the most money!

Seems to me that we will very, very quickly see why these teams were created.

Less snarkily, I appreciate that not everyone loved their work. But their work solved a particular problem, even if it created others. Now that problem is unsolved again. It will be interesting to see if a better solution to the problem appears by 2024, or if the decision is to allow that original problem to exist.

Fair, I hope I was clear in my post that I don't mean to say C++ is never the right choice, but... rarely.

This is good, right? There are better languages for most (although certainly not all) purposes, whether you measure "better" through features like memory-safety or through developer happiness or anything in between.

Most of the systems that were written in C++ in the past didn't have to be written in C++. Now they'll become hard to support, because they are in fact hard to support, and eventually they will be refactored or rewritten.

Same thing happened with Assembly and COBOL programs being written into C++.

As a marketer in a former life, I can't understand why somebody would do this. It's very cheap to get a separate phone number for each inbound channel and there's tons of software that will track which channels are working for you, starting at the low end with an intern and Excel.

I read this as "evil Microsoft Product Managers researched the market and understand the competition and if they decide to compete with you watch out because they will be evil folks who understand market needs deeply and are intimately familiar with competitors."

I mean, I get that's hard to compete with for a smaller company or an less-formal org, like those who maintain many OSS projects, but that's just... being a good product manager. If you don't like that, hire a Product Manager and get those skills yourself.

Absolutely! And yet no explicit planning for how they'd reword the manual in the future. That is the root cause of the real problem here -- not that there weren't backups, but that there weren't and the manual said that there were, and there's no plan to fix that!

It's interesting -- they ID the actual cause of the problem up top, and then just zip right past it. The problem wasn't the hardware failure, or the lack of backups, it was that customers expected them to have backups.

Gandi goes into some detail on the recovery process and on ways to fix the issue in the future. But, apart from some hand-waving, they don't have any specifics about how they'll communicate expectations better with their customers in the future.

Imagine the counterfactual: Gandi's docs clearly communicate "this service has no backups, you can take a snapshot through this api, you're on your own." Of course customers with data loss would've complained, but, at the end of the day, the message from both Gandi and the community would've been "well, next time buy a service with backups?" Yet there's no explicit plan to improve documentation.

I switched to https://www.honeyfi.com/ and couldn't be happier. It's really powerful for handling joint finances.

A "personal key" was a 16-character string that was used as a salt(?) for encryption and as a backup for lost passwords, https://www.login.gov/help/creating-an-account/personal-key/. Frankly, this change seems like an improvement. While text messages are weak, the other options are strong and widely-available.

I think this is exactly it. Offices are prettier than ever and also less conducive to work than ever. I bet most people would choose an office with actual quiet workspaces -- even full-height cubicles! -- given that commutes were also reasonable.

We have a very similar system here at http://www.synacor.com, and it works really well. The "Promotions don't unlock new responsibilities" thing actually has a big upside: you don't come in the day after your promotion and have the chance to fail at your new job, you were succeeding at it already.

The downside is that it really relies on EMs to work hard to make sure that ICs have clear, measurable plans to advance. At Synacor, there's a standard format for how these plans work, and all plans get review from senior managers, so it works fairly well, but a vague plan or one filled with details that are easily overcome by market changes will usually fail and the individual will not be promoted. It can also be challenging because, at higher levels, the plans often include improvement in multiple areas -- say, improving development skills, but also taking on more mentoring. If the developer learns and applies new skills well, but is having a hard time with mentoring, that will delay the promotion, which can leave a frustrated dev whose promotion is delayed.

It does essentially eliminate the Peter Principle, however -- people who are about to get promoted beyond their abilities will discover that before their promotion, and they'll stay in a happy spot.

The accessibility concerns are right on. Another thing to think about is not distributing them as a monolith, so that devs can pull only the features they want to use. One of the biggest benefits of an all-vanilla library should be a minimal download.