> would be richer today had be let his initial inheritance just ride in the S&P 500.

But then he wouldn't have all that experience screwing and trolling people.

Sanitexit: Abandoning sanity.

Slashdotting a site is back, baby!

But it can echo the aggregate behavior of mass morons and trolls and shove it into more places faster.

The "telework revolution" is at least part of the reason for shrinkage. They still "work" in Seattle, just don't live there.

We are addicted to bloat because we are surrounded by bloat.

...Mad Max fiefdom companies?

I'm not saying he regrets his choices, only that it was a unique time and project that he has nostalgia for. For example, if you built your own dinner table you may both admire your work and have fond memories of doing it. But that doesn't necessarily mean you want to become a professional carpenter. One can have nostalgia for one-off projects they've spent a lot of time on.

> Don't think about increasing taxes or we will leave.

And go where? The best and brightest don't want to live in Texas or Sticksville. They beat up nerds and other "oddballs".

It's because we are expecting young children to perform. They should be outside playing with other children rather than sitting in classrooms day in and day out. Educational performance can wait until they're older.

We are trying to compete with Asia, the land of suicidal prodigies. But outside of very specific specialties, people skills matter at least as much as technical skill, as products have to be usable by non-experts, as one has to communicate with non-experts to understand their needs and perspective. Take it from somebody with insufficient people skills.

Zuck even looks like a peeping-tom.

I believe it's more that Bill spent a lot of time thinking about every byte because of the resource constraints on their interpreter. It wasn't meant to be maintenance-friendly, which is how we usually judge code, but space-friendly. It's kind of like slow-motion Tetris.

He was young and had time to ponder and re-adjust every last byte. When the business started growing, he couldn't micromanage bytes that way anymore, so it was the last code he ever got to put so much blood, sweat, and tears into every corner of.

We are pawns in the Plutocrat Asshole Olympics.

Visual Studio 22's Intellisense can make fairly good guesses. Likely its guess-rate will gradually go up, but a human will probably still need to pick among multiple suggestions. So yes, the bot may "write" the suggestions, but a human is still picking among them. Thus saying the bot "wrote" most the code is perhaps misleading even if technically true.

CRUD frameworks are so damned bloated these days that there's lots of repetition for a bot to glom on to. No framework maker seems to strive for DRY, KISS, and parsimony these days, rather uses "scaffolding" to automate bloat. CRUD idioms haven't changed much over the years, yet we keep re-re-re-inventing CRUD frameworks, and bloating them with gimmicks and dependencies.

I'm working on a KISS framework for smaller internal projects to show how it could be done. Specifying the schema itself with "tweak tags" does 85% of the work. "Incremental rendering events" allows one to tweak or overwrite attributes, CSS, and HTML along way so that one is not stuck with declarative-only "logic", a common drawback of most RAD tools.

App code should almost never duplicate info (facts) available in the schema, as it's a DRY violation. For example, one should only have to specify a field is "required" (not nullable*) once and only once. But too many frameworks force one to repeat that fact. App code should mostly be dealing with domain-specific logic NOT covered by the schema itself.

(The issue of how to version schemas comes up, but that's a longer topic.)

* Usually we want "non-white-space-only" when a field is "non-nullable", but most frameworks miss this common idiom and don't fully check for just-white-spaces. CRUD newbies can sure code frameworks up fast, but don't get CRUD, reinventing CRUD gaps.

It's why Australian astronomers came to the opposite conclusion.