Live data from Hacker News

An ex-Googler’s guide to dev tools

about.sourcegraph.com

141–150 of 219 posts

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

#141

The article is based on the assumption that what developers absolutely need are the overengineered and bureaucratic tools of a big monopoly company wealthy enough to hire the absolutely best for even the most menial task.

What are the tools used in the most cash-strapped companies facing fierce competition yet prevailing?

For some of the things mentioned, got pull. If I want to jump around to see how a function is defined or used, I don’t need to be able to click in the web interface like you can in Critique. Pulling the code locally and using the open source tools I’m already used to works even better.

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

#142

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. In order to accomplish its core mission of making build & test so much faster, it has to have near complete knowledge of your build graph (the source files and precisely how they depend upon one another). This means that to get the main benefit, you need to go all-in.

Plug: for those interested in codesearch within bazel repositories, my vscode plugin for bazel has a special feature for this: https://stackb.github.io/bazel-stack-vscode/searching

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

#143
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…

It is called cargo cult culture [0]. The idea is to succeed by replicating what other successes have done. The problem is that from the outside, we only see how the successes got where they are in a superficial way.

[0] https://en.m.wikipedia.org/wiki/Cargo_cult

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

#144

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…

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

One of the things that amuses me most is ex-FAANG engineers who are absolutely stymied when they don't have access to the tools and support systems available at their former employers. They've never had to deal with some of the very rough systems the rest of us deal with on a daily basis just to make the business run.

Hubris runs rampant in the ex-FAANG crowd, and businesses who aren't tech companies who hire these folks do so precisely because they don't understand that what worked at ex-FAANG won't necessarily translate to their business.

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

#145
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…

Yes please, Github PRs are much, much better than Gerrit or Ritveld (urgh), and the +1/+2 quirks of it No, I'll take Github PRs any day. They could be better, of course.

Stacked reviews are the crucial thing missing from GitHub pull requests. Truly, once you get used to working wit hthose, going back is intolerable, to the point where I now have a hacked together workflow where I live in git rebase -i and have it automatically push specially named branches for each commit in a stack.

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

#146
post #33

Earlier quoted context omitted.

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?

Another Googler here. We usually have a 3 steps process. 1st new API interface/service using the new dependency is added and runs in parallel with the existing one, 2nd we blast email to users of old one to migrate to the new one, 3rd when usage of the old one hits 0 it is removed. When a team slacks off in migrating (usually we have months between receiving the first notification and service shutdown) things escalat…

In practice it's optimized to a 2 step process, since step 3 almost never triggers.

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

#147
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…

> CEO hired his buddy from high school with a degree in poly sci to run things and is having an affair with the head of hr.

Thats pretty close to the Google story.

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

#148

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.

At this point there are probably 100k ex Google employees.

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

#149
post #34

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.

The revolution was the Internet, bringing together a huge collaboration of open source devs vs the aging ivory tower in each proprietory company.

It's not just Linux and http anymore. It's frameworks towering up to the heavens.

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

#150
post #81

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

New orgs are forming at big companies all the time. In my time at Microsoft, I’ve seen the tooling go from horrible monorepos with perforce to really nice git repos in azure devops. I also don’t think “failing” is the right term for these megacorps. Slow maybe, but even that varies per team.

What does it mean to have plural monorepos?
Post reply on HN