kaizendad

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.

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.

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.

But that's probably paranoid.

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.

What am I missing?

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.

Standing desks can be amazing for those of us who tend to sit like we're misbehaving second-graders. When I sit down, I rarely have 2 feet on the floor, I slouch not just forward but left or right, I spin in my chair... if there were a nun standing behind me, she'd whack me with a yardstick.

That makes sitting all day unhealthy for me. And I know a lot of people who fidget like this! When I stand, I actually have to align my body correctly so that I can, you know, stand up. My core does work, my legs do work, I'm not standing on one foot or slouching because that's harder when you're standing.

I could learn to have perfect posture, but I'm 43, it's not cheap to teach an old dog new tricks. A standing desk is a great investment for me.

On the other hand, my co-worker both has perfect posture at their desk and also has bad knees. A standing desk would be more problematic for them. A quality, expensive chair (almost as expensive as my standing desk!) is a great investment there.

As you say, why are we always looking for the one way to do things? Even if things are factual, there's no reason that the same experience is factually best for all people. Factually, a standing desk is great for me. Factually, it's not great for my co-worker.

That's a really excellent point. If there's any risk that an employee would leave to run after a cheap perk like a standing desk or a good chair, it's just bad management to not spend that money.

The fact that this is true just makes it hurt more that I am obviously Jared.

The SoCal fires this year are not in the woods, so it happens both in the woods (NorCal) and not in the woods (SoCal), and people die and communities are razed both in the woods and not in the woods.

One issue that's often overlooked is that PG&E has severe issues in their safety record. Last year their equipment sparked 16 wildfires, 11 of which may have been related to negligent maintenance. https://www.sfchronicle.com/business/article/PG-E-to-pay-2-5.... In 2010, they blew up 8 people and an entire neighborhood from improperly maintained gas pipes. https://abc7news.com/news/pg-e-receives-maximum-sentence-for.... I'm ok with open-ended liability for things like this. These are risks that are managed by utilities across the country and around the globe, in a responsible way.

It's amazing, Sears CEO Lampert has done so much self-dealing -- turning Sears assets into Sears cash + Sears debt, with the debt owned by Lampert's own companies -- that he'd be the only beneficiary in a bankruptcy. There's so little equity, other shareholders would be wiped out. It's hard to see how this doesn't end in a massive lawsuit, and, hopefully, some kind of consequences for rapacious capitalists.

cites: https://www.usatoday.com/story/money/2017/03/22/sears-holdin..., https://www.cnbc.com/2018/04/23/eddie-lamperts-hedge-fund-es...

I love how HN is actually done. How often does one give oneself permission to call anything but the smallest project done? I know I rarely do. It seems very healthy, for both the community and for Paul Graham individually, that something like HN can be done.

When I was getting my MBA, about <many> years ago, I suggested to our career placement folks that they work up a legal agreement with the companies who recruited with us, indemnifying them against any EEOC suits if they shared detailed feedback with us (most large companies go directly to business schools to hire on a yearly basis). They asked a half-dozen companies, and no company's legal team thought they could be confident such a document would stick. Pity, as, at that stage, we all had a lot of interviews to take, and a lot of support in getting new interviews.

This is great! A college degree can really help in a lot of careers (and I say this as someone with both a college and a grad degree), but rarely is it actually essential. It's not often even a good proxy for knowing that someone can do something. Direct measures of ability, such as reviewing past work, or even tests of certain types, are going to be much better at actually assessing whether or not someone can do the job, and also make jobs accessible to people from backgrounds that might make getting a college degree hard, but have no effect on whether or not a given individual can do a given job.

My wife and I have the same process, and it's worth its weight in... well, processes have no inherent weight, but, anyway, it's amazing. Highly-recommended. Also gives the awake parent some valuable quality time with the kids, build some traditions unique to that one set of relationships.