17 ms·

Context: Staff Eng @ Google for 7+ years 1) This is solved by 2 interlocking concepts: comprehensive tests & pre-submit checks of those tests. Upgrading a vers

Context: Staff Eng @ Google for 7+ years 1) This is solved by 2 interlocking concepts: comprehensive tests & pre-submit checks of those tests. Upgrading a version shouldn’t break anything because any breaking changes should be dealt with in the same change as the version bump. 2) Google’s monorepo allows for visibility restrictions and publicly-visible build targets are not common & reserved for truly public interfaces & packages. 3) “Code churn” is a very uncharitable description of day-to-day maintenance of an active codebase. Google has invested heavily in infrastructural systems to facilitate the maintenance and execution of tests & code at scale. Monorepos are an organizational design choice which may not work for other teams. It does work at Google.

deleted 4y ago
[deleted]
ghosty141 4y ago
How do you deal with wanting to see the history, graph etc of just one sub-project? Does the tooling handle this?
- aleksiy123 4y ago
  I believe everything is tracked at the folder/file level and not a project level. I'm not sure there even is a concept of a project. But maybe someone can correct me.
  - ASinclair 4y ago
    There is a concept of a project. Though viewing change history is more organized around packages and files.
- dastbe 4y ago
  git log <directory> accomplishes this already.
  - myko 4y ago
    Google uses piper and perforce (well, g4) before that
- saagarjha 4y ago
  History for folders is visible in code search, it’s basically equivalent to what GitHub or Sourcegraph would give you. You can query dependencies from the build system. Anything beyond a couple levels deep is unlikely to load in any tools you have ;)
spion 4y ago
> any breaking changes should be dealt with in the same change as the version bump Does this mean that some things will never get updated, as the effort required is impossibly high?
- lallysingh 4y ago
  No you use automated systems to do the change. https://mobile.twitter.com/obeattie/status/1080496955753750533?lang=en https://mobile.twitter.com/obeattie/status/10804969557537505...
  - spankalee 4y ago
    Even so, the cost is often outrageously high. No to mention that if you're the first team to import a third_party library, you own it and other teams can add arbitrary cost to you updating it. You have to be very aggressive with visibility and SLAs to work around this.
    - admax88qqq 4y ago
      You're basically just describing all the pain with pulling in a dependency regardless of monorepo or not. If the third party dependency does not add enough value to justify the cost then don't add it.
      - spion 4y ago
        In a multi-repo setup you can upgrade gradually though, tackling the services that need the upgrade the most first. Can you do that in a monorepo setup?
        onion2k 4y ago
        In a multi-repo setup you can upgrade gradually.. This also means services can be left to rot for years because they don't need to be upgraded, while all the infrastructure changes around them, which is a giant pain when you do eventually need to change something. If you have a multi repo architecture you absolutely need both clear ownership of everything and well planned maintenance.
deleted 4y ago
[deleted]
password11 4y ago
>> 3. It encourages a ton of code churn with very low signal. > 3) “Code churn” is a very uncharitable description of day-to-day maintenance of an active codebase. Also implicit in the discussion is the fact that Google and other big tech companies performance review based on "impact" rather than arbitrary metrics like "number of PRs/LOCs per month". This provides a check on spending too much engineer time on maintenance PRs, since they have no (or very little) impact on your performance rating.
- gajjanag 4y ago
  > based on "impact" rather than arbitrary metrics Umm, from whatever I have seen in big tech "impact" is also fairly arbitrary. It all is based on how cozy one is with one's manager, skip manager, and so on. More accurate is "perception of impact". Especially as it gets more and more nebulous at higher levels.
