Podcast appearances and mentions of aja hammerly

Aja Hammerly, director of developer relations at Google, sees AI as the always-available coding partner developers have long wished for—especially in those late-night bursts of inspiration. In a conversation with Alex Williams at Google Cloud Next, she described AI-assisted coding as akin to having a virtual pair programmer who can fill in gaps and offer real-time support. Hammerly urges developers to start their AI journey with tools that assist in code writing and explanation before moving into more complex AI agents. She distinguishes two types of DevEx AI: using AI to build apps and using it to eliminate developer toil. For Hammerly, this includes letting AI handle frontend work while she focuses on backend logic. The newly launched Firebase Studio exemplifies this dual approach, offering an AI-enhanced IDE with flexible tools like prototyping, code completion, and automation. Her advice? Developers should explore how AI fits into their unique workflow—because development, at its core, is deeply personal and individual.Learn more from The New Stack about the latest AI insights with Google Cloud:Google AI Coding Tool Now Free, With 90x Copilot's OutputGemini 2.5 Pro: Google's Coding Genius Gets an UpgradeQ&A: How Google Itself Uses Its Gemini Large Language ModelJoin our community of newsletter subscribers to stay on top of the news and at the top of your game. 

Aja Hammerly, Developer Relations Manager at Google Cloud, joins Corey on Screaming in the Cloud to discuss her unexpected career journey at Google and what she's learned about improving the developer experience throughout her career. Aja and Corey discuss the importance of not only creating tools for developers that are intuitive and easy to adopt, but also cater to different learning styles. Aja describes why it's so important to respond with curiosity when a user does something seemingly random within a piece of software, and also reveals why she feels so strongly about the principle of least surprise when it comes to the developer experience. About AjaAja lives in Seattle where's she's a Developer Relations Manager at Google. She's currently excited about developer experience, software supply chain security, and becoming a better manager and mentor. In her free time she enjoys skiing, kayaking, cooking, knitting, and spending long hours in the garden.Links Referenced: Google Cloud: http://cloud.google.com/developers Personal Website: https://www.thagomizer.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn and I am joined today by Aja Hammerly, who's a Developer Relations Manager over at a small company called Google Cloud. Aja, thank you for joining me.Aja: Thank you for having me. I've been looking forward to this for quite a while.Corey: You have been at Google for, well, let's call it eons because that's more or less how it feels when you're coming from my position of being great at getting yourself fired from various companies as a core skill. How long have you been there now? And what is your trajectory been like over that time?Aja: So, I've been in there a little over eight years. And the funny part of that is that it was intended to be a two-year gig for me. I moved from consulting developer working on, you know, building out websites for other people to Google's like, “Hey, you want to do this advocacy [unintelligible 00:01:19] relations thing?” And I'm like, “Sure.” And at the time, I'm like, there's no way I'm going to last more than two, three years in this. I hadn't really held the job much longer than that.Turns out, I like it. And then they're like, “Hey, do you want to manage people doing this job?” And I'm like, “That sounds like fun. Let's try that.” And it turns out, I like that just as much if not more. Because I haven't picked a major in tech yet and so managing people doing a bunch of different things is a fantastic way for me to keep my squirrel brain engaged in all the different topics and, you know, always bouncing around. So, it's been great. Cloud's been—well, I started, Cloud was very, very, very small back in 2014 compared to what it is now. Google Cloud is way bigger.Corey: Google Cloud, if you take a look at its entire portfolio, I'm probably one of the only people in the world who looks at it and says, “Yeah, that seems like a reasonably small number of services,” just because I eat, sleep, and breathe in the firehose of AWS announcing every feature as a service. But let's be clear here, Google Cloud is fairly broad in terms of what it does and what it offers. Where do you start and where do you stop? Because increasingly, the idea of, “Oh, I am responsible for talking about everything that Google Cloud does,” is a—it's clearly a fantasy.Aja: Yeah. No, there's too much for any one person to be an expert on. I could give you a list of products, but that's not interesting, quite frankly, because I would prefer that people don't think about it as a set of products. Because—Corey: Why is this such a rare perspective to have? It drives me nuts whenever I go to a cloud conference, and okay, here's the database track, and here's the container track, and here's the storage track. It doesn't matter if I'm building Hello World, let alone anything more complicated. I have to think about all of it.Aja: Yeah. So, I don't know why it's a rare perspective, but at least within my—the folks that I look up to, the folks that I consider mentors internally, we tend to think more about audiences or problems. And the problem that I care the most about—I cared about this well before Google, and Google just pays me to care about it, which is awesome—I care about developers. I one hundred percent want to help people build cool stuff, ideally efficiently, as quickly as possible.I worked at a startup and as part of that experience, I learned that sometimes you just need to get something out quick. I wanted tools that would let me do that. When I worked in consulting, the whole gig was to get something out quick that folks could look at, folks could touch, then we could do feedback, we could iterate, we could come back. And so, I want to make developers successful and I want to get out of their way. And I've always liked tools like that as a developer; I don't want to have to read your 10,000-page manual in order to learn your product.So, when I come to Google Cloud, I'm focused on the products that help developers build stuff quickly. And by developers, I mean, developers. I mean, the people who are hands-on-keyboard with Python, with Go, with Java, building it out features for their employer or, you know—Corey: What about really crappy bash? Does that count?Aja: Sure. If you're going to build some sort of application, a really crappy bash. Awesome.Corey: You'd be surprised. My primary development stack usually is a combination of brute force and enthusiasm.Aja: Yeah. Honestly, there are days that I feel that way, too. And I was working on some demo stuff over the weekend and I'm like, “Well, I could sit down and actually read this code or I could just run it, fix the first bug, and then run it again and fix the next bug. Yeah, let's do it that way.” Brute force is fine.Corey: I think the iterative development.Aja: Yeah, iterative development and/or brute force. Whatever. It works. And, you know, if people want to build cool stuff, cool. Let's help them do that. That's what I get to do every day is figure out how I can make it easier for developers to build cool stuff.Corey: The thing that keeps confusing me, for lack of a better term, is that I see a bunch of companies talking in similar directions of, “Yeah, we want to talk to developers and we want to meet them across the stack about the problems they're having.” “Great, so what's your answer?” And then they immediately devolve it into industry verticals. As if the finance company is going to have problems that the healthcare company could never fathom happening. It's, you get that you to look an awful lot alike, right, and things that work for one of you are going to map them at least 80, if not 90 percent of what the other is doing? But nope, nope, completely separate audiences; completely separate approaches. And I find myself increasingly skeptical about that model.Aja: Yes. I think—I see that too. I have sometimes behave that way. And I think it's because… it's a combination of factors. One is people want to believe that their problems are unique and special. I've worked in edtech, I've worked on real estate stuff, I've worked in… a lot of different fields. As I said, haven't picked a major over my career.I've done a lot of different jobs, worked on a lot of different fields. I have passing knowledge of the electrical industry from an early, early job. And yeah, it's all code. At the end of the day, it's all code. But people like to believe that their problems are unique and special because they want to be unique and special. And cool. People can be unique and special. I am there to support that.I also think that different altitudes see the problems differently. So, if you're someone fairly high up and you're at a healthcare company versus a finance company, you're going to be thinking about things like your different regulatory requirements, your different security requirements. And some of those are going to be imposed by you by law, some of those are going to be imposed by you by your company policies, ethics, I would hope. But if you're the actual developer, I need to store some stuff in a database. Like, down at the lower level where you're actually writing code, getting your hands on keyboard, getting dirty, the problems all start looking roughly the same after a while.And so, you need different people to tell those stories to the different audiences because the higher level folks thinking about regulatory requirements or thinking about efficiencies, they're going to just have a different perspective than the folks I like to go chat with who are the ones banging out features.Corey: I'll take it one step further. Whenever I'm building something and I'm Googling around and talking to people in the community about how to do a certain thing and everyone looks at me like I've lost it, that is a great early warning sign that maybe I'm not doing something the right way. Now, yes, the ultimate product that I'm developing at the end of the day, maybe that's going to be different and differentiated—or at least funnier in my case—but the idea of, well, then I need to write that value back to a database, and people look at me like, “Writing data to a database? Why would you do such a thing?” Like, that's an indication that I might be somewhat misaligned somewhere.The other failure mode, of course, is when you start Googling around—because that's what we do when we're trying to figure out how to do something with a given service—and the only people ever talking about that service are the company who has built that thing. That's also not a great sign. There, at least for my purposes, needs to be a critical mass of community around a particular product where I can at least be somewhat reassured that I'm not going to be out twisting in the wind as the only customer of this thing.Aja: Yeah. No, a hundred percent agree as someone who's, in past lives, evaluated, you know, which APIs, which products, which companies we're going to work with. Having really great developer docs, having really great materials was always important. And I don't tend to read docs, so when I say materials, I like stuff that's interactive because I'm just going to dive in and fix the issues later. That's just how my brain works.But you know, people are different. Everyone has different learning preferences. But if there is a community, that means that you have lots of ways to get help. And you know, super concretely, I'm not a Kubernetes expert, I did some talks on it back in 2015 when it was brand new and shiny, I can use it and understand it, but I'm not an expert. I have other people on my team who have had the time to go deep.When I need help with Kubernetes, even though I work at Google, I've actually gone to my local community. I go to my local DevOps Slack, or I go to my local Kubernetes groups and stuff to get help. And I like that because it gives me all those different perspectives. I also know that if I'm asking you a question that no one understands—and I've had that experience [laugh] numerous times—either I'm doing something wrong, or the actual thing that I found more often is I'm explaining it in words that people don't understand. And that's always a challenge is figuring out the right words to go search for, the right phrasing of something so that everyone else understands the terms you're using. And that's a huge challenge, especially for folks that don't speak English as their primary language or their first language. Because we have lots of different ways to say the same thing, especially when it comes to code.Corey: I've noticed that. There are almost too many ways to do certain things, and they're all terrible and different ways, let's be clear. But that does mean that whenever I'm trying to find something that's 90% done on GitHub or whatnot, I will often find something that fits pretty well, and it's, “Well, I guess I'm learning TypeScript today because that's”—Aja: Yep.Corey: —“What it's written in,” versus building it in the language I have a bit more familiarity with, like, you know, crappy bash.Aja: Yep. Nope, I think that's a problem that anyone who's been developing on a deadline or, you know, spending a lot of time doing proof-of-concept stuff is super familiar with. And I think sometimes folks who haven't worked in those environments, at least not recently, forget that that's our reality. Like, “Cool. Okay, I guess today I'm learning Elastic,” was definitely a day I had when I was consulting. Or, “Cool. Okay. Swift is new”—because that's how long ago that was—“I guess we're all learning swift this afternoon.”Corey: I've been banging on for a fair bit now about the value of developer experience from my point of view. But given that you work with developers all the time, I'm betting a you have a more evolved position on it than I do, which distills down to, the better the developer experience, the happier I am, which is generally not something you can measure super effectively. Where do you stand on the topic?Aja: So, this is one of my passion points. I feel very strongly that tools should fit the workflows that developers have; developers shouldn't alter themselves to work toward their tools. I also think there's kind of a misunderstanding of the nature of developer experience that I've seen, especially from some of… a lot of different companies. Developer experience is not actually tools. Developer experience is the experience you as a developer have while using those tools.So, APIs: I like things that don't have surprises; I like things to get out of my way. I know that we joke about there being 9000 ways to run containers, or you know, five different ways to do this other thing, but you know, if that means it's faster to get something done, and you know, most of those are equally bad or equally good, I'm okay with it because it gets out of my way, and lets me ship the thing I want to ship. I enjoy coding; I think computers are rad, but what I enjoy more is having something finished that I can show to other people, that I can use, that I can make better. So, some of the things I feel super strongly about with developer experience is principle of least surprise. I was a Rubyist for years and years and years.Haven't written a lot of Ruby the last two, three years—management, I'll do that to you—but… I loved that once you understood some of the underlying concepts behind Ruby, stuff generally worked the way you expected. I know a lot of people find the very nature of Ruby surprising, but for those of us who learned it, stuff generally worked the way I expected. So, I like it when APIs do that. I like it when it's super easy to guess. Consistent naming schemes, you know?If you're going to call… you're going to call the way to list a set of services ‘list' in one place, don't call it ‘directory' in another. Keep things consistent. I like it when APIs and the cloud companies all—I've had many thoughts about all of the big cloud companies in this—when their APIs that they provide a fit the language. If you're making me write TypeScript like C because your APIs are really just designed by C programmers and you've loosely skinned them, that's not a great experience, that's not going to make me happy, it's going to slow me down. And quite frankly, my tools should speed me up, not slow me down. And that's kind of the underlying theme behind all of my feelings about developer experience is, I don't want to be angry when I'm writing code unless I'm angry at myself because I can't stop writing bugs.Corey: I don't really want to bias for that one either, personally.Aja: Yeah. And then the other one is, I don't want my tools to be something that I have to learn as a thing. I don't want there to have to be a multi-week experience of learning this particular API. Because that is interesting, potentially, but I'm not being paid to learn an API, I'm being paid to get something done. So, all of the learning of the API needs to be in service of getting something done, so it should go as quickly as possible. Stuff should just work the way I expect it.We're never going to do that. This I acknowledge. No company is ever going to get that right no matter where I work because turns out, everyone's brains are different. We all have different expectations. But we can get closer. We can talk to folks, we can do UX studies. Everyone thinks about UI and UX and design is very much focused on the visual.And one of the things I've learned since I've had the opportunity to hang out with some really amazing UX folks at Google—because big companies have advantages like that, you have lots of people doing UX—is that they can actually help us with our command line interfaces, they can help us with how we name things in an API, they can do studies on that and turn, you know, “It feels good,” into numbers. And that is fascinating to me and I think something that a lot of developers who are building tools for other developers don't realize is actually up there as an option.I spend a lot of time reading UX studies on developer experience. Managers working at big companies, you get to have access to data like that going back years. And I've spent a lot of time reading about this because I want to understand how we turn, “Feels good,” into something that we can develop against, that we can design against, and we can measure.Corey: One of the things that I've always viewed as something of a… a smell or a sign that ‘Here Be Dragons' are when I'm looking for a tool to solve a problem and there's a vendor in the space, great, awesome, terrific. Someone has devoted a lot of energy and effort to it. I want the problem solved; I don't necessarily need to do it for free or cheap. But I'm looking through their website and they talk about how awesome their training programs are and here's how you can sign up for a four-day course, and et cetera, et cetera, et cetera. That feels to me like in most cases, someone has bungled the interface. If I need to spend weeks on end learning how a particular tool works in order to be effective with it, on some level, you reach a point, fairly quickly for anything small, where the cure is worse than the disease.Aja: Yep. This is an interesting thing for me because I, my personal feelings are very similar to yours. I don't want to take a class. Like, if I have to take a class, we have failed. I don't really want to read extensive documentation.I want to get in, get dirty, try it, see, you know, watch the errors, come back and learn from the errors, that kind of thing. If there's code to read and it's a language, I know, I will actually often go read code as opposed to reading docs, which… is weird. The interesting thing to me is that, as I've managed folks, as I've, you know, spent time working with customers, working with folks who I, you know, think would benefit from some of Google Cloud's products, there are some folks who really, really want that formal training, they want that multi-day course before they dig in. And so, while in the past, I definitely would have agreed with you, if it's the only thing, maybe, but if it's one of many different ways to get started, I just keep telling myself, “Hey, that's how someone else needs to learn this.” Isn't my preference, but my preference isn't necessarily better.It's just, this is the brain I got and the tools that came with it. And it doesn't do well for four days in a classroom learning all of the intricacies of this because I need to learn this stuff in context, otherwise, it doesn't stick. Whereas I have people that work for me, I've had people who I've worked with who are like, “No, I actually need to go read the book.” And I'm like, “Let's make sure that there's both a book.”Corey: Everyone learns differently.Aja: Yeah. I just constantly reminding myself, both as a manager and also as someone who works in developer relations, all of the above is the correct option for how are we going to teach this? How are we going to help people? We really need to offer as much as possible all of the above because we need to be able to reach everyone in a way that works for them.Corey: It's the height of hubris to believe that everyone thinks, processes, learns, et cetera, the same way that you do. This is a weird confession for someone who hosts a podcast. I don't learn very well by listening to podcasts. I find that when I'm trying to absorb something if I can read it, it sticks with me in a way that listening to something or even watching a video doesn't.Aja: Yeah, and I'm actually very much the opposite. I take most of my information and learn best through hearing things. So, while I don't particularly like watching video, relatively often, I'll actually have video if I'm just doing like email or something running in the background and I'm listening to the audio as I'm learning the concepts. I adore learning stuff from podcasts, I love audiobooks, but I don't retain stuff as well when I read it. And it's just because, you know, human beings are interesting and weird and not consistent, in all sorts of delightful and confusing ways.Which, you know, as an engineer sometimes drives me nuts because I really wish there was one right way to do stuff that worked for everyone, but there just isn't. There are all sorts of interesting problems. And just like there are multiple valid ways to solve problems, there are multiple valid ways to learn, and we have to support all of them. And we have to support engineers with all of those styles too. People often will say, “Oh, sure. There's lots of learning, different learning styles, but you know, most engineers are like X.” No. There is no ‘most engineers.'Corey: Early on in my career, one of the things I noticed—in myself as well, let's be clear here, I was no saint—that, oh, if people don't learn the way that I learned, then clearly they're deficient in some way. Of course that's not true. Everyone learns differently. And that, among other things, was part of the reason that I stopped being as dismissive as I was about certifications, for example, or signing up for a planned classroom experience. There is tremendous value to folks who learn well from that type of structured learning.I am just barely contained chaos. And for whatever reason, that doesn't resonate with me in the same way. If anything, I'm the one that's broken. The trick is, is making sure that when you're trying to drive adoption, no matter what method people learn best from, you need to be there with something that approximates that. One area that I think resonates with something you said earlier is this idea that the best way for me to learn something, at least is to sit down and build something with it. Bar none, that's what I actually want to experience. And that is only slightly informed by the unfortunate reality that I've been through too many cycles of an exec in a keynote getting on stage and making grandiose promises that the service does not backup.Aja: Yep. And I actually do have a bias here that I will own. I don't believe in anything until I can touch it. And by ‘touch it,' I mean, use it. And that also includes I don't believe in my own learning or the learning of others until I can see it practically applied.And so, even when I have folks on my team who are like, “Hey, I want to go read a book, take a class,” I'm like, “Cool. What else are you going to do with that? How are you going to know that you can actually take what you learned and apply it to a novel situation?” And this has been based on mentors I had early in my career who I'm like, “Hey, I just read this book.” And they're like, “That's awesome. Can you write anything with what you learned?”And I'm like, “Yes. Let me do that and prove it to myself.” So, I do have a bias there. I also have a bias, having worked in the industry for 20-plus years now, that a lot of people say a lot of things that are either theoretically true or true through, you know, a happy path lens. And I started my career as a tester and compu—I always joke computers run in fear of me because if there's a way to cause something to error out in a confusing and unknown way, I will find it. I will find it on accident. And when I can't find it on accident, I will find it on purpose.So, that's the other reason I don't believe stuff until I touch it. It doesn't matter if it's at a keynote, doesn't matter if it's a blog post, I want to know that this works beyond that happy case that you just showed me. And part of this is also that I've built some of those keynote demos and I know that they're explicitly designed so that we can fit in the timeframe allowed to avoid any possible dragons that might be lurking in the background. So, I always go get dirty with things, new products, new features. It's one of the things I actually love about my job is I get to try stuff before anyone else does.And I'm like, “Hey, so, um… I did this thing. You probably didn't expect anyone to do this thing, but I did this thing. Can we talk about whether this thing that I did is actually a valid use case? Because it made sense to me, but you know, I might have been thinking about this backwards, upside down, in purple, so let's back the truck up and have a discussion.”Corey: Yeah, I get to moonlight occasionally as something that looks vaguely like an analyst at a variety of different companies. And as a part of that, I'm often kicking the tires on something that they're going to be releasing soon. And a very common failure mode is that, for obvious reasons, no one has ever really looked at this thing from the perspective of I've never seen this before or heard of this before. Let me approach this as someone who's learning about it for the first time. The documentation is always treated as an afterthought at those stages where it's, “Oh yeah, just spin it up and do it. And you do the thing that we all know about, right?” “Well, okay, assume I don't have that shared understanding. What's the experience?” And, “Oh.” Yeah, if I'm not on the path of a few pre-planned test cases, then everything falls off pretty quickly. I think I share that somewhat special ability to cause chaos and destruction to all about me [laugh] when I start trying to do something in good faith on the computer.Aja: Yeah. No, it's both a blessing and a curse. It's really annoying when like, I managed to brick my work laptop on the morning that I have, you know, a super important talk and I call up, you know, internal tech support at Google and they're like, “You did what, and how?” But it's also great because I know that… I know that I get to—because I started my career in tests working at other companies, I've always done some informal testing no matter where I've worked, everything I find we at least know about, even if we don't have time to fix it. We at least know about it, so if someone else runs into it, we can at least help them untangle whatever crazy stuff they did.And I'm also just not afraid of breaking computers either, which means that I'm very willing to go off happy paths. If I see a tutorial that's close, you know, if all of the steps that work, and I'll guess on the others. And that's a thing that I don't actually see a ton of folks being always willing to do because they're afraid of breaking it. And I'm like, “It's software.”Corey: And a lot of products are designed though, that once you deviate from the happy path, well, now you've broken it and you get to keep all the pieces. There's little attention paid towards, okay, now you've done something else and you're bringing something back into the happy path. It feels like if you haven't been here for every step of the way, well, your problem now. I have work to do. Go away kids, you're bothering me.Aja: Yeah, I've seen that. And I've seen that open-source frameworks, too, when people—when I talk about, you know, deviating from the happy path—and this will date me—using multiple databases with Rails was one of the ones that I ran into numerous times. Just was not designed for that in the beginning. Did not work. There was also some easy security stuff, ages and ages ago, that you often wanted to do, but was not at that point integrated into the framework, so it was clunky.And so, anyone would come to, like, a Ruby meetup or something like, “Hey, I want to use three databases with my Rails application,” we'd be like, “So, you can… but you may not actually want to do it that way. Can we interest you in some microservices so that you can go one-to-one?” And that wasn't always the right choice. I worked on an app for years that had multiple databases in Rails, one was a data warehouse, one was our production database. And it was clunky.And eventually, you know, the Rails community got better. Eventually, people do improve, but people are weird. They do weird things. Like, and I don't think people truly understand that. One of my jobs at various points was I was working in education tech and I was working on an application for kindergarteners.And I don't have kids, but I think kindergarteners are just [unintelligible 00:24:44]. And until you see five-year-olds use software, I don't think people get a true appreciation for how random human beings can actually be when given a textbox or when given a mouse. And, like, we like to think that, you know, engineers and adults are better. We're not. We just, you know, have a different set of five-year-old tools available to us.So, we do have to at least acknowledge that people are going to go do weird stuff. And some of that weird stuff probably makes sense in the context they're living in, and so, the best step is not to say, “Hey, stop doing weird stuff.” The best thing to then say is, “Okay, why did you do it that way?” Because everyone has good reasons for the decisions they make most of the time. And understanding those is important.Corey: Yeah. It's very rare—not entirely unheard of, but at least rare—that when someone shows up and says, “Okay, I'm making a bunch of choices today. What are the worst ones I can possibly make that I'm going to be tripping over for the next five years and leave is my eternal legacy to every engineer who ever works at this company after I do?” But it happens all the time, for better or worse.Aja: Yeah.Corey: Never intentional, but it always hits us.Aja: Yeah. Well, one of the things that I learned in the last-ten ish years, and one of the things that I tried to bring to all of my developer relations, all my developer education work, is, “It made sense at the time.” Now, it may have been that they made a assumption six years ago, that led them down the path of chaos and sadness and now that they're deep into this, they're going to have to back up to that decision six years ago and undo it. But based on the knowledge they had, the assumptions they were making—which may or may not have been true, but you know, were likely made in good faith—they're doing their best. And even when that's not true, I haven't found a situation where, assuming that with regards to technical decisions is harmful.Assume that people are relatively intelligent. They may not have the time to go learn all of your tools, the intricacies and use things exactly the way that you want them to be used because time is a limited resource, but assume that they're relatively intelligent and they're doing their best. And then try to understand why. What assumptions, what skills, what previous knowledge led them down this crazy path? And you know, then you can start having a conversation about okay, well, what should the tools do? How should the tools work together? Just because I wouldn't make that decision doesn't mean that their version of it is necessarily bad. It may not be the most efficient way to get stuff done, but if it works, eh, okay.Corey: So, as we wind up coming towards the end of this episode, one thing that I want to explore a little bit is, you've been with Google Cloud for eight years now. How have you seen the organization evolve during that time? Because from my perspective, back then it was oh, “Google has a cloud? Yeah, I guess they do.” It's a very different story, but all of my perspective is external. How have you seen it?Aja: Oh, that's an interesting question. And I'll caveat that appropriately with I only see the parts I see. One of the hard parts of big companies is, I don't actually dig in on some of the areas particularly deeply. I don't go deep on data analytics, I don't go deep on AI/ML. And I will also [laugh] own the fact that when I started, I'm like, “Oh, Google has a cloud? Huh. Okay, yeah, sure, I'll work on that.”I didn't even know the list of products my first day. I knew about App Engine and I knew that it didn't work with my preferred languages so I had a sad. Some of the things that I've seen. I've seen a real focus on how we can help people with real big problems. I've seen a real focus on listening to customers that I really like.I've learned a lot of techniques that we've been shared out, things like empathy sessions, friction logging. If you're not with the community of developer relations about how we make sure that, as an engineering team, we're thinking about real customer problems. I've seen a lot of maturing thoughts around how we maintain products; how we make sure that we've got updates where we need them, as much as we can; how we talk about our products; how we listen to customers and take, you know, direct feature requests from them.The other big thing is, I've just seen us grow. And that's the big thing is that there's just so many more people than when I started. And I've never worked at a company this big before and just getting my head around the number of people who are actively trying to make cloud better, and spending every day doing their best to improve the products, to add the features that are missing, to make sure that we're keeping stuff up to date where we can, it's kind of mind-boggling. Like, when I go look at the org chart, I'm like, “Wait, there are how many people working on what?” And that in and of itself is a story because that, to me at least shows that we care about getting it right. Google cares about getting it right.I'm not Google, of course, but I feel like from the inside, I can say that Google cares about getting it right as much as we can. And you know, sometimes it's not a hundred percent what people want, which is why we iterate. But we've also had a couple of things that I'm particularly happy with Cloud Run, I think landed pretty well.Corey: I'd say that I would agree with what you're saying. I've had nothing but positive experiences when I've been building admittedly very small-scale shitposting-style stuff on top of Google Cloud. There have been times where the biggest criticism I have is, “It's not the particular flavor of broken that I'm used to coming from AWS-land.” But that's hardly a fair criticism. I think that by and large, it is a superior platform coming from the perspective of developer experience.And people don't like it when I say that and they often like it even less when I say, “And thus, it has better security than something that does not have better user experience because simplicity is everything in that space.” But it's true. It is foundationally and fundamentally true.Aja: I agree with you. Obviously, it's my employer. But I do think you actually were onto something interesting with, “My particular flavor of broken.” I've talked to a lot of folks who are migrating and sometimes they struggle because there are particular magic incantations or other things that they learn to work with a different tool. It's the same thing is when you're learning a new language, a new programming language, or a new framework. You're like, “Wait, I don't have to do this thing. But I'm really good at doing that thing.”And so, I do think there is to some degree, everything—nothing's perfect and it happens to be, you know, it's hard for some folks. And I think some folks resist the better developer experience because it isn't what they're used to. And that's okay, too. Like, if I was a developer, I wouldn't want to have to relearn everything from scratch, so I get that and I think that that is a valid piece of feedback.[unintelligible 00:31:22] it make it familiar to folks working from other clouds, we're working on it. There's stuff coming out of DevRel. There's other things that we do to try to make it easier. But no, I do think, and I'm very grateful I get to work with a lot of teams to do this, we want to make developers like working with Google Cloud. I want to make developers like working with Google Cloud.Like, at the end of the day, if I had to say the most important thing for me is I want to make developers enjoy their time using Google Cloud to get other stuff done. I don't need to live in a world of people who are like, “You know, I really just want to go spend some time on Google Cloud today,” but I want it to be something that they enjoy using or at least gets out of their way, out their way to doing the stuff that they actually want to do: you know, add features, build shitposting websites, whatever it ends up being.Corey: As someone who does an awful lot of that, thanks. It's appreciated. I really want to thank you for spending so much time talking to me. If people want to learn more, where's the best place to find you?Aja: Oh. That's the best place to find me right now is www.thagomizer.com. Thagomizer is the spiky part of the end—at the end—Corey: Of a Stegosaurus.Aja: —of a Stegosaurus.Corey: Yes.Aja: It is. That is my website and it has my most recent social, et cetera on it. That's also where I theoretically blog, although it's been about a year. I've got, as I said, as I mentioned before the show, I've got several blog posts three-quarters of the way done that I'm going to hopefully try to get out over the next couple of weeks… on various topics.Corey: I have a pile of those myself, that for some reason, it never quite ends up happening when you hope it will.Aja: Yeah, exactly.Corey: And we'll, of course, put links to all of that in the [show notes 00:32:47]. Thank you so much for being so generous with explaining your point of view I appreciate it.Aja: Yeah. And thank you for having me. This was lovely.Corey: Likewise. Aja Hammerly, Developer Relations Manager at Google Cloud. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me exactly which four-week course I need to sign up for to understand that comment.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

