Google. monorepo with almost full visibility, code search/cross referencing/review tools, good infrastructure support, great videoconference and collaboration tools, a culture of written knowledge vs. oral lore, clear strategy in many parts of the business (loosely coupled, tightly aligned). Perks, pay, vacation are excellent. Work life balance is generally good. World experts in relevant subject matter are never far away.
The things you mentioned are mostly true, however the technical culture is very reactionary and the promo process rewards worse engineers on average in my experience. Most of the better engineers I knew there ended up leaving after a while.
Did you work there? The promo process, especially at the higher levels, does reward ability-to-explain-and-contextualize over pure technical ability, but my opinion is that senior engineers need more of the former than the latter anyways. Deeply understanding your product and what is necessary to make it better can be more important than the ability to pump out algorithms and models.
I recommend reading the Cliff Notes for "The Origin of Wealth" (the full book is just too damn long). Sometimes product designs with a devout following still fail the product market fit test. Trying a bunch of things to see what sticks is a pretty valid strategy, it's what nature does. Steve Jobs would just convince you of your folly for wanting anything but a one button mouse, but Eric, Larry, and Sergey would offer you mice with 1-10 buttons, hover mice, eyeball tracking systems that act as mice, a laser pointer mouse, etc. Each is a small fixed cost and if there's product market fit, the winning variant pays for all the others...
Basically, yes; that is, their strategy is not to avoid taking multiple simultaneous efforts at solving the same broad class of problem, even if it is one where in the long term there is unlikely to be a reason to keep multiple solutions, and they also aren't afraid to take stabs at solving problems where they need a solution to exist but don't strategically need to own the solution.
These strategic choices give them the best chances of having a viable solution either for the market as a supplier or for themselves as a user when they need it, but also makes the number of failed efforts they are going to need to kill higher than it would otherwise be. Or, in short, the strategy creates corpses.
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.
- 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.
