6 ms·
Nope, that's not quite how it worked. Except for a few critical libraries that were pinned to specific versions, every build built against HEAD. However, a pr
by thirtyseven 10y ago
Nope, that's not quite how it worked. Except for a few critical libraries that were pinned to specific versions, every build built against HEAD. However, a presubmit hook would run tests on the transitive closure of code depending on the changed code, and if anything broke, it was your responsibility as the committer to fix it or roll it back.
This is really what kept things stable. If you maintained a a common library and wanted to update it, you had to either keep things backwards compatible, write an automated refactor across the codebase (which wasn't too hard because of awesome tooling), or you would get dozens of angry emails when everything broke. If you relied on a library, you had to be sure to write solid e2e tests or your code might silently break and it would mostly be your fault.
I definitely miss the big G, so many resources were dedicated to engineer productivity and tooling. It's what makes the monorepo work.
- lpolovets 10y agoThanks! I appreciate the correction. I miss a lot of the resources, too. I also miss the spirit of dedicating serious attention to code quality. Things like Testing Fix-it and Documentation Fix-it days were awesome.
- squeaky-clean 10y ago> Things like Testing Fix-it and Documentation Fix-it days were awesome. Can you elaborate on this? Are they just days where the team goes "Ok, no need to stress about new features today, let's just catch on on test coverage / documentation" ? If so, that sounds pretty wonderful.
- lpolovets 10y agoIt was company-wide. Every month or two, there would be a "documentation fix-it day" or something similar. The theme would vary: sometimes it was docs, sometimes unit tests, sometimes localization, etc. If memory serves correctly, the idea was that unless you had a high priority/production bug, you'd spend your day working on the theme of the fix-it.
- krashidov 10y agoWhy did you leave?
- iainmerrick 10y ago"Oh yeah, and this is our awesome in-house build system. You're really going to enjoy working on ads!"
- packetslave 10y agoYes, working in a product area that's directly responsible for generating $N*10^9 of revenue per year is just terrible. I'm sure they don't do ANYTHING interesting, technology-wise.
- iainmerrick 10y agoI'm being facetious and exaggerating a bit, sure. But for every engineer doing cool machine learning stuff, there are 10 mucking about with AdWords and AdSense front-ends -- on customer-facing stuff that they probably don't use themselves. It's energising to work on a product you use, it's draining to work on one you don't. (And I guess I'm putting words into the mouth of the earlier poster, sorry about that. This is from my own experience, not theirs!)
- throwaway6497 10y agoJust curios how does this automatic refactoring across entire code base work? Do they build AST's and then refactor? Or it at more surface level where you are replacing text intelligently?
- honkhonkpants 10y agoEither one. http://research.google.com/pubs/pub41342.html http://research.google.com/pubs/pub41342.html for the former.