While DevRel holds some universal truths, there is at times a difference between how we handle our external communities as opposed to our internal communities. While we are still bringing people together, some of the approaches and interested parties may change. How do we foster communities and communicate feedback within an organization? Is it so different from “traditional” DevRel?   To find out more, Wesley and PJ sit down with Aja Hammerly, Davey Shafik,  and Kevin McIntosh to talk about the ins and outs of both sides.

While DevRel holds some universal truths, there is at times a difference between how we handle our external communities as opposed to our internal communities. While we are still bringing people together, some of the approaches and interested parties may change. How do we foster communities and communicate feedback within an organization? Is it so different from “traditional” DevRel?   To find out more, Wesley and PJ sit down with Aja Hammerly, Davey Shafik,  and Kevin McIntosh to talk about the ins and outs of both sides.

Aja Hammerly and Brian Dorsey are here this week to start off a new year of podcasts! In an interview with Google Developer Advocate Katie McLaughlin, we talk about the advantages of Python 3 and why version 2 has been retired, as well as the cool things you can do with Django. Later, Katie discusses the complexities of deployment and how she makes it work smoothly with GCP, and we have some fun with emojis! Katie McLaughlin Katie has worn many different hats over the years. She is currently a Developer Advocate at Google Cloud, and a Director of the Python Software Foundation. When she’s not changing the world, she enjoys making tapestries, cooking, and seeing just how well various application stacks handle emoji. Cool things of the week Running workloads on dedicated hardware just got better blog Container security summit is going on as we record this site Easily upgrade Windows Server 2008 R2 while migrating to Google Cloud blog Launch of the BigQuery Weekly Data Challenge! site New data engineering learning path site Interview Python Software Foundation site PyCascades site Django Demo site Emojipedia site App Engine site Compute Engine site Cloud Run site Cloud Build site Secrets Manager site Kakapo Mountain Parrot site The Power ⚡️ and Responsibility 😓 of Unicode Adoption ✨ video Question of the week I need to run something later, but Cron isn’t a good fit. What do I do? Where can you find us next? We’ll be at Cloud Next in San Francisco in April! Katie will also be at PyCon US in April! Sound Effects Attribution “African Gray” by Jmagiera of Freesound.org

