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:<p>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.<p>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.<p>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.<p>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.<p>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! <a href="https://discord.gg/SSCBGByJeu" rel="nofollow">https://discord.gg/SSCBGByJeu</a>
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.<p>[1] <a href="https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/" rel="nofollow">https://admin.phacility.com/phame/post/view/11/phacility_is_...</a><p>[2] <a href="https://graphite.dev/" rel="nofollow">https://graphite.dev/</a>
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!<p>* Consistent build structure<p>* Rigorous code reviews<p>* Ginormous company-wide shared filesystem holding all code<p>* Point-click-drag report building<p>* Big-query<p>I'm sure I'm missing additional awesome internal aspects of being a developer at Google, and some parts are also horrendously bad.
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.<p>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.<p>You also don’t have problems to solve like google’s. Use the tooling appropriate to the task.<p>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”).
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.<p>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.
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...
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.<p>So, I was trying to find a URL shortnener which allowed for pretty links similar to what the internal “go/“ site supports.<p>I couldn’t find anything, and it seemed simple enough so I made it:<p><a href="https://github.com/dijit/redirector-rs" rel="nofollow">https://github.com/dijit/redirector-rs</a>
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.<p>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.<p>Startups need speed over accuracy. Google needs accuracy over speed.<p>Source: Acquired from startup to Google.
Another Code Review tool discussion from 25 days ago: Show HN: Crocodile - Better code review for GitHub (<a href="https://news.ycombinator.com/item?id=31841215" rel="nofollow">https://news.ycombinator.com/item?id=31841215</a>)<p>Related, but from distant past: <a href="https://news.ycombinator.com/item?id=15722849" rel="nofollow">https://news.ycombinator.com/item?id=15722849</a><p>@Dang: Can we add a feature to auto link related threads in an expand\collapse section?
If you want to have a taste of what those tools look like (kind of)<p><a href="https://source.chromium.org/chromium" rel="nofollow">https://source.chromium.org/chromium</a><p><a href="https://chromium-review.googlesource.com" rel="nofollow">https://chromium-review.googlesource.com</a>
I’ve hear a lot about the amazing internal tools at Google but why on earth is GCP such a mess outside Firebase? You’d think they would lead in developer experience from the way people talk about their internal tools but it’s just as bad as AWS: opaque, not enough examples and hard to figure out what services actually do