Not having a speed limit is unique only to private car ownership

Governments around the world impose various requirements on vehicle speeds, most notably ebikes being capped at 20mph for "safety reasons". Meanwhile private cars can travel at over 100mph for no apparent reason other than to not upset drivers at the expense of everyone else on the road.

Also, this claims that the wall type or video quality doesn't matter, but I have a hard time understanding how the model would be able to understand that a small crimp could possibly be dual textured and therefore has only a few specific ways of approaching it.

So it seems that this is more for visualizing a climb (which is a skill most climbers should develop) and not really for dialing in some sort of microbeta for a problem.

By his logic, Bell Labs would be one of the largest hives of orthodox thinking to ever exist, and its the complete antithesis of vc heterodox thought

Even 4chan has stronger moderation than what you advocate

> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

Refreshing take on the peak alarmism we see from tech "thought leaders"

Instead of bashing the author and his credentials, maybe you should engage with the argument hes making instead?

RSS makes it very difficult to measure the performance of an ad. Most players in this space wrap a publishers hosted podcast link with their own tracking link, and the main metric of engagement is a download. Downloads themselves are a pretty crude measurement and don’t hold up to something like minutes watched/listened.

Placing ads into the audio directly also just isn’t as performant as streaming it into the media like in video. Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener. Podcast ads currently don’t deliver on that.

Does agricultural and industrial pollution not contribute to climate change?

Some pain points:

- Does it take forever to spin up infra to run a single test?

- Is grabbing test data a manual process? This can be a huge pain especially if the test data is binary like avro or parquet. Test inputs and results should be human friendly

- Does setting up a testing environment require filling out tons of yaml files and manual steps?

- Things built at the wrong level of abstraction! This always irks me to experience. Keep your abstractions clean between which tools in your data stack do what. When people start inlining task-specific logic at the DAG level in airflow, or let their individual tasks figure out triggering or scheduling decisions is when things just become confusing.

Right now my workflow allows me to run a prod job (google cloud dataflow) from my local machine. It consumes prod data and writes to a test-prefixed path. With unit tests on the scala code + successful run of the dataflow job + validation and metrics thrown on the prod job I can feel pretty comfortable with the correctness of the pipeline.

Speaking from my DE experience at Spotify and previously in startup land, the biggest challenge is the slow and distant feedback loop. The vast majority of data pipelines don't run on your machine and don't behave like they do on a local machine. They run as massively distributed processes and their state is opaque to the developer.

Validating the correctness of a large scale data pipeline can be incredibly difficult as the successful operation of a pipeline doesn't conclusively determine whether the data is actually correct for the end user. People working seriously in this space understand that traditional practices here like unit testing only go so far. And integration testing really needs to work at scale with easily recyclable infrastructure (and data) to not be a massive drag on developer productivity. Even getting the correct kind of data to be fed into a test can be very difficult if the ops/infra of the org isn't designed for it.

The best data tooling isn't going to look exactly like traditional swe tooling. Tools that vastly reduce the feedback loop of developing (and debugging) distributed pipelines running in the cloud and also provide means of validating the output on meaningful data is where tooling should be going. Trying to shoehorn traditional SWE best practices will really only take off once that kind of developer experience is realized.

Comments URL: https://news.ycombinator.com/item?id=32931469

Points: 31

# Comments: 17

* influential politicians

* journalists

* Jerome powell "... though there's some evidence that Jay Powell, the chairman of the Federal Reserve, may consult it for ideas on monetary policy"

* College educated people (94 million americans)

I don't think this is the own-the-libs that the author intended