There’s an interesting question of if the distributor misrepresented the deal to Mora as he claims, but from the summary it appears nothing related to that is recorded that the court finds legally relevant.

Additionally, you're using the average software engineer salary in the US but then picking California for rent. The article you linked says country wide you'd expect $1950 for renting a 1-bedroom not the $2500 number you are picking for a studio in the bay area.

So you're off by something like $1000 per month (edit: I admit I am simply looking at what I pay for HMO, it's possible that is somehow unrepresentative but I doubt it) by picking the most expensive health plan and mixing up national salaries vs very expensive areas.

The gun violence risk is vastly overblown. The page you are linking to cites a study where gun deaths are being accumulated for ages 1 to 24 years old. Gun deaths are highly non-random and concentrated in older ages and in very specific areas (largely related to gang activity). The average software engineer with family is not going to run into any of that unless they are in the habit of leaving loaded weapons around the house.

Disease factors were probably the biggest factor in selection until very recently (and maybe now is just a temporary blip before a return to the historical pattern). Disease almost wiped out the Native Americans and strongly held sub-Saharan Africa back.

Especially with kids, it's difficult since you don't control how much they decide to eat making pre-bolusing meals challenging (part of why reducing carbs tends to be helpful for people is it reduces the need to pre-bolus and makes it less risky since you need less up front meal insulin).

It would be odd for a faulty sensor to cause an otherwise bad day into dka and death though. The sensor would need to be wildly off for hours and the user to not notice. Insulin delivery would need to be paused or greatly reduced for many hours. There are additional therapies like SGLT-2 that could make this more likely but they usually aren’t used with T1D precisely because they break the normally very strong correlation between inadequate insulin levels (leading to dka) and high blood glucose.

Even though I can’t think of an easy way for a false low(s) to turn into lethal DKA, that doesn’t mean it didn’t happen. Abbott sells a lot of CGMs. It could have been a contributing factor to several deaths even if the fault would almost always not be a significant issue.

In some cases, an excellent researcher even has cogent papers but is absolutely abysmal at lecturing and in person teaching skills.

Peers are very important, but from talking to others, it's harder to know where you will get good peers than you would think. Even 1st tier universities will have majors dominated by students whose primary interest is in maximum grades with minimum work and where cheating is rampant. You've got to either get lucky (I did) or put in some leg work to find smart students who are actually interested in learning and doing things right.

I think how much rote memorization is encouraged or required is strongly dependent on the field. Pre-med students will sometimes memorize their way through calculus; a professor I knew once described it as "grimly impressive".

For scientific simulations, I almost always want invalid state to immediately result in a program crash. Invalid state is usually due to a bug. And invalid state is often the type of bug which may invalidate any conclusions you'd want to draw from the simulation.

For data analysis, things are looser. I'll split data up into data which is successfully cleaned to where invalid state is unrepresentable and dirty data which I then inspect manually to see if I am wrong about what is "invalid" or if I'm missing a cleaning step.

I don't write embedded software (although I've written control algorithms to be deployed on it and have been involved in testing that the design and implementation are equivalent), but while you can't exactly make every invalid state unrepresentable you definitely don't punch giant holes in your state machine. A good design has clean state machines, never has an uncovered case, and should pretty much only reach a failure state due to outside physical events or hardware failure. Even then, if possible the software should be able to provide information to intervene to fix certain physical issues. I've seen devices RMA's where the root cause was the FPU failed; when your software detects the sort of error that might be hardware failure, sometimes the best you can do is bail out very carefully. But you want to make these unknown failures be a once per thousands or millions of device years event.

Sean is writing mostly about distributed systems where it sounds like it's not a big deal if certain things are wrong or there's not a single well defined problem being solved. That's very different than the domains I'm used to, so the correct engineering in that situation may more often be to allow invalid state. (EDIT: and it also seems very relevant that there may be multiple live systems updated independently so you can't just force upgrade everything at once. You have to handle more software incompatibilities gracefully.)

There is no royal road. If all your kids are biologically yours and you and all your family are good at math and you marry someone from a similar family, you can stack the deck maybe 95/5 in favor or your kid being good at math? But that option is already off the table if you lack that talent. And there are other things you should probably prioritize first!

If the main failure of British companies is that they don't have U.S. company market caps, it seems more off base to blame this on government science funding policy instead of something else. In almost every part of the economy, U.S. companies are going to be larger.

The article mentions but underrates the fact that post-war the British shot themselves in the foot economically.

As far as I'm aware, the article is kind of wrong that there wasn't a successful British computing industry post war, or at least it's not obvious that it's eventual failure has much to do with differences in basic research structure. There was a successful British computing industry at first, and it failed a few decades later.

And then there's a subtlety where units might be preserved, but x may be "absolute" where as (x - x) is relative and you can do operations with relative units you can't with absolute units and vice versa. Like the difference between x being a position on a map and delta_x being movement from a position. You can subtract two positions on a map in a standard mathematical sense but not add them.

A lot of my frustration it is that the ergonomics of these things tend to be not great even when they are available. Or the different pieces (units, shape checking, ranges) don't necessarily compose together easily because they end up as 3 separate libraries or something.

I've read that F# has units, Ada and Pascal have ranges as types (my understanding is these are runtime enforced mostly), Rust will land const generics that might be useful for matrix type stuff some time soon. Does any language support all 3 of these things well together? Do you basically need fully dependent types for this?

Obviously, with discipline you can work to enforce all these things at runtime, but I'd like it if there was a language that made all 3 of these things straightforward.

DuckDB is much nicer in terms of types, built in functions, and syntax extensions for analytical queries and also happens to be faster for big analytical queries although most of our data is small enough that it doesn't make a big difference over SQLite (although it still is a big improvement over using Pandas even for small data). DuckDB only just released versions with backwards compatible data storage though, so we don't yet use it as a source of truth. DuckDB has really improved in general over the last couple years as well and finally hit 1.0 3 months ago. So depending what version you tried it out on tiny data, it may be better now. It's also possible to use DuckDB to read and write from SQLite if you're concerned about interop and long term storage although I haven't done that myself so don't know what the rough edges are.

I'd say the closest description to us in the article is the practical research team. We have fairly clear business goals we are fulfilling with our work.

You generally shouldn’t put code you want to reuse in notebooks, but we haven’t found this to be much of a problem. And >3/4 of the people who’ve worked on our team don’t have software engineering backgrounds. If you set clear expectations, you can avoid the really bad tar pits even if most of your co-workers are (non-software) engineers or scientists 0-3 years out of college.

The second question seems like the type of feedback that would usually be fine. People's skills and knowledge don't always overlap. What is crazy complex for A may not be for B and what is crazy complex for B may not be for A! And that doesn't have to have anything do with A or B being smarter. A might not know SQL and B might not know pandas. But sometimes it really does make sense to move some code from SQL to pandas or vice-versa (assume for the moment that both SQL and pandas are already in the tech stack). Some people find it simple to write in object oriented style and others in a functional style. What makes more sense to do is not always obvious. So the question could be a good one. If the suggestion is bad, explain why it's bad. If the suggestion is good, maybe consider if it's worth doing at current point. If it's somewhere in the middle or there's no time, acknowledge and move on.

On the flip side, even for coding I don't love, I can usually grind out 9-10 hours at fairly high productivity; I usually won't because I have other priorities to balance but I can. If I find what I'm working on really interesting, I can do 12 hours at high productivity.

For work, I try to have 2 days a week where I put most of my meetings so that hopefully at least 1 or 2 days of the rest are high productivity.