I also own a Tesla, and there is no indication shown to the user that FSD's vision is degraded. They need to add this in.

For example, numerous times I have been driving my Tesla with FSD activated with ostensibly a clean and clear windshield when suddenly the car will do the "clean the windshield in front of the camera routine" without any indication that the car's camera is degraded. If people haven't seen this "clean the windshield routine", the wiper fluid is dispensed and the wiper will vigorously wipe in front of the camera only -- the rest of the windshield only gets a cursory wipe.

This indicates to me that the camera has poor visibility and I am not informed or aware of this as a driver, which is concerning. I am often curious if there is a thin occluding film on the windshield in the camera box in front of the camera, or something that has degraded FSD's vision, but they do not give you the ability to view the camera feed, nor do they notify you that the vision is degraded. I think a "thin occluding film" may be in the camera box because my normal windshield outside of the camera box started to show a thin chemical film after a couple of months, which apparently (according to a Google search) happens when a new car off-gasses, adding a thin film of chemical byproduct to the windshield. This is my first new car so I've no idea if this is normal or not.

Unfortunately its name makes it hard to search for and find.

I think every time I swipe I need to do at least one correction like this, where I type one similarly spelled word with as minimum an edit distance as I can think of in the moment, then do a manual correction.

This is what people are missing. Even those "slow" apps are faster than their alternatives. People demand and seek out "fast", and I think the OP article misses this.

Even the "slow" applications are faster than their alternatives or have an edge in terms of speed for why people use them. In other words, people here say "well wait a second, I see people using slow apps all the time! People don't care about speed!", without realizing that the user has already optimized for speed for their use case. Maybe they use app A which is 50% as fast as app B, but app A is available on their toolbar right now, and to even know that app B exists and to install it and learn how to use it would require numerous hours of ramp up time. If the user was presented with app A and app B side by side, all things equal, they will choose B every time. There's proficiency and familiarity; if B is only 5% faster than A, but switching to B has an upfront cost in days to able to utilize that speed, well that is a hidden speed cost and why the user will choose A until B makes it worth it.

Speed is almost always the universal characteristic people select for, all things equal. Just because something faster exists, and it's niche, and hard to use (not equal for comparison to the common "slow" option people are familiar with), it doesn't mean that people reject speed, they just don't want to spend time learning the new thing, because it is _slower_ to learn how to use the new thing at first.

[1] https://en.wikipedia.org/wiki/The_Secret_Life_of_Machines

    function x() {/* ... */}
    const x = function() {/* ... */}
    const x = function foo() {/* ... */}
    const x = (function() {/* ... */}).bind(this)
    const x = (function foo() {/* ... */}).bind(this)
    const x = () => {/* ... */}
    const x = () => /* ... */

That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a frustrating experience.

I can make sure my code is good before I submit it for review, not when I'm just trying to make sure my work has been saved so I can continue working on it later (commit).

To me it is confusing that they've mixed the two, even though it is convention to do so.

> He lived and wrote in the late 200s and early 100s BCE

Shouldn't this instead be phrased as:

> He lived and wrote in the early 200s and late 100s BCE

He was born in 254 BCE and died in 184 BCE, he lived from the mid 200s BCE, started writing in the _early_ 200s BCE, and died in the _late_ 100s BCE.

I was recently asked this question, and while I've had some disagreements with coworkers over minor things, I've never had a major disagreement that was noteworthy, so I (to my inevitable detriment) said: "Nothing really comes to mind at the moment but if something like that were to happen, I'd do X, Y, and Z". Given the reaction from the interviewer I doubt I passed. I still have 2 more interviews with this company.

Not to nitpick but this statement implies causation (family environment causes life outcome) which you contradict right after.

Sorry to sound obtuse, but, I asked because it may seem obvious to you, but it's not so obvious to me that there will be much improvement. I've seen data that indicates that outcomes are not changed (much) when those early interventions / "investments" are made. There is _an_ improvement, but not to the level people expect. Like a person's height, access to high quality food will only do so much; some people are just going to have short stature however much money you invest into making sure they have access to nutritious meals.