from Hacker News

An ex-Googler's guide to dev tools (2020)

by intrepidsoldier on 11/29/23, 4:16 AM with 94 comments

  • by beyang on 11/29/23, 6:27 AM

    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!

  • by siva7 on 11/29/23, 1:05 PM

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

  • by Groxx on 11/29/23, 6:05 AM

    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.

  • by yeukhon on 11/29/23, 8:38 AM

    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.

  • by next_xibalba on 11/29/23, 1:17 PM

    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.

  • by whatever1 on 11/29/23, 6:10 AM

    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.

  • by dalf on 11/29/23, 6:11 AM

  • by hyperman1 on 11/29/23, 8:25 AM

    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

  • by loosescrews on 11/29/23, 6:10 AM

    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.

  • by jatins on 11/29/23, 8:33 AM

    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.

  • by toasted-subs on 11/29/23, 6:00 AM

    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.

  • by codeapprove on 11/29/23, 6:55 AM

    Shameless but relevant plug: if you’re a Xoogler and you miss Critique check out CodeApprove (https://codeapprove.com).

    CodeApprove was built to make GitHub PRs a lot more appealing to those who miss the Critique workflow (among others audiences).

  • by DeathArrow on 11/29/23, 8:25 AM

    This guy asserts that Google has the best code development process in the world but I don't think it is true.

  • by meiraleal on 11/29/23, 2:19 PM

    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.

  • by hwc on 11/29/23, 6:16 PM

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

  • by erhaetherth on 11/29/23, 6:59 AM

    What about Mendel and Streamz? I don't see those in https://github.com/jhuangtw/xg2xg

  • by rvz on 11/29/23, 10:01 AM

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

  • by meiraleal on 11/29/23, 10:31 AM

    Are those dev tools helpful at building fast/discontinue faster?