piotrkaminski

This part:

> Sometimes, if the problem (like the injury or damage) was not discovered right away, the statute of limitations generally starts counting from the date the problem was discovered or should reasonably have been discovered, whichever comes first.

> Given what we have already seen of AI, we can be confident that its widespread adoption will create a less free society, a less virtuous people, and a degraded culture.

I think this claim needs stronger evidence than "we can be confident".

I thought this was the weakest argument in the article. Yes, non-determinism is inherent to LLMs. It's also inherent to human brains, yet somehow we still manage to call (some) people reliable.

The bit about backwards compatibility doesn't make sense either. LLMs, just like humans, can take backwards compatibility into consideration — or not. Sometimes they'll forget, and sometimes they'll fixate on it even in a system that hasn't been deployed yet. It has nothing to do with LLMs never doing "the same thing the same way twice".

LLMs may or may not become as reliable as other productivity-improving infrastructure, but it's not the nature of their technology that will decide this.

By and large we do. Unfortunately, the losers don't care unless you identify them personally. For them, the thrill of cheating and griefing others easily overcomes some generalized cultural zeitgeist.

That certainly used to be the case in Canada 20 years ago, don't know if they've standardized since.

> I prefer to call them Low Information High Satisfaction theories

If you called them Low Information Excessive Satisfaction theories instead you'd end up with a much more satisfying acronym! :)

> brand that emphasizes safety or enjoyment of experience (like Hondas and Toyotas)

This is plausible on its face, and yet the Honda CR-V Hybrid ended up higher on the list than the Model Y. No idea how to explain that...

What in the world is the Honda CR-V Hybrid doing so high on this list?! That doesn't seem to fit any of the theories I've seen spun up so far.

We do three things:

First, we use Missive to integrate email and chat. This way everything's in one place, properly threaded, and we can easily discuss emails internally in context. Much much better than GMail + Slack.

Second, I run video chat office hours twice a week (Tuesday/Thursday). Anybody can drop in to discuss anything — or not, if there's no need. This lowers the activation energy for "in person" discussions that otherwise might not get scheduled and promotes async work the rest of the time.

Third, regular company offsites! Even a few days a year is good.

I'm building an open source implementation of the Firebase RTDB server, that will be wire-compatible with Google's. This means that all the (already open sourced) SDKs will work pretty much as is, over REST or websockets. Security rules will also be fully supported. (The only meaningful caveat is that it's just the RTDB, so you need to deal with authentication yourself, and kinda shoehorn it into the existing APIs.)

What I get out of this is that even for teams that prioritize trust and velocity and eschew the use of pre-commit code reviews, there's a strong argument to be made for putting all new hires on an approval-required list for the first few months!

Yep, Git's semantics are seriously lacking (see also renames). In Reviewable, we work around this with heuristics: we use Change-Id if it happens to be available, and otherwise do best-effort loose lexical matching on the commit messages to match up pairs across a rebase. It works reasonably well in practice but it's a bunch of complex code that I'd rather not have to maintain...

Agreed that their API is the most important thing, but IMHO they're not doing a particularly great job of it. You've got two separate API systems (REST and GraphQL) that overlap but with neither a superset of the other, two separate ID systems, no help in handling the wide range of incompatible API versions used by old GHE instances in the field, OAuth apps vs Apps that have different constraints on the APIs they're allowed to call and with no clear migration path between them, important bits of functionality used by their own UI that aren't available through the API at all, a convoluted API quota system, etc.

Frankly, a lot of it feels like they were trying to deprecate and replace an older system with the shiny new thing, then realized halfway through that they couldn't and now we're stuck with two somewhat incompatible ones for the foreseeable future. They could really use a strong tech lead on this.