Everybody, this is Christian Buckley, doing another MVP buzz chat and I'm talking today with Ola. Hello. Hello, Christian. So, for folks that don't know you, who are you, where are you and what do you do? Well, I'm a Norwegian MVP in the Cloud and Data Center Management Group. And I've been an MVP for 15 years since 2008, so I like to say that I got my MVP award when I was about 10 or 12 years or something like that. Of course. That's right. And I got married when I was 12 as well, so, yeah. It's always easier to lie to yourself than other, right? Of course. Yeah. So, I always like to ask too, so for being a seasoned MVP, been in it for a while to go back down memory lane, but what was that process like, like, what were you doing prior to becoming an MVP and what was the process of becoming an MVP for you? Yeah. For me, it was, I was actually the first non-developer MVP in Norway that got the title. So they had only had a couple before me, but they were all developers. But I was so lucky that I had my MCT certified trainer and I did a lot of training and Microsoft asked me one time when they was out of a speaker in my hometown, Bergen, in Norway. If I could just do a session on, I think it was server 2003 or something like that. So I just jumped on it and did a presentation. It was maybe the hardest thing I have done up till then because it was a new forum. It was a lot of people, but still it was a fun topic to talk about. So I did the first session of Microsoft conference and I was happy. The next time they asked me to come back and after that one, they asked me to be on the, it was a Norwegian tour with four cities. So I attended all the four cities and started to do this every year and do speeches and suddenly Microsoft just decided that maybe we should nominate Olaf and at that time I was working on the fabulous operating system Windows Vista. Oh, yes. Yeah. So we were early in the deployment phase actually and I did some speak, I had a session at TechEd in the States about upgrading Norway to Windows Vista and then I was nominated in the setup and deployment team at that time and got successfully in hopefully and have been an MVP since but in different categories. But my main thing to stay an MVP have been basically doing speeches at conferences and some other kind of activities. But lately I've gone down the road. You are on the podcast track. So I have my Blue Screen Brothers podcast. That's a Norwegian sound podcast, but it's an English YouTube channel doing demonstration, more technical demonstration because that's easier with the picture than just the sound. Well, it's interesting too.  You must be very technical. And certainly we're all focused on technology. I'm also a business focused MVP. You know, my degrees are in marketing, but I've been in tech for 32 years. And so it's, you know, the topics that I focus on are more, you know, user centric, user experience, you know, that side of things, business topics and dabbled in the IT pro, the admin topics as well. But can't can't write a line of code. Sorry. Yeah, I started that mostly that way myself. And when they changed the setup and deployment program to another job, to I think it was to be a part of the Windows Update group. It suddenly didn't fit me as well. And then I was over to the Windows MVP part instead. And one year I actually had two MEPs and then it was Windows and Office MEPs. So what I like to think about it as I grown up and started to do something else. So then I went over to the data center and Azure mainly. But I'm always loving Microsoft 365. That was my main cloud technology chaser. And after a while, I was starting to do more Azure work. And suddenly I was hired in a bank as an operation manager for Azure. And now I see myself as an Azure janitor doing maintenance and security. So that sounds really glitzy and Azure janitor. Yeah, yeah, because I don't think we have any good name because it's it's a kind of operation manager role. But I do more jobs. I find stuff that shouldn't be there. I deleted. I I do a lot of what I call janitoring. Right. It's it's a kind of governance and everything in governance is the main main part you have to do to stay secure. So you have the security side as an effect that you actually are a janitor and clean up stuff and find all these loopholes with networks that shouldn't be there or gateways that should be closed and so on. I've spent a good portion of my career, certainly when I was back in the project management world as doing janitorial services and operations. Same thing where it's you know, unappealingly referred to as like special projects. I was the one that would come in and I usually was like I had teams that would get merged into by my team. I was a task with managing people out. So to to taking teams, taking peers that got moved under me so that I could then cut across and clean up that. So not always the fun job doing the clean up stuff. But I prefer more of the governance as well, which is the oversight. Put the process in place to to have transparency on the work that's being done and yeah, policies, procedures for provisioning new systems and sites and teams and and putting the life cycle management in place and make sure that it's all running. Yeah, so and then you also get the place to be with the regarding of news because when you are doing the maintenance or the governance, you actually are in place of discovering new technologies, new way of doing stuff. So so you are allowed to stay ahead and actually do do exploring of everything you think could be a greater solution or better way of doing stuff for a new security system and stuff like that. So it's quite fun. I agree because it's also it's perfect for people that have adult ADHD. And yeah, but it's but having that variety, there's something to be said about having a variety in work. And I've never been that operations that ongoing, you know, basically it's it's packaged or set up. It's established and now it's just running it ongoing. Like drives me crazy. I got to be in new challenges and new challenges always. That's the thing. And that's why I call it a janitor because I feel like you do a lot of different stuff. You need to know a lot of stuff and you do a lot of different stuff. And because we are a bank, my work are really techno intensive and we have high priority on the technology and the security side and cost, of course, because every bank need to have they don't need to have a low cost, but they have to justify the cost. So so when I can discover that somebody set up an SQL server and forgot to delete the disks and we suddenly have 20,000 a year in disk space, not being used for something. So then you save money and you secure the system because in the same feature we actually discovered that we had firewall ports open to Avina that wasn't connected to anything, but it could easily be connected. So so you have different challenges all the time.  We have a lot of fun technology technology. So and that's going back to the MVP year. The way of being able to connect to different kind of product groups when I need to learn something new, if I need to learn something I didn't know anything about or I have a silly question. I can actually ask it and people will understand. OK, this is a new BN. We try to help him. So both in communities and internalists, of course.  And for those that are familiar, it's the so it's it's there. We're all under NDA. We get advanced views of things that product teams, some of them are more forthcoming than others were sharing with roadmap. And hey, here's what we're thinking about, but we've not made decisions on what are your thoughts about this. Other things that we see that are, you know, before or during a private preview and we provide feedback on. But one of the things that I love about that is being able to see things. And sometimes I'll be honest, I'll join a call about something new and be like, all right, this has like I see no value in this for me, for the stuff that I'm doing, I'll drop out of the call.  Sounds like it might be interesting or apply or drop back out of that. I was doing that kind of activity. Maybe that's just the personality of a of an MVP to go and experiment to to take in all this new. But I I'm part of local communities here and I was in California, where I was born and raised, but was part of different technical communities and would often sign up for, you know, hey, new product or new. Hey, this is a new advance in this area. Come check it out. What we're doing, I would constantly participate in those community based activities. I'm doing less of that now, more MVP stuff. But again, it's just a great way to expose yourself to new ideas that could possibly impact your company or the very least something a blogger or a podcast about. Yeah. And the same thing if I'm attending a conference. Usually I'm doing some speeches at conference when when I am attending. But I always try to go to session. I don't know anything about because going to something you already know. Well, it's not so rewarding as going to something you should have an insight to and learn something just to see how stuff works. It's like when you were a kid and you got a present in took every parts from it to see how it works. It just for finding the screwdriver and see if you can dissimulate and then you could put it right back. Right.  But knowing side stuff is also really fun and important. Well, that's why I also love to take the occasional class. I mean, stretch yourself, which is another I mean, it's always being learning. I think that's something I think humans need to always be learning something in general. I think it helps us to stay grounded and well rounded into the things that we're doing. Like I just I just finished a week long class and I it was around power platform and there are pieces of what I learned, which I'll never use again unless I take another class. But I wanted just to be able to speak to it to be aware of the various components. Now I have better understanding how they come together. And I can recommend it for other people. Right. Exactly. And that's why I actually love the Microsoft Learn platform because it's so easy to go in, especially when they have challenges where you can attend a challenge, cloud challenge and be a part of a rewarding system and stuff like that. But but I like to do the Microsoft Learn courses. I don't do the certification anymore because I have done enough of them and I know I don't need need them in my my work anymore, but I still like to take the different courses like the Azure developer course. I'm not a developer, but I read it to see how would the developer affect my daily work? What kind of system should I know about that they might be using? Yeah, that that's great advice in general. Anything else that you give I'm sure as an MVP for 15 years, you've had plenty of people come up to you and say, what is this process to become an MVP?  I think it's the the main part is the same that I will give to everybody that will have a good career. It's to be visible and you can be visible by having a Twitter account, Twittering stuff, a blog and and people think that if you blog, you need to write 14 pages of something. But basically, the most read blogs are just half a page because they are directly to the point. So I think that you should try to be visible and on the online world, on the different medias, you should attend community classes, community groups, if you have some in your neighborhood and try to do speeches or at least attend and talk to them. So you are visible and people know you, but you need to have a footprint in the digital world before you can be an MVP today. It was easier when I was an empty and it was not easier that way. But but that way you got notice for what you did from your local Microsoft office, but now you can just have something online and people will start to see that you are often in in this community pages and answer question or stuff like that.  So you need to be visible and that's the main thing. And people think that MVPs are the best in class that everybody are the best engineer they can get. But but in basically, it's actually about sharing your knowledge with other people. So you don't need to be the top guy, but you need to be the guy that actually are willing to learn and share what you are learning with others. Yeah, that's really the key. That that's the point. I think when I became an MVP, it was kind of a big deal that there was just a handful of us that were business focused MVPs that were non technical and that's and I use that phrase too. It's like it's not exactly fair. Like again, my entire career has been in it. I'm technical in a number of areas, but not being a developer and not being an engineer by trade. I was there for a non technical MVP. And again, there was just a handful of us. And now you have a good portion of it where I think it was a shift even for Microsoft to recognize exactly what you said that these are individuals who are doing more to share what they're doing. You do need to be involved in the technology. That's kind of the point. But it's you're right. You're surfacing the work that you're doing, highlighting the work of others, recognizing that being in the conversation. Those are ways that you can become visible. Yeah, build up a network around you. So that's always a good thing. But I think always the local Azure groups, Office 365 groups or whatever group you have in your neighborhood, try to find one that you are involved in that kind of work. And if you get involved there, you have a good starting ground to become an MVP, I would say. Exactly. Yeah, there's there's always there's there's not a single user group out there that doesn't look at somebody who is willing to volunteer to get involved to they'll they'll not say no to that. You welcome the bigger issue is that you have a lot of people that just don't be one of them where they come and say, hey, I want to get involved and then you ghost them. You that you never respond, never follow up with the user group leadership. I'm on the user group board for my local community here in Utah. And we have plenty of people that get excited, go to an event that we put on or show up at a user group meeting and say, hey, I really want to get involved. I'd love to do more. I'd love to be in charge of a committee within the user group or something. And then we never see them again. Yeah, and then you get more work because if you think they are going to do something and you set it up and they don't follow up, you have to do it yourself. And it's twice as hard as just trying to do somebody else's job. So it's it's better to say it's too much for me, but I can help in another way. So yeah, so easy and then do what you promise. That's maybe the best thing. And just always showing up, being an attendee and participating, engaging in the conversation. That's fantastic right there. So yeah. Yeah. And share, share if there are good events because some of the community events are not that well visited and it should be more people there. So you should just start to share it, write it on LinkedIn or Twitter or whatever you have as social media. And then then you will start to create your own footprint so people can see that you actually have a digital footprint in technology. Exactly. Well, I'll really appreciate your time and your insights. And hopefully we'll we'll get to meet in person one of these days, maybe at another MVP summit in person. If they start, yeah, yeah, thanks for inviting me.


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