4 ms·

Its both. The tooling has a very direct impact on the quality of the code. I think the reason its not easy replicable is: 1. It takes a ton of initial investm

Its both. The tooling has a very direct impact on the quality of the code. I think the reason its not easy replicable is: 1. It takes a ton of initial investment and ongoing maintenance but its worth it when your code base is gigantic. 2. There is a consistent set of top down enforced rules. With the consistency it becomes much, much easier to build tight integrations between tools. (almost?) everything is buildable by a single build system (blaze). When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. Probably someone can dive deeper than I can. But one thing I learned the most important property for a code base to be maintainable/scalable is consistency.

aleksiy123 2y ago
One more thought, is also how much other systems can utilize the same tooling/workflows by just storing things in source code. Things that would probably traditionally stored as application state in a database are often stored instead in google3 as config. Things like on team rosters, on call rosters, code review permissions, service permissions, feature flags. All of it stored in google3 and can all utilize the same consistent set of tooling like presubmit test, integration tests, deployment automation, permissions, code search. Its sort of like Infrastructure as Code but more.
- kridsdale3 2y ago
  I also love the built-in history diffing that this gives you on those files.
- nurple 2y ago
  Org as code
ryukafalz 2y ago
> When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. As someone who hasn't worked for Google, how does Google's implementation of this differ from e.g. Guix/nixpkgs? Being able to easily build/test any available package is a big reason I like using tools like those.
- aleksiy123 2y ago
  I'm unfortunately not that familiar with the internals. I think the public bazel (public version of blaze) docs is probably the best place to look. https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity

aleksiy123 2y ago

One more thought, is also how much other systems can utilize the same tooling/workflows by just storing things in source code. Things that would probably traditionally stored as application state in a database are often stored instead in google3 as config. Things like on team rosters, on call rosters, code review permissions, service permissions, feature flags. All of it stored in google3 and can all utilize the same consistent set of tooling like presubmit test, integration tests, deployment automation, permissions, code search. Its sort of like Infrastructure as Code but more.

kridsdale3 2y ago
I also love the built-in history diffing that this gives you on those files.
nurple 2y ago
Org as code

ryukafalz 2y ago

> When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. As someone who hasn't worked for Google, how does Google's implementation of this differ from e.g. Guix/nixpkgs? Being able to easily build/test any available package is a big reason I like using tools like those.

aleksiy123 2y ago
I'm unfortunately not that familiar with the internals. I think the public bazel (public version of blaze) docs is probably the best place to look. https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity