While I definitely understand what the author is saying, the reality is that, for the majority of writing developers will be doing, having something that is easy-to-produce and easy-to-consume is paramount. There are tons of more powerful and flexible options than Markdown, but none that let you create a document that is both computer- and human-readable quite as quickly. Documentation that is written is better than documentation that isn't.
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.
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.
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.
This was the idea behind the late-Cold War "high/low" concept that gave us the F-15/F-16 in the US Air Force, and F-14/F-18 in the US Navy. Initially the F-35 was supposed to be the "low" companion to the "high" F-22, but, with the end of the Cold War, that changed.
One major issue that the US has run into with deploying that strategy, in the absence of great power opponents, is that the largest long-term costs are not the airframes, but pilots and pilot training. An F-16 pilot isn't cheaper than an F-15 pilot, and getting hours for an F-16 pilot isn't cheaper than getting hours for an F-15 pilot, other than the lower fuel cost for the F-16.
That said, the F-15X that the USAF is procuring is basically going to be used as a lower-cost-than-F-35 "missile truck," so not incompatible with what you suggest.
Although a significant cause of the kill ratio issue over Vietnam was restrictive rules of engagement, which prohibited beyond visual range engagement with missiles such as Sparrow, which the VPAF had no counters to whatsoever. These rules of engagement effectively required these turning dogfights, but would not have been present in a large-scale shooting war between NATO and the Warsaw Pact.
This does, of course, beg the question: how well would an F-35 do in a conflict with restrictive rules of engagement, such as might be found in future US-Iraq/Afghanistan-style conflicts.
This is exactly correct. The cost of holding the entire object in memory, for any significantly complex statement, is going to add up quick if you're dealing with large numbers of users/pageviews/etc. The cost of pre-calculating everything in the object for any complex math similarly gets large when you're dealing with something large-scale. Early returns matter a lot with scale, and make [code line of sight](https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea...) much clearer -- which matters a lot of if your team scale is larger, as in many companies that might have multiple teams working on one shared codebase.
I'm more inclined to the latter. Sure, they hedged their bets in their SAFT, but to say "our plan involves not being regulated, and we give up if we are" strikes me as silly.
But you're right, maybe they expected a different level of regulation than they were ultimately going to be subjected to, and maybe they just didn't communicate that.
Come to think of it, if I were a big bank, skilled in handling regulation, I might absolutely give a bunch of $ to a startup in this space, knowing I'd, at worst, own a big chunk of them, and, at best, prove out the market with someone else's time, then get to launch myself, with my own giant regulations team behind everything.
I'm extraordinarily confused as to how this was not an issue handled before Basis got to this point. It's not a secret that regulators would like to have purview over these types of assets, and that regulators have in fact successfully pursued those involved in other cryptocurrencies that turned out to be fraudulent. Of all the risks the Basis founders had to confront -- building a new technology, proving out a new algorithm, getting interest from others, etc. -- understanding at least the threat of regulation seems like among the simplest.
So true on the "afternoon drowsiness" thing! I hadn't thought of that.
A friend who is a USMC veteran used to tell me that standard procedure in a briefing was: if you're tired, go stand up in the back. Super hard to fall asleep standing up. I bet there's a big chunk of that here.