6 ms·

Everybody comments about how there are all these amazing tools that help your productivity (which is true), but they don't talk about how the opposing force of

Everybody comments about how there are all these amazing tools that help your productivity (which is true), but they don't talk about how the opposing force of organizational complexity ultimately results in "just normal" levels of productivity. They don't cancel each other out exactly though, so some things are way easier (spinning up a huge computation), while some things are way harder (making a small change to shared components).

bt848 7y ago
Absolutely disagree, to the maximum possible extent. My entire job at Google was to find and fix inefficiency in other people’s projects. I didn’t own any projects! But I submitted changes to foreign code daily and I rarely got any kind of pushback. Working on shared code is so easy at Google because they have a fantastic cross-referenced code browser and search engine, ways to inspect production jobs and configs that anyone can access, and everything is open and visible. By contrast the other large publicly-traded cloud company where I now work has the opposite culture: no code search worth using, “why are you touching my project?” culture, not enough tests to give anyone confidence in a change. The polar opposite of Google.
- BeetleB 7y ago
  >My entire job at Google was to find and fix inefficiency in other people’s projects. I believe when he said "organizational efficiency" he was not referring to technical inefficiencies, but rather chain of command, how organizations are structured, etc. Not at Google, but that is the case in my company as well. In most of the company, doing extremely great technical work is not going to get you far.
- jeremysalwen 7y ago
  Hmm, I think you interpreted my comment about "making a small change to shared components" differently than I meant it. I am guessing that your changes did not change the semantic behavior of other people's code. e.g. you were replacing one hash-map implementation with a more efficient one. That's something where obviously Google's tools do cancel out the inherent inefficiency of large organizations/code bases. My point was that Google has the level of efficiency of a small organization, despite being a large organization. That the default for big organizations is to "just suck" as you described, makes this remarkable, but I never felt like this resulted in a superhuman level of productivity that you might expect considering how advanced the tools are.
tedmiston 7y ago
I thought the monorepo setup made cross-project dependency changes easy?
- Moto7451 7y ago
  Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical necessities) have lead to all the languages being twisted into an odd hybrid of the dependency management style of each other. Things are very complicated to manage and some teams are trying to leave their current and best known language for a language with internal champions/leaders that are louder, more opinionated, and better positioned politically. A lot of this is due to a lack of wide familiarity with intermediate git skills and a fear of learning the tool. So many of our solutions to this problem are to automate things under the rug, which is why every language ends up being handled generically using medium grade internal tooling instead of best of class industry standard tooling. Most of these issues can be boiled down to an avoidance of pain rather than a championing of the best technical choice. Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need. The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.
- skybrian 7y ago
  Well, it depends. If you have an API with only a few direct usages, you might do it in a single commit. Changing API's that have many usages is difficult to do atomically even if you have a monorepo, due to the difficulty of getting approvals and the risk you'll have to roll it back. Often it's better to introduce a new function and migrate usages to it across multiple commits. Either way, it's on you to fix everyone else's code, which is a different mindset from releasing a library and letting downstream users do the migration themselves when they feel like it.

bt848 7y ago

Absolutely disagree, to the maximum possible extent. My entire job at Google was to find and fix inefficiency in other people’s projects. I didn’t own any projects! But I submitted changes to foreign code daily and I rarely got any kind of pushback. Working on shared code is so easy at Google because they have a fantastic cross-referenced code browser and search engine, ways to inspect production jobs and configs that anyone can access, and everything is open and visible. By contrast the other large publicly-traded cloud company where I now work has the opposite culture: no code search worth using, “why are you touching my project?” culture, not enough tests to give anyone confidence in a change. The polar opposite of Google.

BeetleB 7y ago
>My entire job at Google was to find and fix inefficiency in other people’s projects. I believe when he said "organizational efficiency" he was not referring to technical inefficiencies, but rather chain of command, how organizations are structured, etc. Not at Google, but that is the case in my company as well. In most of the company, doing extremely great technical work is not going to get you far.
jeremysalwen 7y ago
Hmm, I think you interpreted my comment about "making a small change to shared components" differently than I meant it. I am guessing that your changes did not change the semantic behavior of other people's code. e.g. you were replacing one hash-map implementation with a more efficient one. That's something where obviously Google's tools do cancel out the inherent inefficiency of large organizations/code bases. My point was that Google has the level of efficiency of a small organization, despite being a large organization. That the default for big organizations is to "just suck" as you described, makes this remarkable, but I never felt like this resulted in a superhuman level of productivity that you might expect considering how advanced the tools are.

tedmiston 7y ago

I thought the monorepo setup made cross-project dependency changes easy?

Moto7451 7y ago
Not a googler, but at my company this has not been the case. We use several programming languages and some of the people driven choices (rather than technical necessities) have lead to all the languages being twisted into an odd hybrid of the dependency management style of each other. Things are very complicated to manage and some teams are trying to leave their current and best known language for a language with internal champions/leaders that are louder, more opinionated, and better positioned politically. A lot of this is due to a lack of wide familiarity with intermediate git skills and a fear of learning the tool. So many of our solutions to this problem are to automate things under the rug, which is why every language ends up being handled generically using medium grade internal tooling instead of best of class industry standard tooling. Most of these issues can be boiled down to an avoidance of pain rather than a championing of the best technical choice. Ultimately no decrease in dependencies have been made. Projects are barely bundled together any more than before. The only thing that’s made that possible has been Docker and Docker Compose, and our monorepo strategy makes it more difficult to build images due to its size and our topical file systen layout making it almost impossible to check out only the parts of the repo you need. The monorepo itself may be a good idea but it’s no silver bullet. I’d say it’s one of the worst choices we’ve made due to the cultural impact it’s had. In our case I think we’d be better off with small monolithic repos due to a lack of proper training around how to manage either many small repos or a large monorepo.
skybrian 7y ago
Well, it depends. If you have an API with only a few direct usages, you might do it in a single commit. Changing API's that have many usages is difficult to do atomically even if you have a monorepo, due to the difficulty of getting approvals and the risk you'll have to roll it back. Often it's better to introduce a new function and migrate usages to it across multiple commits. Either way, it's on you to fix everyone else's code, which is a different mindset from releasing a library and letting downstream users do the migration themselves when they feel like it.