An ex-Googler’s guide to dev tools • Hacker News Board

Re: An ex-Googler’s guide to dev tools

#11

Post by tdeck » Thu, Nov 26, 2020, 7:52 AM UTC

> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me.

Perhaps the operative phrase being "Many years ago". I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. Some things really are better at Google (code search and Blaze are definitely a big improvement over what we had), but many of our monitoring and CI tools feel antiquated and cluttered with inscrutable debris. Or take Gerrit, where each change has 3 different IDs and the developers decided that every workflow status should be expressed as an integer in the range [-2, 2] for some reason [1].

They were probably amazing (and much simpler) tools back in the day, but the world has moved and we're somewhat constrained by what's familiar.

[1]: https://gerrit-review.googlesource.com/Documentation/images/...

Re: An ex-Googler’s guide to dev tools

#12

Post by tdeck » Thu, Nov 26, 2020, 7:59 AM UTC

akhilcacharya wrote: post #6

galkk wrote: post #5

I also think that one of the parts of the success is that insane amount of system configs and other data are also source controlled or provide other means textual access for search (bigquery, etc). This makes code search a super power. (googler)

Isn't *this...common? IaaS is good practice these days. I work at an eCommerce co and we do this as well.

Perhaps, but what's notable about Google is the extent to which everything is a text config file, and the fact that everything is in a monorepo.

As an example that surprised me, even our oncall rotations are kept in a text file along with a list of upcoming assignments. The rotation tool checks out that file and appends the next few names in the list to the end of that file to prepare the "calendar" for the coming weeks.

Re: An ex-Googler’s guide to dev tools

#13

Post by greggman3 » Thu, Nov 26, 2020, 8:02 AM UTC

Sevii wrote: post #8

Isn't code search more table stakes nowadays? Both github and gitlab have it. There isn't anything said about end to end, integration or functional testing here. I'm in a world where everyone hacks their own system together onto the same runtime, leading to some wonky outcomes and lots of operational support. Would be interesting if there was a 'google' way to do it.

I don't know what Google's internal code search is like but if you want to see Chromium's code search it's here

https://cs.chromium.org

also android's

https://cs.android.com/

So you can compare

Re: An ex-Googler’s guide to dev tools

#14

Post by logicslave » Thu, Nov 26, 2020, 8:03 AM UTC

Honest opinion on FAANG tools is that the big ones are now antiquated and slowing these big tech companies down. Eventually they will need to rip out all these tools that once gave them an edge and replace them, but they cant bc of how much depends on them, and whala, you have a large failing slow company

Re: An ex-Googler’s guide to dev tools

#15

Post by ma2rten » Thu, Nov 26, 2020, 8:05 AM UTC

tdeck wrote: post #11

> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me. Perhaps the operative phrase being "Many years ago". I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. Some things really are better at Google (code search a…

Note that Critique (Google's main code review UI) doesn't have the same issues that Gerrit apparently has.

Re: An ex-Googler’s guide to dev tools

#16

Post by ponker » Thu, Nov 26, 2020, 8:08 AM UTC

logicslave wrote: post #14

Honest opinion on FAANG tools is that the big ones are now antiquated and slowing these big tech companies down. Eventually they will need to rip out all these tools that once gave them an edge and replace them, but they cant bc of how much depends on them, and whala, you have a large failing slow company

Is “whala” an adaptation from the French “voilá” or of a different origin?

Re: An ex-Googler’s guide to dev tools

#17

Post by burakemir » Thu, Nov 26, 2020, 8:08 AM UTC

(Googler here) The article is a good description of the tools, and I was not aware of the blaze clones plz and pants.

One thing that is maybe not obvious: For an API author, code search in combination with a monorepo and the somewhat hermetic universe which is Google's code base provides immediate access to all uses of a library. You can see what worked well and what didn't, and it enables effective refactorings. That also means when writing a client, you can quickly figure out from other client code how stuff is supposed to be used. All this makes code search such an effective tool in Google's development environment (in the broader sense).

If anything like this were possible for open source (indexing code that depends on a library/API, across subrepos in any version control system, in a way that gets near complete coverage), it would enable similar possibilities of systematic improvement.

Alas, it does not seem realistic except in a few niches where the number of clients is bounded and code owners are willing and able to follow a protocol (approve changes to their code that unblock such global improvements.)

Re: An ex-Googler’s guide to dev tools

#18

Post by logicslave » Thu, Nov 26, 2020, 8:09 AM UTC

ponker wrote: post #16

logicslave wrote: post #14

Honest opinion on FAANG tools is that the big ones are now antiquated and slowing these big tech companies down. Eventually they will need to rip out all these tools that once gave them an edge and replace them, but they cant bc of how much depends on them, and whala, you have a large failing slow company

Is “whala” an adaptation from the French “voilá” or of a different origin?

Its me not caring about the spelling haha...

Re: An ex-Googler’s guide to dev tools

#19

Post by tpetry » Thu, Nov 26, 2020, 8:11 AM UTC

logicslave wrote: post #14

Honest opinion on FAANG tools is that the big ones are now antiquated and slowing these big tech companies down. Eventually they will need to rip out all these tools that once gave them an edge and replace them, but they cant bc of how much depends on them, and whala, you have a large failing slow company

Declaring a FAANG company failing because it‘s toolset is antiquated is the rare hn elitist opinion you see here more and more. Are startup people in the valley more and more becoming blind to the real world?

Re: An ex-Googler’s guide to dev tools

#20

Post by rockwotj » Thu, Nov 26, 2020, 8:15 AM UTC

ind3mp0tent wrote: post #3

Refreshing article! For people with less time check out https://github.com/jhuangtw/xg2xg which tracks open source implementations of Google internal tools (also linked in the article) Also I have been looking to move away from Makefiles and bash scripts and Bazel does come up more often. What are your experiences working it and how does it compare to Blaze?

I'm a big fan of bazel. It's very similar to blaze, which outside of Google is a good and bad thing.

The good is that I find BUILD files easier to read/reason about than Makefiles and it also is multilingual.

The bad is external dependency is hard, especially if you want to take advantage of all of bazel's features like hermetic builds. Most larger C and C++ don't use bazel to build and don't have BUILD files, so you end up maintaining your own build system for that project OR use something like [this][1].

1: https://github.com/bazelbuild/rules_foreign_cc