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

101–110 of 219 posts

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

#101

Post by lima »

corentin88 wrote: post #46
ma2rten wrote: post #15

Earlier quoted context omitted.

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

Critique seems a well-guarded secret inside Google. Can't find more information on it. No images. Interesting

Not really. The "Software Engineering at Google" book[1] has a whole chapter on it with screenshots.

Gerrit, Reviewable and Phabricator are very similar, except that Critique is much more polished.

Having used all three, Gerrit works best and the new UI is starting to look pretty good. Reviewable has great UX, but inherits some of the disadvantages of GitHub PRs.

[1]: https://books.google.de/books/about/Software_Engineering_at_...

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

#102

Post by JeremyNT »

Cthulhu_ wrote: post #92
daralthus wrote: post #87

Earlier quoted context omitted.

> 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. Exactly my feelings about Phabricator. GitLab simply runs circles around it if you consider the issue tracking, CI etc. as part of the problem.

I would've loved to have Gitlab at our company, but unfortunately we're on a tight budget so they didn't want to go for anything paid.

Gitlab CE would be perfect, then, since it's free. If you're on a tight budget it actually seems like one of the best options available.

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

#103

Post by cobbzilla »

rockwotj wrote: post #79
cobbzilla wrote: post #78

Earlier quoted context omitted.

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.

There are only so many package managers out there. Most languages have a "preferred" one which makes things even easier. Stuff built with ad-hoc systems might be more difficult, but I don't think that's the norm.

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

#104

Post by [deleted] »

greggman3 wrote: post #13
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

[deleted]

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

#105

Post by kevincox »

dannyw wrote: post #33
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…

Can I ask a monorepo question: what do you when you’re trying to upgrade dependency XYZ, and a moderate or large refactor is required in another team’s code?

Also note that "upgrading a dependency" is a relatively rare occurrence in the sense the I understand the question. Google definitely uses third party code but it is outstanding how much is proprietary Google owned and authored. For this code you don't release new versions and update, instead you evolve APIs gradually (as the other commenters have explained).

For third party dependencies there are two main options.

1. Do it all at once. This is good for relatively small numbers of users or small API changes.

2. Introduce the new version, migrate users, then delete the old version.

Note that for third party libraries Google does maintain a fairly strict one version policy so 2 is always a temporary measure.

https://opensource.google/docs/thirdparty/oneversion/

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

#106

Post by mkoryak »

rwmj wrote: post #77
tdeck wrote: post #12

Earlier quoted context omitted.

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.

What does google use for calendaring?

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

#107

Post by dboreham »

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…

> integer in the range [-2, 2] for some reason

This sounded awesome to me (imagining some Fortran code behind it), but disappointingly the cited screen shot only has the range [-1,0,1] which is hardly the same.

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

#108

Post by vorhemus »

Cthulhu_ wrote: post #90
zcw100 wrote: post #88

The one tool everyone missed was marketing with being able to call yourself an ex-googler being the biggest tool in the toolbox. Let me share the other side of the diaspora (I dislike this term). Tons of former X, pick your popular Silicon Valley company, employees with little else to sell other than that they worked foe x company. The vain CEO hires them hoping that they’ll sprinkle some magic fairy dust on their dy…

I have one experience with that. Guy, late 20's or early 30's at best, ex-Googler joins a bank and becomes CTO. Pushes for them to replace Angular (which they went all in on, migrating from a set of JQuery UI components) with, drumroll, Polymer. Nothing finished yet, performance issues (because guess what, polymer's routing turned out to be pretty much the same as a 'tab panel'), aaand Polymer 2 rolls around, backwar…

It's surprising that the fact "Something that works for Google doesn't necessarily work for company X" is not common knowledge.

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

#109

Post by zcw100 »

mav3rick wrote: post #98
Cthulhu_ wrote: post #90

Earlier quoted context omitted.

I have one experience with that. Guy, late 20's or early 30's at best, ex-Googler joins a bank and becomes CTO. Pushes for them to replace Angular (which they went all in on, migrating from a set of JQuery UI components) with, drumroll, Polymer. Nothing finished yet, performance issues (because guess what, polymer's routing turned out to be pretty much the same as a 'tab panel'), aaand Polymer 2 rolls around, backwar…

There are many companies where ex Googlers have made an impact as founders or senior engineering leaders. Your anecdata has many counters.

It wasn't an absolutest statement but interesting that you've tried to make it so.
Post reply on HN