Transcript

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