People need to stop believing insane, delusional things like the existence of a human being with a certain name, address, phone number, birthday, SSN being secret or private information.

Downstream of that, people need to stop accepting knowledge of the basic public metadata fields or possession of images containing them as evidence of identity verification. Do actual public key cryptography on the internet or check biometrics and the document’s physical security measures in person.

I do not buy that LLMs and the capability to run them are fundamentally different from other software or general purpose computing infrastructure in this regard. Moves to ban open source software or force OEMs to put little cops in everyone's computers are bad.

They aren't open source? And no one said anything about cops.

The proposal I’m hearing is to make people training models accountable for anything users do with them.

Obviously you’re going to keep the model behind an API and be very selective about the people allowed to call and the queries it’s willing to answer, in that case. As Anthropic has done with Fable. But that is voluntary restraint - mostly in today’s regime we get frontier capabilities in open weight models on a ~year delay.

It’s to keep “the people running it accountable.” The context is agents ran by OpenAI/Anthropic doing damage outside.

There is no user-involved damage. No one is recklessly running agents by the thousands without air-gapped containers, except “the people” than run these labs.

One through eight read as the list of sacrifices you make in having children. But the experiences of loving and being loved back seem at least incomplete without that.

Even startups that beat the incredibly long odds to become successful mostly aren’t successful enough to make up for a long stretch of not earning BigCo RSUs.

I work at a household name tech company and pretty much all our "data" dashboards are running SQL queries against a Hive/Presto environment that's at least 24 hours behind. Real-time dashboards are limited to the service metrics time series database (so combinations of categorical variables, no individual records) or rare expensive Pinot tables.

I have seen this on the business side too. A lot of we need live data requests don’t really need live data. If the decision is made once a day, hourly data is more than enough. Yet we still build dashboards that refresh every few minutes just because people asked for it.

In this case, we do actually need live data! We use wide events for monitoring business events and it lets us understand our platform with utmost flexibility, which is important for us as a fintech company.

Traditional observability is ill-suited for observability around business events. What if you forget to instrument a counter or gauge for something? In my experience it's far easier to log wide events with as much context as possible instead of agonizing over anticipating the dimensionality of metrics upfront (you're going to miss something).

Perhaps changing is a better word.

Yes this was also my experience working at a large tech co. I work in fintech now and data volumes are low enough to maintain 2-3 minute up to a few hour data freshness.

>Despite all the noise, remote work has not really decreased much in recent years. "Less than 1/3 of companies requiring fully in-person work in 2026."[3]

Remote work is generally being displaced by hybrid. That still requires employees to live in expensive metros and employers to maintain offices with space for everyone. The offices can be a little more austere and the commutes a little worse given that they're only for 2-3 days a week, but everybody's still got to pay for basically the same stuff. Downtown retail, though, is screwed with only 2-3 days of foot traffic to pay the bills.

Most of the 60 minute travel time radius around a San Francisco or Silicon Valley tech HQ is water and nature preserve.

It doesn’t make sense to assume SF logistics even on this board because it’s such an outlier. Just my opinion.

The obvious 21st century United States instance of "don't collect data that the government might later use for persecution" is E-Verify.

The part that has stood the test of time and genuinely seems to carve reality at the seams is the query part. The data definition and data manipulation parts are just ok.

Even so, "FROM t SELECT t.foo, …" has an ergonomic advantage over "SELECT t.foo, … FROM t" in that editors can autocomplete column names without needing to backtrack while editing.

IIRC, this is why C# query syntax uses the former.

The problem with the query part is that query fragments aren't composable.

CTEs are how you compose SQL.

I don't quite like how the same CTE lives in 60 different places in my codebase, but at least the WITH clause changed things for me.

Also really liked Snowflake's result_scan for composing chains, mostly because I don't rerun expensive parts again and again. You can use ->> as a shortcut, but I don't think it uses results caching internally to skip waiting for them to all re-run & actually optimizes the whole thing.

you create one view and have the ctes query that, to deduplicate the implementation

I definitely hear about segments of the industry being like that, but FAANG and adjacent generally isn't. Engineers are expected to display ownership of a problem space (scope depending on seniority), navigate ambiguity, and manage their own time.