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

21–30 of 219 posts

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

#21

Post by logicslave »

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?

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.

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

#22

Post by rockwotj »

skrebbel wrote: post #10
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.

Last I checked, GitHub's code search was so bad that it's useless. There's definitely a use for good code search.

Search on GitHub is very bad IMO.

The recent semantic references stuff they've added is helping, but that only seems to be available in certain language/setups and doesn't work cross repo. Google's xref system allowed you to browse essentially the whole Google codebase - it was amazing. Third party code was indexes too, I remember my team used code search to track down a bug in NGINX once.

Githubs normal search feature is bad. I can't even quote stuff for exact matches. I usually end up using bigquery for GitHub wide searches [1] or just pull down the repo and grep locally.

[1]: https://www.google.com/amp/s/cloudblog.withgoogle.com/produc...

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

#23

Post by discordance »

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

Unless I’m missing your point, I disagree. Many Microsoft teams I’ve worked with use Azure Dev Ops or Github + whatever OSS tooling they need. They have all done solid testing, infra as code and CI/CD etc. The tooling is not at all antiquated.

It’s actually been pretty refreshing to be around.

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

#24

Post by lima »

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…

Gerrit is configurable and it is common to use it like Critique with blocking comments and LGTMs.

It's still a big step up from, say, GitHub PRs, and the UX has improved significantly.

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

#25

Post by ra7 »

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…

Unsurprisingly, this reminds me of upstream Kubernetes where code reviewers/approvers and project maintainers are all just text files named OWNERS, and the tools just read the files to enforce the rules. Very simple and elegant!

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

#28

Post by herodoturtle »

logicslave wrote: post #21
tpetry wrote: post #19

Earlier quoted context omitted.

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?

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 and a hard place.

Of course that's just in banking. I most certainly don't have the experience to comment on whether the same liability tradeoff would happen at FAANGs.

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

#29

Post by prepend »

Sourcegraph seems interesting but the pricing seems off for me. The “Teams” plan costs $150/month for 25 people and that works out to $6/user/month.

Using GitHub it’s between $4-21/user/month.

So this means that insight from my source costs sometimes more than actually managing my source.

I’ve never worked at Google but it seems like one benefit is that they’ve figured out how to scale the costs of this kind of functionality so you don’t have to run into conundrums like this.

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

#30

Post by dannyw »

prepend wrote: post #29

Sourcegraph seems interesting but the pricing seems off for me. The “Teams” plan costs $150/month for 25 people and that works out to $6/user/month. Using GitHub it’s between $4-21/user/month. So this means that insight from my source costs sometimes more than actually managing my source. I’ve never worked at Google but it seems like one benefit is that they’ve figured out how to scale the costs of this kind of funct…

It only needs to save your developers a few minutes of time on average to be worth it.
Post reply on HN