The manufacturer obviously, but they can sell the car in the first place because this defect risk is quantifiable for their liability insurance provider, who can evaluate how risky said car company is in terms of their manufacturing and how likely it is they'll need to pay out a claim, etc.
For self-driving, that evaluation is almost impossible. Sure it can look good statistically, but for things like brake lines, brake pad material, brake boosters, etc, they are governed by the laws of physics which are more understandable than any self-driving algorithm.
The way I always remember leftmost and rightmost binary search (the C++ equivalents-ish of lower_bound and upper_bound) is to always have a "prior best" and then move the bounds according to the algo
while (l < r)
{
//find the midpoint
auto mp = l + (l-r)/2;
if (nums[mp] == target)
{
prior = target;
#ifdef upper_bound
l = target + 1; // move the left bound up, maybe there's more up there we can look for!
#else
//lower bound, we found the highest known instance of target, but let's look in the exclusive left half a bit more
r = target - 1;
#endif
}
excuse the terrible formatting, it's been a long day grinding leetcode after getting laid off...
If this sounds like you, I highly recommend reading "The Problem of the Puer Aeternus".
You can definitely skip a lot of the tedious bits where the author essential copy-pastes other books for analysis, but this is a very common pattern where people tend to hold themselves back because doing the unambitious, rather pedestrian next step forward requires one to face these preconceived notions about oneself, e.g. "I should've done this long ago", etc.
I understand the sentiment, but disagree with the solution. PKMs can be overwhelming if someone nerdy enough to use one ends up using it ineffectively.
The way I do it that I find works well is to have the following:
1. each day, have a journal page for a given day. Content only happens in the journal pages
2. have a series of topics that you tag. This system is up to you, but I usually find something with a hierarchy that is <=3 levels deep is best, e.g. I have "Job Search/2025/Company"
3. for each of the relevant tag pages, have those have some sort of "query" that will pull in all relevant tasks from all the journal pages, sort them by priority / state / deadline so you can see this all in one place (e.g. "What's the next step I have to do for my Nvidia application?" -> easy to answer with this system). Depending on your PKM, the hierarchy enables you to easily answer that question at a higher level, e.g. "What's the next steps I have to do for ALL of my applications?".
In each journal page, you can also write down a "task backlog" so minor tasks that you remember don't take up headspace while you intend to work on other major tasks (e.g. write down "get back to Joel about the Nvidia referral").
Regarding a point other folks have made: treat the journal and these tags as more of a "stream" of things you're doing in your life, instead of a collection of every-expanding obligations or a mausoleum of unexplored ambition.
I built this in Logseq, which seems to be the only one that has an advanced-enough query language to do this in that is possible to do local-only (no mandatory cloud data) in text files. If anyone knows how to build such a system in a different application, I'd be happy to learn! Logseq has been stale for a year or 2 as the authors are working on a much needed near-total rewrite which I'm not sure is ever going to arrive at this point.
It's basically like having N of the most prolific LoC producing colleagues who don't have a great mental model of how the language works that you have to carefully parse all of their PRs.
Honestly, I've seen too many fairly glaring mistakes in all models I've tried that signal that they can't even get the easy stuff right consistently. In the language I use most (C++), if they can't do that, how can I trust them to get all the very subtle things right? (e.g. very often they produce code that holds some form of dangling references, and when I say "hey don't do that", they go back to something very inefficient like copying things all over the place).
I am very grateful they can churn out a comprehensive test suite in gtest though and write other scripts to test / do a release and such. The relief in tedium there is welcome for sure!
At least for C++, I try to use copilot only for generating testing and writing ancillary scripts. tbh it's only through hard-won lessons and epic misunderstandings and screw-ups that I've built a mental model that I can use to check and verify what it's attempting to do.
As much as I am definitely more productive when it comes to some dumb "JSON plumbing" feature of just adding a field to some protobuf, shuffling around some data, etc, I still can't quite trust it to not make a very subtle mistake or have it generate code that is in the same style of the current codebase (even using the system prompt to tell it as such). I've had it make such obvious mistakes that it doubles down on (either pushing back or not realizing in the first place) before I practically scream at it in the chat and then it says "oopsie haha my bad", e.g.
```c++
class Foo
{
int x_{};
public:
bool operator==(Foo const& other) const noexcept
{
return x_ == x_; // <- what about other.x_?
}
};
```
I just don't know at this point how to get it (Gemini or Claude or any of the GPT) to actually not drop the same subtle mistakes that are very easy to miss in the prolific amount of code it tends to write.
That said, saying "cover this new feature with a comprehensive test suite" saves me from having to go through the verbose gtest setup, which I'm thoroughly grateful for.
Oh I agree it can be a multiplier for sure. I think it's not "AI will take your job" but rather "someone who uses AI well will take your job if you don't learn it".
At least for C++, I've found it does very mediocre at suggesting project code (because it has the tendency to drop in subtle bugs all over the place, you basically have to carefully review it instead of just writing it yourself), but asking things in copilot like "Is there any UB in this file?" (not that it will be perfect, but sometimes it'll point something out) or especially writing tests, I absolutely love it.
Just this morning, I had Claude come up with a C++ solution that would have undefined behavior that even a mid-level C++ dev could have easily caught (assuming iterator stability in a vector that was being modified) just by reading the code.
These AI solutions are great, but I have yet to see any solution that makes me fear for my career. It just seems pretty clear that no LLM actually has a "mental model" of how things work that can avoid the obvious pitfalls amongst the reams of buggy C++ code.
Totally agree. I'm renting on the eastside at the moment, but places like Ballard and Magnolia are on my list of places to look to buy for the very reasons you mentioned. Having more space in these exurbs is "nice", but you pay the time tax every time you want to do something.
I remember coming here mid-pandemic and having white picket fences in my eyes as the company pointed me to a real estate agent. Thank god I didn't pull the trigger and buy because I would've been financially trapped (upside down) in some very unsafe urban area (e.g. south Seattle) or far-flung place (like Sultan).
This is a state thing, usually some N-year break an payroll taxes if they have M people working in the office. These deals are really about butts-in-seats unfortunately, and there is usually a non-trivial clawback clause.
Source: I was hired by a well-known hyperscalar cloud company that didn't want to send me to HQ, but wanted to place me at some random remote satellite offices. I looked into why, and it was this payroll / other tax break by the locality. (I sorta forced them to send me to HQ, as I don't deal with the heat / humidity well in the remote locations, which were in the US south).
Do you have an example of this? I'm curious where C++ exceeds Rust in this regard.