Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An ex-Googler’s guide to dev tools

about.sourcegraph.com

Post reply on HN
Print view View original

71–80 of 219 posts

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

#71

Post by cobbzilla »

burakemir wrote: post #17

(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. Tha…

> 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. ... 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.

gets me thinking — this is totally doable for open source code. someone just needs to build some giant indexes across git repos + package repos (maven/npm/pip/etc)...

Then write plugins for VScode/intellij, and when developing you can right-click a symbol and “Find uses in open source code”

Does something like this already exist?

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

#72

Post by summerlight »

For me, logs processing system and Dremel were probably the most marvelous tools that I've ever seen in my SWE career. Millions of machines are producing trillions of logs records everyday. Then Dremel runs some arbitrary query over those records in an order of minutes (seconds for simple queries), without indexing.

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

#73

Post by thrweo24324324 »

tpetry wrote: post #19
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?

There is a certain kernel of truth to it. I work at Google, and doing anything at all is a chore - it's almost as if we're back to programming with punch cards.

It's not surprising that Python doesn't work well in such a high-delay dev environment.

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

#74

Post by rockwotj »

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…

I agree - grafana is wayyy better than viceroy and the other monitoring dashboards that were available when I worked at Google.

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

#75

Post by thrweo24324324 »

tdeck wrote: post #12
akhilcacharya wrote: post #6

Earlier quoted context omitted.

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 we…

Yes, but on the other of the spectrum, GCL itself has turned into another half baked programming language. Editing these configs is the bane of my life.

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

#76

Post by rockwotj »

cobbzilla wrote: post #71
burakemir wrote: post #17

(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. Tha…

> 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. ... If anything like this were possible for open sou…

I don't think so. When you consider that you'd have to index every library and every version of it. That's a huge index. Google has the "live at HEAD" [1] mentality so in reality you don't need as much. I don't remember if xrefs for old versions of the code we're retained.

1: https://abseil.io/about/philosophy#upgrade-support

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

#77

Post by rwmj »

tdeck wrote: post #12
akhilcacharya wrote: post #6

Earlier quoted context omitted.

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 we…

The company I work for uses Google Calendar, which is worse in every way than the approach used at Google for calendaring.

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

#78

Post by cobbzilla »

rockwotj wrote: post #76
cobbzilla wrote: post #71

Earlier quoted context omitted.

> 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. ... If anything like this were possible for open sou…

I don't think so. When you consider that you'd have to index every library and every version of it. That's a huge index. Google has the "live at HEAD" [1] mentality so in reality you don't need as much. I don't remember if xrefs for old versions of the code we're retained. 1: https://abseil.io/about/philosophy#upgrade-support

It would be huge but storage is cheap, you could build in phases based on popularity. Maybe paid subscriptions for the full index?

But yeah, it could get expensive to keep the indexes current as things grow.

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

#79

Post by rockwotj »

cobbzilla wrote: post #78
rockwotj wrote: post #76

Earlier quoted context omitted.

I don't think so. When you consider that you'd have to index every library and every version of it. That's a huge index. Google has the "live at HEAD" [1] mentality so in reality you don't need as much. I don't remember if xrefs for old versions of the code we're retained. 1: https://abseil.io/about/philosophy#upgrade-support

It would be huge but storage is cheap, you could build in phases based on popularity. Maybe paid subscriptions for the full index? But yeah, it could get expensive to keep the indexes current as things grow.

Yeah but you also have to understand the dependency management systems for every open source project on GitHub to get the right dependency, which is a sisyphean task. Google has the advantage there is only one way to build stuff.

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

#80

Post by stgx »

xorcist wrote: post #34
logicslave wrote: post #21

Earlier quoted context omitted.

I'd say once you take a peak behind the curtain at some of these FAANGS you see that their once greatest assets are becoming liabilities. The magic of "FAANG" goes away. The innovative systems they all built in 2007-2012 period are now aging.

What great revolution do you suppose happened in the past decade that made these tools obsolete? To my eyes, we still develop software in plain text and the same languages are still dominant. It's still Linux and http.

A lot has improved over the past decade.
Post reply on HN