[Joe8Bit]

I like the blog post and broadly agree with the conclusions, but I want to double down on something in the article:

> Shared pain

I've worked in some orgs with very large monorepos (1000s of developers working in a single repo) and broadly have had positive experiences with them, but this 'shared pain' was by FAR the biggest drawback I experienced. When things went wrong with the monorepos they tended to go VERY wrong and effect EVERYONE. Multiple incidents of the monorepo just crushing productivity for 1000 person engineering orgs, for a period of time.

That's not to say I think monorepos are bad, it's 100% context dependent whether they make sense for your org in my experience, but I learned that the same tradeoffs you get with architectural monoliths/distributed systems often apply to multi/mono repos as well.

[dandigangi]

Same experience. It's interesting because we've had great success on our internal design lib's monorepo compared to the overall application. Which makes sense in some regards.

[purplerabbit]

The fact that you split your design lib from your "overall application" suggests that what you are describing is not, in fact, a monorepo pattern :)

[dandigangi]

There's a split between our orgs. DocuSign runs a mono repo. But the big product I work on has its own giant mono repo. Design lib is another giant mono repo comprising general front end things also.