Our guests Matthew Tamsett and Ravi Upreti join Gabi Ferrara and Aja Hammerly to talk about data science and their project, Qubit. Qubit helps web companies by measuring different user experiences, analyzing that information, and using it to improve the website. They also use the collected data along with ML to predict things, such as which products users will prefer, in order to provide a customized website experience. Matthew talks a little about his time at CERN and his transition from working in academia to industry. It’s actually fairly common for physicists to branch out into data science and high performance computing, Matthew explains. Later, Ravi and Matthew talk GCP shop with us, explaining how they moved Qubit to GCP and why. Using PubSub, BigQuery, and BigQuery ML, they can provide their customers with real-time solutions, which allows for more reactive personalization. Data can be analyzed and updates can be created and pushed much faster with GCP. Autoscaling and cloud management services provided by GCP have given the data scientists at Qubit back their sleep! Matthew Tamsett Matthew was trained in experimental particle physics at Royal Holloway University of London, and did his Ph.D. on the use of leptonic triggers for the detection of super symmetric signals at the ATLAS detector at CERN. Following this, he completed three post doctoral positions at CERN and on the neutrino experiment NOvA at Louisiana Tech University, Brookhaven National Laboratory, New York, and the University of Sussex UK, culminating in a EU Marie Curie fellowship. During this time, Matt co-authored many papers including playing a minor part in the discovery of the Higgs Boson. Since leaving academia in 2016, he’s worked at Qubit as a data scientist and later as lead data scientist where he lead a team working to improve the online shopping experience via the use of personalization, statistics and predictive modeling. Ravi Upreti Ravi has been working with Qubit for almost 4 years now and leads the platform engineering team there. He learned distributed computing, parallel algorithms and extreme computing at Edinburgh University. His four year stint at Ocado helped developed a strong domain knowledge for e-commerce, along with deep technical knowledge. Now it has all come together, as he gets to apply all these learnings to Qubit, at scale. Cool things of the week A developer goes to a DevOps conference blog Cloud Build brings advanced CI/CD capabilities to GitHub blog Cloud Build called out in Forrester Wave twitter 6 strategies for scaling your serverless applications blog Interview Qubit site Qubit Blog blog Pub/Sub site BigQuery site BigQuery ML site Cloud Datastore site Cloud Memorystore site Cloud Bigtable site Cloud SQL site Cloud AutoML site Goodbye Hadoop. Building a streaming data processing pipeline on Google Cloud blog Question of the week How do you deploy a Windows container on GKE? Where can you find us next? Gabi will be at the Google Cloud Summit in Sao Paulo, Brazil. Aja will be at Cloud Next London. Sound Effect Attribution “Small Group Laugh 6” by Tim.Kahn of Freesound.org

