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.

It's pretty easy to get yourself into trouble with channels: deadlocks, send on closed, channel leaks, deadlocks "fixed" thoughtlessly with arbitrarily-sized buffers, etc.

This seems to have little to do with Go's facilities. Any concurrent program has hazards like these.

In my experience, shared memory instills the appropriate fear and caution, while the apparent simplicity of channels encourages novice Go programers to take on concurrency projects beyond their abilities and without due care. Been on both the submitter and reviewer side of that plenty of times in 10 years.

Rust's concurrency libraries leverage the type system to make these issues much harder to encounter.

Rust's std::sync::mpsc contains most of the hazards of Go's channel, and arguably adds some because the Go runtime provides deadlock detection that Rust lacks.