A million is hardly buying mansions, yachts, and champagne-filled swimming pools in the current economy

The only way for "Big AI" to become a thing is for them to establish a moat, and right now the only path to that appears to be achieving regulatory capture in the US, which is a fickle and unstable state of affairs.

They weren't prepared for data that was obviously noisy. The data has always been inherently inaccurate, and folks just chose to ignore that previously

That is indeed how the VC funding game is played. If you don't raise another round, you are dead anyway, so you spend down your seed round to try and justify that following round...

Winit has had so much churn over time, I hope they settle down at some point.

I can pretty much guarantee that if I try to build a project from 3+ years ago, the old version of winit will not compile on my Mac, and the new version of winit will have a completely different API surface.

Do your coworkers not reliably produce readable, tested code?

That's kind of the minimum bar for a software engineer in my book

Which themselves generate more PRs (or larger PRs)...

From my perspective, there are three sorts of PRs:

- One is very close to the final form of a particular change, and any feedback you get at that late stage is indicative of holes in your process.

- Another is one where someone throws something up and says "hey, this is an experiment, can I get feedback on the approach". This is great, the parameters are clear, not much to say about these.

- The 3rd sort is someone making a trivial 5-line patch to a makefile/cargo.toml/github workflow/etc. These add basically no value to anyone.

Of those only the 2nd type really brings much value, and those are the ones that folks would keep posting even if you didn't require PRs (since they have an actual question, or a cool thing to show off).

I'll also note that this only really negatively impacts small remote teams, because on a sufficiently large, co-located team, you just ask your buddy one desk over to rubber stamp all the trivial commits...

Of course pensions aren't contingent on being in-country, but I have trouble picturing the same bureaucracy being less anal about other government benefits.

Do the landing pages of auth0.com, devcycle.com, micro.com, or datadog.com not look like slop to other people?

Do you expect everyone to hand-code their websites in WASM? Do you expect every webapp be cross-compiled to WASM?

From where I'm standing, WASM is extremely successful in its specific niches: in enabling islands of high-performance in otherwise web-based software, and in sandboxing plugins to native apps/servers.

This is a very game-able system, and I'd wager a decent amount that any senior engineers on those teams know exactly what they are doing. In a lot of (broken, but aren't they all) management structures, it's better to be seen to swoop in with the save than to quietly fix it ahead of time.

And if your management is structuring rewards like this, it leads to your seniors anticipating a bunch of these failures, lining up 90% of the fix before hand, so that they can jump on the oncall escalation with a 100% "Hail Mary" of a fix...

We're all aware that a huge portion of the busywork that makes a team successful is not actually reflected in their upwards-facing deliverables (increasing test coverage, improving infra, adopting new tools/methodologies, preemptive security patching, etc). Your actual high performers, if you have any, are doing all that stuff in addition to their regularly-scheduled duties.

If management weren't at least tacitly on board with this arrangement, your high performers would go work somewhere else. So my experience is that good managers don't tend to see this your way.

I'm not sure how much I'd enjoy working on teams who were routinely producing PRs that were in bad shape.

With human reviewers, I find that by the time someone has churned out enough of a solution to post a PR, they are already quite invested in specifics of the solution, and it makes it emotionally costly (to both author and reviewer) when someone says "hey, I'm not a fan of this whole approach, lets start over and do it this other way"

I think the ultimate answer to this is a stacked PR workflow (which we had at Meta), where I can cheaply maintain/review a 1,000 line PR as a stack of 10 incremental PRs. But unfortunately GitHub et al are still not quite there on this one.

In this sense, I'm not sure I've ever seen a team that does codereview "right".

In the before times, most PR feedback was stylistic, with the occasional bug identified. Now that we have ubiquitous auto-formatters/linters/CI, most PR review falls into either "you misunderstood the spec", or "I disagree with your architectural choices" - and my personal feeling is that your process ought to catch both of those well before the PR stage