On the podcast this week, we have a great interview with Google Developer Advocate, Dale Markowitz. Aja Hammerly and Jon Foust are your hosts, as we talk about machine learning, its best use cases, and how developers can break into machine learning and data science. Dale talks about natural language processing as well, explaining that it’s basically the intersection of machine learning and text processing. It can be used for anything from aggregating and sorting Twitter posts about your company to sentiment analysis. For developers looking to enter the machine learning space, Dale suggests starting with non life-threatening applications, such as labeling pictures. Next, consider the possible mistakes the application can make ahead of time to help mitigate issues. To help prevent the introduction of bias into the model, Dale suggests introducing it to as many different types of project-appropriate data sets as possible. It’s also important to continually monitor your model. Later in the show, we talk Google shop, learning about all the new features in Google Translate and AutoML. Dale Markowitz Dale Markowitz is an Applied AI Engineer and Developer Advocate for ML on Google Cloud. Before that she was a software engineer in Google Research and an engineer at the online dating site OkCupid. Cool things of the week Build a dev workflow with Cloud Code on a Pixelbook blog Feminism & Agile blog New homepage and improved collaboration features for AI Hub blog Interview TensorFlow site Natural Language API site AutoML Natural Language site Content Classification site Sentiment Analysis site Analyzing Entities site Translation API site AutoML Translate site Google Translate Glossary Documentation docs Google News Lab site AI Platform’s Data Labeling Service docs Question of the week How many different ways can you run a container on GCP? GKE Cloud Run App Engine Flexible Environmnet Compute Engine VM as a computer Where can you find us next? Dale will be at DevFest Minneapolis, DevFest Madison, and London NEXT. Jon will be at the internal Google Game Summit and visiting Montreal. Aja will be holding down the fort at home. Sound Effect Attribution “Mystery Peak2” by FoolBoyMedia of Freesound.org “Collect Point 00” by LittleRobotSoundFactory of Freesound.org “Cinematic Piano” by Ellary of Freesound.org

