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

171–180 of 219 posts

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

#171

Post by maxekman »

breck wrote: post #131
cobbzilla wrote: post #71

Earlier quoted context omitted.

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

Yes, definitely. And what they already have is often very useful, I find myself spontaneously traversing code bases by going to definitions and references. Quite an impressive (and non-intrusive) addition from a UI perspective.

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

#172

Post by EricBurnett »

cromwellian wrote: post #52

I think what's missing from the tools discussion is the infrastructure that the tools sit on top of: 1) CitC (Client in the Cloud). Mounts your development environment on FUSE filesystems that exist in the cloud. The entire monorepo is mapped into your CitC directory. You can access it from your desktop shell, your home laptop, or a Web Browser based IDE. Any edits you make are overlaid onto the (readonly) source rep…

> 5) Forge -- basically Blaze's remote build execution (what Bazel calls RBEs). Almost every build at Google is extremely parallelized, and if you need to run flake tests, running a suite of tests 10,000 times is almost as fast as running it once.

This is available outside Google now - start at https://github.com/bazelbuild/remote-apis or https://docs.bazel.build/versions/master/remote-execution.ht... . It's a standardized API, supported by a growing set of build tools (notably Bazel, Pants, Please) with a variety of OSS and Commercial implementations. At this point almost anyone can set up Remote Execution if they wish to, and remote caching is even easier.

Minor terminology correction: RBE generally refers to Google's own implementation of the same name; Remote Execution (RE) and the REAPI are used to refer to the generic concept.

(Disclaimer: I work on this at Google.)

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

#173

Post by snazz »

thrweo24324324 wrote: post #73
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?

There is a certain kernel of truth to it. I work at Google, and doing anything at all is a chore - it's almost as if we're back to programming with punch cards. It's not surprising that Python doesn't work well in such a high-delay dev environment.

I haven't worked at Google or any other big tech company, but I understand that Google's culture is far more like academia anyway. Compared to Facebook, Google prioritizes code quality over development speed. Other companies seem to fall somewhere in between.

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

#174

Post by snazz »

alisonkisk wrote: post #150
mlazos wrote: post #81

Earlier quoted context omitted.

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?

Org-wide instead of company-wide, maybe?

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

#175

Post by matt_o »

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…

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

I wrapped a 2-year stint at Facebook recently and my experience was similar to yours.

Some tools were amazing and cool and I really appreciated how they evolved over time to manage huge amounts of resources. But most were subpar when compared to OSS tooling - outdated, deprecated functionality, very little documentation, very few people working on them. The common approach was to learn about "the duct tape" way to make something work, then pass it on to new engineers.

An example would be tool X for working with diffs (PRs). It's the latest and greatest, except that it only covers 75% of its predecessor's, tool Y's, functionality, so you end up learning both. Tool Y has been "deprecated" for the past 3-4 years. Some of its features don't work, but you'll only know when you try and execute them.

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

#177

Post by cmrdporcupine »

Sesse__ wrote: post #159
corentin88 wrote: post #46

Earlier quoted context omitted.

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

It's a reimplementation of an earlier system called Mondrian, which you can find some information on.

I used Mondrian for the last couple months it existed, and I recall critique being fairly different.

I think they kept the same keystrokes, though.

That is one nice thing about Critique is although it's a webapp you can drive it pretty much entirely by keyboard. It has the feel of an old usenet newsreader like nn, in a way.

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

#178

Post by u801e »

plorkyeran wrote: post #155
u801e wrote: post #115

Earlier quoted context omitted.

Github PRs (at least on the enterprise version) still have the problem of collapsing comments where the associated line of code changed in some way that had nothing to do with the comment. They also require a lot of scrolling if the overall diff is rather long. And, they still don't provide a way to comment on commit messages themselves.

Collapsing comments when the code changes is the correct thing to do 90% of the time in my experience, and for that other 10% you can manually mark is as unresolved. It's the correct default IMO.

> Collapsing comments when the code changes is the correct thing to do 90% of the time in my experience

Why not just leave them uncollapsed and allow one to mark them as resolved when the change is actually resolved. The other problem is that it's difficult to see what actually changed when a line is marked out of date without having to scan through the entire updated diff and then jump back and forth between the diff and conversation view.

Collapsing them by default makes it difficult to find the comment by scanning. If they were uncollapsed until I marked them as resolved, then I could at least use the find feature in the browser and search for my username to find my comments.

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

#179

Post by jeffbee »

rockwotj wrote: post #152
jeffbee wrote: post #129

Earlier quoted context omitted.

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.

Hasn't pcon been deprecated for a year and a half now? :P More pixels != to more information. The visuals and varieties in ways to present data in grafana always seemed more intuitive for me, being able to lay stuff out in different ways was great. I worked on a G-on-G project at Google and used both grafana and viceroy. I never had an issue with grafana on mobile, but I was never was able to see viceroy on a mobile…

On viceroy if you unintentionally put 2000 lines on a graph, you get a visual mess. If you do that on grafana your tab will hang for ten minutes. Big difference.

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

#180

Post by u801e »

raverbashing wrote: post #119
u801e wrote: post #115

Earlier quoted context omitted.

Github PRs (at least on the enterprise version) still have the problem of collapsing comments where the associated line of code changed in some way that had nothing to do with the comment. They also require a lot of scrolling if the overall diff is rather long. And, they still don't provide a way to comment on commit messages themselves.

Agreed on the comment collapse, about comment on the commit message I'd say it's a commit on the main PR (since by the time the PR is done the commit msgs are pretty much not changeable, except for the last one)

> about comment on the commit message I'd say it's a commit on the main PR

Except that if the overall diff line I choose to comment on about the commit message changes in some way, then the comment is collapsed, which makes it difficult to keep track of what needs to change.

> since by the time the PR is done the commit msgs are pretty much not changeable, except for the last one

They can be changed via a git rebase.

Post reply on HN