I don't think they did an exceptional job keeping teams separated. In fact, I think monorepos only end up artificially tying teams down with an arbitrary and completely unnecessary constraint.

Also, not all work is services.

Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.

Taken from https://datatracker.ietf.org/doc/html/rfc6648

In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

I still work on software that extendively uses X- headers.

Ah, the Microsoft tradition of always having the wrong priorities.

I wouldn't be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

that managers want to stay in control of everything, and they decide whether they do it or not.

That's fine, it's a call from the manager.

That doesn't make it Agile's fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.

(...) so more open standards and just Web apps instead of proprietary apps

What do you classify as "proprietary apps", and from the user's standpoint where do you see a difference between them and web apps?

I’m absolutely biased as a data engineer who loves SQL, but there are some good reasons why SQL has been the de facto standard for interacting with databases since the 80s.

I find it funny how the people who actually have to wrangle data swear by SQL as awesome, but there are always random hacks coming out of the woodwork, who don't even look at SQL at all, with sweeping statements claiming SQL sucks because reasons.

It's like the most opinionated people against SQL are the ones who don't use SQL.

So there is fundamentally no difference between cargo and any other contemporary dependency/package manager.

I would also mention support for third-party compiler cache systems. Install something like ccache, set a couple of flags in the CMake project, and your whole project can now reuse build artifacts with barely no CPU load.

From the video:

Of course there is a market for real bulldozers, but it turns out there are so many people in this world that there is also a market for miniature bulldozers. A market enough to support a company that makes nothing but miniature bulldozers. Go sit under a three and think about that one for a while. It's wild. There is a lot of people. I can't believe this thing actually exists.

...and proceeds to buy one, and record themselves playing with it night and day.

What's wrong with automating processes?

It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.

I don't think this is a lack of support in C++. There are already a few C++ libraries that implement Either and Result monads. It would be nice if those were supported in the C++ stand library, but that does not stop anyone from adopting them.

Electron apps created with React can definitely push the boundaries of what ‘acceptable’ memory usage is.

I have a pet theory that webview-based apps are popular only because currently there is absolutely no usable multiplatform desktop GUI framework. Therefore, developers have to resort to the one thing that works: load a webpage in a web browser.

Even React Native feels like a kludge in a way it converts React components to UI components.