On the show today, we speak with Developer Advocate and fellow Googler, Sherol Chen about machine learning and AI. Jon Foust and Aja Hammerly learn about the history and impact of AI and ML on technology and gaming. What does it mean to be human? What can machines do better than humans, and what can humans do better than machines? These are the large questions that we aim to solve in order to understand and use AI. Sherol goes on to explain the types of deep learning machines can achieve, from neural networks to decision trees. Sherol also went into depth about the potential social impact of AI as it assists doctors parsing through medical records and plans agricultural endeavors to maximize food production and safety. Sherol also elaborates on the ethical responsibilities we must realize when developing AI projects. For developers looking to build a new AI project, Sherol outlines the pros and cons of using existing tools like Cloud Speech-to-Text, AutoML and AutoML Tables. Sherol Chen Sherol advocates for Machine Learning for Google Cloud, and works in Research at Google Brain for Machine Learning in Music and Creativity for the Magenta team. She’s taught Artificial Intelligence at Stanford and around the world in six different countries. Her PhD work is in Computer Science, researching storytelling and Artificial Intelligence at the Expressive Intelligence Studio. Cool things of the week AMD EPYC processors come to Google—and to Google Cloud blog Kaggle Petfinder Dataset site Streaming data from Cloud Storage into BigQuery using Cloud Functions blog App Engine Standard Ruby site Thagomizer blog Interview AutoML Tables site AutoML Tables Promo Video video Can Machines Think? article AI Impact Challenge site NeurIPS site ICLR site ICML site Machine Learning Crash Course site TensorFlow site Project Magenta site Cloud Speech-to-Text site Cloud AutoML site Sherol’s Blog blog Question of the week You mentioned that you can run App Engine + Rails, how do you handle migrations? Where can you find us next? Jon will be at PAX Dev and PAX West, the internal game summit at Google in Sunnyvale, and taking some personal time to travel to Montreal. Aja will be hanging around at home, on the internet, and at Seattle.rb. Sound Effect Attribution “Coins 1.wav” by ProjectsU012 of Freesound.org “Wedding Bells.wav” by Maurice_J_K of Freesound.org “Small Group Laugh.wav” by Tim.Kahn of Freesound.org

