Live data from Hacker News

An ex-Googler’s guide to dev tools

about.sourcegraph.com

121–130 of 219 posts

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

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

When someone says "ex googler" usually during the beginning of a call,I immediately multi-task, let them finish with their chest pounding and move on from them, trying to avoid them going forward. If you can't convince people with the technical merits of your plan, I guess you just try and name drop (company drop). Some people buy it, most don't and they sit in some enterprise architect role with maybe a few internal fans. If you want to waste tons of money, scale your company for billions of users when you have 2000, hell don't even scale just say you can and claim success before you even do it, it works there are tons of these guys and gals ripping apart companies for their perfect "designs" that worked at google.

(i never worked at google but did interview, argued with the interviewer and hung up, he thought computers worked differently than they do in reality and just spoke with this heir of authority, without having a spec of it )

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

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

> Both github and gitlab have it

If you want to search code sitting on your local hard disk try this tool (built on top of Lucene):

https://github.com/Rajeev-K/eureka

I made it when I was frustrated by existing tools such as sourcegraph and opengrok.

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

#123

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.

you're assuming the egg is after the chicken. There's a lot to argue for in stating that orgs should create tools to increase the volition of their devs.

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

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

so right, but it won't make you any money or get you any linkedin/twitter fans if you speak the truth. We have AI being tossed around like it isn't just database queries most of the time.

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

#125

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.

An analogy, if I may share: On the one hand I agree with you, in that these liabilities you describe are much like the legacy systems I see in our local banking sector. On the other hand, these legacy systems just work. And adopting newer / more modern systems might definitely have advantages, but doing so creates a bunch of other liabilities - as I've seen take place in our new startup banks. Stuck between a rock an…

FAANG's often don't have paying customers, banks do.

Its not being stuck between a rock and a hard place, you just need strong management that understands that changing whole systems is never a good idea without clear benefit, other than "technical debt" which is such a bad term for reliable software. Software doesn't age, im not sure how software engineers don't understand this, or maybe they do and want to write more s/w.

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

#126

1. Why does Google develop their own tools? 2. Why doesn't Google open source them?

(googler here)

For 1 I guess it also boils down to the mindset you approach a problem. On my past companies when you have a problem the first thing you do is to find a OSS or product that solves that for you and even when you don't find you try to reframe the problem in a way that will fit that solution that you already have in your mind, at google it normally involves on you solving that by yourself or reusing much lower level of abstractions.

This doesn't mean that you will need to always create your own database, but when you really need to you have the skills to do a decent job.

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

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

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

This was actually pretty useful in OpenStack back in the day. The reviewers who couldn’t yet approve code could only put +1s on there (and there were a lot of low quality reviewers who slapped these everywhere) so it was very obvious when a patch still needed attention from a commit-privileged dev.

Then -1 was standard review feedback of stuff that needed improving and -2 would come from commit-privileged devs when the patch fundamentally didn’t fit with the project direction.

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

#128

Earlier quoted context omitted.

It went through a re-design recently. I don't think I would call it a well-guarded secret though, if you look at Phabricator's Differential, it is very similar [0]. [0] https://www.phacility.com/phabricator/differential/

Reading through that page it seems like every single component is an unrelated, seemingly random, “cute” name. Are cli, triggers/actions, and rules too generic? Out of context, what meaning do Arcanist, Maniphest, or Herald have?

Related answer from one of the developers: https://www.quora.com/Phabricator/Phabricator-Why-is-the-Bro...

But yeah... even I find the names difficult to handle and remember, even after using Phabricator for more than 4 years now. Nevertheless, it is a great piece of software, especially the code review process is top-notch.

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

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

Interesting. Viceroy can put way more pixels on the screen than grafana with the same cpu and memory usage, and panopticon is specifically written to send little traffic over the wire, so it’s useful to an oncall engineer over a poor mobile backhaul like GPRS. Grafana is a massive resource hog in all dimensions.

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

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

Google’s internal code search is far ahead of GitHub, Gitlab, and even sourcegraph. But you can use it, because they open-sourced it. I don’t know why more people don’t use it.

https://kythe.io/

Post reply on HN