Live data from Hacker News

An ex-Googler’s guide to dev tools

about.sourcegraph.com

131–140 of 219 posts

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

#131

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

GitHub is moving in this direction (they now show interpackage dependencies at the package level, and intra dependencies at the symbol level.

However, neither works great—maybe 30%-80% coverage?, and far from "in a way that gets near complete coverage" that the parent stated about the benefit of Google's monorepo.

It may be a case where you need 90 or 99 or even higher coverage before it becomes a game changer. But I think GitHub is headed there quickly.

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

#133

Earlier quoted context omitted.

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.

Tried self hosting once and it was challenging just to get setup. That said their free hosted solution is feature such enough for most of my projects.

I self host it at home. Haven't had problems but probably only because of how small my instance is (10 people). The omnibus installer makes it relatively simple to maintain!

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

#135
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 agree that it isn't a perfect predictor of future success, but it is a free indicator that carries a decent amount of signal.

And I would encourage anyone who loves the field IMO should have a goal to do a stretch at one of the big ~5 (an internship may be enough). I speak as someone who was very anti-big tech until 2014 when someone convinced me to get my head out of the sand.

Your technical abilities can still improve (as long as you keep practicing yourself, because dev speed will slow down at a big org), you will gain tons of practice working with a lot of talented people, but irreplaceably you will understand more about how the industry is piloted.

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

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

-2 and 2 can be disabled, which I guess is the case on the screenshot you saw.

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

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

GitHub's $4/user/month pricing is very hard to compete against and actually make money as a business. Charging half the price of GitHub for example isn't sustainable.

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

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

There must be a name for this psychology: “Product A is great value and product B is more expensive than (or same as) product A therefore product b is bad value and I won’t buy it.” The ROI or otherwise of a product is not related to the first one. Unless your budget is so limited it’s either-or, why is this fallacy so prevalent?

First, anchoring is very real and humans judge things in comparison to others, especially when compared to unclear things.

I think that fairness is a factor in pricing and it’s not just an ROI calculation.

It’s like those epi pens that went up in price right? From an ROI perspective it’s great because you pay $400 and get to live. But know it costs little makes me think it’s less just.

Relative ROI is also important as we have to prioritize. GitHub seems a much better value to cost than this tool.

It’s perfectly fine for them to price however they like and it seems from their site that lots of companies pay this.

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

#140

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

There are a couple of search engines that do this. Sometimes when I get stuck on a underdocumented Python library, the big G will take me to one via a search on a method or constant. I can then see the code from other open source libraries/projects.

I don’t have any links saved, since they feel kinda sketch (ads all over the place). But it has been very helpful, unlike searching within GitHub for a string that I know is in the repo.

Post reply on HN