 We're getting bombarded with tree stuff now. I'll be on it. I want it. It's just like doing the picking the entire time. I'm back at camouflage. Blending into the background. Yeah, blending in with the tree stuff. Who are you and why? Who am I? I am Darren Fisher. I work on Chrome. Welcome. From engineering. So you were there right at the start of Chrome? Yes. Middle of 2006 we got started coding. Wait, 2006? 2006. Chrome launched in 2008, but we started in 2006. Oh, the launch. I was like, I heard we're talking about the 10-year anniversary. Like it's 12 years now. That's why I tell people like 10 years? It takes 12. It takes two years to build a browser. It took two years to build a browser. Now mind you, that's without the rendering engine. We just used WebKit. We were WebKit based, yeah. That already existed. And when I say we didn't have in the beginning a team that could go and build a rendering engine like that. I mean that's an undertaking, isn't it? How many people were at the start? Well, we were actually, you have to rewind the clock a little bit because we were a team at Google working on Firefox. And the whole idea was... It doesn't look like I didn't expect. Yeah, so for about a year and a half. I joined Google in the beginning of January 2005. Okay. We had a little small team bootstrapped out of Google security to invest in making web browsers work better. Google's business depends a lot on the web, obviously. And the idea of actually investing in Firefox seemed like a really great way to make the web work better. Yeah, okay. So quick question in between. You said you started in 2005. Do you remember your interview question? Yeah, totally. I interviewed with the Gmail team. Do you really want to know if they interviewed questions? Yeah. I'm curious. Oh my goodness. We're not going to try them. We want to keep our jobs. Okay, so some of these are banned questions now in the Google interviews. Right? Because they get asked so many darn times. But there was things like draw a line on a monochromatic bitmap. So imagine you have a monochrome bitmap. So ones and zeros. And draw a line on that. So it's getting you to do break shift operators. Oh. Yeah. I had another question which was given an array of integers, find the maximum values in that array or something like this. And so they just have you pretty much write a brute force algorithm for that. And then they ask if you can do it faster and you're like, wait, but I gave you, that was so simple. Why would they do it faster? Why would you make it harder? So if they asked me, can you do it faster, I think I would have deleted the code and then just type the same code again, but really gone for the typing. Especially because I knew it now. Yeah, that would have been a misinterpretation of the question. But thinking outside of the box, would I call it? Yeah. For some reason, when you said like a line on a monochromatic bitmap, I've got a very visual memory. So when you said like, there's a monochromatic bitmap, I imagine the sheet of paper stuck to the wall with a black and white picture on. And you said, you've got to draw a line on it. Give me the black marker. Can I get the job? That's why you're in DevRel. Yeah, absolutely. I've been here while products and stuff have launched and there's a period of sort of picking, trying to figure out the name of the thing we're launching. There's always code names. What other things could Chrome have been called? Oh, yeah. So the code base was originally called Goose. Wait, I did not see that coming. That was the internal repository originally called Goose. Yeah. Just because somebody came up with it, it was random. So when you ask engineers to name things, you get random names. So then we asked the team to come up with a good name for the project. And they came up with a whole bunch of other random names. And I think in general, the engineers didn't necessarily take the process very seriously. So a lot of names that were pretty silly. Well, because Chrome. Yes. Making the Chrome. I think it was our engineering manager who came up with the idea of Chrome. And he said, let's just call it Chrome. Forget all those names you guys came up with. Because I'm in the end. The Chrome in that day was just called the... Yeah. The Firefox called the rest of the browser, right? Chrome of an application is the UI around the container. Yeah, the window border. The window border. In fact, yeah, absolutely in Firefox, Chrome refers to that part of the browser. All the Zool parts of the UI. And I mentioned Zool if I need to explain that. Zool runner. I remember. Yes. But anyway, so in Chrome, in WebKit, even there's APIs that refer to informing the Chrome of the browser about state changes. And so we just called the browser Chrome. It was almost like a joke. That was a pun, yeah. Yeah, and then so we didn't actually expect that to be the name of the product. The joke's gone too far now. Here we are. At some point they're like, hmm, if we put Google in front of it, could that just be the product name? Let's see if we can get that past the... I would have loved to see that with those. Through the naming process. The idea of Chrome also kind of evolved into this emphasis on content, not Chrome. So, you know, this idea, this guiding principle of we're here to build a browser that's like, the users care about the content that they're engaging with, not about using the browser, right? And so if you think about it, we wanted to have this, that sort of informed a minimalistic approach to the browser UI. So you don't want to go back to the times in IE where you had like 18 different search bars. Yeah, exactly. Yeah, exactly. So like minimize the Chrome. It's called Chrome, but minimize the Chrome. So are we going to keep working on Chrome for like four years? I'm trying to figure out if I can just write this job to retirement or whether I need something. That's a good choice, good career choice. Yeah, the web's going to be around. Yeah, the web's been around for a long time. It's going to continue to be around for a long time. The fundamental concepts of the web, you know, an open platform where anybody can publish content and others can come along and bring that content to users through different form factors. It's actually remarkable, right? It is. And I think that adds an amazing staying power. And the stuff from the 90s still works. I mean, the canonical example at this point is Space Jam, which I still love to open up, apparently. The first ever website still works. Still works. That wasn't Space Jam. No, that wasn't it. Very close. It's interesting to see how the web evolves from a world with, you know, desktop computing to mobile computing. Yeah. And, you know, now with, yeah, watches, VR, AR, everything and so on and so forth as form factors change, that fundamental principles of an open way in which people can publish content and then others can figure out how to bring that content to users and new form factors is there. There's an opportunity created. It feels like one of the, like, a lot of different systems have promised that multi-platform, like, yeah, running everywhere thing, but it feels like the web's the first one that's really actually worked. Yeah, it's kind of there by default. Yeah. So, with Chrome being around for stable future, what is the thing you look forward to in, like, the near future of Chrome? What are the next upcoming things that you think that's a big one? Oh, well, I mean, there's so many things we're working on. There is, right? Yeah. I mean, I'm really excited. Pick a favorite. Yeah. Which of your children are your favorite? You know, I'm pretty jazzed about the future with thinking about WebAssembly, for example, and the opportunity that creates for developers, especially folks who, you know, have the roots in, or they have a bunch of C code that they want to, they wish they could bring to users through the web. Tapping in this existing ecosystem of C has been around for years, and it's not been usable on the web. Yeah. Suddenly, it is. I was really excited to see what the work AutoCAD did to bring Autodesk to bring AutoCAD to the web through WebAssembly. I think it's really exciting because there's just actually a lot of, not only a lot of code written that way, but also a lot of developers who know how to create cool things this way, and I think it just creates a lot more opportunity. I don't think the WebAssembly talk, because they have AutoCAD presenting what they did, which is absolutely amazing, so that's going to be really cool. And I think, actually, the thing that's amazing is, they made previous attempts to bring some of their applications to the web, but it was only until WebAssembly that it was actually possible for them to do it in a reasonable fashion, right, and get a good result. Something I wanted to build for years was an image compressor on the web, something that brings all the existing codecs in, and it's something I tried five years ago when Asm was a thing, but couldn't quite get there. Some memory management stuff wasn't there. I think it doesn't really scale to say the browser has to bake in APIs for everything you could possibly want to do, rather to give the right low-level primitives so that developers can build not just great applications, but also frameworks that allow others to build great applications. And for people to be able to innovate on that foundation, that means we can't possibly think about all the stuff that people are going to do, but we have to build a platform that creates more freedom. Yeah, yeah. Yeah, to be able to build something that can display and compress WebP in Safari, a browser that doesn't support it natively, and now we can do it. Even in Lego. Yeah, put together. Give the building blocks. Yeah. Give the building blocks, yeah. When someone's suggesting names for products and someone goes, no, we can't have that. That's a silly name. I stop everyone and say, we all work at a company called Google. Yes. That might seem normal now. But if you tell people about that, sounds ridiculous.