Author of the post here—as another commenter mentioned, this is indeed a bit dated now, someone should probably write an updated post!
There's been a ton of evolution in dev tools in the past 3 years with some old workhorses retiring (RIP Phabricator) and new ones (like Graphite, which is awesome) emerging... and of course AI-AI-AI. LLMs have created some great new tools for the developer inner loop—that's probably the most glaring omission here. If I were to include that category today, it would mention tools like ChatGPT, GH Copilot, Cursor, and our own Sourcegraph Cody (https://cody.dev). I'm told that Google has internal AI dev tools now that generate more code than humans.
Excited to see what changes the next 3 years bring—the pace of innovation is only accelerating!
> I'm told that Google has internal AI dev tools now that generate more code than humans.
Given that code is not an asset but a heavy liability the elephant in the room is the question: Who is going to maintain all that huge piles of generated code?
Wake me up when there's an AI that can safely delete code… That would be a really disrupting achievement!
Besides the tools mentioned, what are some other AI tools that can be used to accelerate coding for established codebases? I have some money to try out new tools, but am wondering if there are that are less "black boxy" and would work with a company's private instance of Azure ChatGPT?
> One of your competitive advantages after leaving Google will be to apply these experiences to bring great new dev tools into your new organization to boost your own productivity and the productivity of your teammates
Please don't do this blindly. Your new organisation likely won't be similar to Google. If a xoogler would onboard with this attitude that any other tooling and process must be inferior, they wouldn't last long.
tbh the vibe I get is that Google seems to be great at building tools that teach people nothing about how to collaborate with anything outside their current company... so they're both hamstrung when they leave, and then they continue to build new tools that don't work together with anything else because they don't understand the community at all.
Bazel is a perfect example. Bazel projects are horrifically (arguably impossibly) hard to use to collaborate with other Bazel projects outside of your control, and its abilities encourage you to do (useful!) things that don't hold up outside its little isolated world. It's a super great system in a lot of ways, but it is anathema to open source development.
At times it feels like it's probably extremely destructive in aggregate, particularly as more and more companies blindly mimic it, and that worries me.
I think that's quite an uncharitable interpretation of what's happening - Google doesn't really have bad intentions here imho, but with every tool you suffer from a conflict of goals: Should it be as good as possible for the current environment or should it work "well enough" in as many environments as possible?
That's also the conflict between external libs/frameworks vs. NIH. Yeah, sure. Sometimes NIH is a matter of arrogance, but it's also a fact that something you build yourself can work far better in your environment and with your constraints than something you took in and then banged on until you have a reasonable fit.
The corollary is of course that open-sourcing such a thing is often rather useless at first, especially if the company that does it (and Google imho is one of the worst offenders here) doesn't really put in the work to make it useful for a wider audience. Which is partially a function of the companies' devs being more used to working with very fitting tools. With those tools which are useful enough you often see a period of adjustment then. A few releases which don't bring much in the direction of new features, but "only" things you need to make it work in more environments.
To your last sentence: I think that in general it's a bad idea to blindly use or emulate what some (especially big) company did. Just because it works well in their use cases, doesn't mean it will work well for others. It's cargo cult programming, which is unfortunately rather popular in our hype driven industry ("New fancy library by x, we have to use this too or we will be done for in six month!")
What do you think about Bazel makes it hard to collaborate with other projects (any more than other build systems)?
I mean, very few people use Bazel so you're likely to have to implement Bazel support for any projects you use, but that's no different to other build systems (e.g. until it became a de facto standard I frequently had to implement CMake support for third party C++ libraries I used).
Some of the in-house stuff was built before alternatives were available or scalable, and now there'd be a high cost and friction to trying to change it. Happens in many big companies that have been around for a few decades, it's not because of bad intentions.
When I left Facebook, I missed all the internal tools the company developed. I currently work on dev tooling at my company (though leaving soon). So I have some thoughts as well.
Having been at facebook prior led me to believe that we can definitely 2x productivity if tools made by these large organizations are open sourced and maintained.
I will probably write my thoughts like the author (if anyone cares), but the bottom line is I consistently find many existing open source projects missing critically useful features and/or don’t focus as much on real developer productivity (I admit that can be very subjective).
Eg Bazle is fantastic when it works (all deps are accounted for) but it is not unusual to find github comments that tell users to add patches because the maintainers (core and contrib) haven’t fixed the problems (some over 2-3 years old) or because they hardcode a version of Go….
Another example is VS Code. facebook (now meta) offered everyone to its heavily extended VS Code. While I didn’t use that as much since I am a terminal and a Vim developer, now that I use VS Code almost daily at work for writing Go, I really do appreciate the customization facebook engineers did - because too often someone (both engineers and non-engineers) would come to us and complain about some issues with the built-in git UI, trying to figure out how to construct a working workspace settings, switching between git and arcanist. The facebook’s version had all this figured out really nicely. With minimal training someone could submit code very quickly without ever touching the terminal.
I can go on and talk about how awesome ods is compared to prometheus and its query UI. Finally, I miss Scuba too (and Honeycomb founders were involved building Scuba).
Sure, facebook tools don’t always work and there are issues and bugs like any software, but overall I felt more productive.
Maybe it is because I did’t maintain them - now I do as a full time engineer at work, I feel the pains. But then again, if google and facebook maintain these as open source would be really nice.
How would you rate VS Code for Go? I use the official Go extension but am not impressed. My main gripe is that I often have to manually add a local import that should have been found and suggested when I typed the name of a variable or function exported from an adjacent package. I much prefer Goland, but use VS Code because it is the only editor my company's internal AI code assistant supports.
Is Google still an org whose methods are to be emulated? Maybe small parts of it? In general the vibe I get from Google is a scerlotic company completely overrun by bureaucracy. And it’s been that way for a decade.
Google's problems are in leadership, planning, and prioritization. They aren't in their developer tools and technical foundation. I think there is some connection between the monorepo and aggressive deprecations, but that's not the root cause.
Google didn't copy Microsoft, and Netflix didn't copy Amazon, and Apple and Microsoft and Yahoo do their own thing also. Every big tech company claims its culture and tooling is the best and yet they mysteriously share none of it.
And in any case, your company isn't Google. And it doesn't succeed or fail based on using this or that tooling.
Identify your own pain points and solve those instead. Maybe you need a code search tool and buy it from the author, maybe you don't.
Google dev tools serve Google scale needs. Not only your 2 people startup has no need for these, but they introduce friction that might kill your company.
Not just google scale needs, but google-specific needs, regardless of scale. Having your entire company in a monorepo is something that Google went all in on and makes work, but it’s arguably not really necessary, even at Google scale.
I wonder why Prometheus/Grafana are so popular in the monitoring stack. They seem to promote a culture of 'Hang a screen over there and stare at it'. I always have to do a lot of work finetuning them, and some important metric will be missing.
My experience with zabbix was just the opposite, BTW. Ugly, but practical. The defaults let you quickly set up monitoring, and then nagstamon or other alerting allows you to forget it exists until bad things happen. Then you browse trough the templated graphs where a spartan but interesting indicator of what happens will exist somewhere
I don't think they promote the "Hang a screen over there and stare at it" approach. In our company we use both, but Promteheus has an Alertmanager and I only ever open the UI for debug when the alert is raised.
In fact, I truly hope no one has a screen with Grafana in their office. I agree: if anyone has those - you are probably not doing it right.
This is from 2020 and it is out of date. Phacility is no longer offering hosted Phabricator and Phabricator itself is no longer actively maintained. Also, graphite.dev is a solid option in the code review space. It provides better GitHub integrated code review like reviewable.io, but also provides a CLI with a more Mercurial like workflow and replicates workflows available inside of Google and Facebook.
Which BigTech (10k+ employees) has the worst internal dev tooling? I have heard horror stories about some build systems at Microsoft but curious how others fare.
Not sure this counts, but adobe had no org wide tooling afaik. Each team could pick its CI, code review, repo , issue tracker etc. I was on a smaller product but it was chaos. I especially felt it when we had some CI issues and no expertise to help. It was a lot of time out the window trying to get the basics working.
I'd be interested to hear these horror stories about Msft (are they from the modern era? 2010s? 2020s?). On my old team there, I really liked our build system (Azure Devops/Azure Repos, basically all-in-one tool from issue tracking to Git to CI/CD deploying to Azure....
That's not true, I was able to get working environments with all of the tools I used at Google within a month.
That being said most of them were overkill for startup or small teams. Found it kind of funny even though the tools are "open source" all the name's are different the documentation is non-existent.
Some of the open source stuff is just better anyway.
A good many of the less critical internal tools were have-a-nice-day tested. Meaning, if you looked at them cross-eyed they fell over. Teams put them out, gave a tech talk, got promoted, and then lost interest and moved on.
Note I said "less critical." Some of the important ones were really excellent, e.g. Dremel.
Almost 1.5 years in, here is my opinion on Critique:
Github < Critique < Azure DevOps (or actually, I think it's called Azure Repos)*
*might have changed because I was at MSFT until mid 2021, but development and review used to look sort of like this: https://www.youtube.com/watch?v=dGCid5W-HK0. I just felt the UX was really clean and clear, plus it immediately tied into the walled garden of tools like private package repos, CI, and Azure deployments.
Based on the comments in this thread, it seems that Google is using AI to replace software engineers. That explain the continuous layoffs. Let's see for how long they can continue moving from a engineers company to a managers company.
that's how they get the good jobs after being laid off. Nowadays google engineers have nothing special besides being easy to brainwash and fit a big machine.
[+] [-] beyang|2 years ago|reply
There's been a ton of evolution in dev tools in the past 3 years with some old workhorses retiring (RIP Phabricator) and new ones (like Graphite, which is awesome) emerging... and of course AI-AI-AI. LLMs have created some great new tools for the developer inner loop—that's probably the most glaring omission here. If I were to include that category today, it would mention tools like ChatGPT, GH Copilot, Cursor, and our own Sourcegraph Cody (https://cody.dev). I'm told that Google has internal AI dev tools now that generate more code than humans.
Excited to see what changes the next 3 years bring—the pace of innovation is only accelerating!
[+] [-] still_grokking|2 years ago|reply
Given that code is not an asset but a heavy liability the elephant in the room is the question: Who is going to maintain all that huge piles of generated code?
Wake me up when there's an AI that can safely delete code… That would be a really disrupting achievement!
[+] [-] burgerquizz|2 years ago|reply
wondering how good it is? any googler using it can compare it to copilot?
[+] [-] da39a3ee|2 years ago|reply
[+] [-] bulldog13|2 years ago|reply
[+] [-] ksjskskskkk|2 years ago|reply
[deleted]
[+] [-] siva7|2 years ago|reply
Please don't do this blindly. Your new organisation likely won't be similar to Google. If a xoogler would onboard with this attitude that any other tooling and process must be inferior, they wouldn't last long.
[+] [-] brlewis|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Groxx|2 years ago|reply
Bazel is a perfect example. Bazel projects are horrifically (arguably impossibly) hard to use to collaborate with other Bazel projects outside of your control, and its abilities encourage you to do (useful!) things that don't hold up outside its little isolated world. It's a super great system in a lot of ways, but it is anathema to open source development.
At times it feels like it's probably extremely destructive in aggregate, particularly as more and more companies blindly mimic it, and that worries me.
[+] [-] sgift|2 years ago|reply
That's also the conflict between external libs/frameworks vs. NIH. Yeah, sure. Sometimes NIH is a matter of arrogance, but it's also a fact that something you build yourself can work far better in your environment and with your constraints than something you took in and then banged on until you have a reasonable fit.
The corollary is of course that open-sourcing such a thing is often rather useless at first, especially if the company that does it (and Google imho is one of the worst offenders here) doesn't really put in the work to make it useful for a wider audience. Which is partially a function of the companies' devs being more used to working with very fitting tools. With those tools which are useful enough you often see a period of adjustment then. A few releases which don't bring much in the direction of new features, but "only" things you need to make it work in more environments.
To your last sentence: I think that in general it's a bad idea to blindly use or emulate what some (especially big) company did. Just because it works well in their use cases, doesn't mean it will work well for others. It's cargo cult programming, which is unfortunately rather popular in our hype driven industry ("New fancy library by x, we have to use this too or we will be done for in six month!")
[+] [-] IshKebab|2 years ago|reply
I mean, very few people use Bazel so you're likely to have to implement Bazel support for any projects you use, but that's no different to other build systems (e.g. until it became a de facto standard I frequently had to implement CMake support for third party C++ libraries I used).
[+] [-] Mesopropithecus|2 years ago|reply
[+] [-] yeukhon|2 years ago|reply
Having been at facebook prior led me to believe that we can definitely 2x productivity if tools made by these large organizations are open sourced and maintained.
I will probably write my thoughts like the author (if anyone cares), but the bottom line is I consistently find many existing open source projects missing critically useful features and/or don’t focus as much on real developer productivity (I admit that can be very subjective).
Eg Bazle is fantastic when it works (all deps are accounted for) but it is not unusual to find github comments that tell users to add patches because the maintainers (core and contrib) haven’t fixed the problems (some over 2-3 years old) or because they hardcode a version of Go….
Another example is VS Code. facebook (now meta) offered everyone to its heavily extended VS Code. While I didn’t use that as much since I am a terminal and a Vim developer, now that I use VS Code almost daily at work for writing Go, I really do appreciate the customization facebook engineers did - because too often someone (both engineers and non-engineers) would come to us and complain about some issues with the built-in git UI, trying to figure out how to construct a working workspace settings, switching between git and arcanist. The facebook’s version had all this figured out really nicely. With minimal training someone could submit code very quickly without ever touching the terminal.
I can go on and talk about how awesome ods is compared to prometheus and its query UI. Finally, I miss Scuba too (and Honeycomb founders were involved building Scuba).
Sure, facebook tools don’t always work and there are issues and bugs like any software, but overall I felt more productive.
Maybe it is because I did’t maintain them - now I do as a full time engineer at work, I feel the pains. But then again, if google and facebook maintain these as open source would be really nice.
[+] [-] nwsm|2 years ago|reply
How would you rate VS Code for Go? I use the official Go extension but am not impressed. My main gripe is that I often have to manually add a local import that should have been found and suggested when I typed the name of a variable or function exported from an adjacent package. I much prefer Goland, but use VS Code because it is the only editor my company's internal AI code assistant supports.
[+] [-] next_xibalba|2 years ago|reply
[+] [-] UncleMeat|2 years ago|reply
[+] [-] knallfrosch|2 years ago|reply
Google didn't copy Microsoft, and Netflix didn't copy Amazon, and Apple and Microsoft and Yahoo do their own thing also. Every big tech company claims its culture and tooling is the best and yet they mysteriously share none of it.
And in any case, your company isn't Google. And it doesn't succeed or fail based on using this or that tooling.
Identify your own pain points and solve those instead. Maybe you need a code search tool and buy it from the author, maybe you don't.
[+] [-] whatever1|2 years ago|reply
[+] [-] appplication|2 years ago|reply
[+] [-] rjst01|2 years ago|reply
[+] [-] antupis|2 years ago|reply
[+] [-] goodpoint|2 years ago|reply
[+] [-] dalf|2 years ago|reply
Post from 2022: https://news.ycombinator.com/item?id=32134038
[+] [-] dang|2 years ago|reply
An ex-Googler's guide to dev tools (2020) - https://news.ycombinator.com/item?id=32134038 - July 2022 (139 comments)
An ex-Googler’s guide to dev tools - https://news.ycombinator.com/item?id=25217291 - Nov 2020 (211 comments)
[+] [-] hyperman1|2 years ago|reply
My experience with zabbix was just the opposite, BTW. Ugly, but practical. The defaults let you quickly set up monitoring, and then nagstamon or other alerting allows you to forget it exists until bad things happen. Then you browse trough the templated graphs where a spartan but interesting indicator of what happens will exist somewhere
[+] [-] alentred|2 years ago|reply
In fact, I truly hope no one has a screen with Grafana in their office. I agree: if anyone has those - you are probably not doing it right.
[+] [-] sevagh|2 years ago|reply
[+] [-] tacker2000|2 years ago|reply
The only thing it cant do is handle large amount of logs
[+] [-] goodpoint|2 years ago|reply
[+] [-] loosescrews|2 years ago|reply
[+] [-] asddubs|2 years ago|reply
[+] [-] jatins|2 years ago|reply
[+] [-] wombat-man|2 years ago|reply
[+] [-] oneepic|2 years ago|reply
[+] [-] toasted-subs|2 years ago|reply
That being said most of them were overkill for startup or small teams. Found it kind of funny even though the tools are "open source" all the name's are different the documentation is non-existent.
Some of the open source stuff is just better anyway.
[+] [-] AlbertCory|2 years ago|reply
Note I said "less critical." Some of the important ones were really excellent, e.g. Dremel.
[+] [-] codeapprove|2 years ago|reply
CodeApprove was built to make GitHub PRs a lot more appealing to those who miss the Critique workflow (among others audiences).
[+] [-] oneepic|2 years ago|reply
Github < Critique < Azure DevOps (or actually, I think it's called Azure Repos)*
*might have changed because I was at MSFT until mid 2021, but development and review used to look sort of like this: https://www.youtube.com/watch?v=dGCid5W-HK0. I just felt the UX was really clean and clear, plus it immediately tied into the walled garden of tools like private package repos, CI, and Azure deployments.
[+] [-] tucnak|2 years ago|reply
[+] [-] DeathArrow|2 years ago|reply
[+] [-] meiraleal|2 years ago|reply
[+] [-] hwc|2 years ago|reply
For reading code, I tend to use `highlight -O xterm256 "$1"|less -R` or `source-highlight -f esc -o STDOUT -i "$1"|less -R` in a shell function.
[+] [-] still_grokking|2 years ago|reply
How does code navigation work in such a setup?
[+] [-] erhaetherth|2 years ago|reply
[+] [-] rvz|2 years ago|reply
You are not Google and neither is your startup.
[+] [-] meiraleal|2 years ago|reply
[+] [-] meiraleal|2 years ago|reply