vl 4y ago
It’s not really even a true monorepo. Little known feature - there is a versions map which pins major components like base or cfs. This breaks monorepo abstraction and makes full repo changes difficult, but keeps devs of individual components sane.
- joshuamorton 4y ago
  This was done away with years ago. Components are no more. There are still a couple of things that develop on long lived dev branches instead of directly at head, but my personal opinion is the need for those things to do that is mostly overstated (and having sent them cls in the past, it's deeply annoying).
baq 4y ago
Is monorepo an important reason for Google to kill products? Or is it just my imagination?
archgoon 4y ago
[dead]
oikawa_tooru_ 4y ago
Hi, unrelated to this, but since you are working at Google, were there actually "code red" meetings at Google concerning chatgpt?

deleted 4y ago

[deleted]

ghosty141 4y ago

How do you deal with wanting to see the history, graph etc of just one sub-project? Does the tooling handle this?

aleksiy123 4y ago
I believe everything is tracked at the folder/file level and not a project level. I'm not sure there even is a concept of a project. But maybe someone can correct me.
- ASinclair 4y ago
  There is a concept of a project. Though viewing change history is more organized around packages and files.
dastbe 4y ago
git log <directory> accomplishes this already.
- myko 4y ago
  Google uses piper and perforce (well, g4) before that
saagarjha 4y ago
History for folders is visible in code search, it’s basically equivalent to what GitHub or Sourcegraph would give you. You can query dependencies from the build system. Anything beyond a couple levels deep is unlikely to load in any tools you have ;)

spion 4y ago

> any breaking changes should be dealt with in the same change as the version bump Does this mean that some things will never get updated, as the effort required is impossibly high?

lallysingh 4y ago
No you use automated systems to do the change. https://mobile.twitter.com/obeattie/status/1080496955753750533?lang=en https://mobile.twitter.com/obeattie/status/10804969557537505...
- spankalee 4y ago
  Even so, the cost is often outrageously high. No to mention that if you're the first team to import a third_party library, you own it and other teams can add arbitrary cost to you updating it. You have to be very aggressive with visibility and SLAs to work around this.
  - admax88qqq 4y ago
    You're basically just describing all the pain with pulling in a dependency regardless of monorepo or not. If the third party dependency does not add enough value to justify the cost then don't add it.
    - spion 4y ago
      In a multi-repo setup you can upgrade gradually though, tackling the services that need the upgrade the most first. Can you do that in a monorepo setup?
      - onion2k 4y ago
        In a multi-repo setup you can upgrade gradually.. This also means services can be left to rot for years because they don't need to be upgraded, while all the infrastructure changes around them, which is a giant pain when you do eventually need to change something. If you have a multi repo architecture you absolutely need both clear ownership of everything and well planned maintenance.

deleted 4y ago

[deleted]

password11 4y ago

>> 3. It encourages a ton of code churn with very low signal. > 3) “Code churn” is a very uncharitable description of day-to-day maintenance of an active codebase. Also implicit in the discussion is the fact that Google and other big tech companies performance review based on "impact" rather than arbitrary metrics like "number of PRs/LOCs per month". This provides a check on spending too much engineer time on maintenance PRs, since they have no (or very little) impact on your performance rating.

gajjanag 4y ago
> based on "impact" rather than arbitrary metrics Umm, from whatever I have seen in big tech "impact" is also fairly arbitrary. It all is based on how cozy one is with one's manager, skip manager, and so on. More accurate is "perception of impact". Especially as it gets more and more nebulous at higher levels.

vl 4y ago

It’s not really even a true monorepo. Little known feature - there is a versions map which pins major components like base or cfs. This breaks monorepo abstraction and makes full repo changes difficult, but keeps devs of individual components sane.

joshuamorton 4y ago
This was done away with years ago. Components are no more. There are still a couple of things that develop on long lived dev branches instead of directly at head, but my personal opinion is the need for those things to do that is mostly overstated (and having sent them cls in the past, it's deeply annoying).

baq 4y ago

Is monorepo an important reason for Google to kill products? Or is it just my imagination?

archgoon 4y ago

[dead]

oikawa_tooru_ 4y ago

Hi, unrelated to this, but since you are working at Google, were there actually "code red" meetings at Google concerning chatgpt?