Welcome to day three of Next! More awesome interviews await in this episode, as hosts Mark Mirchandani, Aja Hammerly, Mark Mandel, Jon Foust and their guests explore more of Next. To start, Dan of Viacom joins Mark and Jon to talk about his job in the TV business and why he loves Istio. Host-turned-guest Aja and Lauren of the Developer Relations team sat in the booth to talk with the Marks about the developer keynote at Next. Aja and Lauren elaborate on how they work to promote Next and put together content inclusive of all aspects of Google Cloud. Mark and Mark hear how Yuri from Scotiabank is using Kubernetes to help advance Scotiabank’s latest projects. Anthony from Google joins the conversation, too. And lastly, we tease you with a short interview with Andrew of MongoDB to speak more on the partnership between MongoDB Atlas and Google Cloud. Andrew will be joining us for a full interview on the podcast later this year! Interviews Cloud Next site Next On Air site Google Cloud Next ‘19: Day 3 Run Channel video Google Cloud Next ‘19: Day 3 Build Channel video Google Cloud Next ‘19: Day 3 Collaborate Channel video Day 3 at Next ‘19: A look back at an amazing week blog Playlist: All Sessions - Google Cloud Next ‘19 videos Viacom site How Viacom modernized its Intelligent Content Discovery Platform with Google Cloud blog GKE site Anthos site Istio site Developer Keynote: Get to the Fun Part (Cloud Next ‘19) video Jenkins site Slack site Cloud Run site Announcing Cloud Run, the newest member of our serverless compute stack blog GCP Podcast Episode 167: World Pi Day with Emma Haruka Iwao podcast Dev Zone Walkthrough (Cloud Next ‘19) video Dev Zone Experiment Pizza Authenticator (Cloud Next ‘19) video Scotiabank site Kubernetes site Google Cloud Next ‘19: Day 2 Product Innovation Keynote (Justin Arbuckle at 25:23) video Securing Kubernetes Secrets (Cloud Next ‘19) video MongoDB site MongoDB Atlas site Where can you find us next? The GCP Podcast will be back to its regular schedule next week!

