9 ms·
An ex-Googler's guide to dev tools (2020)
- toasted-subs 3y agoThat'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.
- AlbertCory 3y agoA 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.
- Groxx 3y agotbh 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.
- IshKebab 3y agoWhat 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).
- sgift 3y agoI 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!")
- simoncion 3y ago> I think that's quite an uncharitable interpretation of what's happening - Google doesn't really have bad intentions here imho... OP didn't talk at all about intentions. OP talked about results. > ...but with every tool you suffer from a conflict of goals: Sure. But it seems to me that OP notices that Google's really, really bad at choosing the "Make it so that people who aren't working in a megacorp who can afford teams of dedicated tool wranglers can easily use the tool and interoperate with others who use the tool." option when presented with it. And like, why would they ever choose that? They have zero need to, because they are a megacorp who can (and do) hire teams of dedicated tool wranglers.
- Mesopropithecus 3y agoSome 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.
- whatever1 3y agoGoogle 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.
- antupis 3y agoIt is the speed of iteration so testing, ci/cd, and monitoring are necessary after the MVP.
- sesm 3y agoIf you really care about speed of iteration, connect REPL to a running process and develop with it. Enterprise development practices are not about speed
- underdeserver 3y agoAt Google they absolutely are about speed - they're trying to help you go as fast as possible without breaking users.
- bootsmann 3y agoWould you say that Google has a reputation for shipping things quickly?
- underdeserver 3y agoI wouldn't. But I left Google early this year to work at a startup. I can tell you that the confidence I have with Google's tooling, testing infra, presubmits etc. are miles ahead of the confidence I have with our current pre-commits. But at Google we had millions of daily-actives and at the startup we have dozens, so if something breaks it's not too bad.
- Jensson 3y agoDo any other company start as many new things as Google? Google builds things extremely quickly for being that large. Then they shut them down just as quickly, which is another matter, but it is hard to argue that they are slow at building products.
- loosescrews 3y agoThis 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.
- dalf 3y agoPost from 2020: https://news.ycombinator.com/item?id=25217291 https://news.ycombinator.com/item?id=25217291 Post from 2022: https://news.ycombinator.com/item?id=32134038 https://news.ycombinator.com/item?id=32134038
- dang 3y agoThanks! Macroexpanded: An ex-Googler's guide to dev tools (2020) - https://news.ycombinator.com/item?id=32134038 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 https://news.ycombinator.com/item?id=25217291 - Nov 2020 (211 comments)
- beyang 3y agoAuthor 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 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!
- burgerquizz 3y ago> Google has internal AI dev tools now that generate more code than humans wondering how good it is? any googler using it can compare it to copilot?
- exitheone 3y agoIt's absolutely fantastic. I feel disabled coding without it in my spare time. Imagine a pair programming session with someone that can read your mind and knows the entire codebase. I don't know how much I'm allowed to talk about so I'll leave it at that. I don't have access to copilot so I can't compare but I'd wager it works a lot better for Google internally because the training data is customized to Google.
- kidintech 3y agoI'm at Google and am not entirely sure what you are referring to, but I'd love to try it. Could you provide an internal codename I could search for? Or is it integrated somewhere in Cider (the name is public knowledge so I'm not leaking anything by using this) that you could guide me to (i.e. X dropdown -> 3rd option) while preserving ambiguity?
- 3y ago
- codeapprove 3y agoShameless but relevant plug: if you’re a Xoogler and you miss Critique check out CodeApprove (https://codeapprove.com https://codeapprove.com). CodeApprove was built to make GitHub PRs a lot more appealing to those who miss the Critique workflow (among others audiences).
- oneepic 3y agoAlmost 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 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 3y agoGerrit?
- erhaetherth 3y agoWhat about Mendel and Streamz? I don't see those in https://github.com/jhuangtw/xg2xg https://github.com/jhuangtw/xg2xg
- hyperman1 3y agoI 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
- goodpoint 3y agoSpot on.
- tacker2000 3y agoI also think Zabbix is far superior and also mich easier to set up and maintain. The only thing it cant do is handle large amount of logs
- alentred 3y agoI 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.
- sevagh 3y agoPrometheus/Grafana doesn't have batteries included. Once you set up exporters and alerts and graphs, then you get something useful.
- DeathArrow 3y agoThis guy asserts that Google has the best code development process in the world but I don't think it is true.
- jatins 3y agoWhich 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.
- oneepic 3y agoI'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....
- jatins 3y ago> I'd be interested to hear these horror stories about Msft I believe it's called Ohome and is an ancient tool still used in Windows/office org
- saalweachter 3y agoThe horror story I used to hear was from the pre-cloud era-- when you set up a new computer to build, you'd need to wait a day while the initial pull & build finished before you could really do anything.
- coredog64 3y agoThat’s Twitter: I had to leave my Mac overnight to pull down the monorepo contents before I could do anything.
- wombat-man 3y agoNot 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.
- yeukhon 3y agoWhen 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.
- nwsm 3y ago> VS Code almost daily at work for writing Go 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.
- rvz 3y agoThese constant comparisons or obsessions around what ex-Googlers use or do at Google needs to stop. You are not Google and neither is your startup.
- meiraleal 3y agothat'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.
- bananapub 3y agohow on earth did your day lead you to deciding to slander en masse 10 000 people who had some bad luck, who you know nothing at all about including their skills?
- meiraleal 3y agoHow does not thinking Google engineering (and then their engineers) are special become slandering? You guys really take "not being special" as an insult? Too bad for those 10 000 ppl.
- meiraleal 3y agoAre those dev tools helpful at building fast/discontinue faster?
- siva7 3y ago> 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.
- brlewis 3y agoIn other words, don't stop reading this article until you get at least through the section with the heading "first month: ...".
- deleted 3y ago[deleted]
- next_xibalba 3y agoIs 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.
- UncleMeat 3y agoGoogle'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.
- alentred 3y agoAny organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway
- next_xibalba 3y agoBut the technical and developer layer does not operate independent of the leadership, planning, and prioritization layers, right? They don't strike me as separable.
- knallfrosch 3y agoNever understood the emulating part. 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.
- fingerlocks 3y agoNobody at Microsoft claims they have the best tooling. Culture, for sure. But tooling is a sad joke. Hell, we can’t even paste a git diff into a Teams chat because the crappy RTF box mangles the output. And Microsoft literally owns GitHub. But we go home early, the stock is up, everyone is Mormon-level nice to each other. Hard to complain.
- meiraleal 3y agoBased 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.
- hwc 3y ago> "Read code ..... Your editor" 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 3y agoHow does semantic information work than (showing inferred types and such stuff)? How does code navigation work in such a setup?