[mlthoughts2018]

I ask if a company uses a monorepo as one of the ways to decide to pass on them if they do. Definitely not an indicator of good engineering practices in my opinion.

One of my former bosses was an ex-Google manager and had the same opinion. I guess Google's monorepo grew out of a historical accident from their early customizations of Perforce, and had nothing to do with any supposed engineering benefits that are used to rationalize it now. Then other companies adopted it for the same shallow cargo-cult copying reasons they also use Google's interview hazing approach. And it became an empty marketing icon, e.g. with the ACM article on monorepos.

Any more, I think monorepo vs. project repos is just a bunch of bikeshedding, and the real value of a monorepo is easier centralized surveillance. I grant this might be an important priority for megacorps, but it still doesn't mean it has anything to do with good engineering practices or culture.

[inertiatic]

Curious, what's the largest project you've worked on?

[mlthoughts2018]

It would be between:

- search engine and combined family of backend and web services for search features (autocomplete, image search, machine translation, session-based personalization, etc.) at an online ecommerce site with a top 300 alexa rank

- legacy code base for large-scale integrated air defense system simulations at a research lab (code spanned from 80s to 00s)

Both projects well into the tens of millions of lines of source code, much of it old FORTRAN and C in the IADS codebase, requiring us to maintain old compiler toolchains, etc.

The defense simulation stuff was one centralized repo for security purposes, with lots of bespoke extra pieces of code on this researcher’s machine or that researcher’s machine. It was exceedingly hard to work with, but obviously is not a fair comparison to a large tech company which has 1-2 orders of magnitude more code and has customized tooling for it.

The search engine codebase was split into over a hundred different component-specific git repos, and despite the occasional CI headaches, was a joy to work with because component vcs history and project workflows were so well separated.