Why are manhole covers round? How many golf balls can fit in a 747? Why are job interviews so terrible? In this episode, Aja Hammerly, a developer advocate at Google, talks about the drawbacks of common tech interview techniques like whiteboard coding and trivia questions, and shares her tips for improving the process by making it about discovering the candidate's best qualities.

First-time host, Aja, joins Mark today to talk Go Cloud Functions with two Google colleagues! Stewart, lead Product Manager on Google Cloud Functions, and Tyler, Developer Programs Engineer at Google, start the show by explaining the purpose of Cloud Functions. It is a severless compute product that supports many programming languages, scales automatically, and only charges for what you use. It works best as event-driven computing, in other words, when something happens, you want something else to happen in response. Cloud Functions also works well between clouds or even Google Cloud services, acting as the glue between them. Go Cloud Functions works specifically for Go. Google makes a huge effort to make Cloud Functions easy to use for all developers, so that no matter what language you’re familiar with, Cloud Functions works for you. Stewart Reichling Stewart Reichling is the lead Product Manager on Google Cloud Functions. He is a graduate of Georgia Institute of Technology and has worked across Strategy, Marketing, and Product Management at Google. Tyler Bui-Palsulich Tyler is a Developer Programs Engineer at Google. He graduated with his Master’s in Computer Science from NYU and loves detailed documentation, random trivia, and homemade bread. You can find his blog at buipalsulich.com Cool things of the week Actually cool thing of the week twitter NoSQL for the serverless age: Announcing Cloud Firestore general availability and updates blog Site Reliability Workbook now available in HTML site Building a serverless online game: Cloud Hero on Google Cloud Platform blog The tech industry is failing people with disabilities and chronic illnesses article Interview GCP Podcast Episode 34: Stackdriver monitoring with Aja Hammerly podcast GCP Podcast Episode 53: Ruby with Aja Hammerly podcast Cloud Functions site Cloud Scheduler site Firestore site Pub/Sub site Go Mod site App Engine site Open Census site GCP Podcast Episode 118: OpenCensus with Morgan McLean and JBD podcast Google Stackdriver site Launch/overview video video The Go Runtime site Cloud Functions Quickstarts site Question of the week How many ways can you run containers on GCP? Where can you find us next? Mark will be at GDC in March, Cloud NEXT, and ECG in April. Agones has a new website agones.dev! And he’s also back to Twitch streaming! Aja will be at Cloud NEXT in April.

