‹ BackHN Continuity

Thread

Changes at Google DeepMind: Demis Hassabis from CEO to Chair, Jeff Dean departs

820 points · 876 comments · colesantiago

  1. GodelNumbering · · focus · HN ↗
    So, in last several months, all the prominent names Google lost: Demis Hassabis (technically still with google but these things are usually presented with a spin), Jeff Dean, Sanjay Ghemawat, Oriol Vinyals, Quoc Le, Noam Shazeer, John Jumper, Jonas Adler, Alexander Pritzel, David Silver, Denny Zhou, Fernando Pereira, Alex Turner

    And all the prominent names Google gained: NULL

    Combined with no gemini frontier GA release in about 14 months. You have to have created an environment pretty hostile to innovation for this to happen

    1. frollogaston · · focus · HN ↗
      Part of me thinks Google's entire problem is crappy internal tooling, not really an anti-innovation environment. Just making a dev take 2x as long to get something done has a bigger effect than you'd think. With LLMs it's more like 10x now because even Gemini doesn't understand Google-internal tooling.
      1. r0b05 · · focus · HN ↗
        Maybe they are forced to use Google search.
        1. frollogaston · · focus · HN ↗
          No, they have an actually good internal search. And there are some good things like stubby, but again pretty annoying that Gemini doesn't understand stubby.
      2. solenoid0937 · · focus · HN ↗
        I have a friend at Google DeepMind who tells me that Google believes in AGI/superintelligence just as much as HN does, which is probably why no one with conviction wants to work there.
        1. frollogaston · · focus · HN ↗
          How much belief is that? I tend to skip the HN posts that are about AI.
        2. oblio · · focus · HN ↗
          I think HN believes in AGI. HN probably doesn't believe LLMs will lead to AGI.

          Also lots of tech people, HN included, are waking up to technology not only including penicillin (net positive for humanity) but also dynamite (best case: net neutral).

        3. Zigurd · · focus · HN ↗
          A few months ago I heard Demis Hassabis say something, albeit vague, I doubt he truly believed regarding AGI. That AGI is relatively near is the party line everywhere. That may contribute to creating toxic environments and lousy investment decisions. So here we go with the FOMO.
        4. aleph_minus_one · · focus · HN ↗
          > I have a friend at Google DeepMind who tells me that Google believes in AGI/superintelligence just as much as HN does, which is probably why no one with conviction wants to work there.

          With "believes in AGI/superintelligence just as much as HN does" do you mean that they are superbelievers or rather sceptical of AGI/superintelligence? I have seen both positions on HN.

        5. sheeshkebab · · focus · HN ↗
          What’s with fascination with agi/superintelligence? It seems people working on it never had kids and just want to compensate for that. It’s a really horrible thing to try to “solve”.
      3. VirusNewbie · · focus · HN ↗
        > because even Gemini doesn't understand Google-internal tooling.

        this is false, it's very good at internal tooling.

        1. frollogaston · · focus · HN ↗
          Only the GFG models know anything internal. Regular Gemini isn't trained on any of that. And GFG is a much older base model, so people use the regular one. If the tools seem to handle google3 code ok, it's only because of skills and not the model itself, and then you run into issues with skill bloat. Sometimes the A/B test would give me the bad model of the day that'd try to grep all of piper.

          Start in a blank directory and tell it to spin up a boq Scaffolding stubby server that responds with "hello world." Unless something has changed after I quit a few months ago, it won't know how to do that locally, let alone actually deploy it. Try the same outside Google with like a Flask server on AWS or GCP.

      4. Nimitz14 · · focus · HN ↗
        Uh isn’t google known to have the best tooling in the world
        1. frollogaston · · focus · HN ↗
          They earned that reputation in like 2005. Some people have been there so long (without doing side projects) that they don't know what non-Google tooling looks like in this decade or even previous.
      5. vkou · · focus · HN ↗
        The tooling is not the problem. If shit takes forever to launch, it's because there are many stakeholders that need to be satisfied (some for security, some for regulatory, some for the kinds of politics you get in a company that employs almost half a million people.)
        1. frollogaston · · focus · HN ↗
          But GDM isn't gated on launches. They were freely releasing things internally for dogfood. Problem is that stuff was just not as good as the competition.
      6. mhh__ · · focus · HN ↗
        If the tools are all in the same monorepo idk if that's actually true
        1. frollogaston · · focus · HN ↗
          What do you mean about them being in the monorepo?
      7. fooker · · focus · HN ↗
        Google has close to the best internal tooling in the industry for a decade or so.

        Then the Google engineers who joined Facebook missed it so much that they built a better replacement.

        1. frollogaston · · focus · HN ↗
          Replacement for what? Google has some good internal tools, mostly the older ones. They're lucky to be using React instead of Angular at Facebook though.
        2. mikert89 · · focus · HN ↗
          google had the best tooling a decade ago...
        3. swrrt · · focus · HN ↗
          Sounds like a big-company issue, large scale lead to large burden and complexity.
      8. summerlight · · focus · HN ↗
        It's not a tooling problem. It's more of a layer of policy problems. If you realize that you cannot run a simple experimental code even in non-production environment for weeks due to 10s of privacy, security, access, process and legal issues where you gotta collect a bunch of approvals, this is critical. And the problem gets worse because the tooling is too good when it enforces. There used to be some holes and circumvention which are all gone these days. This is probably why they said "the infra is good for services but not for research".
        1. frollogaston · · focus · HN ↗
          I don't even think it's good for services. It's not like you go through cumbersome reviews/tools and then things are safe. They have insane homemade config languages and obscure systems that 99% of SWEs don't really understand but won't say it out loud. That's how they dropped cns2, and the postmortem is never going to blame the tools.
          1. ragall · · focus · HN ↗
            You have no clue what you're talking about.
      9. Cidan · · focus · HN ↗
        Google's internal tooling is still, hands down, better than anything that exists for the scale they operate at, and it's not even close.

        Google's processes, however, is hands down the worst thing to exist for the scale they operate at, and it's not even close.

        1. bushbaba · · focus · HN ↗
          the processes are a result of repeated lawsuit
        2. coderatlarge · · focus · HN ↗
          except for most other companies in the world.
        3. arthurjj · · focus · HN ↗
          I think the internal web tooling was pretty good compared to anyone but AWS circa 2016 but by 2020 when I left it felt a bit antiquated. Similarly they didn't have linters rolled out until it was industry standard iirc.

          But BCL is still the worst language I've ever used.

          1. frollogaston · · focus · HN ↗
            I still don't understand why all that dynamic config stuff isn't just Python. Sure, static configs should be protos, but GCL is a whole nasty programming language. They came so close with Piccolo and Gmon but still made it not Python. Have heard some language purity rants involving determinism, but I don't buy it. And they keep inventing new stuff like Starlark. They need to stop.
            1. ragall · · focus · HN ↗
              > GCL is a whole nasty programming language. They came so close with Piccolo and Gmon but still made it not Python.

              The GCL designers made several mistakes in its design, but the worse was the lack of a versioning that would make language evolution easier, as well as interoperability between different versions. GCL2 solved some issues, mainly cleaning up the interpreter. Still, BCL is IMNSHO by far the best infra language there is.

          2. ragall · · focus · HN ↗
            > I think the internal web tooling was pretty good compared to anyone but AWS circa 2016 but by 2020 when I left it felt a bit antiquated.

            In 2015, the SRE org started project "Prod 2020", with the goal of unifying the SRE stacks and modernizing the web tools. It was quite successful.

            > But BCL is still the worst language I've ever used.

            I'm an SRE and I think it's quite likely the best infra language I've ever seen.

            1. arthurjj · · focus · HN ↗
              > I'm an SRE and I think it's quite likely the best infra language I've ever seen.

              I only worked with 4-5 SREs and they all grudgingly tolerated it. What did you like about it, compared to other infra languages you've used professionally?

      10. flymasterv · · focus · HN ↗
        Thank you!

        Google’s tooling was, hands down, the worst I have ever encountered. I did 10 years at GOOG, 3 at AMZN, 4 in research, and another 5 at companies you have heard of but wouldn’t be impressed by, and every day GOOG infuriated me.

        1. rixed · · focus · HN ↗
          You don't measure tooling quality with devs' enjoyment, though, but with what the tools make possible.

          Technical merit is not correlated to popularity, after all.

      11. vintermann · · focus · HN ↗
        Internal tooling? Didn't Jeff Dean write their internal tooling?
        1. frollogaston · · focus · HN ↗
          He wrote the good old parts
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.