 talk, also unlike the previous talk, you will probably learn nothing at it. So don't hesitate to come up in the front. There's no more seats in the front. But it's going to be a lighthearted session. I'm Vikram Agarwal. I am a software engineer at Google. I've been mistaken for a product manager, but I assure you I have a degree in engineering from a well-accredited university that's still around. It hasn't flopped after I graduated. I wanted to start this session by actually saying, this has been quite a venue. I wasn't planning on being here. And I landed here entirely by accident. And I've talked to a lot of people yesterday. And I am amazed at the level of skill, the level of competence, and the level of expertise that you all have. So I wanted to say, we are told not to make reckless quotes that can show up in the tech blogs. But I'm happy to make reckless quotes like that. You can post it on Twitter. Software engineer at Google, Vikram Agarwal, says, you are all amazing. This has been quite an experience. People say, there's this mobile revolution going on. And there's the frontier of mobile revolution. People are using these mobile devices for the first time. Well, they're not using apps that someone far away has written. They're using apps that you have written. So you should feel proud. You should feel confident you're on the cutting edge. I also wanted to start by saying, this is just my personal experience. This is my journey. Thankfully, you are not me. And I'm going to talk a bit about what I have learned from a few years of working at Google. And I struggled with it. I struggled with what I could tell you that would be impactful. I've worked on a couple of teams. And none of those things are things that you're probably doing, because otherwise I would know you. You would be on my team, and you'd be back in my office where you could yell at me, rather than me yelling at you. So this is purely anecdotes. These are stories that might be interesting to you. But I tried to tune these. I tried to tune these to make sure that they might have some meaning for you. But life is too short to attend boring presentations. So if you find yourself nodding off, that's all right. There's excellent tea and coffee downstairs. If you leave, that's fine. You shouldn't sit here through a boring presentation. Leave, that's OK. But I was told to make talks interesting. So this is how I make talks interesting. I'll include pictures of kittens, pictures of puppies. At the very least, you're going to find something entertaining, even if you find nothing of educational value. And I can probably start out saying, you will find nothing of educational value in my talk. As I mentioned earlier, I am a software engineer at Google. I hope you don't mistake me for a product manager or a people manager. I've written code. I went to grad school. I fully recommend the process of going to grad school. You learn things that have nothing to do with computer science or engineering. I can see some people have actually been to grad school because you're laughing. And I like the experience so much that I was in grad school a fair chunk of my life. But it was a good experience. You pick up skills that are valuable. I learned how to juggle. And then after that, I switched. Google's really the only company I've ever worked at, which makes me a kind of a strange person because I can't survive out in the real world, I'm told. Many of my friends tell me point blank, you have no idea how the real world works because you only worked at Google. So you are a curious creature. They're probably right. I can't survive out in the real world unless I get free food, unless I get that cocoon of Google I probably won't live. But maybe that's not entirely true. I have worked at a startup in India when I was still studying here. And it was a fun place to work in because I was still in college. I had no rent. I had no children, thankfully. I was living with my parents. I had nothing to pay. And I was getting free money. So I pretended to work. And the startup pretended to pay me. And it was an interesting experience. I met a lot of fun people. This was back when the startup scene wasn't as hot as it is today. People worried about me wasting my time. And they were absolutely right. I was wasting my time. And then I went to Google where I worked on Search. I worked on Search ranking at Google for a few years. And I was really happy in that team. I learned a lot about good distributed systems. Google has a very, very mature set of tools, a very mature set of provisioning and engineering. It really is world-class. But I figured the Search stack didn't need me as much as mobile did. And mobile was just taking off. And so I switched rather abruptly to work on Android apps. And that was a hard transition because I went from server to client. I went from releasing twice a week to releasing once a year, once in two years. I worked on the Gmail Android app. And what I'm really talking about is the work of many, many people. I'm just representing their work. And so all the credit here really belongs to them. It's a large team. It's a very qualified team. My current project is Google Search on Android. This is an application on your Android devices that you can touch. It's our flagship app for some features. I'll use Play Store numbers here because we are also told to stick to publicly published numbers. This is what our Play Store entry looks like. It doesn't look anything like our web interface. The Google web interface has just Google and a text bar. And you can tell this thing, even the left screen has some other things. It has some speculative cards, some assistive cards that are telling me that if I leave in 20 minutes, you can't actually read this, which is good. But it tells me that if I leave in 20 minutes, I can make it to the grocery store in time, which is good, except that I wasn't going there that day. But that's already things that we don't do on the web. It does hot wording. It's a fairly complicated application. And it's fairly different from what we do on the web. I'll walk you through some of the complexity so you can get a sense of what it is. For starters, it's the home screen on Nexus devices and certain OEM devices. You can download the Google Home Launcher. So this is the home screen on your Android phone. We have the capability to dictate by voice. And yes, it works in Indian languages. So if you have a third-party application and you want dictation by speech, really the thing that powers it is the Google Search app. It's also the home for the Google Now Assistant, which is on the negative screen on the launcher. So if you swipe all the way to the left, it shows you cards about what you should be doing, like commuting, as opposed to what you are doing, which is wasting time. And when you look at like this, this is not a very complicated app. It's because it does a lot more things. This thing also does the OK Google Hotword. I'm surprised that I haven't triggered anyone's phone yet. Usually you give a talk like this in a room full of 400 people and you hear bing, bing, bing, bing, bing. There's at least one device there. But this allows you to hotword. It's power efficient. You can do voice searches based on that hotword. And some of these features aren't really known to people. So you can say, OK Google, how many inches is 54 feet? And Google will tell you, because the Indian engineering education doesn't actually teach arithmetic, so you might not remember that. And then it does voice actions. It does things that you want to do, because mobile is not about searching anymore. Mobile is about doing. And so why do we bother searching, take you to something that allows you to do, will allow you to do it right away? And so even here, and I tried this yesterday, I probably won't be able to try it right now, because my phone is in a backpack, which I've lost. But you can do a query. You can say, navigate to a cafe coffee day near me. Think about that for a second. Two decades ago, there were no maps. We grew up in a place. I had no idea what was 50 feet away from me. And now you can run a voice action saying, navigate to a cafe coffee day near me. That's just mind blowing. It's science fiction. So the Google search app does all of this. That's what the app icon looks like. It's been downloaded 1 billion to 5 billion number of times, is what the Play Store says. So you probably all have it. But in case you don't, that's the icon to go get. We also do text search, because I think Google does search. That's what I've been told. All that is a lot of complexity. There's a lot that this app is doing. And some of the engineers look at all that complexity and say, you guys are crazy. Why is this in a single app? And to you, I would say you are correct. Here's a puppy. Life must be very easy when you're a puppy, because you don't have to deal with all this code. The thing that Google does, which makes something like this possible, is every single engineer, irrespective of where you are in the team, irrespective of job function, irrespective of how long you've been in the team, thinks a lot about the product. We think about the product obsessively. The best technology makes no difference if it doesn't translate into a usable product. Handwriting recognition was an amazing technology. If you used an old palm device, you know that the palm folks went around handwriting recognition, because they couldn't deliver on it. It was a great idea. You needed a device with a 2GHz processor, and no one ever used it. It never made it into a usable enough tech, and certainly not into a usable product. And at Google, every engineer, whether they're in a one person team or they're in a 50% team, thinks a lot about the product. Technology is cool. What makes it even better is a working product. In the physical world, a product is something tangible. You can hold it. You give it to somebody in a shop. They give you money for it. This is a great example for a product. You might not know anything about guitars. You might not know anything about good guitars. But you know this thing has been used. If you look at the fretboard there, it's been worn out. You can tell that the guitarist probably had a belt buckle, because if you see, the paint has been chipped off where the guitar sits near your belt. This product has been used by someone to create music. When you work on a product like this, you know what you want from it. They use it to create music. We're all working on products. We're all building products. We're writing software, but that's incidental. What we're really doing is building products. When we look at the software that we write, we think of building a product which is this good, which is loved by some user to the point that it's almost falling apart. You're building this product. Can you use it? Does your mother want to use it? This way of talking about a product makes it sound like it's a physical thing that you wrap up. You put stamps on it. You give it to the post office, and they lose it. Maybe you give it to door-to-door courier or FedEx, and they actually deliver it. But that is an excellent way of thinking about it. You're building a product. You're working on something. You're making something. It's software. You can't hold it. But you give it to a user. They take it from you. They give you money for it sometimes. They unpack it. Well, really Android unpacks it. But someone unpacks it. They use it. If you think about your product in this way, you're forced to think of the user who's finally using it, the person who's either paying you money for it or is using it on a daily basis. When they finally receive it, is the experience good enough when they get this package and they open it? Are they happy or are they frustrated? Is this package bringing them joy? When you buy things on Amazon or Flipkart, they come home and you wait for them for two days, and it comes in, and you open it, and you're so happy. You want to recreate that sense of happiness, of wonder in the products that you're building. Especially in India and also across the world, users choose not to auto-update. There are many reasons why people don't want to auto-update. They want to save battery. They want to save their data plan. They just hate you. There's all sorts of reasons. And so when your product ships, it actually leaves your office. It's gone. It's taken a life of its own. You might never get that user again. This is fundamentally different from the web, where to use Amazon.com or Flipkart.com, the user has to be signed in. They have to use your web interface. On mobile, that thing has left you. You might have really good ideas for v4 or v5, and you have a v0, and your manager tells you, ship it. It's all right. This is OK. Well, that's not OK, because you might not get a chance at v2. Your v1 might be so rough that users use it, and they say, this is garbage. Think about that for a minute. This product has left you. You've made a guitar, someone purchased it, and they hated it. They're not going to buy another guitar from you. We obsess about the product we deliver. Sometimes too much. Sometimes we hold back products much longer than we need to. We should have shipped them out earlier. But it's good to have some level of polish never ever release a rough product. The other thing Google does slightly differently is its focus on tools. This thing is an Arduino device. Take a minute to look at it while I sip this unlabeled bottle of water. When this came out, I want to say 2005 or 2006, fact-checker in the first row, this thing came out in 2006. And nothing about this hardware is exemplary. The CPU or the chip used here is made by ACML. It's the 816. It had been around for at least a decade before that. The compiler for this was not new. AVRGCC had existed for a long, long time. And if you look around the board, nothing there is spectacular. There are some resistors. There's a capacitor. There's a crystal. Nothing really fancy. What set this apart was its focus on tools. This thing came with a simple IDE. Before you had Arduino, you had these bizarre IDEs that you had to download. They only ran on Windows. If they ran at all, you couldn't figure out how to start them. You couldn't figure out where to enter code in them. You couldn't figure out anything. Arduino took the world by storm because it had this focus on good tooling. And Google spends a lot of its effort on tooling. Google's always been very focused on tools, even when it was a small company. In my team, we spent a fair amount of time last year working on a large source code migration. The only reason we did this large project was to benefit from mature tools that were present somewhere in Google. We had been in the Android repository. We're using make. And there were many good reasons for us to be there. Over time, we realized those reasons don't hold true for us anymore. And so we put in about nine engineer months of effort in moving our source code repository over. As a result of that, we got good testing tools. The talk before this is about testing. We certainly use Rover Electric. We use a lot of other tools as well. But we also got continuous integration. We got pre-submits, tests running every single time you commit a file, release tools that allow you to release in an automated way. We had to decide whether we should pause the release in December or not, because now one of our channels is entirely automated. It can run on a Sunday. It can run on a Saturday. It can run all through December, even on Christmas. And we figured we probably shouldn't run this on Christmas because the automated system can push even on a holiday, but you don't have any engineers to fix problems if bugs are reported. And so we might just pause it. Google spends a lot of its effort on tooling. And in the work that you do, even as individual engineers, there's a lot of effort that you can put on learning the tools around you. I think you're in a great group, because you're exposed to the tools that other people are talking about. We looked at Toboelectric in the talk before. You saw the Jenny Motion emulator. There are many other tools that you're now aware of, because you're at GroidCon. And I would recommend continuing that investment in tooling, continuing to learn. Even if it is simple tools like Git, often engineers come to me and they say, I don't understand Git at all. This thing is like black magic. And it's true. It's easy. It's remarkably easy to shoot yourself in the foot with Git. And you can take three days off and learn Git, truly understand Git. And those three days will be valuable for your entire career, a two decade, three decade horizon of benefit that you get from three days of effort. The nine engineer months that we spent on making the source code change was perhaps the best nine engineer months we could have spent at that time. I loved it. The team was exceptional. At Google, telling your manager that you're going to invest in tools is fairly straightforward. It's understood. Everybody understands the value in it. But I see a lot of companies struggling with this. People don't see the value in investing in tools in sometimes paying for tools or spending time to see if a tool is worthwhile. The talk yesterday, Anshul's talk about React Native, was an excellent talk, because he had invested in learning about React Native. And his conclusion was, this thing is great, but perhaps not ready for his use right then. That's exactly the kind of mentality you want. You want to look at a new tool and say, what does this do? Can it help me out? Even if the answer is, well, not today. Maybe in three months. You want to put in that effort. And sometimes you can just buy the tool outright, either if you're in a big company or even if you want to buy an IDE. Sometimes it's worth it. The amount of effort that you would spend working around the quirks of whatever tool you're in is sometimes just not worthwhile. The best tools, the best products, make no difference if they don't see the light of day. There are many products that people have worked on. They're excellent products, and they have never shipped. The standard industry phrase around this is ship and iterate. Well, of course you'll iterate. Who ships and then stops working on a product? I think the real mantra should be ship it and ship it and ship it and ship it and ship it. You should make sure every step of the way, as an individual engineer, your incentive is making a product that goes out and sees the light of day. Even when I was a junior engineer at Google, it was painfully obvious that some of the things that you do, unless you scope down, unless you reduce the amount of things that you're going to deliver, it'll never really see the light of day. And this isn't just a product manager problem. This is not just something that your manager has to think about. It's something that all of us have to think about. You have to make sure that we set either milestones or we identify something that's small enough that we can actually deliver, because there's no point if it doesn't go out. You can work on it forever. When I moved from server to client, it was a hard transition, because I was used to the world where you push roughly every other day. You push twice a week. Things are so easy. Everyone always had the latest version of their application. You knew what the problems were. You never had legacy versions floating around. The client is very different. Mobile has update problems. Mobile has problems with APK sizes being too large. People don't want to upgrade. And you end up with a version distribution out there, which is all over the place. Your latest version might only be used by a percent or 2% of your user base. And the ability to do functional pushes on this is critical to the morale and productivity of your team. Even if users never get your application, say you're pushing every other week. And users still don't auto-update. That is still an engineering win, because every two weeks you have the capability to do a push. Users who get a new device or who choose to auto-update get your new version. And the amount of effort that you have to spend in curating two weeks worth of changes is a lot less than if you waited five months or eight months or a year worth of changes. And then you'd have to run your suite of tests against it. And you find out of the 1,000 tests, you had 3,000 failures. Every single thing fails. And then you're going to firefighting mode, you find out what broke, why aren't my tests green. And if this happens often enough, if you fail enough releases, engineers get the sense that nobody really is in control. It's a huge hit on productivity. It's a huge hit on morale. In my current team, we used to have fairly irregular releases. We used to be at six weeks. But that was a nominal six-week release cycle. We used to have frequent failed pushes. And I was speaking to a few people about this. And everyone agreed that we had to fix it. And we tried to identify what could we do. We could either make it faster or we could make it more regular. And of course, when you give someone a choice of A or B, they say, yes, give me both. And so we tried to go from six weeks to three weeks. And we wanted it to be regular. I would have been happier if we just did six weeks, but we were regular. Or we could have done three weeks and been slightly irregular. Well, we were already at three weeks very, very irregularly. We were shipping at about six weeks. That's pretty irregular three-week schedule. But the lesson out of this was aim aggressively, try to reduce your release cycle. We were at six weeks. We were able to get it to three weeks, even if we had failed at delivering an APK every three weeks, even if we got four weeks, that would have been a huge win. The amount of changes that go in in a single month is still relatively small, even though our team is very large. We tend to aim big. We were able to deliver on three weekly releases this year. We were able to do every single release on time. We missed no release at all. For an application that's used by more than a billion people that has many, many, many engineers working on it, this is a fairly big accomplishment. And at places like Google, we want to invest in making sure that releases can be regular. It allows for a lot of things. It allows for product planning. That icon that you see was changed this year. I wonder if anyone noticed. But we used to have a different icon. And that icon change required close coordination with many teams. And we were able to deliver that because we knew that we would have a very, very regular release cycle, that we could launch on a day. Whether it's December 4th, September 9th, you knew you could track that day. And as an engineer, that's amazing. You know when your change is going to go out. You can plan for it. You know when you have to write your tests. If the milestones and the roadmap is given out to you, you can account for it. And you can deliver it on time. It gives you this great feeling of accomplishment. And it gives you a great feeling of control. Again, here I should remind you that I'm representing the work of a fairly large team. And also, going back to the talk that we had earlier, you can't possibly do this unless you've automated most of your tests. You can't do a regular release cycle if you're going to run the tests two days before you actually launch. All your tests are going to fail. So a big part of this was making sure that all of our tests, all of our release tools, really everything that we rely on was as automated as possible. At Google, we have code reviews. And so every time you check code in, you'll get to know whether that code was going to break an existing test or not. We also have aggressive rollbacks and pre-submit checks. If your code breaks an existing pre-submit check, it just won't be allowed in. But automating most of this is key to fixing most of the hurdles that you will encounter during shipping. And so even if you weren't shipping every three weeks, even if you're still continue shipping every six weeks or six months, having a system like this in place is great for making sure that your code health is clean. Going through all that, you might think that Google has a fairly large number of people working on it. And so you expect that this is roughly what our team structure should look like, mostly white American men in suits on motorcycles. It's more or less accurate. This is exactly how it looks. We also wear a costume to work. But the team sizes might surprise you. Most of the work done for a recent feature that we worked on, which is contextual search inside Android M, was the work of three client engineers. So there were three engineers who worked on this for about six or seven months. And that three engineer team with no Android expertise was able to deliver on a feature. So this is really what our teams look like. We have really good engineers. But more importantly, you can always train a really good engineer. Training an engineer is not our, that's easier to accomplish. What's harder to accomplish is the team camaraderie. It's harder to accomplish a team that works well together. If you think about a group like this, the lead pilot doesn't have time to give all the other pilots specific instructions on what to do. And when you're in a team like that, irrespective of whether you are the team lead or you're an individual engineer, it's in your interest to make sure that you have team structures where you can execute independent of the other people. You don't have to get direction every step of the way. You know what to do almost instinctively. The feature that I talked about that I didn't speak much about because I didn't have slides on it, that was done by three people. The source code migration was really the work of one engineer. She did this nearly all by herself. She was able to move the source code with history into a different depository. All the build rules that were written for this were written by one guy. He also made all the automated testing changes that were required. The release cycle changes was pretty much made by one person. These are really, really tiny teams. And in a way, this is similar to what your teams probably look like. You have a feature that you're working on. There's probably one engineer on it, or there's two engineers or a half engineer working on it. Many people wonder what kind of an engineer does Google hire? Is it all software engineers? I tend not to think of it as software engineering. You might be doing many different things. You might be doing build changes one day. You might be doing a feature the other day. You might be thinking of UX a third day. I really think of it as an anything engineer. And this is something for all of us engineers to remember. We're at DroidCon, and I know we should be talking only about Android. But you should look outside. You should see what the rest of the people in your team are doing with web. What are they doing on iOS? What are they doing on Microsoft Windows? What are they doing elsewhere? There's a talk on hardware later. Have the confidence in your ability that you can really set out to do whatever you want. You can be a part of a team where, if the web engineer goes on leave for a month, that you can take over, that you can pitch in. It allows for a team structure where any engineer can take over any other engineer's task. Also, the other thing to remember is good engineering talent comes from everywhere. It's not just the top schools. It's not just people who grew up in a certain area or come from a certain demographic or income background. And it's certainly not related to gender. I'm so heartened to see that there's so many talks here. There's so many female engineers here. There was an excellent talk earlier. There were many questions. This is exactly what you want to foster as individual engineers. Be sure that we should not have any implicit bias on what we consider as engineers. Engineers aren't just people who look like me. Boys who look like me. On mobile, the teams are also very, very small. It's common to see a mobile engineering team, which is one person. All the Android work is done by one engineer. And when you're in a team like that, it's useful to find somebody in your team who can handle some of the Android work for you, who can do code reviews for you, who can bounce ideas off. In Google, we try to be resilient against all sorts of things. My best engineer recently changed teams. He was a code ninja. And he moved to a different team. And we were able to still deliver on the feature that we were working on. We had our team change direction mid-course. We've done some infrastructure work. We're doing some features work right now. We've had engineers who've left for a long break. We've had engineers who left for many month breaks. Or we've had managers who've left halfway through it. And the team still survives. As an engineer, you should make sure that you're in a team that can allow you to take a vacation. We also allow for other productivity problems at work, like when people bring dogs to work. The last thing I wanted to cover was when I was an engineer, when I just started out at Google, I used to attend talks like this. And I used to think, this talk is really aimed at my manager, or this talk is really aimed at my product manager, or this talk is aimed at my VP. And I was in this office, and two of my colleagues who were also fairly junior engineers, had a fairly deep disagreement. And they both talked to me separately about it. It was unfortunate. And it clearly poisoned the air in my office. It was kind of hard to get any work done with the two of them constantly at each other's throat. And I spoke to them separately. And I told them, this is just crazy. We're in this. Wow, that is crazy. I wonder if that happens again. Though it did improve how good this is. You can see this much better. You can see the eye on that ants. Oh, shit. No, I shouldn't have done that. And so I talked to them, and they were able to fix their differences. And I wasn't a manager. I wasn't anywhere in the hierarchy. And that was a big lesson for me. The lesson that no matter where you are in the chain, you have a lot of impact. I talked about product things, about thinking about the product. Traditionally, we think of that as the product manager's thing. Or that's your manager's thing. He's supposed to do this for you. At every step of the way, every single engineer has a lot more impact than you think you do. So when you walk out of a talk like this, give it a shot. If you've got tools problems, if you've got product problems, talk to the people who you think are responsible for it, and make a pitch for what you think is the right way. You'll find out more often than not that you have a lot more impact than you think you do. Engineers in general have a bad rep. We are taken kind of for granted because we speak poorly, we dress badly, and I'm a prime example of this. This is something I found lying down on the bed, on the bathroom floor. But we have a lot more impact than we give ourselves credit for. I have one more slide, and then I'm going to open it up for questions. I'm also going to be around for questions during coffee, if you buy me enough coffee. That's really all I had. I have five minutes for questions, six minutes and counting. Yes, just yell it out and I'll repeat the question. What's my favorite tool? That is a good question. That is a spectacularly good question. What is my favorite tool? I'll represent Google for a minute, and then I'll stop representing Google. I think my favorite tool to date is Git. I love it. When I saw it, I don't want to use family unsafe words. I was blown away. It made me happy to be a software engineer again. I love Git. I'm sorry, I won't be able to convince you, but Git is the most amazing thing I've ever seen. But beyond that, I've worked a lot with Linux. I think the tooling around Linux is surprisingly good. But if I were to pick one tool, it would probably be Git. I could probably use Git for a month, just playing around with it. I think it's amazing. It's absolutely amazing. Linux is a genius. He can do the kernel, and then he stops doing the kernel. If he could just do Git, he'd be my hero, but he did the kernel before that, so I don't know. It's hard sell. Questions? Yes? OK. Question was about what tools do we use for quality and performance. That's a good question. Much of the tools that we have internally aren't, unfortunately, available outside, because they rely on our machine structure. They rely on our distributed build system. And so even if I could tell you names, you wouldn't really be able to use them. Some of the things that we use around performance of networks are things like Charles Proxy. So you can tell whether the app performs well on poor quality networks. We do a fair amount of MAT, and I see Eric Andre, who talked about this earlier. We use a lot of tools to analyze memory. We also use Cistrace and standard Android tools. But then it depends on the domain. On the server side, it's different. Yes, question? Correct. Yeah. Are there any plans to open up an API for Google Now? Are there plans to open up an API for Google Now? Yes. That question is so good that I've actually gone back in time to provide that API. There is a third-party API for Google Now that should be available. I don't have details off the top of my head, but I know that the economist sends me Google Now cards to keep me well-informed and set up. There's another question that I wanted to ask. I mean, there was a lot of hype now on tap in the Marshmallow launch. But after Marshmallow launched, the hype almost died on now on tap. So is there anything new coming up on that front? I'm so glad you asked me that question. For the record, I have no idea who this person is. I don't know him. And my friends can validate that he and I have no relation. But now on tap was a product that I worked on. I delivered it on M. That's the feature that I was talking about that was done by engineers with no background. It was launched in Android M. This is the contextual search thing. There aren't any announcements on now on tap this month. But stay tuned. We're working on it. We're working pretty hard. It's really quite a fun product. And if you meet me outside, I'll show you stuff that I have running on my phone. So you'll see what we've got in store for you. Yeah, OK. Hello. Yes. Shout it out, wherever you are. Oh, yes. Speak it. No, that's not you. Hello. Yes, shout it out. You talked about automated releases. Can you give a little brief about what tool you are using or how you do it? Sure. I could tell you what the tool is, but it doesn't matter because it's not public. So this is an internal tool. But the idea is not that hard. There's a web interface for Play Store. You might not be able to do a full push entirely automatically using the Play Store web interface. But what this tool does, it's an internal Google tool. It creates APKs for all the different architectures, all the different variants that you might have, the bug versus release, and all the other ideas. You could write it yourself. It's internal to Google, so it wouldn't really matter. Thank you. On the same lines, actually, whenever you are in need of a tool or something like that, so do you tend to develop it to yourself or do you look for external sources? Excellent question. The question was, when you find the need for a tool, what the hell do you do? In Google, the standard decision tree that I would follow is I'd look at open source. Quite often, there's something that somebody else has written. And so I would use something that's available publicly, for sure. But if that doesn't work for reasons of licensing or reasons of other reasons, if it's an open source thing that doesn't work for you, we pitch to it, we improve it if we can. Otherwise, we just write it internally. There are some tools that you write internally anyway, because they're so easy to write. So the standard tool that I use, it's a fairly straightforward thing for looking at iNode modification on Linux when you're compiling code. If you know you're modifying a file often enough and you want to load it up on an iNode device, I have a small script that checks whether that file was modified. It runs the whole build. It pushes on my device. Things like that, we just write ourselves, because I'm sure something externally exists. But it's just so much effort learning that tool versus writing it yourself. It really depends. It depends what the need is. Yeah? Yeah? Yes? How do you personally compare pure Linux system with a Mac OS or the Mac system? For development? For the users, for an engineer, what do you suggest? That's a good, I don't know. I love Linux, so I think it's a lot more mature. Macs have some advantages. I'm a huge fan of Linux, personally. My desktop's a Linux machine. I love it. Any more questions? Yes? Oh, no idea. I really wish that Sundar were here giving that. And I would like to think that he's delegating that to me, but he hasn't yet. So maybe if I get promoted many, many times over, then I can give you a good answer. OK, yes. We're in time for a tea break. All right, I'll be outside. I love coffee, so if you have coffee coupons that you haven't used yet, I'll happily take them off you. And I'm available for any questions you might have. Thanks. Thank you.