Author of the post here. Thought it might be of interest to call out some observations about how the world has changed since I wrote this:
1. Code search is more mainstream. It used to be most of Sourcegraph's sales came from ex-Googlers missing code search, but nowadays, most of our new revenue originates from dev teams just struggling with the challenge of big codebases.
2. Investment in dev tools has only accelerated. A lot of pandemic beneficiaries (virtual events, tele-medicine, at-home exercise equipment, crypto) are now reversing, but dev tools growth continues to be strong.
3. Bazel adoption has grown. Were I writing the post today, I would have had a category for monorepo tooling that included companies like EngFlow and Turborepo.
4. Kubernetes is still dominant for container orchestration, but serverless and managed services seem to be gaining more adoption. Classic tension between customer focus and open standards—will be interesting to see how we trade off dev-ex vs proprietary platform dependency.
Since this post was first published, we've also made a lot of advances at Sourcegraph and are looking for people who want to play around with some new experimental search and code intel features. Come say hi in our Discord! https://discord.gg/SSCBGByJeu
For code review: At my previous company we used Phacility/Phabricator but unfortunately it's no longer maintained[1]. Both my previous and current companies have since switched to using Graphite[2], which has delivered a pretty compelling stacked PR and code review experience.
Oh my god, it finally happened! I've been waiting for someone to make something like this for ages. The best part is I can use this for my own work without forcing my team to. Thanks for sharing! So far, it seems pretty good.
Shameless plug but anyone interested in a code review tool on top of GitHub may also want to check out CodeApprove (https://codeapprove.com). It's got a lot of the things that people from FAANG companies, especially Xooglers, miss about the excellent internal code review tools those companies have.
Phabricator is no more actively maintained but its author (Evan) is still doing some improvements and recently applied a security fix. The latest release https://secure.phabricator.com/w/changelog/2022.15/
There is also plz.review which more closely mirrors gerrit (ui flow, keyboard driven, etc). Plus I found the cli more pleasing to use than graphites. But glad there are finally options in this space!
How does it compare to using Gerrit? It doesn't come with a custom cli wrapper around git, but the code review experience is getting fairly close to critique these days. Self hosting, GitHub wrappers, and paid hosts are all available so there is a lot of flexibility.
Sourcegraph is one piece of the puzzle but there is still a long way to go to bring google-quality dev experience to the universe that exists outside of Big-G!
* Consistent build structure
* Rigorous code reviews
* Ginormous company-wide shared filesystem holding all code
* Point-click-drag report building
* Big-query
I'm sure I'm missing additional awesome internal aspects of being a developer at Google, and some parts are also horrendously bad.
I don't think an enormous company-wide filesystem matters when you're not an enormous company and you're not committing to fixing downstream dependencies maintained by other teams (or, often, by nobody) when you break them. Go's approach to versioning and dependencies works better when you don't have or want a monorepo managed by a single organization. Let unmaintained code sit, using the dependencies it was using at the time, until someone decides to maintain it.
One obvious benefit of the internal tools at Google is that they're all integrated with each other. So any Googler can quickly:
1. Search another team's code
2. Quickly jump into a Cloud IDE to make a change
3. Build and test the code, because everyone uses one build system
4. Send that code off for review and have the review tool automatically select the right reviewers and run the right tests
For a simple change (let's say a typo fix) all of the above can happen in a single browser tab in under 5 minutes even if you've never been in that part of the code before.
----
While I'm here a shameless but relevant plug: if you're looking for a Google-like code review experience on GitHub check out https://codeapprove.com
Related: The new GitHub Code search in testing has already completely changed my workflow, not only allowing me to search code within my codebase but on the whole of GitHub which allows me to find documentation, examples, and other kinds of stuff you'd never find by using Google or any other search engine. It's also great because I know where the code comes from, what's the license, who made it, and in what context.
I really hate dependency on GitHub for workflows but Microsoft is nailing the dev tools people are looking for and I think taking a look at what happens inside of big tech dev tooling is always interesting to see what we can build in the wild to improve developers ergonomics.
> The Google diaspora has seeded so many other organizations with... But adapting to programming outside of Google can be tough, especially when you've come to rely on tools you no longer have at your disposal.
You also don’t have problems to solve like google’s. Use the tooling appropriate to the task.
I find this problem with non-programmer ex googlers as well. They are so used to having so much infrastructure and opaque/screwed up objectives they’ve been given to meet that they often struggle in a startup environment (where the goals are merely “let’s get this button to show up 100% of the time,”, “let’s store the data for our 10k customers”, or “let’s give our phone number to these key customers so if there’s a problem they can call us right away”, or “figure out the most important thing that’s keeping our sign ups from converting and fix it — this week”).
Well, Google is a large enterprise, and in my experience most people that primarily worked at enterprises have problems adapting to working for startups, for the exact reasons you describe. I don’t think that’s unique to Google at all.
I wonder if other large companies also have great development experiences, and we just don't hear about those as often? For example, I would have expected Microsoft's internal tools to be at least at parity with what they sell.
I have heard certain large companies having very a fragmented development culture (every team does their own thing, no central repository), so maybe Google's tools being particularly refined is the result of most of the company sharing the same tools.
Amazon's internal tooling has everything described here. I can't say if it's better or worse than Google, but every team uses the same internal tooling for building and testing, code reviews, deployment, issue tracking etc. All code is also searchable in one place. The tooling is generally quite good too IMO.
Microsoft has/had a mono-repo based on the Git Virtual Filesystem, but future efforts have apparently moved towards the use of Scalar: https://github.com/microsoft/scalar
Technically this should mean hiring people from Google is a bad idea because they won't be as productive without access to the tools that make them so capable at Google...
They will probably be just as productive as all the other employees but they will be sightly unhappy about how incredibly lacking the non-google tooling is because they know how productive someone could be.
Source: Googler but still writing lots of code outside of Google and constantly think to myself "why is this so needlessly hard? Why does nothing integrate well?"
Ironically, some of the steps that Bazel takes to make builds hermetic make it more difficult to integrate with to pull the information we need out of the build for precise code navigation. But we're working on it :) If this is an area of interest to you, pop into our community Discord and say hello!
Bazel often comes up as an awesome aspect of Google's tooling but as far as I can see it's open source and hasn't really caught on elsewhere. Is there something I'm missing about why?
Relatedly, I was reading software engineering at google and came across the chapter about being able to find things; they have a URL shortener internally that works a little like AOL keywords from back in the day it sounded like. With human readable URLs so things like the employee handbook could easily be found at “go/handbook” or if you were looking for information on blaze then “go/blaze” would link to the docs.
So, I was trying to find a URL shortnener which allowed for pretty links similar to what the internal “go/“ site supports.
I couldn’t find anything, and it seemed simple enough so I made it:
The reason URL shorteners have mostly gone away, AFAICT, outside of ones that a company provides for its own links only, is that they got used a lot for spam and malware campaigns.
I miss the functionality a lot for a number of not malicious use cases, but I don't see a way to avoid that problem at the moment.
What does one have that the other doesn't? It doesn't make sense to me why there would be any real difference because of the cross pollination of employees
I think Google's tooling works best primarily because it's uniform, not because it's the best for all use cases. Yes, they are efficient but that efficiency is worth it at Google scale and probably not required for everyone.
Blaze is cool, but do you want to do it for every small project? It's actually a bit annoying for small projects, the verbosity of it. Granted that it helps optimise a lot of downstream workflows and enables pretty good tooling, but you wouldn't need those in startups not operating at that scale.
Startups need speed over accuracy. Google needs accuracy over speed.
Protobuf was really nice to do in critique, the new vs code version of critique they were rolling out also was a pretty solid Golang environment for the brief bit I did there.
But yeah, for the day to day java I was writing IntelliJ was way better.
[+] [-] jsnell|3 years ago|reply
Original discussion: https://news.ycombinator.com/item?id=25217291
[+] [-] beyang|3 years ago|reply
1. Code search is more mainstream. It used to be most of Sourcegraph's sales came from ex-Googlers missing code search, but nowadays, most of our new revenue originates from dev teams just struggling with the challenge of big codebases.
2. Investment in dev tools has only accelerated. A lot of pandemic beneficiaries (virtual events, tele-medicine, at-home exercise equipment, crypto) are now reversing, but dev tools growth continues to be strong.
3. Bazel adoption has grown. Were I writing the post today, I would have had a category for monorepo tooling that included companies like EngFlow and Turborepo.
4. Kubernetes is still dominant for container orchestration, but serverless and managed services seem to be gaining more adoption. Classic tension between customer focus and open standards—will be interesting to see how we trade off dev-ex vs proprietary platform dependency.
Since this post was first published, we've also made a lot of advances at Sourcegraph and are looking for people who want to play around with some new experimental search and code intel features. Come say hi in our Discord! https://discord.gg/SSCBGByJeu
[+] [-] sthupukari|3 years ago|reply
[1] https://admin.phacility.com/phame/post/view/11/phacility_is_...
[2] https://graphite.dev/
[+] [-] n42|3 years ago|reply
[+] [-] mdaniel|3 years ago|reply
> Join the waitlist
:-(
Since you seem to be in the beta, you may want to let them know their Homebrew tap is pointing to the wrong GH org: https://github.com/withgraphite/homebrew-tap/blob/master/For...
[+] [-] codeapprove|3 years ago|reply
Shameless plug but anyone interested in a code review tool on top of GitHub may also want to check out CodeApprove (https://codeapprove.com). It's got a lot of the things that people from FAANG companies, especially Xooglers, miss about the excellent internal code review tools those companies have.
[+] [-] hashar|3 years ago|reply
There is also a (blessed) community fork at https://we.phorge.it/
[+] [-] keegancsmith|3 years ago|reply
[+] [-] surajrmal|3 years ago|reply
[+] [-] mikevm|3 years ago|reply
[+] [-] metadat|3 years ago|reply
* Consistent build structure
* Rigorous code reviews
* Ginormous company-wide shared filesystem holding all code
* Point-click-drag report building
* Big-query
I'm sure I'm missing additional awesome internal aspects of being a developer at Google, and some parts are also horrendously bad.
[+] [-] dilyevsky|3 years ago|reply
* Automated presubmit/bisect queues
* Well built code review ui and not like github
On this topic, most companies will give up on “rigorous code reviews”.
[+] [-] skybrian|3 years ago|reply
[+] [-] codeapprove|3 years ago|reply
1. Search another team's code
2. Quickly jump into a Cloud IDE to make a change
3. Build and test the code, because everyone uses one build system
4. Send that code off for review and have the review tool automatically select the right reviewers and run the right tests
For a simple change (let's say a typo fix) all of the above can happen in a single browser tab in under 5 minutes even if you've never been in that part of the code before.
----
While I'm here a shameless but relevant plug: if you're looking for a Google-like code review experience on GitHub check out https://codeapprove.com
[+] [-] mayank|3 years ago|reply
- BigQuery is available on GCP
- Bazel is an open source Blaze
- google source formatting (for java at least) is open source
There are probably more…
[+] [-] doodlesdev|3 years ago|reply
I really hate dependency on GitHub for workflows but Microsoft is nailing the dev tools people are looking for and I think taking a look at what happens inside of big tech dev tooling is always interesting to see what we can build in the wild to improve developers ergonomics.
[+] [-] ffhhj|3 years ago|reply
https://github.com/sindresorhus/awesome/search?q=markdown
[+] [-] gumby|3 years ago|reply
You also don’t have problems to solve like google’s. Use the tooling appropriate to the task.
I find this problem with non-programmer ex googlers as well. They are so used to having so much infrastructure and opaque/screwed up objectives they’ve been given to meet that they often struggle in a startup environment (where the goals are merely “let’s get this button to show up 100% of the time,”, “let’s store the data for our 10k customers”, or “let’s give our phone number to these key customers so if there’s a problem they can call us right away”, or “figure out the most important thing that’s keeping our sign ups from converting and fix it — this week”).
[+] [-] stingraycharles|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] omoikane|3 years ago|reply
I have heard certain large companies having very a fragmented development culture (every team does their own thing, no central repository), so maybe Google's tools being particularly refined is the result of most of the company sharing the same tools.
[+] [-] mmiyer|3 years ago|reply
[+] [-] jiggawatts|3 years ago|reply
[+] [-] onion2k|3 years ago|reply
[+] [-] exitheone|3 years ago|reply
Source: Googler but still writing lots of code outside of Google and constantly think to myself "why is this so needlessly hard? Why does nothing integrate well?"
[+] [-] minighost|3 years ago|reply
[+] [-] beyang|3 years ago|reply
[+] [-] technion|3 years ago|reply
[+] [-] dijit|3 years ago|reply
So, I was trying to find a URL shortnener which allowed for pretty links similar to what the internal “go/“ site supports.
I couldn’t find anything, and it seemed simple enough so I made it:
https://github.com/dijit/redirector-rs
[+] [-] rincebrain|3 years ago|reply
I miss the functionality a lot for a number of not malicious use cases, but I don't see a way to avoid that problem at the moment.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] zeroonetwothree|3 years ago|reply
I think arguably Facebook/Meta has them beat.
[+] [-] googlryas|3 years ago|reply
[+] [-] sawyna|3 years ago|reply
Blaze is cool, but do you want to do it for every small project? It's actually a bit annoying for small projects, the verbosity of it. Granted that it helps optimise a lot of downstream workflows and enables pretty good tooling, but you wouldn't need those in startups not operating at that scale.
Startups need speed over accuracy. Google needs accuracy over speed.
Source: Acquired from startup to Google.
[+] [-] mandeepj|3 years ago|reply
Related, but from distant past: https://news.ycombinator.com/item?id=15722849
@Dang: Can we add a feature to auto link related threads in an expand\collapse section?
[+] [-] dinobones|3 years ago|reply
[+] [-] schreiaj|3 years ago|reply
But yeah, for the day to day java I was writing IntelliJ was way better.
[+] [-] 29athrowaway|3 years ago|reply
https://source.chromium.org/chromium
https://chromium-review.googlesource.com
[+] [-] tomthumb|3 years ago|reply
[+] [-] aaomidi|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]