Agree - the site focuses a lot on build, but ignores scm tooling. At a certain size, git no longer works well as a pure monorepo w/o submodules and these mega companies have teams of people optimizing code time vs build time checkouts of these monorepos to handle subsections.

Ahahaha, good one.

But, this is what you get when the barrier of entry for software development has been set so low :)

Millions of developers using tools that they don't fully understand to produce sub-par solutions.

I am so happy that this is the state, so people who can build working, delivered on time solutions are getting paid very well.

FWIW I like that there aren't much gatekeeping in the industry and think it is a genuinely good thing, not only because my "hobby" (application security) relies on it :)

Also, with an unsolved problem you get paid to make whatever crazy attempt you want, which is absolutely a perk.

What does one thing have to do with the other? Monorepos are famously used at giant tech companies. Clearly they are being introduced by tech management in those cases, not a couple of people in their garage that don’t know what they are doing.

Could you elaborate? I use a monorepo at work and if anything dealing with 3rd party dependencies is easier because you don't have to coordinate upgrading versions across teams. For 1st party stuff in the repo we don't have a need to version libraries at all, if it all builds and passes all the tests everything is good. The whole point is to use the whole tree from a consistent snapshot as a release, so you never worry about using a new first party library with an old first party binary.

If you're able to release everything as a consistent snapshot, it probably is not a monorepo. Instead it is just a normal repo containing a single big project.

Here's an example: let's say that is you've got a single product with a backend server, database, web frontend, and a iOS app. How would you release all those projects as an atomic unit?

If there's a new field in this release, the database schema needs to be changed on the servers before the backend is released. The backend needs to change before the frontends do. You have no control over the deployment speed of some of those components, so releasing them all at the same time is impossible.

Similar issues would happen if you update 3rd party library, and software using the new Vs. old versions of the library are incompatible.

So the value of this monorepo isn't that you could cut a release for all of the components at once. It is that everyone doing development has a shared view of the current state of the system.

We deal with that too, but only for network/file format compatibility. We don't ship libraries used by an external group.

Yeah, that's what I meant by "morphing dependency management problem to a source control problem". With a monorepo dependency management is way easier! But, sometimes:

- git on large repo 100% pain 0% fun. hg is slightly better, but not much.

- No version means no prebuilt libraries, which translates to "you need a great build cache to keep build time reasonable".

- "passes all the tests everything is good" if only we can run all the tests on such changes.

- People hate coordinating on imported/pinned third-party dependency versions, sometimes you need tools for large-scale automated changes to make progress, but :(

- Similarly, not all places make all their codes accessible to all engineers.

i.e. source control problem is, sometimes, harder.