3 ms·

He is referring to the codebase itself, not individual projects or CLs.

simoncion 2y ago
As a Google outsider, that's not at all the impression I got from the paragraphs. This: > It's not held to THAT high a standard. We absolutely commit janky MVPs and iterate. seems to very directly address this: > The opposite of move fast, build a shitty prototype and iterate is a deliberate problem solving approach undertaken by the highest caliber of engineers. The actual challenges to be addressed are effectively addressed right at the design stage. If your claim is that "Well, if you look at the codebase AS A WHOLE, there's absolutely no iteration and shitty prototypes, it's all designed right from the start."... well, I can't see any way that codebase came into existence without being built up by individual projects and changesets. So, yanno, when folks on the ground report that individual projects and changesets/PRs/whatever ARE using the "Commit something barely serviceable, test it out, and iterate." process, statements like "We always get the design right before we write even a single line of code!" definitely come off as a circlejerk. Google's a very large software house, it has a very exclusive hiring process, and it (reportedly) has internal tooling that's very well-adapted for the problems a company of its size faces. But Google is still hiring from the same pool of programmers as everyone else, and the odds that zero of those that it hires will work best with the "Get something out there to field-test, and use the test results to make it more suited for field use." method of development are absolutely zero. Given Google's size, the odds that zero of those will never be able to negotiate to work in the way they work best are ALSO zero. (And -frankly- I expect that this method of development gets used a lot in the company. You can burn an assload of time on simulators (and what is the "What if?" game, but a in-brain simulator?), but in the realm of software, it's not-infrequently the case that the simulator with the best ROI is real-world deployment.)
- elevatedastalt 2y ago
  While Google is a monorepo, that doesn't mean that every part of the codebase is equally critical. People don't yolo submit CLs to core library components for example. OTOH submitting somewhat hacky code to a new project while you iterate on it doesn't harm the rest of the code base that much since very little will depend on it.
  - simoncion 2y ago
    Okay, sure. How does this comment address any parts of my statement? I'll even quote what might be the most important part for you: > If your claim is that "Well, if you look at the codebase AS A WHOLE, there's absolutely no iteration and shitty prototypes, it's all designed right from the start."... well, I can't see any way that codebase came into existence without being built up by individual projects and changesets.
remram 2y ago
He is referring to the codebase not the code? What does that mean?
- reverius42 2y ago
  I think they are referring to the developer experience of working in the codebase, rather than the quality of the code.

As a Google outsider, that's not at all the impression I got from the paragraphs. This: > It's not held to THAT high a standard. We absolutely commit janky MVPs and iterate. seems to very directly address this: > The opposite of move fast, build a shitty prototype and iterate is a deliberate problem solving approach undertaken by the highest caliber of engineers. The actual challenges to be addressed are effectively addressed right at the design stage. If your claim is that "Well, if you look at the codebase AS A WHOLE, there's absolutely no iteration and shitty prototypes, it's all designed right from the start."... well, I can't see any way that codebase came into existence without being built up by individual projects and changesets. So, yanno, when folks on the ground report that individual projects and changesets/PRs/whatever ARE using the "Commit something barely serviceable, test it out, and iterate." process, statements like "We always get the design right before we write even a single line of code!" definitely come off as a circlejerk. Google's a very large software house, it has a very exclusive hiring process, and it (reportedly) has internal tooling that's very well-adapted for the problems a company of its size faces. But Google is still hiring from the same pool of programmers as everyone else, and the odds that zero of those that it hires will work best with the "Get something out there to field-test, and use the test results to make it more suited for field use." method of development are absolutely zero. Given Google's size, the odds that zero of those will never be able to negotiate to work in the way they work best are ALSO zero. (And -frankly- I expect that this method of development gets used a lot in the company. You can burn an assload of time on simulators (and what is the "What if?" game, but a in-brain simulator?), but in the realm of software, it's not-infrequently the case that the simulator with the best ROI is real-world deployment.)

elevatedastalt 2y ago
While Google is a monorepo, that doesn't mean that every part of the codebase is equally critical. People don't yolo submit CLs to core library components for example. OTOH submitting somewhat hacky code to a new project while you iterate on it doesn't harm the rest of the code base that much since very little will depend on it.
- simoncion 2y ago
  Okay, sure. How does this comment address any parts of my statement? I'll even quote what might be the most important part for you: > If your claim is that "Well, if you look at the codebase AS A WHOLE, there's absolutely no iteration and shitty prototypes, it's all designed right from the start."... well, I can't see any way that codebase came into existence without being built up by individual projects and changesets.

remram 2y ago

He is referring to the codebase not the code? What does that mean?

reverius42 2y ago
I think they are referring to the developer experience of working in the codebase, rather than the quality of the code.