I’ve been gone a few years, but there was a process for contributing OSS code outside the company, and another for releasing company code externally, etc
It seemed to mostly work. Some people complained it was too slow, others seemed to manage fine.
We simply cannot allow an unstable white nationalist who's deeply enmeshed in global far-right politics to be in singular control of a megacorp that's critical to national security. It's a far bigger risk than divesting from SpaceX and building or doing something else, if not outright nationalization.
Any non-MAGA leader would find this pretty obvious.
"Buying time" is an ordinary phrase in English but, it doesn't make a lot of sense here because there'd be some activity SpaceX is doing to "buy time". If you're just waiting that doesn't "buy time".
The court ruling was a good one, and anticipated. The federal government can either allow all gambling, or ban it all. They can’t pick and choose states where it may be allowed.
Before online gambling went wild in the US, most brick and mortal gambling was one of three sources: (1) Nevada (Las Vegas, etc.), (2) Atlantic City, New Jersey, (3) Native American tribes. There were also some other odd locations, like river boat gambling on the Mississippi River or "cardrooms" in California. As a result, most Americans did not live close to a casino. Now, you can do it from your smartphone.
And federal law said states other than Nevada and New Jersey had to ban gambling. The court said they can’t do that. They could ban gambling nationwide in federal law.
I had fun on both sides of that process. As both a candidate and interviewer I prefer the in person whiteboard because it makes it more clear this is about ideas, not exact syntax.
I feel like the balance has shifted over the last 30 years, and is speeding up. Semi-automatic and fully automatic re-factoring has made dealing with duplicated code much faster, cheaper and safer. Changing abstraction is still high risk.
Automated re-factoring means you can refactor duplicated code only as long as it is exactly duplicate.
Whereas the whole problem is that when somebody changes 3 out of 10 of the duplicate cases in a simple way that they are no longer exactly duplicate, and then somebody fixes a bug in one of the other 7/10 cases, they can update the bug across the 7 "duplicate" cases but they'll miss the 3 that aren't.
The problem with duplicate code is always when some of the instances get changed/fixed but not all of them. And that when somebody edits one instance, they often aren't even aware of all the other instances.
Abstractions are low-risk, because you know where the code is. If it's the wrong abstraction, you can fix that and know what you're fixing. Whereas with duplicated-yet-modified code, you've now lost the connections between them.
I have regularly watched agents forget to update one duplicated pattern after changing it somewhere else. If it's within a single file or related class, it'll catch it, but if it's off in some other package in the monorepo, it's a crapshoot.
Seems kind of rude.
reply