Context is incredibly important. The author is writing from the standpoint of a startup trying to fine tune an MVP. Of course it doesn't matter if it lasts if you don't know what you're building and rewriting everything isn't hard.
Code-first matters a lot when you're trying to make a 15 year old cobbled-together system last another 15 when you don't have the resources to stop everything for the many engineer-years it would take to do a full rewrite. Anything you touch is going to have to last too and people have to care about adding more technical debt because it's already the 500lb sled they have to drag behind them every single day.
Some chiropractors do have the education and experience to operate as physical therapists. When I was doing competitive weight lifting, I saw a chiro who had a masters in sports medicine and had spent years as a college football trainer. He ran his office like a rehab clinic, and a lot of his clients were high school, college, and amateur athletes like me. He wasn't just popping some bones and moving on, he was working to keep his patients healthy through identifying weaknesses and imbalances and making training recommendations to correct them. Being a chiro got people in the door who didn't understand what their problem was to begin with, just that they needed relief.
I realize the industry is full of snake oil practitioners, but some of them are actual professionals.
Working for a for-profit company is a completely different labor relationship than working for an OSS org or other non-profit. You absolutely should fight to prevent management from extracting more of the value you generated just because you cut your personal costs, but you may be able and willing to accept less income in order to contribute to an organization that you believe in that isn't profiting off your labor. One is adversarial theft, the other is the willing donation of your time to a cause.
Wasting massive amounts of mostly carbon-producing electricity as the planet dies to do absolutely nothing productive is a pretty cyberpunk evil megacorp thing to do, agreed.
Neat project, awful name. Overloading Flow, an already important part of the React ecosystem, just makes it harder to both find information about your project and find information about Flow.
I think a fair few of us have been burned by companies where this level of respect absolutely did not and could not exist and engineers were treated equivalent to you, an amateur, calling a plumber to your house and then hovering over them telling them everything they're doing wrong. Informal PTO would have just made the situation even worse.
Something I never see mentioned in these discussions is the surprisingly high hurdles to actually operating a distributed company. You'd think in 2021 it wouldn't be difficult to have employees doing knowledge work in multiple US states without running face-first into laws governing conducting actual business in multiple states, but that's not at all the case. International is even worse. The additional complexity and costs of having non-local employees can absolutely be prohibitive, leading some companies to just abuse 1099 status.
This obviously isn't a problem if you're FAANG or Salesforce, but for a company of 20 it is.
FIG standards are explicitly interoperability standards. They make it easy for anyone to jump into a new company or open source project with minimal friction and minimal bikeshedding.
If you or your team don't care about that and want to do something different, there's nothing stopping you. Even the Symfony team, who contributed to these standards and largely follow them, have gone their own way when they thought it was worth the trade-off.
So what's your proposed alternative that doesn't involve checking? Option-style wrappers enforce consistent checking and handling, but so do explicitly nullable type signatures. At some point you're going to need to know whether you have data or not, and that requires checks.
Individuals may not need it, but companies? The company I work for has multiple products which internally rely on geolocating arbitrary addresses. OSM keeps our costs way down, we only have to pay Google when OSM fails a match and we fall back to the Google Maps API. I doubt we're uncommon in this. OSM had less of a programmatic use when Google's free monthly tiers were large and subsequent costs low, but that hasn't been the case for a good while now.
$125 for my zoji that I've used at least 4 times a week for the last decade is significant value that you just don't see out of most appliances anymore. I'm more impressed by the reliability than the cooking tech (though it makes wonderful rice of course).
Postgres stores records by primary id sequence. If you have completely random IDs, records inserted at the same time are fragmented across the entire set, which makes accessing them slower if they're meant to be sequential.
Whether this matters entirely depends on the type of data you're storing. If you're storing unrelated data which is always random access anyway, non-sequential ids don't really matter. If you're storing related data which is mostly accessed sequentially, e.g. Impressions filtered by a creation date range, it's definitely better to have sequential ids for non-fragmented storage. UUIDv6 isn't as commonplace in libraries as v1 or v4 but offers a good compromise for this.
It's not a question of perfect, it's a question of __unnecessary__ fragility/vulnerability. We all rely on electricity because the alternative is far more difficult. We drive despite the costs and problems because most places in the US have been designed entirely around driving and it's very difficult to survive otherwise.
Does my fridge actually need to talk to the internet? Do my lightbulbs? Are the gains from having an addressable coffee maker worth the downsides when things break (or are broken due to security being an afterthought at best) over having a coffee maker that's just a coffee maker?
It's not any different than any other code all of us write on a weekly basis, when you start tacking on unnecessary features and increasing the complexity you will inevitably compromise the stability and simplicity of the features it must have to do its job. It's why the Unix philosophy exists to begin with.