However, I think the original thinking behind the term "meme" is probably still the definitive discourse on the subject: in analogy to genes, ideas undergo natural selection for survival/reproduction and the attributes that promote this specific kind of fitness (ease of spread, satisfaction, advantage obtained by spreading) will be selected for in the course of social interaction. Qualities we might like to encourage (accuracy, completeness) will not be selected for except insofar as we can connect them back to the actual selection mechanism.
That said, "meme" really doesn't quite put as sharp of a point on the problem as "LIES."
I guess I wouldn't be surprised if there were issues with data and/or analysis. Should we assume they are basing their miles driven off of used car listings? That is, they see someone puts a 2019 Subaru Impreza up for sale in 2023, with 50,000 miles, and they add that to their data set on how many miles the average Impreza gets driven per year? But maybe people leasing drive differently than those who own or keep vehicles longer? I'd like to see the data on their average number of miles driven per car model per year.
Would also be interesting to see which were the safest cars according to their analysis.
It’s why I was very careful to make it as clear as possible that my own theory is rooted purely in conjecture and speculation based on personal experience, because:
A) I don’t want to get sued
B) I am not a researcher
Though if I had to take a guess on the CR-V: big, cheap SUV, often seen driven by young drivers in my area. Could be lack of experience? I can only speculate, though.
...and the study only covered model years up to 2022. It would be interesting to compare the hybrid to the standard version. If there is a significant difference, I'd be suspicious of data quality.
The Highlander rates somewhat higher on crash ratings from what I can find (both are top picks). Also a significantly heavier vehicle (by about 10% depending on model years).
First, we use Missive to integrate email and chat. This way everything's in one place, properly threaded, and we can easily discuss emails internally in context. Much much better than GMail + Slack.
Second, I run video chat office hours twice a week (Tuesday/Thursday). Anybody can drop in to discuss anything — or not, if there's no need. This lowers the activation energy for "in person" discussions that otherwise might not get scheduled and promotes async work the rest of the time.
Third, regular company offsites! Even a few days a year is good.
I'm building an open source implementation of the Firebase RTDB server, that will be wire-compatible with Google's. This means that all the (already open sourced) SDKs will work pretty much as is, over REST or websockets. Security rules will also be fully supported. (The only meaningful caveat is that it's just the RTDB, so you need to deal with authentication yourself, and kinda shoehorn it into the existing APIs.)
What I get out of this is that even for teams that prioritize trust and velocity and eschew the use of pre-commit code reviews, there's a strong argument to be made for putting all new hires on an approval-required list for the first few months!
Yep, Git's semantics are seriously lacking (see also renames). In Reviewable, we work around this with heuristics: we use Change-Id if it happens to be available, and otherwise do best-effort loose lexical matching on the commit messages to match up pairs across a rebase. It works reasonably well in practice but it's a bunch of complex code that I'd rather not have to maintain...
Agreed that their API is the most important thing, but IMHO they're not doing a particularly great job of it. You've got two separate API systems (REST and GraphQL) that overlap but with neither a superset of the other, two separate ID systems, no help in handling the wide range of incompatible API versions used by old GHE instances in the field, OAuth apps vs Apps that have different constraints on the APIs they're allowed to call and with no clear migration path between them, important bits of functionality used by their own UI that aren't available through the API at all, a convoluted API quota system, etc.
Frankly, a lot of it feels like they were trying to deprecate and replace an older system with the shiny new thing, then realized halfway through that they couldn't and now we're stuck with two somewhat incompatible ones for the foreseeable future. They could really use a strong tech lead on this.
It feels this way with PATs as well, with legacy PATs still necessary for most of the things I use them for, despite being pushed into the newer ones. And the documentation is terrible. I had the exact same thought, the PAT transition feels like an unfinished feature as does the API transition.
For me the API transition is even more bizarre since it’s almost trivial to wrap REST calls with GraphQL.
What it feels like to me is a mounting level of serious technical debt which isn’t being addressed, and if that’s not a sign of trouble in a product like GitHub, I don’t know what is.
To be fair, they did improve several things in the PR flow over the last decade but there's definitely a lot more that could be done. I just hope they keep their API team well-resourced so that code review tools like Graphite and Reviewable can keep working! (Disclaimer: I'm the founder of Reviewable.)
If you called them Low Information Excessive Satisfaction theories instead you'd end up with a much more satisfying acronym! :)