Screaming in the Cloud - Improving the Developer Experience with Aja Hammerly

Episode Date: April 6, 2023

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/developersPersonal Website: https://www.thagomizer.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief 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. 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. Thank you for having me. I've been looking forward to this for quite a while. 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 has your trajectory been like over that time?

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. And we've from consulting developer, working on building out websites for other people, to Google's like, hey, you want to do this advocacy, resolve 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 or 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 on all the different topics and, you know, always bouncing around. So it's been great. Cloud's been, well, when I started, cloud was very, very, very small back in 2014 compared to what it is now. Google Cloud is way bigger. 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 fire hose 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. Yeah, no, it's, 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. 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. Yeah. So I don't know why it's a rare perspective,

but at least within 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 100% 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, and 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 out features for their employer. What about a really crappy bash? Does that count? Sure. If you're going to build some sort of application to really crappy Bash, awesome. You'd be surprised. My primary development stack usually is a combination of brute force and enthusiasm. 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. I think it's called iterative development.

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. The thing that keeps confusing me, for lack of a better term, is that I see a bunch of companies talking in similar directions. Yeah, we want to talk to developers and we're going to meet them across the stack with 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 have problems that the healthcare company could never fathom happening. You get that you two look an awful lot alike, right? And things that work for one of you are going to map to at least 80, if not 90%

of what the other is doing. But nope, nope, completely separate audiences, completely separate approaches. And I find myself increasingly skeptical about that model. Yeah, so I think I see that too. I have sometimes behaved that way. And I think myself increasingly skeptical about that model. Yeah, so I think I see that too. I have sometimes behaved 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 ed tech.

I've worked on real estate stuff. I've worked in a lot of different fields. As I said, I 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 have just have a different perspective than the folks I like to go chat with who are the ones banging out features. 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. Yeah, no, 100% agree. And 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. I understand it. But I'm not an expert. I have other people on my team who've 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 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 a question that no one understands, and I have had that experience numerous times, either I'm doing something wrong or the actual thing that I've found more often is I'm explaining it in words that people don't understand. And that's always a challenge. It's 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. I've noticed that. There are almost too many ways to do certain things, and they're all terrible in 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 what it's written in versus building it in a language I have a bit more familiarity with, like, you know, Crappy Bash. Yeah, no, 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. 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 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? 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 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 that get out of my way. I know that we joke about there being 9,000 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 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 will 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 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 expected.

So I like it when APIs do that. I like it when it's super easy to guess. It's consistent naming schemes. If 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 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 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 thing 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. I still don't really want to bias for that one either, personally. 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. I have to say, acknowledge. No company is ever going to get

that right, no matter where I work, because it 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 out there as an option. I spent a lot of time reading UX studies on developer experience. Advantage is working at a big company is 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. One of the things that I've always viewed as something of 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. Yep.

And this is an interesting thing for me because my personal feelings are very similar to yours. I don't want to take a class. 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 spent time working with customers, working with folks who I 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. It 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 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. Everyone learns differently. 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. It's the height of hubris to believe that everyone thinks, processes, learns, etc. 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.

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, I am 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 audios and learning the concepts. I adore learning stuff from podcasts. I love audio books, 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., 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, well, sure, there's lots of learning, different learning styles. But, you know, most engineers are like X. No, there is no most engineers.

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, 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 that if anything, I'm the one that's broken. The trick 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 and a keynote getting on stage and making grandiose promises that the service does not back up yeah 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 is 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 to myself. So I do have a bias there. I also have a bias having worked in the industry 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 I always joke computers run in fear of me because if there is 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. Doesn't matter if it's in 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 are explicitly designed so that we can fit in the time frame

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 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 I might've been thinking about this backwards, upside down, and in purple. So let's back the track up and have a discussion. 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, I just spin it up and do it.

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 you, that somewhat special ability to cause chaos and destruction to all about me when I start trying to do something in good faith on the computer. 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 a super important talk, and I call up

internal tech support at Google, and they're like, you did what and how? But it's also great because I know that I get to, because I started micro-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 am very willing to go off happy path. If I see a tutorial that's close, you know, I'll follow 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. And a lot of products are designed though, that once you deviate from the happy path, well, now you've broken and you get to keep all the pieces that 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 bother me. Yeah, I've seen that. And I've seen that in open source frameworks, too. And people, when I talk about 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 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, 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. 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 kindergartners. And I don't have kids, but I think kindergartners are just a hoot. 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 text box or when given a mouse. And we like to think that engineers and adults are better. We're not. We just 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'd you do it that way? Because everyone has good reasons for the decisions they make most of the time and understanding those is important. 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. Yeah. Never intentional, but it always hits us. Yeah. One of the things that I learned in the last 10-ish years, and one of the things that I try to bring to all of my

developer relations, all of my developer education work is it made sense at the time. Now, it may have been that they made an 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, we're 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, 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. So as we wind up coming toward 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? 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 AIML. And I will also 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, 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 us add. 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 then shared out, things like empathy sessions, friction logging. We shared out 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 direct feature requests from them. The other big thing is I've just seen us grow. And that's the big thing is 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 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 100% 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. I'd say that I would agree with what you're saying. I've had a nothing but positive experiences when I've been building admittedly very small scale shit posty 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. 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. 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 as 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 to 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 that 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 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 like, you know, I really just want to go spend some time on Google Cloud today. But I want to be something that they enjoy using or at least gets out of their way, out of their way to doing the stuff that they actually want to do. You know, add features, build shitposting websites, whatever it ends up being. 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? Oh, that's the best place to find

me right now is www.thagomizer.com. Thagomizer is the spiky part at the end of the stegosaurus. It is. That is my website, and it has my most recent social, etc. on it. 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 was mentioning 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. I have a pile of those myself that for some reason, it never quite ends up happening when you hope it will. Yeah, exactly. And we'll, of course, put links to all of that in the show notes. Thank you so much for being so generous with explaining your point of view. I appreciate it. Yeah. And thank you for having me. This was lovely.

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 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.