Have you ever wanted to know what powers BigQuery under the hood? Tino Tereshko and Jordan Tigani sit in front of the microphone with co-hosts Mark and Francesc to talk all about it! About Tino Tereshko Tino is the Big Data Lead for Office of the CTO at Google Cloud, focusing on building strategic relationships with the world's top Enterprises in the interest of sharing and accelerating technological innovation. Tino hails from the BigQuery team, where he solved difficult cloud-native product problems, enabled Googlers and customers, and built programs like BigQuery Pacific. In earlier years Tino held various positions of leadership in several Silicon Valley startups, and could be found working as a quant developer on the floor of the Chicago Board of Equities at a boutique market making firm. Tino holds a Bachelor's degree in Applied Mathematics and Economics from University of California - Davis. When not at work, you can usually find him playing beach volleyball, cycling, skiing, paddle boarding, or enjoying a nice glass of wine. About Jordan Tigani Jordan was one of the founding engineers on Google BigQuery, wrote the first book on the subject, and is now the engineering lead of the product. Before Google, he worked at a number of star-crossed startups, and also spent time at Microsoft in the Windows kernel team and MSR. Cool things of the week This week in Google Cloud Platform medium This week in Google Cloud — “Premium and Standard networking tiers, NYT Games on App Engine, Puppet for GCP, and a firewall for App Engine” blog Creating a GCP type provider in 6 (well 7) easy steps blog Aja Hammerly's Battleship blog series Interview BigQuery site docs BigQuery under the hood blog Dremel paper Borg and Kubernetes with John Wilkes podcast Question of the week I want to talk to to my phone like it's J.A.R.V.I.S. and make it do things. How can I build a bot to do this? Cloud Speech API site docs Cloud Natural Language Processing API site docs API.AI site docs Intents docs Go library github BigQuery Where can you find us next? Francesc will be presenting at Google Cloud Summit in Sydney and Google Cloud Summit in Chicago in September. In October, he'll be presenting at Velocity London, Google Cloud Summit Paris and Devfest Nantes Mark is speaking at Austin Game Conference and attending Strangeloop in September. He is also heading to Australia in October for GDG Devfest Melbourne and Game Connect Asia Pacific and will be hanging out at Unite Melbourne and PAX Australia.

Guest: Aja Hammerly @the_thagomizer Full show notes are at https://developeronfire.com/podcast/episode-255-aja-hammerly-fun-pink-dinosaur

Today Aja Hammerly, Developer Advocate and fellow teammate at Google Cloud Platform, joins your cohosts Francesc and Mark to tell us about all the cool things you can do with Ruby on Google Cloud. About Aja Hammerly Aja lives in Seattle where she is a Developer Advocate at Google and a member of the Seattle Ruby Brigade. Her favorite languages are Ruby and Prolog. She also loves working with large piles of data. In her free time she enjoys skiing, cooking, knitting, and long coding sessions on the beach. Cool thing of the week Announcing GPUs for Google Cloud Platform blog Google Cloud to join .NET Foundation Technical Steering Group blog Interview Ruby on Google Cloud Platform docs APIs & Ruby Libraries docs Google App Engine Ruby Flexible Environment Documentation docs Create a BigQuery table with Ruby: Cloud Minute YouTube Create a VM with Fog & Ruby: Cloud Minute YouTube Upload to Google Cloud Storage with Fog: Cloud Minute YouTube RubyConf 2016 home page Official Ruby logo by Yukihiro Matsumoto, Ruby Visual Identity Team Question of the week How can I add constraints on what hosts can run given pods? Constraining pods to run on particular nodes docs

Aja Hammerly, Developer Advocate for Google Cloud, discusses with your cohosts Francesc and Mark what monitoring is and how Stackdriver makes it easy on Google Cloud, other cloud providers, and even on premise. About Aja Aja lives in Seattle where she is a developer advocate at Google and a member of the Seattle Ruby Brigade. Her favorite languages are Ruby and Prolog. She also loves working with large piles of data. In her free time she enjoys skiing, cooking, knitting, and long coding sessions on the beach. Cool thing of the week Kubernetes moves onwards and upwards Kubernetes 1.3 on tap for Google Container Engine Scalable Microservices with Kubernetes - Udacity Interview Stackdriver Monitoring Documentation Stackdriver Introducing Google Stackdriver: unified monitoring and logging for GCP and AWS Using metrics Stackdriver pricing Uptime checks Six things Stackdriver brings to the DevOps table Question of the week How to keep data in sync while limiting bandwidth? gsutil rsync

There's so much talk about containers as it's clearly the buzzword today. Rather than doing a deep dive into container tech, Scott talks to Aja Hammerly about what containers really means to us as developers. How do containers change our workflow? Is the promise of cloud portability real?

Aja Hammerly talks to the Rogues about distilling data into a graphical representation that communicates the meaning and message of your data.

Aja Hammerly talks to the Rogues about distilling data into a graphical representation that communicates the meaning and message of your data.

Aja Hammerly talks to the Rogues about distilling data into a graphical representation that communicates the meaning and message of your data.