Matthew McCullough, VP of Product for Android Developer Experience, sits down with Ryan to talk advancements in Android development, enhancing developer efficiency and reducing routine toil, and the application of Gemini AI models to improve software toolchains.
Get the whole rundown of what’s new in this version of Android Developer’s Studio.
Google I/O just happened, and the Android team announced a bunch of things.
Connect with Matthew on LinkedIn.
Congrats to Populist badge winner chudo xl for their answer to Android app stuck at "Launching on Devices" or 'device 'DEVICEID' not found' error.
[intro music plays]
Ryan Donovan Hello everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host Ryan Donovan, and I know a lot of times we talk about the ins and outs of AI, but today we're giving a little love to the mobile developer. We have a special guest from the Android Developer team. The guest today is Matthew McCullough, VP of product for the Android Developer Experience. So how you doing today, Matthew?
Matthew J. McCullough I'm doing great, Ryan, any day that I can talk about what we're doing on behalf and for Android developers is a good day. So pick your day of the week.
RD All right. Well, I know we have a few of them listening today, so hopefully we'll give them some information they can use. But, top of the show, we like to ask our guests how they got into software and technology, to find out their origin story.
MM Mine goes way back. So I'm kind of a one trick person, but I've loved software development for a very long time. Spent my allowances on programming books. I, you know, mowed yards for lawn money to do that. I think kind of a big leap for me was like, ‘wow I could do this for a long time’ and the one catalyst was there was a little local competition in Belle Ville, Illinois that I lived when I was single digits age, and you did a poster and a little kind of mock program about what the future could look like enhanced by software and technology. And remember that was in the early vintage Apple and trash days. And even then, I thought ‘wow, this could transform farming, medicine education’. And the funny thing is, all these decades later, I have seen that happen and I still believe that it has a long way to go to still help in those same disciplines. So in a nutshell Ryan, software and getting into it for me was an opportunity to make the world a better place. Since I'm not a doctor and I'm not a lawyer, and you know, maybe I don't work in global health, but this is my way.
RD All right. Well, as a child of California I love the idealism. So I know, as of this episode's publication, you will have announced a bunch of interesting things for Android at the Google IO conference. What's most exciting for you to jump in on?
MM You know, I think it's the category, not the what, but then I can cover both things. I think categorically, if you look at what I see as trends, year after year, is more and more demand for software experiences. And so I always think, how do we help them achieve more, do more, get more of their creative ideas from idea to in the hands of users, because I've often talked about software that if you just write the code and upload it to a GitHub repo, or even if you build the APK, but you don't have it in user's hands, it's more liability than benefit. So I'm very much in the ‘how do we more quickly get software from idea into the hands of actual users?’. And so most of our tools and innovations are doing exactly that. A couple things that are specific around that is we always look to reduce toil. You might hear me mention that a couple times during the podcast, but that's a common pattern that we're looking for. Take away the nightly chores, the morning chores, so to speak. And give more time back to the stuff that really gives people joy, mocking, creating, prototyping, experimenting with versions of algorithms or the user interface. So we're really trying to just shift the allocation of time. And then a couple ways that we specifically do that, are for example, inside Android Studio, our primary IDE, providing more contextual hints over things that you'll need to do. What version of library makes the most sense? Can we give intelligent recommendations? What information are you getting from Play Console that you might need to modify in your application? Or when it comes to version bumps across a whole series of libraries, can we do most of that work for you and just present you with a nearly finished product for you to approve? Kind of puts you in a very broad shoulders posture state when the robots do the work and you get to do the approval.
RD I have a kind of a double question here about toil. Do you think as sort of restricted development environment, something that has a SDK, do you think there's more toil? And do you think you, as the owner of that space, do you have more control over reducing toil?
MM It cuts both ways because I think, you know, I've always been a believer in open source. My career was for a long time in that space, teaching, helping, building in that, so I believe in that dimension. But with millions of choices also comes millions of choices. No deep insight for this one. And I think what we're able to do in the mobile development space and with SDKs is kind of look at some of the patterns that we see of ‘oh wow, a lot of developers are wanting to accomplish this’. For example, with our Gemini nano model and some of our AI core work that we're doing there, we've got a facility to bring on device AI and ML in a very kind of standardized way. And then we even have a solutions API that brings out a four core set of workflows in a greatly simplified way. So instead of a big box of Lego parts with no instructions of how to put 'em together. We're a little bit more getting towards one of the kits, so it has an intended final design, it has some instructions on how to put it together, and it includes all or just enough of the right parts to build that particular thing. So for me, I see it as a little bit of like being able to express more guidance to help developers get to commonly needed tasks more rapidly. But, you know, software is freedom. You can code anything if you wanna go all the way down the stack.
RD Right. Yeah. And it's really interesting to see this sort of double movement going on where a lot of people are looking at components and making these little building blocks that are easier to put things together. But also, people still want to go down to, you know, bare metal in some cases, right.
MM Yeah. Some of our, you know, social media apps that are the most [inaudible] experiences on Android devices. I mean, when we work with those third party partners, they are tuning down to frames, down to the amount [inaudible] in the fractions of a single percent. So the level of tuning and care, while not quite assembly language from the old days, is pretty darn close to the same level of tweaking. I mean, down to, you know, what do we buffer, what do we load early? Can we delay load this for later? Can we skip a frame in strategic places? So it still exists, but just in new ways than maybe 10 or 15 years ago.
RD I've heard of social media companies building their own DNS and just like doing the bare bones of the network themselves.
MM When every percent matters, you come up with energy to work on stacks a long way down.
RD Yeah. And you mentioned letting some of the robots have some of the toil. Uh, we'll probably next month we'll have some of the DeepMind folks on for a conversation about Gemini, but wanted to see how you all are incorporating Gemini into your developer tools.
MM I think that's one of the really cool advantages you talked about, ‘hey, with SDKs and a little bit more on the rails, mobile development, you know, which way does this cut? Is this a positive? Is this a challenge?’ I'll tell you, having mobile development for Android have a lot of the components of Google is a very wonderful thing for that developer community. Being able to bring a whole host of individuals that really, really care about Android developer and not just me, not just my team, but two more rings outside of us going, ‘Hey, how can we help make this better?’ including the DeepMind team, is really amazing for that community. I think it's hard for you to point to other developer communities that have that same yin and yang. Now, some specific ways that this is coming out is, you know, we have the opportunity to give back evals for the Kotlin programming language, for the core training of these models. So that means it can be really, really good. We can contribute things when we're opinionated about what the future looks like. For example, compose over XML based views in the past. So we can supply a lot of really high quality examples of composed. So we have these very virtuous ways to be able to kind of contribute upstream, if you will, to create goodness to kind of flow through the tree for Android developers. So that's a very exciting leverage point that I didn't imagine or fully think about before I had come to Google, and now I just see it everywhere.
RD It's really interesting to have, you know, almost systemic controls of the developer's environment to be like, ‘what's the big pain points and how can we solve this as far up the chain as we can?’ What are some of the biggest pain points that you've heard recently?
MM They're pretty common. Even if you kind of closed your eyes to mobile development, you'd recognize a fairly good amount of these. I think number one is, if you look at the dependency tree of a modern application, whether it be a web app or whether it be a mobile app, or whether it be a desktop app is true across all of those. You've got your dependency trees that have stacks of open source and commercial libraries, and they usually in turn have dependencies themselves. You know, as the old phrase goes, it's turtles all the way down. So in order to keep up either for performance or vulnerability reasons or new features. It could be any one of the three. You've got to do version bumps and to someone who's not in software development, that just sounds like opening notepad and changing a number to a larger number. And to anyone who's spent any portion of their career touching that particular experience, you know that it's pretty far from that. Because usually there's dependent work that has to be done. ‘Oh look, the method signature change. Now I need to update my code’. ‘Oh look, there's a cascading dependency that's locked or pinned to that set, so I also have to upgrade this other’. And so I think in that particular case, we see that as a huge opportunity and we're bringing the best of AI and Agentic workflows to try to take a lot of that looping labor off and look at it more just like accepting a diff with a final review. And we talked about toil, but I can add another dimension to this: what we're really trying to continue to do is put experienced software developers in kind of a control cockpit lighting experience. They still choose, they still direct, they still decide, they still approve, but usually they have to do the labor behind each of those steps as well. And so I'm trying to, with my team, leave those steps intact, leave the top level steps intact, but remove some of the labor of the double quick steps that are behind each of those.
RD Right? Add some mechanics in to move the package to the next step. Right?
MM And you don't care if they work all night. You know, we often, in my past employment, we often talked about what can we do that improves the code base while developers sleep. And it wasn't even meant to be either funny or silly at all. It was literally what can we run in nightly jobs that when you wake back up and come back to this awesome job, things are literally in a better state than when you walked away from the keyboard. And I think that's a really good charge. Now, we haven't totally cracked that code or solved that entirely. But I think it's a durable and virtuous goal. How do we make the code base better the minute you walk back up to that laptop?
RD It's interesting that, how do you do this as they sleep? That almost comes from a world where you did these eight hour builds or whatever it was, you had to step away while it built. So what can this code be doing to be better by the time it's finally built.
MM Yep. And you can run, you know, with compute power that we have to Ryan, just that one of the easy opportunities that we've got now, and existed, you know, even before the realm of AI, is just to simply run combinatorics. Can you test in different ways? I mean, fuzzing to some degree is one example of that. But can you run on different hardware? And then when you're talking about mobile specifically, we have some constraints. Do you wanna run it on a foldable, do you wanna run it on a traditional candy bar? Do you wanna run it on a tablet? What if we ran all those combinatorics for you? Those are, you know, easy opportunities.
RD I think that's an important one. I know Android is a mobile OS, and I had a friend who was doing mobile game development. He would go to conferences just to get the device to test his games on. And being able to do that in a more single source way, it seems like it's a big win for anybody who's writing anything on mobile.
MM It is Brian, you touched on something though that wasn't quite even a question, but I'm too exuberant about it not to share just a tiny smidge. Which is, you talked about tablet by implication, and I held up a foldable and I held up a regular candy bar. And yes, I have many more on the rest of my desk too for this. But when you think about all these different variations, one of the really magical things about Android, and has come to be even more true during my three years of the company, is that you can think about Android as a starting platform with a lot of the frameworks, behaviors that give you the ability then to target the nuance of specific form factors. In cars now, in XR, I don't know if we wanna talk about that in a minute, in foldables, in candy bars, in tablets, in TVs. So you have all of these destinations but you know that building a skillset over the years is really expensive. Like you have to learn all this tech stack and the nuances and the behaviors, and we try to give you an awesome dividend for learning that because you can go to any of these different surfaces and bring exactly the same skillset that you learned maybe from many mobile devs on, on this one.
RD We do wanna talk about the XR a little bit because that seems like that is a vastly different form factor than a lot of the other ones, although maybe it's not. Maybe it is just a screen put over the real world, right.
MM It's blended though. When you say over, we can see if there's time to unpack that, but it's interesting how blended those experiences have become. Your map location is kind of an ambient gift that you give to family members or to friends or acquaintances. Your wallet is now digital in some experience. So when you say overlay, this is your wallet to pay in many cases.
RD What is the complication there? Are there things that exist only on XR experiences that don't exist on the other Android experiences?
MM There are for sure. I think by definition it's trying to break into a set of new paradigms that are really difficult. They've kind of, a little bit been piloted on handset. You know, we've got some AR experiences where you can point at something and get an overlay, either of an image or an object or some sort of mapping there. But I think it's taking it to the next level. And I think Ryan, you know, just even playing around with this, you've seen the Wuhan headset that we've announced at XR Unlocked and with Samsung, and we've got dev kits and we've now getting a lot of feedback from the folks that are working with that. And it's neat for them to think, to be able to blend the two because you have this hard surface that is the world, and then you have a soft representation in a really automatic way: wire frame meshes over all of the objects, boundary control, understanding of where walls and other objects are placed. And then you can start to imagine, and I think that's actually the keyword, is imagine when you can bend and mesh in between those two. I can software enhance the hard surface world. So now you can do things like project what the future would look like. And I promise that's not even philosophical or meant to be the least bit silly, but you can start imagining that there's really expensive things to do. I'm gonna hang up some blinds in my office here and I'm a little nervous to drill holes in things, I wanna be committed, I feel like that's a pretty strong commitment. And even something as simple as that, I've been able to use some basic models to be able to paint in what those roller shades will look like in the future. And I'm now more confident of making a purchase. This is an interesting life experience loop because I can quote unquote, ‘see the future’. I know what those will look like. I see that the placement makes a lot of sense, and so now I'm more confident even to have a commercial transaction. So it's funny how predicting the future, seeing the future can increase confidence and maybe even activate shopping.
RD I saw somebody here testing out cabinets, taking a picture of their kitchen, and virtually adding in cabinets to see how they look.
MM I have a 15 second anecdote on that too. We're trying to have some doors put on some bookshelves in our family room, and I wanted to make sure that for the craftspersons that we had coming, he had a good sense of what we wanted when it was finished. And to one of them, we showed them the picture of the mock that we created with a Gemini. And this is just handset based, not XR. And they were so enthralled with the image that their first question is, ‘why did you remove the doors if you'd like me to add some?’ because it was just so perfectly placed. So that was fun AI moment: ‘why did you remove the doors?’ Nope. That's what we would just like it to look like in the end state.
RD Yeah. With these different form factors, is there a component of adapting to them? Because I know AI has been very good at sort of scaffolding things when you have a thing you need to apply, and then you have the templates for application.
MM I think there's a couple ways, but let's see if there's a couple that you wanna explore for that. I think the one that I'm most interested in is reducing the cost for developers to be able to experiment. So I think there's certainly a classic quote of, ‘the way to have a good idea is to have many’, it's attributed to several historic figures, but I think the concept holds. But the problem in software development is often that it's expensive to implement an idea. Sometimes even to a barely working prototype, that can be a pretty expensive investment. And so one of the things that my team and I are thinking about is, if having many ideas is a virtuous thing, if having prototypes that you can play with usually leads to refined and better experiences, then how do we lower the cost? Developer ROI is something that we talk about. We can either increase the return or we can decrease the amount of investment to get there, or hopefully, do both, which is a really nice double-ended lever. And so one of the things that we've seen is mock to code. You've even heard some of our third party partners and applications talk about using some of the capability that we've released in Android Studio of mock to code. But it is sufficient now to create basic idiomatic compose our declared a UI framework from something as simple as a Figma drawing, a screenshot, or in some cases, and this is a little more stretchy, it's not as successful, but we have successfully drawn on napkins and had that translated to code. And I think that even though that's early days. So under promise, over deliver. I mean, Ryan, if you put yourself back five, maybe 10 years ago, and I told you with a straight face that you could draw with a Sharpie on a napkin, and I could take a picture and have it translated into relatively idiomatic code for a specific mobile platform.
RD That sounds ridiculous.
MM I feel like you're like, ‘he might not be all right’.
RD Yeah. Yeah. Not, not even the Jetsons went that far. Come on.
MM Yeah, and that happens. So now this is absolutely an everyday capability, and so we're trying to find as many of those. I don't think it's a one only, we're trying to find as many of these magical ‘I have a hard time believing you’ kind of experiences for developers. And we're just trying to find them across the entire development ecosystem. But that's one Ryan in particular.
RD With AI, we've done some surveys and everybody is using it, but not everybody trusts it. And I know that the DeepMind team is doing a lot of work on that governance, and I wonder how much the Android team is putting on top of that because you have a more constrained environment to use the AI in.
MM Yeah, there's a couple dimensions that we're thinking about this. I think we will start with the device itself, and then we'll go out to models. One of them in particular is the origin of the model that I'm getting to use for my certain task, and I think that a lot of our developers place a lot of trust in materials that are first party right from Google -
RD Right -
MM So there's a lot of confidence of ‘wow, this is DeepMind's model run through all of the safety process, procedures, and guardrails that Google creates and it's brought to me on a mobile device that I can count is there on flagships’. That's one. The second component is where that inference runs, and I mentioned earlier, Gemini nano our own device model, and I think for certain classes of use case, that's a cost savings. That's great. You can just use the compute on the phone, but you're kind of pointing on trust. And I think that's another high value column for being able to do on device inference because if you can offer your end users. Because again, we're talking about developers today and what can they do on behalf of the users of their applications. If you can offer a guarantee that what you type, what you take a picture of, or what we're running inference on, never leaves the device and in fact, as ephemeral, as soon as that inference is done, there is no history of that. If you wished to make that a promise, just even enabling that level of promise to their end users is pretty cool.
RD That's really great for privacy, right? But I'm sure that's an [inaudible] quantized model or it's a smaller model, right? So does that run the risk of being less accurate?
MM So, that's a great question. I think it solves some scenarios. It's certainly not for every scenario. And in fact, I'll pull this back and say that for developer scenarios, you really want something akin to the world's knowledge about code as your source. And as much as I love the storage capacities of the latest devices, I'm still confident that we can't put all of that just here just yet. And so that's actually where it allows me to extend your original question a little bit more into the cloud. We have, for example, in Gemini and Android Studio, so now back to the developer workflow, we really want access to the world's biggest and best model for completion of code. These Agentic tasks of like bumping versions and the like. And so for those, we have a couple of offerings. We have the leading edge, hot off the presses that people can get either for free or as an individual purchase. But when you're talking about trust, the kind of other end of buying the maximum amount of this, we offer these same products through our Google Cloud team, and that comes with no training data, private only to you, compute only runs on instances that you're in control of. So not only on the consumer side is there a set of choices to be made, largest model possible, or privately computing on device, but developers are making the same one where if they work in an enterprise that wants to make sure that their code is never seen by any place else or never used for training, that is an offer that Google Cloud allows us to power to. It's kind of cool being part of a company as large as Google to be able to have all of these offering points so that people can kind of choose along the spectrum what fits them.
RD Right. You got the whole stack if they want it.
MM Exactly. And they can choose where both from price and freshness. Hot off the presses.
RD Right. I wanted to make sure I got some questions about Kotlin, 'cause I know the Kotlin community is very passionate. Years ago I worked on an article about Lombok, which is a Java decorator, and it was the most popular at that point, and all the comments were just use Kotlin. So what sort of improvements are coming for Kotlin to make those folks happy?
MM There's a couple things here. One, I can give you the high-level elements that I'm excited about, but I can also tell you that this is the space that requires the greatest amount of specialists. So, but at the top level, I can see what's most exciting for me today. On a language like this and, and I say Stack Overflow is actually a source of this kind of confidence and truth, you wanna know that a language is vibrant. When developers are making a choice of either learning something, or adding to that knowledge base or using it in production, I think one thing that really matters is does this have a future? Does this have a community? Does this have strong computer science underpinning it? Because if it's missing those three things, you are, if you're thinking about it from an investment strategy, even if it's our retirements, making a pretty flimsy bet unless it has all of those components. And Kotlin does, and I'll give you a couple pieces of evidence as to how, as an answer to your question. Number one, the multi-year effort in partnership with JetBrains to get to a K2 compiler has amazingly been an effort that we finally landed and got all the way into the Android studio IDE, and into some of the tool chains. And this isn't just faster performance, though it is, it isn't just more correctness, which it is, but it's actually an unlock for the next generation of tools sitting on top a compiler. And one of my colleagues, Jeffrey, who I was talking to the other day, who was reminding me of something, it's nice when you have like 10 minutes walk and talk and they can remind you of the basics, is that compilers aren't just a way of emitting the final binaries anymore. Maybe they were at some longer point in the past, but these are now empowering tools that are often API accessed for linters, for things that are in your margin, giving decoration of color, for syntax, red and blue squiggle underneath elements, for determining optimization recommendations, that are coming through the IDE, so they aren't just emit me the ones and zeros. They are the tool that tells you about your code that you've written. So that was a major, major investment. And then the second thing about this is, and I'll keep it to just two, is really embracing the idea of multi-platform development but without a lot of compromise. And so for example, KMP, our Kotlin multi-platform is our recommended way of encapsulating business logic in a platform independent way. And that is getting tremendously positive results. And as we've spoken about publicly, our workspace team, sheets, stocks, drive meet that brings that set from Google is heavily invested and has that out to production with some really incredible statistics that I'll leave for later. But productivity gains, ease of understanding the code base, minimization of lines of code, being able to reduce and collapse and get absolutely consistent business logic across platforms. That's another one. So K2 compiler and making sure that KMP is an interesting new concept to reach across platforms. Those are two big ones.
RD Yeah, I know that Multi-platform has been a traditional source of toil for mobile developers. At previous job, we had two separate teams for four platforms, and there's a lot of work going into that multi-platform future. So I love to hear it.
MM And Ryan, you know, just one add on to that too is where people are, as appetites and trends change over time, what we're actually seeing is most important in a multi-platform approach is that business logic remains the same. And an easy one for our audiences together is to just think about even like tax calculation logic. That is not something that should be platform dependent. I think most of us can agree. That is regulatorily consistent, but then maybe there is some slight variation to the user interface, a [inaudible] that sits atop that, and that might just actually be the okay path in the future.
RD So this is a big release and you're the guy who cares about the developer experience for Android, but what are the pain points that you're still hearing?
MM There's quite a few, and my job is to try to work with teams across Google to reduce these year after year. And if we've all, you know, we've all worked on software, I hope for our listeners today. We know that this is a chip away, chew away, kind of approach at it. But the first one is being able to predict when these version upgrades or bumps will happen and when you're required to take them. And I think we've really worked on this by having a predictable cadence and a predictable range of time in the future for you to be able to get compliant with those. So that's great, predictability is often a way to reduce stress and be able to build something into a schedule grade. I know this will drop in this season and I don't need to have it complete by then. That's one. The second then is to be able to have trust or recommendations on these large sets of dependencies. We've covered that three times already in this podcast or touched on dependencies, but can someone please provide me linting and recommendations? Not just that there is a new version, but what is a recommended set that makes sense together? We've got capabilities in Gradle to be able to bundle, and we do this drop already today for our jet pack libraries, of saying that this is the family of versions that make sense together. And so what that helps with is you still have independent, fine-grained control, if you want it, we talked about that difference between recommendations versus control, but at least we're coming with, ‘Hey, the Android developer experience team recommends this set as a tested together set of dependencies’. So that's really helpful, that's like us giving some work ahead. And maybe just a very last one on this same dimension, is making sure that we're making the inner loops as short as possible. So now I'm gonna go to UI. We spend a lot of time in Kotlin and syntax and language and dependencies, but in the user interface, make the preview loop as short and real as possible is also really helpful. If you don't have to do a full build and a push of an APK to an emulator and then watch the application light up there. It's a useful tool, but that's maybe the longer one. If you can just have a paint up, which we do now, and be able to see live change as you're typing syntax and see that reflected in a preview pane that is taking, you know, metaphorically this long of a step and turning it into a wild keystroke kind of step.
RD I wanted to also follow up and talk about, you know, the Android open source project. What's the changes? Are these filtering down to that project and hear intel that there's some controversy?
MM There is, but I can dispel it and unfortunately make it seem just normal, natural, and boring once again, which it is. There was a difference. And back to our patterns before, I think most developers that I work with, like consistency, over variety in some cases. There was a variety of release approaches when these dropped to open, whether they were synchronized with one another, and effectively what we've done now instead of some repositories having a continuous release mode with small incremental changes that may not have been in a main milestone and other ones having major milestones, is we've lined everything up. The libraries, the core open source project, all drop in a synchronized fashion, which a little bit like those version bundles that I just talked about before, means that we're saying this set has been tested and works well together. So this is actually a quality of life improvement for developers. It is still in the open. It's still in the same repositories that everybody has always seen. It still has the same level of confidence in open source. Nothing and nothing and nothing have changed with those. But we've now synchronized, whereas before it was drip, drip, drip of change and now it comes at logical units that we've tested together.
RD That sounds great. And you know, I know a lot of what you're releasing is part of the development environment, the IDE, and having put out an article about IDEs as I know developers have strong feelings about IDEs and, and their terminal text editors. What are you excited about the future of IDEs?
MM It is the vibrancy of them. Some of us have been in industry 5, 10, 15, 20 years. Kind of look at the arcs and the waves where there feels like there was times where there wasn't a lot of choice or investment. And I am always interested in healthy competition because it means a space is alive and it's getting attention and investment in ideas. So I would really say this is a golden era again, for IDEs and editors in general, that that first and foremost excites me. Because there's lots of people thinking about it. But they're not just which variations, right? We've always had the emax versus them versus [inaudible] versus plus plus argument. We're gonna leave that one for another day. But it does, people are starting to rethink what it means to be an IDE. Is this code completion? I remember all the way back in the day [inaudible] software, I think back in Visual Studio ages and decades ago. But now we're doing that with the world's knowledge baked into AI models to supplement. One of the beautiful things about this too is taking old ideas, maybe pulling a little bit from what you just said, taking old ideas and using the latest technology to make them superpower. The idea might still be highly relevant. Another one is to make recommendations in code. And this is, I've always loved pair programming, I think we're taking some concepts that were physical concepts and also bringing them to digital experiences too. What if you had someone constantly recommending, ‘Hey, that's not idiomatic’. ‘Hey, there's a shorter way to write that particular intention that you've got there’. ‘There's a better algorithm for the approach that you're using or a more compressed way to write that loop’. Those have all been things that I hope many of us have experienced, either from a colleague, a friend, a mentor, something in a code review. But I don't know that I've ever gotten enough of that, so where IDEs are going is they're starting to take some of the best attributes of experiences that people rarely got, in either teams or pair programming, and you could almost say democratizing them and giving them to many more people than we're able to get those wonderful experiences in the past. And I think it's hard for me not to smile about this because it's so energizing and exciting. It's nice to have a job where you're this excited about it. It's the things that I always thought were best about software development. There's a little bit of a dream in me that many more people are going to get some of the best things that I've been able to experience.
RD All right, well, the future's mentorship, I hope.
MM I hope so.
RD Well, thank you for listening ladies and gentlemen. We have come to the end of the show where we shout out somebody who came on to Stack Overflow, shared some curiosity, dropped a little knowledge, and earned a badge. Today we're shouting out a populous badge, somebody who dropped an answer that outscored the accepted answer. Today's badge goes to Trudeau Excel for answering Android apps stuck at launching on devices or device ID not found error. If you are curious about that, we have the answer. I am Ryan Donovan. I edit the blog, host the podcast here at Stack Overflow. If you like what you heard or have suggestions for topics and guests, email me at podcast@stackoverflow.com. And if you wanna reach out to me directly, you can find me on LinkedIn.
MM Ryan, thanks for having me. I got to talk about the thing that I care most about, which is Android development with somebody who cares as equally as much about it. And I hope that you know, with this we'll share some of the same excitement with all your listeners and we'll see even more amazing Android apps as a result.
RD All right, ending on hope. Thank you very much for listening, and we'll talk to you next time.