Podcasts about devrel

Mais um episódio sobre TechGuide para vocês! Nesta conversa, vamos falar sobre SQL, bancos de dados relacionais, queries e o que é "sequel". Vem ver quem acompanha a gente neste papo!

On this episode of Rehash, we sit down with Cami Ramos, the Head of DevRel at Fuel, an early contributor at DeveloperDAO, and creator of WBW3. We discuss the job of developer relations, account abstraction, the importance of crypto in LATAM countries, how to build a global community, and how necessity breeds innovation. COLLECT THIS EPISODEhttps://www.rehashweb3.xyz/ FOLLOW USRehash: https://twitter.com/rehashweb3Diana: https://twitter.com/ddwchenCami: https://twitter.com/camiinthisthang EDITORSEllie: https://twitter.com/elliedotsTyler: https://twitter.com/tylerinternet SPONSORSLens Protocol: https://lens.xyzAmbire Wallet: https://www.ambire.com/NFT.Storage: https://twitter.com/NFTdotStorage TIMESTAMPS0:00 Intro1:02 Sponsors5:14 Welcome Cami6:12 Developer relations8:55 How DevRel differs in web3 vs. web211:18 Talent DAOs16:43 Global community building20:01 How to give a community autonomy21:56 Why Latin America is perfectly situated for innovation29:23 Building for the real world 33:03 Change that's needed in web334:04 Account abstraction 37:29 What Cami is Most excited to see built38:33 Audience questions40:44 Word association game42:19 Follow Cami! LINKSDeveloperDAO - https://www.developerdao.com/WBW3 - https://twitter.com/womenbuildweb3Fuel - https://www.fuel.network/Manta - https://manta.network/The Deadend of Eurocentric Crypto - https://mirror.xyz/camiinthisthang.eth/qUCbEGmphCHTYQVD27G_MFCL53tr96y3A3qqXt5l3ts DISCLAIMER: The information in this video is the opinion of the speaker(s) only and is for informational purposes only. You should not construe it as investment advice, tax advice, or legal advice, and it does not represent any entity's opinion but those of the speaker(s). For investment or legal advice, please seek a duly licensed professional.

In episode 124 of Jamstack Radio, Brian speaks with James Perkins of Clerk. Together they explore tools and practices for simplifying authentication and user management, the latest trends in DevRel hiring, and the correlation between internal feedback loops and productivity within small orgs.

In episode 124 of Jamstack Radio, Brian speaks with James Perkins of Clerk. Together they explore tools and practices for simplifying authentication and user management, the latest trends in DevRel hiring, and the correlation between internal feedback loops and productivity within small orgs.

Today we've got Nick on the pod. Nick is a full stack developer who handles Docs and DevRel at the Solana Foundation and hosts the Solfate Pod. We seem to have an information gap between the Solana community and the rest of crypto. This podcast is an attempt to go over what is fact and fiction about the network in 2023. We go over some of the most common FUD levelled at Solana as well as what we are excited for. This conversation is made possible thanks to Streamflow. ------ THE COVE SPONSOR TOOLS:

with @amandacassatt @kimbatronic @smc90All about marketing, and web3 -- not just for marketers already in or seeking to enter web3, but also anyone doing community marketing/ community management, devrel (developer relations); or simply doing marketing in web2 or classic growth marketing, seeking to understand the latest trends and tactics.With the  author of the new book, Web3 Marketing: A Handbook for the Next Internet Revolution, Amanda Cassatt (who was also the first CMO at ConsenSys, helping bring Ethereum to market; and also founded and leads the pioneering, native web3-marketing agency Serotonin). Also joining this episode to share insights on marketing web3 -- in conversation with host and editor in chief Sonal Chokshi -- is Kim Milosevich, CMO at a16z crypto, where she oversees brand, marketing, events, and communications (and before that was VP of communications at Coinbase, where she took the company through its direct listing while leading internal, policy, product, and corporate communications internationally). The episode also covers key top of mind questions for web3 builders and others, including how to do community marketing, manage "profiles" in decentralized and open source, and finding your audience... including feedback for product-market fit. And much. much more! 

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.

Listen in as PJ and Wesley process their conversation with Erin, PJ Metz, and Jared and the changes in the tech employment landscape over the last few months. Enjoy the podcast? Please take a few moments to leave us a review on iTunes (https://itunes.apple.com/us/podcast/community-pulse/id1218368182?mt=2) and follow us on Spotify (https://open.spotify.com/show/3I7g5WfMSgpWu38zZMjet?si=565TMb81SaWwrJYbAIeOxQ), or leave a review on one of the other many podcasting sites that we're on! Your support means a lot to us and helps us continue to produce episodes every month. Like all things Community, this too takes a village.

Mais um episódio sobre TechGuide para vocês! Nesta conversa, vamos falar sobre programação orientada a objetos, esse paradigma usado na maioria das linguages de programação hoje em dia, e coisas como encapsulamento, abstrações, polimorfismo e muito mais. Vem ver quem acompanha a gente neste papo!

Yoav Ganbar is a DevRel at Builder.io and host of the FedBites podcast. Yoav joins us to talk about Builder.io, using React inside Qwik, and more. Links https://www.builder.io/blog/resumable-react-how-to-use-react-inside-qwik https://podcasters.spotify.com/pod/show/fedbites https://twitter.com/HamatoYogi https://www.hamatoyogi.dev https://www.builder.io Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Yoav Ganbar.

In episode 122 of Jamstack Radio, Brian catches up with Anthony Campolo of Edgio. In this conversation they recap Anthony's career journey and explore many technical topics including edge computing, the current state of the JavaScript ecosystem, insights on leveraging Jamstack for infrastructure ambitions, and combatting imposter syndrome in DevRel.

In episode 122 of Jamstack Radio, Brian catches up with Anthony Campolo of Edgio. In this conversation they recap Anthony's career journey and explore many technical topics including edge computing, the current state of the JavaScript ecosystem, insights on leveraging Jamstack for infrastructure ambitions, and combatting imposter syndrome in DevRel.

We've seen a lot of strange habits when it comes to hiring DevRel folks over the past few years. But recently, a surprising phenomenon has occurred: a large-scale layoff or re-org leading to many folks in DevRel being suddenly unemployed. What are the knock-on effects we can expect from this? What are folks impacted by this doing as next steps? Checkouts Jarek Jarzebowski * Developer Ambassadors Motivation Survey 2023 (https://www.advocu.com/developer-ambassadors-motivation-survey-2023?trk=public_post_comment-text) * "10% Happier: How I Tamed the Voice in My Head, Reduced Stress Without Losing My Edge, and Found Self-Help That Actually Works--A True Story" (https://www.thriftbooks.com/w/10-happier-how-i-tamed-the-voice-in-my-head-reduced-stress-without-losing-my-edge-and-found-self-help-that-actually-works--a-true-story_dan---harris/3223663/item/34958913/#edition=7654643&idiq=4167572) by Dan Harris PJ Metz * Current music obsession: Dan Mason - Electric Elevator 2: Second Floor (https://youtu.be/ovpO-c0DpEI) * Projectdiscovery.io (Projectdiscovery.io) Erin Mikail Staples * GenSpace NYC (https://www.genspace.org/) * DevRelish (https://www.youtube.com/watch?v=IICDgnu4-PI) * Labelstud.io (https://labelstud.io/) » integrations library and hugging face spaces Wesley Faulkner * Engineer, Male Engineer (https://www.facebook.com/845933925525600/posts/pfbid025SXD6Y2vGke5znJ8NxrczbZyEFHr2XvvVDYGTqYvTE9BK1b57fiuYVYiB3NoGswfl/) PJ Hagerty * "Do You Talk Funny?: 7 Comedy Habits to Become a Better (and Funnier) Public Speaker (https://www.amazon.com/Do-You-Talk-Funny-David-Nihill-audiobook/dp/B018F3FTZY)" by David Nihil * Spotify AI DJ (https://newsroom.spotify.com/2023-03-08/spotify-new-personalized-ai-dj-how-it-works/) * Open Sourcing Mental Health (OSMHhelp.org) - get ready for Mental Health Awareness month in May Enjoy the podcast? Please take a few moments to leave us a review on iTunes (https://itunes.apple.com/us/podcast/community-pulse/id1218368182?mt=2) and follow us on Spotify (https://open.spotify.com/show/3I7g5WfMSgpWu38zZMjet?si=565TMb81SaWwrJYbAIeOxQ), or leave a review on one of the other many podcasting sites that we're on! Your support means a lot to us and helps us continue to produce episodes every month. Like all things Community, this too takes a village. Artwork photo by Clem Onojeghuo (https://unsplash.com/@clemono?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash (https://unsplash.com/@clemono?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) Special Guests: Erin Mikail Staples, Jarek Jarzebowski, and PJ Metz.

Matty Stratton, Director of Developer Relations at Aiven, joins Corey on Screaming in the Cloud for a friendly debate on whether or not company employees can still be considered community members. Corey says no, but opens up his position to the slings and arrows of Matty in an entertaining change of pace. Matty explains why he feels company employees can still be considered community members, and also explores how that should be done in a way that is transparent and helpful to everyone in the community. Matty and Corey also explore the benefits and drawbacks of talented community members becoming employees.About MattyMatty Stratton is the Director of Developer Relations at Aiven, a well-known member of the DevOps community, founder and co-host of the popular Arrested DevOps podcast, and a global organizer of the DevOpsDays set of conferences.Matty has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL.He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. Links Referenced: Aiven: https://aiven.io/ Twitter: https://twitter.com/mattstratton Mastodon: hackyderm.io/@mattstratton LinkedIn: https://www.linkedin.com/in/mattstratton/ TranscriptAnnouncer: 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.Corey: This episode is brought to us in part by our friends at Min.ioWith more than 1.1 billion docker pulls - Most of which were not due to an unfortunate loop mistake, like the kind I like to make - and more than 37 thousand github stars, (which are admittedly harder to get wrong), MinIO has become the industry standard alternative to S3. It runs everywhere  - public clouds, private clouds, Kubernetes distributions, baremetal, raspberry's pi, colocations - even in AWS Local Zones. The reason people like it comes down to its simplicity, scalability, enterprise features and best in class throughput. Software-defined and capable of running on almost any hardware you can imagine and some you probably can't, MinIO can handle everything you can throw at it - and AWS has imagined a lot of things - from datalakes to databases.Don't take their word for it though - check it out at www.min.io and see for yourself. That's www.min.io Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined today by returning guest, my friend and yours, Matty Stratton, Director of Developer Relations at Aiven. Matty, it's been a hot second. How are you?Matty: It has been a while, but been pretty good. We have to come back to something that just occurred to me when we think about the different things we've talked about. There was a point of contention about prior art of the Corey Quinn face and photos. I don't know if you saw that discourse; we may have to have a conversation. There may be some absent—Corey: I did not see—Matty: Okay.Corey: —discourse, but I also would accept freely that I am not the first person to ever come up with the idea of opening my mouth and looking ridiculous for a photograph either.Matty: That's fair, but the thing that I think was funny—and if you don't mind, I'll just go ahead and throw this out here—is that I didn't put this two and two together. So, I posted a picture on Twitter a week or so ago that was primarily to show off the fact—it was a picture of me in 1993, and the point was that my jeans were French-rolled and were pegged. But in the photo, I am doing kind of the Corey Quinn face and so people said, “Oh, is this prior art?” And I said—you know what? I actually just remembered and I've never thought about this before, but one of my friends in high school, for his senior year ID he took a picture—his picture looks like, you know, that kind of, you know, three-quarters turn with the mouth opening going, “Ah,” you know?And he loved that picture—number one, he loved that picture so much that this guy carried his senior year high school ID in his wallet until we were like 25 because it was his favorite picture of himself. But every photo—and I saw this from looking through my yearbook of my friend Jay when we are seniors, he's doing the Corey Quinn face. And he is anecdotally part of the DevOps community, now a little bit too, and I haven't pointed this out to him. But people were saying that, you know, mine was prior art on yours, I said, “Actually, I was emulating yet someone else.”Corey: I will tell you the actual story of how it started. It was at re:Invent, I want to say 2018 or so, and what happened was is someone, they were a big fan of the newsletter—sort of the start of re:Invent—they said, “Hey, can I get a selfie with you?” And I figured, sure, why not. And the problem I had is I've always looked bad in photographs. And okay, great, so if I'm going to have a photo taken of me, that's going to be ridiculous, why not as a lark, go ahead and do this for fun during the course of re:Invent this year?So, whenever I did that I just slapped—if someone asked for a selfie—I'd slap the big happy open mouth smile on my face. And people thought, “Oh, my God, this is amazing.” And I don't know that it was necessarily worth that level of enthusiasm, but okay. I'll take it. I'm not here to tell people they're wrong when they enjoy a joke that I'm putting out there.And it just sort of stuck. And I think the peak of it that I don't think I'm ever going to be able to beat is I actually managed to pull that expression on my driver's license.Matty: Wow.Corey: Yeah.Matty: That's—Corey: They don't have a sense of humor that they are aware of at the DMV.Matty: No, they really don't. And having been to the San Francisco DMV and knowing how long it takes to get in there, like, that was a bit of a risk on your part because if they decided to change their mind, you wouldn't be able to come back for another four months [laugh].Corey: It amused me to do it, so why not? What else was I going to do? I brought my iPad with me, it has cellular on it, so I just can work remotely from there. It was either that or working in my home office again, and frankly, at the height of the pandemic, I could use the break.Matty: Yes [laugh]. That's saying something when the break you can use is going to the DMV.Corey: Right.Matty: That's a little bit where we were, where we at. I think just real quick thinking about that because there's a lot to be said with that kind of idea of making a—whether it's silly or not, but having a common, especially if you do a lot of photos, do a lot of things, you don't have to think about, like, how do I look? I mean, you have to think about—you know, you can just say I just know what I do. Because if you think about it, it's about cultivating your smile, cultivating your look for your photos, and just sort of having a way so you don't—you just know what to do every time. I guess that's a, you know, maybe a model tip or something. I don't know. But you might be onto something.Corey: I joke that my entire family motto is never be the most uncomfortable person in the room. And there's something to be said for it where if you're going to present a certain way, make it your own. Find a way to at least stand out. If nothing else, it's a bit different. Most people don't do that.Remember, we've all got made fun of, generally women—for some reason—back about 15 years ago or so for duck face, where in all the pictures you're making duck face. And well, there are reasons why that is a flattering way to present your face. But if there's one thing we love as a society, it's telling women they're doing something wrong.Matty: Yeah.Corey: So yeah, there's a whole bunch of ways you're supposed to take selfies or whatnot. Honestly, I'm in no way shape or form pretty enough or young enough to care about any of them. At this point, it's what I do when someone busts out a camera and that's the end of it. Now, am I the only person to do this? Absolutely not. Do I take ownership of it? No. Someone else wants to do it, they need give no credit. The idea probably didn't come from me.Matty: And to be fair, if I'm little bit taking the mickey there or whatever about prior art, it was more than I thought it was funny because I had not even—it was this thing where it was like, this is a good friend of mine, probably some of that I've been friends with longer than anyone in my whole life, and it was a core part [laugh] of his personality when we were 18 and 19, and it just d—I just never direct—like, made that connection. And then it happened to me and went “Oh, my God. Jason and Corey did the same thing.” [laugh]. It was—Corey: No, it feels like parallel evolution.Matty: Yeah, yeah. It was more of me never having connected those dots. And again, you're making that face for your DMV photo amused you, me talking about this for the last three minutes on a podcast amused me. So.Corey: And let's also be realistic here. How many ways are there to hold your face during a selfie that is distinguishable and worthy of comment? Usually, it's like okay, well, he has this weird sardonic half-smile with an eyebrow ar—no. His mouth was wide open. We're gonna go with that.Matty: You know, there's a little—I want to kind of—because I think there's actually quite a bit to the lesson from any of this because I think about—follow me here; maybe I'll get to the right place—like me and karaoke. No one would ever accuse me of being a talented singer, right? I'm not going to sing well in a way where people are going to be moved by my talent. So instead, I have to go a different direction. I have to go funny.But what it boils down to is I can only do—I do karaoke well when it's a song where I can feel like I'm doing an impression of the singer. So, for example, the B-52s. I do a very good impression of Fred Schneider. So, I can sing a B-52 song all day long. I actually could do better with Pearl Jam than I should be able to with my terrible voice because I'm doing an Eddie Vedder impression.So, what I'm getting at is you're sort of taking this thing where you're saying, okay, to your point, you said, “Hey,”—and your words, not mine—[where 00:07:09] somebody say, “The picture is not going to be of me looking like blue steel runway model, so I might as well look goofy.” You know? And take it that way and be funny with it. And also, every time, it's the same way, so I think it's a matter of kind of owning the conversation, you know, and saying, how do you accentuate the thing that you can do. I don't know. There's something about DevOps, somehow in there.Corey: So, I am in that uncomfortable place right now between having finalized a blog post slash podcast that's going out in two days from this recording. So, it will go out before you and I have this discussion publicly, but it's also too late for me to change any of it,m so I figured I will open myself up to the slings and arrows of you, more or less. And you haven't read this thing yet, which is even better, so you're now going to be angry about an imperfect representation of what I said in writing. But the short version is this: if you work for a company as their employee, then you are no longer a part of that company's community, as it were. And yes, that's nuanced and it's an overbroad statement and there are a bunch of ways that you could poke holes in it, but I'm curious to get your take on the overall positioning of it.Matty: So, at face value, I would vehemently disagree with that statement. And by that is, that I have spent years of my life tilting at the opposite windmill, which is just because you work at this company, doesn't mean you do not participate in the community and should not consider yourself a part of the community, first and foremost. That will, again, like everything else, it depends. It depends on a lot of things and I hope we can kind of explore that a little bit because just as much as I would take umbrage if you will, or whatnot, with the statement that if you work at the company, you stop being part of the community, I would also have an issue with, you're just automatically part of the community, right? Because these things take effort.And I feel like I've been as a devreloper, or whatever, Corey—how do you say it?Corey: Yep. No, you're right on. Devreloper.Matty: As a—or I would say, as a DevRel, although people on Twitter are angry about using the word DevRel to discuss—like saying, “I'm a DevRel.” “DevRel is a department.” It's a DevOps engineer thing again, except actually—it's, like, actually wrong. But anyway, you kind of run into this, like for example—I'm going to not name names here—but, like, to say, you know, Twitter for Pets, the—what do you—by the way, Corey, what are you going to do now for your made-up company when what Twitter is not fun for this anymore? You can't have Twitter for Pets anymore.Corey: I know I'm going to have to come up with a new joke. I don't quite know what to do with myself.Matty: This is really hard. While we will pretend Twitter for Pets is still around a little bit, even though its API is getting shut down.Corey: Exactly.Matty: So okay, so we're over here at Twitter for Pets, Inc. And we've got our—Corey: Twitter for Bees, because you know it'll at least have an APIary.Matty: Yeah. Ha. We have our team of devrelopers and community managers and stuff and community engineers that work at Twitter for Pets, and we have all of our software engineers and different people. And a lot of times the assumption—and now we're going to have Twitter for Pets community something, right? We have our community, we have our area, our place that we interact, whether it's in person, it's virtual, whether it's an event, whether it's our Discord or Discourse or Slack or whatever [doodlee 00:10:33] thing we're doing these days, and a lot of times, all those engineers and people whose title does not have the word ‘community' on it are like, “Oh, good. Well, we have people that do that.”So, number one, no because now we have people whose priority is it; like, we have more intentionality. So, if I work on the community team, if I'm a dev advocate or something like that, my priority is communicating and advocating to and for that community. But it's like a little bit of the, you know, the office space, I take the requirements from the [unintelligible 00:11:07] to people, you I give them to the engineers. I've got people—so like, you shouldn't have to have a go-between, right? And there's actually quite a bit of place.So, I think, this sort of assumption that you're not part of it and you have no responsibility towards that community, first of all, you're missing a lot as a person because that's just how you end up with people building a thing they don't understand.Corey: Oh, I think you have tremendous responsibility to the community, but whether you're a part of it and having responsibility to it or not aligned in my mind.Matty: So… maybe let's take a second and what do you mean by being a part of it?Corey: Right. Where very often I'll see a certain, I don't know, very large cloud provider will have an open-source project. Great, so you go and look at the open-source project and the only people with commit access are people who work at that company. That is an easy-to-make-fun-of example of this. Another is when the people who are in a community and talking about how they perceive things and putting out content about how they've interacted with various aspects of it start to work there, you see areas where it starts to call its authenticity into question.AWS is another great example of this. As someone in the community, I can talk about how I would build something on top of AWS, but then move this thing on to Fastly instead of CloudFront because CloudFront is terrible. If you work there, you're not going to be able to say the same thing. So, even if you're not being effusive with praise, there are certain guardrails and constraints that keep you from saying what you might otherwise, just based upon the sheer self-interest that comes from the company whose product or service you're talking about is also signing your paycheck and choosing to continue to do so.Matty: And I think even less about it because that's where your paycheck is coming. It's also just a—there's a gravitational pull towards those solutions because that's just what you're spending your day with, right? You know—Corey: Yeah. And you also don't want to start and admit even to yourself, in some cases, that okay, this aspect of what our company does is terrible, so companies—people shouldn't use it. You want to sort of ignore that, on some level, psychologically because that dissonance becomes harmful.Matty: Yeah. And I think there's—so again, this is where things get nuanced and get to levels. Because if you have the right amount of psychological safety in your organization, the organization understands what it's about to that. Because even people whose job is to be a community person should be able to say, “Hey, this is my actual opinion on this. And it might be contrary to the go-to-market where that comes in.”But it's hard, especially when it gets filtered through multiple layers and now you've got a CEO who doesn't understand that nuance who goes, “Wait, why was Corey on some podcast saying that the Twitter for Pets API is not everything it could possibly be?” So, I do think—I will say this—I do think that organizations and leadership are understanding this more than they might have in the past, so we are maybe putting on ourselves this belief that we can't be as fully honest, but even if it's not about hiding the warts, even if it's just a matter of also, you're just like, hey, chances are—plus also to be quite frank, if I work at the company, I probably have access to way more shit than I would have to pay for or do whatever and I know the right way. But here's the trick, and I won't even say it's a dogfooding thing, but if you are not learning and thinking about things the way that your users do—and I will even say that that's where—it is the users, which are the community, that community or the people that use your product or are connected to it, they don't use it; they may be anecdotal—or not anecdotally, maybe tangentially connected. I will give an example. And there was a place I was working where it was very clear, like, we had a way to you know, do open-source contributions back of a type of a provider plug-in, whatever you want to call it and I worked at the company and I could barely figure out how to follow the instructions.Because it made a lot of sense to someone who built that software all day long and knew the build patterns, knew all that stuff. So, if you were an engineer at this company, “Well, yeah, of course. You just do this.” And anybody who puts the—connects the dots, this has gotten better—and this was understood relatively quickly as, “Oh, this is the problem. Let's fix it.” So, the thing is, the reason why I bring this up is because it's not something anybody does intentionally because you don't know what you don't know. And—Corey: Oh, I'm not accusing anyone of being a nefarious actor in any of this. I also wonder if part of this is comes from your background as being heavily involved in the Chef community as a Chef employee and as part of the community around that, which is inherently focused on an open-source product that a company has been built around, whereas my primary interaction with community these days is the AWS community, where it doesn't matter whether you're large or small, you are not getting much, if anything, for free from AWS; you're all their customers and you don't really have input into how something gets built, beyond begging nicely.Matty: That's definitely true. And I think we saw that and there was things, when we look at, like, how community, kind of, evolved or just sort of happened at Chef and why we can't recreate it the same way is there was a certain inflection point of the industry and the burgeoning DevOps movement, and there wasn't—you know, so a lot of that was there. But one of the big problems, too, is, as Corey said, everybody—I shouldn't say every, but I've from the A—all the way up to AWS to your smaller startups will have this problem of where you end up hiring in—whether you want to or not—all of your champions and advocates and your really strong community members, and then that ends up happening. So, number one, that's going to happen. So frankly, if you don't push towards this idea, you're actually going to have people not want to come work because you should be able to be still the member that you were before.And the other thing is that at certain size, like, at the size of a hyperscaler, or, you know, a Microsoft—well, anybody—well Microsofts not a hyperscaler, but you know what I'm saying. Like, very, very large organization, your community folks are not necessarily the ones doing that hiring away. And as much as they might—you know, and again, I may be the running the community champion program at Microsoft and see that you want—you know, but that Joe Schmo is getting hired over into engineering. Like, I'm not going to hire Joe because it hurts me, but I can't say you can't, you know? It's so this is a problem at the large size.And at the smaller size, when you're growing that community, it happens, too, because it's really exciting. When there's a place that you're part of that community, especially when there's a strong feel, like going to work for the mothership, so to speak is, like, awesome. So again, to give an example, I was a member of the Chef community, I was a user, a community person well, before, you know, I went and, you know, had a paycheck coming out of that Seattle office. And it was, like, the coolest thing in the world to get a job offer from Ch—like, I was like, “Oh, my God. I get to actually go work there now.” Right?And when I was at Pulumi, there quite a few people I could think of who I knew through the community who then get jobs at Pulumi and we're so excited, and I imagine still excited, you know? I mean, that was awesome to do. So, it's hard because when you get really excited about a technology, then being able to say, “Wait, I can work on this all the time?” That sounds awesome, right? So like, you're going to have that happen.So, I think what you have to do is rather than prevent it from happening because number one, like, you don't want to actually prevent that from happening because those people will actually be really great additions to your organization in lots of ways. Also, you're not going to stop it from happening, right? I mean, it's also just a silly way to do it. All you're going to do is piss people off, and say, like, “Hey, you're not allowed to work here because we need you in the community.” Then they're going to be like, “Great. Well, guess what I'm not a part of anymore now, jerk?” Right? You know [laugh] I mean so—Corey: Exactly.Matty: Your [unintelligible 00:18:50] stops me. So, that doesn't work. But I think to your point, you talked about, like, okay, if you have a, ostensibly this a community project, but all the maintainers are from one—are from your company, you know? Or so I'm going to point to an example of, we had—you know, this was at Pulumi, we had a Champions program called Puluminaries, and then there's something similar to like Vox Populi, but it was kind of the community that was not run by Pulumi Inc. In that case.Now, we helped fund it and helped get it started, but there was there were rules about the, you know, the membership of the leadership, steering committee or board or whatever it was called, there was a hard limit on the number of people that could be Pulumi employees who were on that board. And it actually, as I recall when I was leaving—I imagine this is not—[unintelligible 00:19:41] does sometimes have to adjust a couple of things because maybe those board members become employees and now you have to say, you can't do that anymore or we have to take someone down. But the goal was to actually, you know, basically have—you know, Pulumi Corp wanted to have a voice on that board because if for no other reason, they were funding it, but it was just one voice. It wasn't even a majority voice. And that's a hard sell in a lot of places too because you lose control over that.There's things I know with, uh—when I think about, like, running meetup communities, like, we might be—well I mean, this is not a big secret, I mean because it's been announced, but we're—you know, Aiven is helping bootstrap a bunch of data infrastructure meetups around the world. But they're not Aiven meetups. Now, we're starting them because they have to start, but pretty much our approach is, as soon as this is running and there's people, whether they work here, work with us or not, they can take it, right? Like, if that's go—you know? And being able to do that can be really hard because you have to relinquish the control of your community.And I think you don't have to relinquish a hundred percent of that control because you're helping facilitate it because if it doesn't already have its own thing—to make sure that things like code of conduct and funding of it, and there's things that come along with the okay, we as an organization, as a company that has dollars and euros is going to do stuff for this, but it's not ours. And that's the thing to remember is that your community does not belong to you, the company. You are there to facilitate it, you are there to empower it, you're there to force-multiply it, to help protect it. And yeah, you will probably slurp a whole bunch of value out of it, so this is not magnanimous, but if you want it to actually be a place it's going to work, it kind of has to be what it wants to be. But by the same token, you can't just sort of sit there and be like, “I'm going to wait for this community grow up around me without anything”—you know.So, that's why you do have to start one if there is quote-unquote—maybe if there's no shape to one. But yeah, I think that's… it is different when it's something that feels a little—I don't even want to say that it's about being open-source. It's a little bit about it less of it being a SaaS or a service, or if it's something that you—I don't know.Corey: This episode is sponsored in part by Honeycomb. I'm not going to dance around the problem. Your. Engineers. Are. Burned. Out. They're tired from pagers waking them up at 2 am for something that could have waited until after their morning coffee. Ring Ring, Who's There? It's Nagios, the original call of duty! They're fed up with relying on two or three different “monitoring tools” that still require them to manually trudge through logs to decipher what might be wrong. Simply put, there's a better way. Observability tools like Honeycomb (and very little else becau se they do admittedly set the bar) show you the patterns and outliers of how users experience your code in complex and unpredictable environments so you can spend less time firefighting and more time innovating. It's great for your business, great for your engineers, and, most importantly, great for your customers. Try FREE today at honeycomb.io/screaminginthecloud. That's honeycomb.io/screaminginthecloud.Corey: Yeah, I think you're onto something here. I think another aspect where I found it be annoying is when companies view their community as, let's hire them all. And I don't think it ever starts that way. I think that it starts as, well these are people who are super-passionate about this, and they have great ideas and they were great to work with. Could we hire them?And the answer is, “Oh, wait. You can give me money for this thing I've been doing basically for free? Yeah, sure, why not?” And that's great in the individual cases. The problem is, at some point, you start to see scenarios where it feels like, if not everyone, then a significant vocal majority of the community starts to work there.Matty: I think less often than you might think is it done strategically or on purpose. There have been exceptions to that. There's one really clear one where it feels like a certain company a few years ago, hired up all the usual suspects of the DevOps community. All of a sudden, you're like, oh, a dozen people all went to go work at this place all at once. And the fun thing is, I remember feeling a little bit—got my nose a little out of joint because I was not the hiring mana—like, I knew the people.I was like, “Well, why didn't you ask me?” And they said, “Actually, you are more important to us not working here.” Now, that might have just been a way to sell my dude-in-tech ego or not, but whether or not that was actually true for me or not, that is a thing where you say you know, your folks—but I do think that particular example of, like, okay, I'm this, that company, and I'm going to go hire up all the usual suspects, I think that's less. I think a lot of times when you see communities hire up those people, it's not done on purpose and in fact, it's probably not something they actually wanted to do in mass that way. But it happens because people who are passionate about your product, it's like I said before, it actually seems pretty cool to go work on it as your main thing.But I can think of places I've been where we had, you know—again, same thing, we had a Pulumi—we had someone who was probably our strongest, loudest, most vocal community member, and you know, I really wanted to get this person to come join us and that was sort of one of the conversations. Nobody ever said, “We won't offer this person a job if they're great.” Like, that's the thing. I think that's actually kind of would be shitty to be like, “You're a very qualified individual, but you're more important to me out in the community so I'm not going to make your job offer.” But it was like, Ooh, that's the, you know—it'd be super cool to have this person but also, not that that should be part of our calculus of decision, but then you just say, what do you do to mitigate that?Because what I'm concerned about is people hearing this the wrong way and saying, “There's this very qualified individual who wants to come work on my team at my company, but they're also really important to our community and it will hurt our community if they come work here, so sorry, person, we're not going to give you an opportunity to have an awesome job.” Like, that's also thinking about the people involved, too. But I know having talked to folks that lots of these different large organizations that have this problem, generally, those community folks, especially at those places, they don't want this [laugh] happening. They get frustrated by it. So, I mean, I'll tell you, it's you know, the—AWS is one of them, right?They're very excited about a lot of the programs and cool people coming from community builders and stuff and Heroes, you know. On one hand, it's incredibly awesome to have a Hero come work at AWS, but it hurts, right, because now they're not external anymore.Corey: And you stop being a Hero in that case, as well.Matty: Yeah. You do, yeah.Corey: Of course, they also lose the status if they go to one of their major competitors. So like, let me get this straight. You can't be a Hero if you work for AWS or one of its competitors. And okay, how are there any Heroes left at all at some point? And the answer is, they bound it via size and a relatively small list of companies. But okay.Matty: So, thinking back to your point about saying, okay, so if you work at the company, you lose some authenticity, some impartiality, some, you know… I think, rather than just saying, “Well, you're not part”—because that also, honestly, my concern is that your blog post is now going to be ammunition for all the people who don't want to act as members of the community for the company they work for now. They're going to say, well, Corey told me I don't have to. So, like I said, I've been spending the last few years tilting at the opposite windmill, which is getting people that are not on the community team to take part in community summits and discourse and things like that, like, you know, for that's—so I think the thing is, rather than saying, “Well, you can't,” or, “You aren't,” it's like, “Well, what do you do to mitigate those things?”Corey: Yeah, it's a weird thing because taking AWS as the example that I've been beating up on a lot, the vast majority of their employees don't know the community exists in any meaningful sense. Which, no fault to them. The company has so many different things, no one keeps up with at all. But it's kind of nuts to realize that there are huge communities of people out there using a thing you have built and you do not know that those users exist and talk to each other in a particular watering hole. And you of course, as a result, have no presence there. I think that's the wrong direction, too. But—Matty: Mm-hm.Corey: Observing the community and being part of the community, I think there's a difference. Are you a biologist or are you a gorilla?Matty: Okay, but [sigh] I guess that's sort of the difference, too which—and it's hard, it's very hard to not just observe. Because I think that actually even taking the mentality of, “I am here to be Jane Goodall, Dr. Jane Goodall, and observe you while I live amongst you, but I'm not going to actually”—although maybe I'm probably doing disservice—I'm remembering my Goodall is… she was actually more involved. May be a bad example.Corey: Yeah. So, that analogy does fall apart a little bit.Matty: It does fall apart a little bit—Corey: Yeah.Matty: But it's you kind of am I sitting there taking field notes or am I actually engaging with you? Because there is a difference. Even if your main reason for being there is just purely to—I mean, this is not the Prime Directive. It's not Star Trek, right? You're not going to like, hold—you don't need to hold—I mean, do you have to hold yourself aloof and say, “I don't participate in this conversation; I'm just here to take notes?”I think that's very non-genuine at that point. That's over-rotating the other way. But I think it's a matter of in those spaces—I think there's two things. I think you have to have a way to be identified as you are an employee because that's just disclosure.Corey: Oh, I'm not suggesting by any stretch of the imagination, people work somewhere but not admit that they work somewhere when talking about the company. That's called fraud.Matty: Right. No, no, and I don't think it's even—but I'm saying beyond just, if it's not, if you're a cop, you have to tell me, right?Corey: [laugh].Matty: It's like, it's not—if asked, I will tell you I work at AWS. It's like in that place, it should say, “I am an AWS em—” like, I should be badged that way, just so it's clear. I think that's actually helpful in two ways. It's also helpful because it says like, okay, maybe you have a connection you can get for me somehow. Like, you might actually have some different insight or a way to chase something that, you know, it's not necessarily just about disclosure; it's also helpful to know.But I think within those spaces, that disclosure—or not disclosure, but being an employee does not offer you any more authority. And part of that is just having to be very clear about how you're constructing that community, right? And that's sort of the way that I think about it is, like, when we did the Pulumi Community Summit about a year ago, right? It was an online, you know, thing we did, and the timing was such that we didn't have a whole lot of Pulumi engineers were able to join, but when we—and it's hard to say we're going to sit in an open space together and everybody is the same here because people also—here's the difference. You say you want this authority? People will want that authority from the people that work at the company and they will always go to them and say, like, “Well, you should have this answer. Can you tell me about this? Can you do this?”So, it's actually hard on both cases to have that two-way conversation unless you set the rules of that space such as, “Okay, I work at Aiven, but when I'm in this space, short of code of conduct or whatever, if I have to be doing that thing, I have no more authority on this than anyone else.” I'm in this space as the same way everyone else's. You can't let that be assumed.Corey: Oh, and big companies do. It's always someone else's… there's someone else's department. Like, at some level, it feels like when you work in one of those enormous orgs, it's your remit is six inches wide.Matty: Well, right. Right. So, I think it's like your authority exists only so far as it's helpful to somebody. If I'm in a space as an Aivener, I'm there just as Matty the person. But I will say I work at Aiven, so if you're like, “God, I wish that I knew who was the person to ask about this replication issue,” and then I can be like, “Aha, I actually have backchannel. Let me help you with that.” But if I can say, “You know what? This is what I think about Kafka and I think why this is whatever,” like, you can—my opinion carries just as much weight as anybody else's, so to speak. Or—Corey: Yeah. You know, it's also weird. Again, community is such a broad and diverse term, I find myself in scenarios where I will observe and talk to people inside AWS about things, but I never want to come across as gloating somehow, that oh, I know, internal people that talk to you about this and you don't. Like, that's never how I want to come across. And I also, I never see the full picture; it's impossible for me to, so I never make commitments on behalf of other people. That's a good way to get in trouble.Matty: It is. And I think in the case of, like, someone like you who's, you know, got the connections you have or whatever, it's less likely for that to be something that you would advertise for a couple of reasons. Like, nobody should be advertising to gloat, but also, part of my remit as a member of a community team is to actually help people. Like, you're doing it because you want to or because it serves you in a different way. Like, that is literally my job.So like, it shouldn't be, like—like, because same thing, if you offer up your connections, now you are taking on some work to do that. Someone who works at the company, like, yes, you should be taking on that work because this is what we do. We're already getting paid for it, you know, so to speak, so I think that's the—Corey: Yeah.Matty: —maybe a nuance, but—Corey: Every once in a while, I'll check my Twitter spam graveyard, [unintelligible 00:32:01] people asking me technical questions months ago about various things regarding AWS and whatnot. And that's all well and good; the problem I have with it is that I'm not a support vector. I don't represent for the company or work for them. Now, if I worked there, I'd feel obligated to make sure this gets handed to the right person. And that's important.The other part of it, though, is okay, now that that's been done and handed off, like do I shepherd it through the process? Eh. I don't want people to get used to asking people in DMs because again, I consider myself to be a nice guy, but if I'm some nefarious jerk, then I could lead them down a very dark path where I suddenly have access to their accounts. And oh, yeah, go ahead and sign up for this thing and I'll take over their computer or convince them to pay me in iTunes gift cards or something like that. No, no, no. Have those conversations in public or through official channels, just because I don't, I don't think you want to wind up in that scenario.Matty: So, my concern as well, with sort of taking the tack of you are just an observer of the community, not a part of it is, that actually can reinforce some pretty bad behavior from an organization towards how they treat the community. One of the things that bothers me—if we're going to go on a different rant about devrelopers like myself—is I like to say that, you know, we pride ourselves as DevRels as being very empathetic and all this stuff, but very happy to shit all over people that work in sales or marketing, based on their job title, right? And I'm like, “Wow, that's great,” right? We're painting with this broad brush. Whereas in reality, we're not separate from.And so, the thing is, when you treat your community as something separate from you, you are treating it as something separate from you. And then it becomes a lot easier also, to not treat them like people and treat them as just a bunch of numbers and treat them as something to have value extracted from rather than it—this is actually a bunch of humans, right? And if I'm part of that, then I'm in the same Dunbar number a little bit, right? I'm in the same monkey sphere as those people because me, I'm—whoever; I'm the CTO or whatever, but I'm part of this community, just like Joe Smith over there in Paducah, you know, who's just building things for the first time. We're all humans together, and it helps to not treat it as the sort of amorphous blob of value to be extracted.So, I think that's… I think all of the examples you've been giving and those are all valid concerns and things to watch out for, the broad brush if you're not part of the community if you work there, my concern is that that leads towards exacerbating already existing bad behavior. You don't have to convince most of the people that the community is separate from them. That's what I'm sort of getting at. I feel like in this work, we've been spending so much time to try to get people to realize they should be acting like part of their larger community—and also, Corey, I know you well enough to know that, you know, sensationalism to make a point [laugh] works to get somebody to join—Corey: I have my moments.Matty: Yeah, yeah, yeah. I mean, there's I think… I'll put it this way. I'm very interested to see the reaction, the response that comes out in, well now, for us a couple of days, for you the listener, a while ago [laugh] when that hits because I think it is a, I don't want to say it's controversial, but I think it's something that has a lot of, um… put it this way, anything that's simple and black and white is not good for discussion.Corey: It's nuanced. And I know that whenever I wrote in 1200 words is not going to be as nuanced of the conversation we just had, either, so I'm sure people will have opinions on it. That'd be fun. It'd be a good excuse for me to listen.Matty: Exactly [laugh]. And then we'll have to remember to go back and find—I'll have to do a little Twitter search for the dates.Corey: We'll have to do another discussion on this, if anything interesting comes out of it.Matty: Actually, that would be funny. That would be—we could do a little recap.Corey: It would. I want to thank you so much for being so generous with your time. Where can people find you if they want to learn more?Matty: Well, [sigh] for the moment, [sigh] who knows what will be the case when this comes out, but you can still find me on Twitter at @mattstratton. I'm also at hackie-derm dot io—sorry, hackyderm.io. I keep wanting to say hackie-derm, but hackyderm actually works better anyway and it's funnier. But [hackyderm.io/@mattstratton](https://hackyderm.io/@mattstratton) is my Mastodon. LinkedIn; I'm. Around there. I need to play more at that. You will—also again, I don't know when this is coming out, so you won't tell you—you don't find me out traveling as much as you might have before, but DevOpsDays Chicago is coming up August 9th and 10th in Chicago, so at the time of listening to this, I'm sure our program will have been posted. But please come and join us. It will be our ninth time of hosting a DevOpsDay Chicago. And I have decided I'm sticking around for ten, so next year will be my last DevOpsDay that I'm running. So, this is the penultimate. And we always know that the penultimate is the best.Corey: Absolutely. Thanks again for your time. It's appreciated. Matty Stratton, Director of Developer Relations at Aiven. 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 talking about how I completely missed the whole point of this community and failing to disclose that you are in fact one of the producers of the show.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.

In this episode, Rob Ocel, is joined by Trecia Kat, to talk about breaking into tech, building a social media following, and finding community. They discuss how to find a niche through being yourself on social media, choosing between DevRel and engineering career paths, CSS, and even their hopes and fears for the Marvel Cinematic Universe.   Guest Trecia Kat, Self-Taught Developer and DevRel Engineer   Host Rob Ocel, Engineering Lead & Software Architect at This Dot Labs   Sponsored by This Dot Labs

Matt interviews Peter Pouliot from Ampere (https://amperecomputing.com). They discuss Peter's experience with working on OpenStack for Microsoft, developer relations in his latest role at Ampere, and how to strategically choose your conference parties to attend. Links: Ampere Altra Developer Platform (https://amperecomputing.com/systems/altra/kraken-comhpc-WS) Linux on Microsoft Dev Kit 2023 (https://blog.alexellis.io/linux-on-microsoft-dev-kit-2023/) Ampere Developer Program (https://amperecomputing.com/developers) Contact Peter: LinkedIn (https://www.linkedin.com/in/peterpouliot/) SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Photo Credits Header (https://amperecomputing.com/_next/image?url=https%3A%2F%2Fsolutions-portal-cms-prod-bucket.s3.amazonaws.com%2FAmpere_Product_Page_035d9bec1c.png&w=1920&q=75) Special Guest: Peter Pouliot.

Wes and Jason talk through some of the nuance around using AI in devrel, including how it can benefit us and areas to be cautious in. Enjoy the podcast? Please take a few moments to leave us a review on iTunes (https://itunes.apple.com/us/podcast/community-pulse/id1218368182?mt=2) and follow us on Spotify (https://open.spotify.com/show/3I7g5WfMSgpWu38zZMjet?si=565TMb81SaWwrJYbAIeOxQ), or leave a review on one of the other many podcasting sites that we're on! Your support means a lot to us and helps us continue to produce episodes every month. Like all things Community, this too takes a village.

As the world of Artificial Intelligence continues to evolve,it's increasingly evident that AI tools are rapidly changing the way we work in Developer Relations & Community Building. Tools like ChatGPT and GitHub Copilot are transforming the landscape of our work by .. automating tedious and repetitive tasks ..providing valuable insights and analytics..and even helping to generate content on our behalf. However, the integration of AI into our industry also raises new questions. Can AI truly enhance the work of DevRel practitioners and allow us to focus on different challenges.. or will it end up diminishing our creativity and impact on supporting developers? How do we make sure AI is used ethically and responsibly? And what impact will it have on the future of not only DevRel, but software development in general? Join us as we explore the exciting world of AI in Developer Relations on this episode of "The Community Pulse". Checkouts Chris DeMars * 3 Ways Feature Flags Could Have Saved Jurassic Park (https://www.split.io/blog/3-ways-feature-flags-could-have-saved-jurassic-park/) * I'll be at Orlando Codecamp (https://orlandocodecamp.com/) in March; DEVNEXUS (https://devnexus.com/) in Atlanta, Georgia, in April; and Chain React (https://chainreactconf.com/) in Portland, Oregon, in May. Rizel Scarlett * DevRel for Black Developers (https://www.youtube.com/live/8AZyqiQ3RKc?feature=share) * Finding Me by Viola Davis (https://www.amazon.com/Finding-Me-Memoir-Viola-Davis/dp/0063037327) * BlackRel Discord - a discord for Black folks in Developer Relations - sign up form (https://tinyurl.com/blackrel-discord) Wesley Faulkner * Elk Alpha (https://elk.zone) - A nimble Mastodon web client * The ChatGPT Cheat Sheet (https://drive.google.com/file/d/1UOfN0iB_A0rEGYc2CbYnpIF44FupQn2I/view) Jason Hand * 8 Things You Didn't Know you Could do with GitHub CoPilot (https://github.blog/2022-09-14-8-things-you-didnt-know-you-could-do-with-github-copilot/) * Platonic : How the Science of Attachment Can Help You Make--and Keep--Friends (https://www.amazon.com/Platonic-Science-Attachment-Make-Keep-Friends/dp/0593331893) by Dr. Marisa G. Franco * Learning From Incidents Conference (https://www.learningfromincidents.io/) (in Denver) * The Darker Side of ChatGPT (https://towardsdatascience.com/not-all-rainbows-and-sunshine-the-darker-side-of-chatgpt-75917472b9c) * ChatGPT for writing technical articles and documentation (https://blog.almaer.com/developer-docs-genai-%e2%9d%a4%ef%b8%8f/) * Developer Docs + GenAI (https://blog.almaer.com/developer-docs-genai-%e2%9d%a4%ef%b8%8f/) AI Tools Caption: For Talking Videos (https://apps.apple.com/us/app/captions-for-talking-videos/id1541407007) NVIDIA: Eye Contact (https://www.nvidia.com/en-us/geforce/broadcasting/broadcast-app/) Descript (https://www.descript.com/) Grammarly (https://www.grammarly.com/) Interesting Articles * The Darker Side of ChatGPT (https://towardsdatascience.com/not-all-rainbows-and-sunshine-the-darker-side-of-chatgpt-75917472b9c) * ChatGPT for writing technical articles and documentation (https://blog.almaer.com/developer-docs-genai-%e2%9d%a4%ef%b8%8f/) * Developer Docs + GenAI (https://blog.almaer.com/developer-docs-genai-%e2%9d%a4%ef%b8%8f/) Enjoy the podcast? Please take a few moments to leave us a review on iTunes (https://itunes.apple.com/us/podcast/community-pulse/id1218368182?mt=2) and follow us on Spotify (https://open.spotify.com/show/3I7g5WfMSgpWu38zZMjet?si=565TMb81SaWwrJYbAIeOxQ), or leave a review on one of the other many podcasting sites that we're on! Your support means a lot to us and helps us continue to produce episodes every month. Like all things Community, this too takes a village. Artwork photo by Emiliano Vittoriosi (https://unsplash.com/@emilianovittoriosi?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash (https://unsplash.com/@emilianovittoriosi?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) Special Guests: Chris DeMars and Rizel Scarlett.

DevRel at CockroachDB, Aydrian Howard, joins us to talk about how CockroachDB gives all of your apps effortless scale, bulletproof resilience, and more. Links https://twitter.com/itsaydrian https://beacons.ai/aydrian https://www.twitch.tv/itsaydrian https://twitter.com/cockroachdb https://www.cockroachlabs.com Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Aydrian Howard.

Public cloud usage. Cloud-native application development. Developer relations. In a down economy, everything gets questioned. Expect a lot of naysayers and doubters. SHOW: 695CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:CloudZero – Cloud Cost Visibility and Savings​​CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendSection is the fastest, easiest and most cost-effective way to run applications across multiple clouds.Cloudcast listeners can experience the benefits of unparalleled performance and uptime, plus the ability to scale as needed. There's no risk to try it out – run one project for free with no credit card required!Did you know that 87% of container images in production include a high or critical vulnerability? No wonder prioritization is difficult. Download the Sysdig 2023 Cloud-Native Security and Usage report to dig into the state of cloud and container usage.SHOW NOTES:Kubernetes is great, but it's been a 7 year distraction (and this thread)Cloud players sound a cautious tone in 2023Is DevRel as an idea being abandoned?THE CURVE IS BENDING DOWN, SO QUESTION EVERYTHINGThe public cloud is no longer economically viableDistributed systems are not practicalKubernetes is now too difficult to useDeveloper relations (DevRel) is no longer needed by vendorsTHE DIFFERENCE BETWEEN EARLY ADOPTERS AND MAINSTREAMEarly adopters typically have a specific problem they are trying to solveNear-term and long-term goals don't always alignThe ROI of technology doesn't always happen immediatelyResume-driven-development is a real thing in good timesEconomic downturns shine a light on practicality and profitabilityGreed is a factor in good times and bad timesFEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

Episode SummaryFloor Drees, Staff Developer Advocate at Aiven, joins Corey on Screaming in the Cloud to discuss her journey into the world of open source and the opportunities she sees to improve developer relations. Floor and Corey dive into the pitfalls and opportunities of being a frequent speaker at events, and Floor shares some best practices to help be prepared for those opportunities. Floor also shares why she feels events should include hybrid remote attendance options, and the benefits of hosting local events to breathe life into new relationships within the developer community. Floor and Corey also discuss the complexities of maintaining an open-source project and what goes into keeping an open-source community healthy and thriving. About FloorFloor is a Staff Developer Advocate at Aiven, a company that manages your favorite open source data tools for you without exploiting the projects and their maintainers. Previously Floor worked in DevRel at Grafana Labs and Microsoft. She is a Devopsdays Core member, and organizes the Devopsdays Amsterdam and Eindhoven chapters. She is a Microsoft MVP for Developer Technologies, and organizes a bunch of meetups, including-but-not-limited-to contributing.today, DevRel Salon Amsterdam, and the Amsterdam Ruby Meetup. Floor is also an art school graduate, who stumbled into tech face-first.Links Referenced: Aiven: https://aiven.io floor.dev: https://floor.dev Mastodon: https://mastodon.lol/@floord Twitter: https://twitter.com/floordrees dev.to: https://dev.to/floord

With over 80% developer growth the past year, the Solana ecosystem has never been stronger. Chase Barker, Head of Developer Ecosystem at The Solana Foundation joins Brian Friel to talk about the current initiatives happening on Solana that excite him the most, along with the biggest opportunities he sees for Developers on Solana in episode 20 of The Zeitgeist. Show Notes:00:05 - Intro                            01:56 - Background / Start with Solana                        11:49 - Highlights from last year with the developer ecosystem16:13 - Latest exciting initiatives in Solana                  20:56 - Opportunities for devs in Solana 25:03 - Opportunities to build a project on Solana27:36 - Solana plays Pokemon" game           30:43 - Where will Solana be in 5 years                          32:55 - A builder he admires Full Transcript:Brian Friel (00:00):Hey, everyone and welcome to The Zeitgeist, the show where we highlight the founders, developers, and designers who are pushing the web 3.0 space forward. I'm Brian Friel, developer relations at Phantom and I'm super excited to introduce none other than the man, the myth, the legend, Chase Barker of Solana Foundation. Chase, welcome to the show.Chase barker (00:24):Hey man, thanks for having me.Brian Friel (00:26):This has been a long time coming. For those who don't know, Chase is the head of developer ecosystem at Solana Foundation. He's one of the earliest guys you could have seen if you were a developer coming into Solana. And it's special for me personally because Chase was the first person I reached out to on Solana. We actually did an episode on your old podcast, Chewing Glass at one point. It's great to be on the other side of the mic though, but officially welcome to the show, Chase.Chase barker (00:49):Thanks man. Yeah, it was super cool and it's also wild for me to be on this other side because we met in some interesting circumstances, you trying to dive into the whole ecosystem and I had no idea what I was doing and I needed help. And you wrote some really cool shit for me for the Solana Cookbook and here you are, leading Phantom. So anyways, I won't dive into that too much. Maybe we'll talk about it later, but it's super cool to be here, so thanks for having me.Brian Friel (01:15):Yeah, thanks for coming on. No, I couldn't agree more. Probably a good place to start, is maybe rewinding time a little bit, going back to some of those early days. Solana's pretty unique from a developer perspective. There was always, having worked in the industry pre-2018, it was always... If you're doing something development wise, solidity is the only game in town you got to be working in EVM. And Solana basically struck it out on its own and completely changed that narrative and you were around to see pretty much that whole evolution. Can you talk a little bit about your journey to finding Solana? Who are you, what were you doing, and what have you seen evolve in Solana since you've been there?Chase barker (01:56):Yeah, for sure. So I've told this story a lot and I'm going to keep this one shorter than I normally do, but I was an engineer for 12 years and then started trading crypto in 2017, made a bunch of money, lost it all in 2018, like most people. And then along that journey I found this project, Kin, who now exists on Solana, but they had their own fork of Stellar and I was into crypto and the bear market in 2018 and they had this hackathon thing and I built a tip bot with a group of other people to be able to tip on Reddit, discord, Twitter and Telegram. And I was like, okay, this is really cool. I really sort of hate my web2 job right now. I'm doing this government contracting work working on legacy Spring VC systems. It was miserable and I've talked about this a lot before and I just got everybody's email addresses and started saying, give me a job.(02:47):And they told me that all the jobs were based in Tel Aviv, but they have this developer relations role for Kin. And I was like, okay, that sounds great. What the hell is that? I had no idea what developer relations was at the time. So did a little bit of research, ended up taking the role and really just started working. They had an SDK, but documentation tried to grow a community. It's a little bit different. I'll get into this from Solana because Kin was like, this is the ICO days. Nobody really gave a shit about use cases. It was just like how am I going to be the most degenerate thing here. It was way ahead of its time, but eventually flash forward after a couple years of really loving what I was doing, traveling around the world, speaking at conferences, and helping people learn how to build in crypto.(03:31):And I heard, and it's March or April 2020 way early, and I'm talking, nobody that I knew, knew about Solana. So they were like, we're going to migrate to Solana this new blockchain. Nobody knows about it, but it's going to be super fast. Our tech team says it's great. So I followed along. Around December, I was involved in the migration process and I had spoken with Dan Albert, who's now the head of the Solana Foundation, and Raj and I engaged with a bunch of these guys but didn't really know them, but I was part of that migration. And then a little bit later into 2021, early 2021, people don't know this, but actually I was leaving Kin and I was looking for another role and I got hired by Circle for one week as a developer advocate. And then I saw Solana had a developer relations role, applied.(04:21):So I actually had an awkward situation where I had to tell Circle that “I know I just started, but I'm going to go work at Solana.” But the reason I worked at Solana is because I just DMed the shit out of Raj and Dan until they finally submitted into saying, okay, finally we're we're going to let you take this role. And at that time all that existed was the core documentation and the PaulX Escrow tutorial, aka the Solana Bible. And that was the start. May 5th, the day after my birthday of 2021, I joined Solana as the first sort of developer advocate and that's sort of the entry point.Brian Friel (05:01):Wow. So yeah, it's not really that long in calendar days. Chase barker (05:07):It's been 20 years. It's been 20 years.Brian Friel (05:09):Yeah, exactly. 20 years in crypto years for sure. A lot has changed since then. Maybe the only thing that hasn't changed is the strategy of just spam DMing somebody to try to get a job. I definitely tried to employ that with you back in the day. I know a few other people who have successfully deployed that strategy as well. But yeah, it's been crazy. There's a lot to talk about here. Maybe we just focus on the last year in particular because you mentioned 2021, it's a pretty crazy year. There was just the public tutorial on the docs and then all these people come in, you get anchor that gets built around that time. Solana takes off, a bunch of independent teams.Chase barker (05:49):Actually, let's go a little bit before that because I think this is just a really interesting thing and I like telling this part because when I started at Kin I was begging people to build on it because nobody was really building on blockchain except Ethereum at the time. And then I started with Solana and I had the exact opposite problem. You had a ton of people that were like, hell yeah, this sounds really awesome, but how the hell do you build on this thing? What the hell is rust? There's no documentation. You go into the Discord and the cord devs are just “go read the tests, that teaches you how to build on Solana.” And that's literally the world that we lived in at the time. And then started putting together this sort of part-time dev advocate team, if you want to call it that. I just skimmed Discord and looked for people who were helping others and be like, hey, come over here into this private discord with me.(06:39):And I'm like, help me scale myself. Because I was starting to write some example code and there was none of that. And then luckily I met Donnie and then Jacob and a couple other guys that are now full-time at Solana Foundation and they were helping in dev support. Jacob was working on the Java STK with Skynet Cap, if any of you guys know him. He was really one of the early OGs there. And then this whole group formed and they were writing content and then you reached out and contributed to the Solana cookbook and this whole thing just came out of nowhere. And I was literally sinking. The demand for Solana was so high because the tech was so new and the sort of hardcore engineers just really wanted to build, and the Dafi's and the Max's and the Armani's just figured the shit out.(07:28):But everybody else was like, let me, let me. And I could not do that on my own. I didn't even have the brain big enough to supply the knowledge to all these people. And then long story short, or maybe long story long is that you and I started talking and you wanted to be part of it and you wrote some really important stuff for the Solana Cookbook, I think retries, possibly PDAs and some of these other things. And it's like, thank you. And I do remember you being like, hey, can I work at Solana? And I didn't have any approval of power at the time and you left me and probably a month later I got approval to hire somebody else, but by that time you were at Phantom, but it seems like it worked out. So it is what it is.Brian Friel (08:12):I think you're right about the demands being so strong for people to figure it out that you just saw people coming together. A lot of times, you look at people who are evangelizing new tech and they're like, hey, here's this awesome thing. Try to explain it. And the first reaction of everyone is like, okay, cool, but then they just move on. And I feel like Solana was one of the few cases where that was the opposite, where everybody was like, this is incredible. How do I use this thing? How do I build this thing? And it was just this hive mind of people coming out of the woodwork to try to make it happen.Chase barker (08:43):Even me leading into Solana, and I say this a lot too because it's true in my mind, and I was like, listen to Anatoli and all this stuff, and I'm one of two things. This is the giant scam, or this is actually really fucking awesome. And luckily my instincts were right on that one and everything sort of worked out. And when I met you and then we started doing this part-time DevRel team that you were a part of for a while, first Solana Foundation.(09:09):And the next thing, my Twitter account became this thing where people would create content and I would share it and then somebody else would be like, oh, I want my shit shared. And then they would make content and I would share it. And this was this huge flywheel and that's really what turned into my account was this person who, you do cool shit, I'm going to share it. And then I became this other guy where I'm also, I do stupid shit and then I also share good shit. So it's this perfect mix of this idiot and then this guy who knows where the good stuff is.Brian Friel (09:46):You either die a developer or you live long enough to be a Twitter celebrity, I guess in your case?Chase barker (09:52):Yeah, I mean I don't necessarily love the celebrity side, but I do love getting DMs from people to say, Hey, all the things that you shared, and you probably hear some of the same like, hey, I got a job here because of this tweet that you made or this thread because I started making threads, who's looking for a job or who's whatever. And in the early days that's all we had, was Twitter. There was no other way to connect. I made a Twitter developer list and I added 300 people to it so that not everybody had to come into Solana Twitter and be like, follow each individual person and these were such manual, weird, really hard... I had no idea what I was doing. Luckily people showed up and were there and then just ran with it. I mean, looking back, dude, it's just awesome to look and see what's happened since then.Brian Friel (10:40):Yeah, no, I couldn't agree more. Lots of connections made in those early days, like you said too, where people get jobs, all this kind of stuff happens and it's crazy how little interactions like that go really far.Chase barker (10:49):Yeah, exactly.Brian Friel (10:50):So I guess taking it now to this past year, so we're recording this January 2023. The past year in particular, if you were just an outside observer looking at crypto, you're like, wow, prices are way down, everything's dead. And there's a report that comes out just the other day, Electric Capitalist Developer Report, which says Solana developers grew over 80% in the year. You and I... I had an intuition for this, I'm sure you did too. It was just developer activity.Chase barker (11:20):I didn't have intuition. I actually knew.Brian Friel (11:23):Yeah, you knew. But other people I'm sure had intuition if you're around the developer ecosystem, it's not stopping. Developer activities keeps picking up, summarize a little bit in your words over the last year, what has stood up to you? What are some of the highlights? You mentioned you started this thing and it's just you and DMing people on Twitter and getting this thing going. Now it's a serious operation of a developer ecosystem here going. What are some of the things you're most proud of that stood out to you?Chase barker (11:50):Yeah, so I think the start of the year in January of 2022, we're all sitting there, and the crypto markets nuke, and the blockchain literally is devastated. And that was any sort of pre any sort of ideas about what is wrong, what is it? Basically it was all these sort of liquidators, spamming to try to liquidate people and that just turned into this thing. And I think by that point in time though, we had some really high conviction developers that were already super invested themselves in Solana. So they stuck around and I think that's very unique for that to happen. Everybody's like, when are you going to fix this? But it literally took two to three months before they even identified what those solutions might be and those solutions to many of you, the devs out there were quick and fee-markets and some of these other things that improved.(12:45):But even though these solutions were being built, that shit takes time. So during that same time, Solana NFTs were going through the roof and these bots were spamming the network. Luckily we're flash forward briefly to right now all of those things have been implemented, but the work is never complete. But we've been pretty battle tested and recently, but I think to your original question, what I'm most proud of is being able to keep that morale up, being able to really build out this sticky community and I'm focused on devs, but it's not just the devs. Without that normal diehard community, without the Dev community, without the NFT community, we would've failed miserably like every other blockchain that tried to do what we did failed.(13:33):But I think a lot of this really comes down to personal relationships and when you come into Solana and you get involved, people really cheer you on and there's that sort of camaraderie there that kept people here, even in the darkest of times. I'm just really happy. Like I said, I knew that those numbers were high and to be honest, a lot of the reason while I've been memeing about the 75 developer ridiculous reports that have been coming out, I was memeing it so hard in the last couple weeks because we crawled GitHub internally and we know where our dev numbers are and we always make sure that we know where those things are. So it was sort of funny to me to just keep memeing that and then knowing Electric Capital was going to put out a report that sort of reflected... at least they have some pretty strict rules around what they constitute a dev. Our numbers are slightly higher, but their rules are strict. As a full-time dev, you have to commit code X amount of days per month or whatever that is.(14:32):I'm sure they have that somewhere and the way that they do it, but yeah man, it takes a village to do this and there's not one person you can point to, but there's obviously some champions out there that really made people inspired to continue building. The proudest thing I can think of is all the shit we took this year and we're still here and now we just have been pretty much named and given the silver medal of the second strongest developer community in crypto and you got to give a shout-out to Eat the Kings, fully open source and putting up numbers for devs, so you got to give them credit.Brian Friel (15:06):Yeah, we mentioned a little bit early on about how it was a narrative violation for Solana to have a completely different programming paradigm to not be using Solidity to get into an account model lower level dealing with Rust.Chase barker (15:20):There was FUD that was like “Solana's using Rust? Good luck. You guys are basically screwed.” Nobody's ever going to build on Rust. So that was false.Brian Friel (15:29):Yeah, most loved GitHub developer language though I'm pretty sure that's another narrative violation for you there. So talking a little bit more about what you guys have been up to you, you mentioned you guys have been crawling the GitHubs and you've seen this dev activity, you now have a full-time team like you said that, that you're working with, but it's not just you guys at Solana Foundation, there's all these other ecosystem teams now. There's people like Super Team Dao who are doing their own thing, coordinating devs and building devs. I'd say there's stuff on the community side getting devs and raising awareness there. There's Lamport DAO, I might be giving you too many answers here, but the community side and the tech side, what are some of the initiatives that are happening right now in Solana that have you most excited?Chase barker (16:14):I think one of the most important things to note about Solana Foundation and Labs in general is the headcount stays low. This sounds weird to a lot of people, but our job is to make ourselves irrelevant in the next five to 10 years as an organization, the super team and the Lamort DAOs and Meta Camp and Singapore in these different groups, a lot of them will get grants from the foundation to get themselves up and running. But after that they basically become these sort of miniature Solana foundations where they start growing their community from the inside out and giving out grants and doing all these really cool things. But you think of Solana as this giant bubble and every time one of these new miniature groups spins out, the Solana Foundation bubble gets smaller, and then these other bubbles start getting more and plentiful to eventually you reach a point where Solana Foundation bubble was the size of the rest of these small groups.(17:08):This is the antithesis of Web 2.0, hiring as many people in as much headcount as you can and trying to own everything. I don't want to own everything. I want to find Mertz, I want to find Super Teams. I want to find Meta Camps and I don't want to just go find them and ask them. I want to find these guys that just put everything they have into Solana the blockchain and they're just so passionate about it, that it's like this is the team that we want to put our energy behind. In the beginning it really was a lot of us at Foundation and Labs doing a lot of the talking, but now you have these stronger voices and I'm not going to lie, it makes my life a lot easier to not have to be doing all that talking online anymore, but I still do it.(17:53):And I think the important point here is that if we're going to become a decentralized blockchain, we also want to become a decentralized organization itself and that means nobody has to get our permission. I think one of the greatest examples of no permission is Hacker House was kicked off, everybody's like, when my city and MTN DAO was like, fuck this, I'm just going to make my own thing. And they actually built the best thing that's really happened out of our community to date and they produced multiple, clockwork previously, Kronos, mtnPay, all these guys won hackathons.(18:33):Because T.J. Littlejohn literally came up with mtnPay at MTN DAO and a food line being like, Solana Pay just came out. Oh shit, maybe I should just build a payment thing with this new thing. And then he set up the system and people were paying with USD right there. So if that trajectory keeps happening through Solana, and I know other blockchains are trying to emulate what we do, but there's no way to emulate this unless you actually do this organically and it's happening. And anytime I just find somebody like a TJ or a  MERT or whoever or a Brian or whatever, I'm going to put all my time and energy behind them and that's literally my philosophy and the foundation's philosophy in general, I think.Brian Friel (19:15):Yeah, for sure. No, I've seen that too. It feels like there's more... Solana is the only ecosystem I know outside of Ethereum really is there are these factions not the best word, but it's these unofficial groups of people that... Maybe it started as simple as we like to ski in February and we want to get together and hack. MTN DAO, but it's becoming an official collective now. People are identifying with it. And it has influence in the community. I mean I totally see what you're saying too about the Hacker House is I know we had our own last summer, we kind of piloted the Summer Camp Hackathon fan of Sponsor [inaudible 00:19:51]. But I just see that model continuing to go and more and more teams coalescing around certain regions and sponsoring their own thing.Chase barker (19:57):And for everybody listening here, don't ask for permission, don't ask when, just literally do it. And if you do it and you do it well, the attention will get drawn onto you and then I'll come find you and I'll knock on your door and ask you how I can help. So that's really the sort of mentality that I personally have.Brian Friel (20:15):Yeah, I couldn't agree more with that. That was my approach trying to work in this space, just do it and then ask for help or permission. Someone will find you. That's so much better than trying to ask somebody for permission to do something. So I guess that's a good transition to, let's put ourselves in the shoes of a developer who's looking at Solana right now. There's a lot of devs out there that might see Solana and they still think, oh, Rust and scary. That's probably not true. We can talk about that. But there's also probably a lot of devs who maybe know a little bit about Solana, they're kind of like right on the cusp, because they want to jump in. What do you want to say to these devs? What are some of the biggest opportunities that these devs should be looking at right now in Solana?Chase barker (20:56):Yeah, I think there's a couple things here. I think it depends on your demographic and age range. I mostly meant age range. So if you're in college right now, look up solanau.org and it's @SolanaUni on Twitter because Dana is our university relations person who is absolutely crushing it, sponsoring and participating in hackathons, doing workshops, just really bringing in my opinion, the next generation, the most risk averse group of people are students who are still funded by their parents that can make some sort of mistakes early on. So they're the next generation that's going to take this forward and luckily they have some really tech heavy guys out there that are just so dedicated to this, the Solana core engineers and the Jito team and all these different groups that are there to mentor them when they're ready to get in this. But I think SolanaU is probably a really high leverage thing.(21:54):We spend a lot of time working with Build Space who's built Solana Build Space Core, which is an amazing program. Things are getting easier. We're still in that place where new things are coming around the corner and I get a lot of shit for this, especially from Rust maxi's, but there's Seahorse Lang where you can build smart contracts on Python right now, not fully ready for production. There's a version of this in typescript coming. We're doing whatever we can to make it easier because the Chewing Glass thing is true and it's mainly true not because of Rust, not because of Solana, it's because learning Rust and Solana and all those concepts at the same time, is literally painful as hell. But content and all these other things combined put together right now and all of the sort of tooling that different groups are building like indexers and all these things are making the lives easier because as adapt dev you want to deal with “get program accounts and all that stuff”, it's not...(22:56):We're getting to a better place and it's coming right now there's a couple places, I mean solana.com/developers we're curating our own list, but I cannot negate what ELO from SOL Dev has done at soldev.app and the whole entire thing that he's built out. So I'm super bullish on a lot of the stuff they're doing. I think there's just too many things to name of how many independent contributors are out there just building shit. I said this the other day on Twitter, I know when things are getting really good when I can't even keep up with the retweets of the things that are being built that I have no idea about. And then you have this other guy that most people don't really know yet. His name's Jonas and I think it's Soul Play Jonas on Twitter,Brian Friel (23:40):He's our hackathon winner.Chase barker (23:41):Is he?Brian Friel (23:42):Yeah. So when we hosted the Summer Camp Hackathon last summer, we had a Deep Links prize and he won as the best use of Deep Links because he was the first to build a Unity game on Solana using it.Chase barker (23:53):I'm not going to dox his location, but I'm going to tell you this mfr is legend and really going to try to push the gaming world forward on Solana, which I think is the blockchain that has the best ability to actually scale. And I want to give credit where it's due, zk-Tech is going to be fucking amazing, but Solana as is right now, has the best chance to scale if a big top tier sort of gaming company hits and decides to leverage that tag.Brian Friel (24:24):Yeah, let's talk about that a little bit because I had Anatoly on as the first guest and he always talked about how his dream was blockchain at Nasdaq speed and it was like “it's DeFi all the way". Then you and I are both around for the 2021 craze where it was just all of a sudden it's the world's greatest JPEG trading machine, it's all NFTs. Now we're seeing stuff about gaming. Is there a certain type of developers interested in something they should come to Solana? It's just like everybody... It's not necessarily specialization here, but what are some of the biggest opportunities maybe if you're looking to start a company on Solana, build a project on Solana?Chase barker (25:03):Yeah, I think we're being honest here. If your use case does not necessarily require high throughput, then the options are pretty unlimited in blockchain. But if you want to be able to have fully on chain games.. And not to say that we both know this, when you're building a game on any blockchain, not everything has to be on chain and it's almost like not necessary to the extent, but DeFi, we need to reignite that on Solana. There's been a series of unfortunate events that–whatever, but I think there's a really strong group of people that are working on this open book DEX and this massive amazing thing that came true. But for me personally, I think that the big unlock comes in gaming and the real original use case of crypto that has never actually been solved, which is payments. I mean it's been solved but not in a usable way. If you're going to bring payments to new and emerging markets, the fees and stuff are important because the fees on some of these different chains is more money than is-Brian Friel (26:12):Not feasible. It's a non-starter.Chase barker (26:13):It's not feasible. And Solana Pay and a lot of these other payment options are starting to enable that. And I think it honestly just has the potential to change a lot of lives, JPEGs and all these other things. That's cool. And I love that people are having fun on blockchain also. Solana is definitely the funnest chain by the way, but payments, man payments, we have to do it. We have to get payments, remittances done on chain and Solana's the most equipped to do it, especially related to fees.Brian Friel (26:45):Yeah, I love you said it too about it being the most fun chain, priding yourselves with that because for a while, and I think you noticed this, with every new blockchain, something that starts, the first thing everyone does is copy what worked before. We're going to have an AMM, we're going to do some DeFi thing, we're going to have an NFT marketplace. But I'm starting to see now on Solana things that are uniquely Solana and just couldn't be done elsewhere. And it definitely feels like there's a unique culture. And I'll shout out too, one, we talked about T.J. Littlejohn and you mentioned payments, the Solana pay spec. Yeah, you can send payments to anyone, but you could send any transaction. So he built that NFT photo booth. You take a photo, scan it, and it mints as an NFT using the payment protocol. It's pretty cool. There's another one though, we just had him on as a guest, which will launch fairly soon on this podcast. Have you seen the “Solana Plays Pokémon” game?Chase barker (27:37):Yeah, I have briefly, but I don't know a ton about it.Brian Friel (27:40):I don't know. It's a game like that... It's like you said, it doesn't have to be crazy. It's not everything on chain, but it's almost like a new genre of game because here you have this emulator that's sitting off chain, it's playing Pokémon and it's like anyone can permissionlessly show up and just start voting to say, press this button, press up, press down. And Solana's so fast that it's basically processing these very quickly and all of a sudden you have people warring over, should we train a Squirtle? Should we release the Squirtle? Should we fight this gym leader? It's a toy today, but you can kind of see how wow, this could become kind of a new game genre where it's multiplayer and, you don't know who you're even playing with or against and it's all real time. It's all being coordinated. It's pretty wild.Chase barker (28:22):I think a lot, and I'm a big advocate of looking at the Web2 world and seeing what is possible on Solana, and also what makes sense because not every use case makes sense, but for example, like I said, I mentioned Shek earlier and Wordcel Club, which is the blogging platform and they're doing some other cool social primitives and it's like they're starting to open source those primitives, but why would you do something on web 3.0 that you could do on Web 2.0? And the answer is sort of incentives. And you look at some of these bigger social platforms that absorb 99.9% of the value and there's a way to distribute that value on web 3.0 that there never was in web 2.0. So I think that's an important one. There might be some disagreement here, but I think the group that really got closest to some sort of web 2.0 success was Stepn, because they went product first instead of... You see a lot of stuff in web 3.0 of it's like, developers first developing for developers, they're developing for things like that.(29:27):But Stepn was like, what does everybody do that we could reward them for and get this on chain? And that was working out, this is an incentive mechanism. Obviously it didn't fully work out and I think there's probably... They're working on that, but at the same time, we need to start thinking what in the web 2.0 world is working, how can we do that on web 3.0, and why would that app make sense in web 3.0? And then usually it's incentive mechanisms that give the user a reason to use it, but they're not going to do that with massive delays or lag times or all this stuff. It better work just like web 2.0 if not better if you're going to do that. So really focusing on things that Solana can do that other blockchains can't at this current moment is probably going to be some of the highest rate of success or at least some more of the higher impact things I think.Brian Friel (30:21):Yeah, I agree. It's got to be seamless in the background. There's people in crypto who care, but the vast majority of people don't want to sit around and wait for something to load. So we talked a lot about the state of Solana today, what you're excited about all these different people building. You alluded to this a little bit, but paint a picture for us. What do you see the Solana ecosystem five years from now?Chase barker (30:43):Five years from now, I see myself not having a job anymore, and I'm okay with that because I've said this since day one. If I do my job the way that I'm supposed to do my job by empowering, enabling others, then there's no need for a me anymore. And any true ecosystem that has a foundation or a labs, whatever, there should be a point that they're looking towards. The North Star is literally being able to walk away and that community in those small groups that you've sort of empowered and sort of distributed out, you can walk away and that shit just runs itself forever.(31:19):That's not just the blockchain that's actually distributed community, not just the distributed blockchain. So that's the North Star. Five years, probably not likely, but I do think in the next five years that it's going to be about as easy to build on Solana as it is to build on React. That's what I have in my mind. And we have the firepower in the ecosystem and the dedicated people that I already see completely just trying to push with Seahorse and all these other things. People are just thinking, how can I make this easier for people if we're already there two to three years in from [inaudible 00:31:59] Beta Solana, we're progressing rapidly right now and if we keep that rate in the next five years, it's going to be insane.Brian Friel (32:09):Love that. And yeah, the beta tag, I'm sure given all the trials and tribulations, we will be shedding that beta tag soon.Chase barker (32:17):I haven't seen the Bernie meme in a while and if anybody listening to this doesn't know, Anatoly said that we're going to drop the beta tag after one year from the Bernie meme that he posts about validators.Brian Friel (32:27):Zero days since last Bernie meme. Really? Okay.Chase barker (32:31):I mean who knows if that happens, but I haven't seen him post that Bernie meme in a while, so we'll see. We'll see.Brian Friel (32:36):Yeah, I'll miss that Bernie meme. We'll put some pit vipers on Bernie again, just for all time sake. Well Chase, this has been an awesome discussion, really great having you on, and it's been a long time coming. One closing question we ask all of our guests, I want to hear it from you, is who is a builder that you admire in the Solana ecosystem?Chase barker (32:55):So my initial sort of instinct is to probably mention somebody that's never been really mentioned before, but I can't not just talk about Armani because he was part of the first wallet. He was part of the framework that made Solana better in terms of developer experience with Anchor. And I mean I know he's now building another wallet and it's just the truth. Armani, his whole sort of ethos and what he is trying to do is just trying to make crypto usable and better for a lot of people.(33:34):And I think that's just an important thing for me and I really respect that about him. So I truly think that Armani is one of the people that I really respect the most in the space for what he's done and transparently and just like everybody who has a very large voice gets a lot of shit. And for people like that to stick around, it's incredible. We all deal with it. You work at Phantom, I work at Solana Foundation. Armani has worked at various groups or whatever and we have to just continue what we're doing and just deal with all the that shit we get and you just got to respect that, man. So that's pretty much my answer.Brian Friel (34:17):That's Awesome. I couldn't agree more. Well, Chase, it has been awesome having you on. Thank you so much for your time. Where can developers go to get started with Solana?Chase barker (34:27):Solana.com/developers or I'll also not show our own stuff and you can go to soldev.app as well. We have different offerings like soldev.app has a lot more, solana.com/developers has a little more curated smaller list, but both are very good options. So yeah man, that's the place. So check it out and let's get going.Brian Friel (34:53):Love it. Chase Barker, head of developer ecosystem at Solana Foundation. Thank you so much.

About JeremyJeremy is the Director of DevRel & Community at CircleCI, formerly at Solace, Auth0, and XDA. He is active in the DevRel Community, and is a co-creator of DevOpsPartyGames.com. A lover of all things coffee, community, open source, and tech, he is also house-broken, and (generally) plays well with others.Links Referenced: CircleCI: https://circleci.com/ DevOps Party Games: https://devopspartygames.com/ Twitter: Iamjerdog LinkedIn: https://www.linkedin.com/in/jeremymeiss/ TranscriptAnnouncer: 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.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I generally try to have people that I know in the ecosystem on this show from time to time, but somehow today's guest has never made it onto the show. And honestly, I have no excuse other than that, I guess I just like being contrary about it. Jeremy Meiss is the Director of DevRel and Community at CircleCI. Jeremy, thank you for finally getting on the show.Jeremy: Hey, you know what? I woke up months and months ago hoping I would be able to join and never have, so I appreciate you finally, you know, getting that celestial kick in the ass.Corey: I love the fact that this is what you lie awake at night worrying about. As all people should. So, let's get into it. You have been at CircleCI in their DevRel org—heading their DevRel org—for approximately 20 years, but in real-time and non-tech company timeframes, three years. But it feels like 20. How's that been? It's been an interesting three years, I'll say that much with the plague o'er the land.Jeremy: Yes, absolutely. No, it was definitely a time to join. I joined two weeks before the world went to shit, or shittier than it already was. And yeah, it's been a ride. Definitely see how everything's changed, but it's also been one that I couldn't be happier where I'm at and seeing the company grow.Corey: I've got to level with you. For the longest time, I kept encountering CircleCI in the same timeframes and context, as I did Travis CI. They both have CI in the name and I sort of got stuck on that. And telling one of the companies apart from the other was super tricky at the time. Now, it's way easier because Travis CI got acquired and then promptly imploded.Security issues that they tried to hide left and right, everyone I knew there long since vanished, and at this point, it is borderline negligence from my point of view to wind up using them in production. So oh, yeah, CircleCI, that's the one that's not trash. I don't know that you necessarily want to put that on a billboard somewhere, but that's my mental shortcut for it.Jeremy: You know, I'm not going to disagree with that. I think, you know, it had its place, I think there's probably only one or two companies nowadays actually propping it up as a business, and I think even they are actively trying to get out of it. So yeah, not going to argue there.Corey: I have been on record previously as talking about CI/CD—Continuous Integration slash Continuous Deployment—or for those who have not gone tumbling down that rabbit hole, the idea that when you push a commit to a particular branch on Git—or those who have not gotten to that point, push the button, suddenly code winds up deploying to different environments, occasionally production, sometimes staging, sometimes development, sometimes by accident—and there are a bunch of options in that space. AWS has a bunch of services under their CodeStar suite: CodeBuild, CodeDeploy, CodePipeline, and that's basically there as a marketing exercise by CI/CD companies that are effective because after having attempted to set those things up with the native offerings, you go scrambling to something else, anything else. GitHub Actions has also been heavily in that space because it's low friction to integrate, it's already there in GitHub, and that's awesome in some ways, terrible in others. But CircleCI has persistently been something that I see in a lot of different environments, both the open-source world, as well as among my clients, where they are using you folks to go from developer laptops to production safely and sanely.Jeremy: Absolutely, yeah. And I think that's one thing for us is, there's a niche of—you know, you can start if you're into AWS or you're into Google, or you're in—any of those big ecosystems, you can certainly use what they have, but those are always, like, add-on things, they're always like an afterthought of, “Oh, we're going to go add this,” or, “We're going to go add that.” And so, I think you adequately described it of, you know, once you start hitting scale, you're eventually going to start to want to use something, and I think that's where we generally fit in that space of, you know, you can start, but now you're going to eventually end up here and use best-in-class. I spent years Auth0 in the identity space, and it was the same kind of boat is that, you know, sure you can start with hopefully not rolling your own, but eventually you're going to end up wanting to use something best-in-class that does everything that you want it to do and does it right.Corey: The thing that just completely blows my mind is how much for all these companies, no matter who they are and how I talk to them, everyone talks about their CI/CD flow with almost a sense of embarrassment. And back in the days when I was running production environments, we use Jenkins as sort of a go-to answer for this. And that was always a giant screaming exemption to the infrastructure-as-code approach because you could configure it via the dashboard and the web interface and it would write that out as XML files. So, you wound up with bespoke thing lots of folks could interact with in different ways, and oh, by the way, it has access into development, staging, and production. Surely, there will be no disasters that happened as a result of this.And that felt terrible. And now we've gotten into a place where most folks are not doing that anymore, at least with the folks that I talk to, but I'm still amazed by how few best practices around a lot of this stuff has really emerged. Every time I see a CI/CD pipeline, it feels like it is a reimplementation locally of solving a global problem. You're the director of DevRel and have been for a few years now. Why haven't you fixed this yet?Jeremy: Primarily because I'm still stuck on the fact you mentioned, pushing a button and getting to XML. That just kind of stuck me there and sent me back that I can't come up with a solution at this point.Corey: Yeah, it's the way that you solve the gap—the schism as it were—between JSON and YAML. “Cool, we're going to use XML.” And everyone's like, “Oh, God, not that.” It's like, “Cool, now you're going to settle your differences or I'm going to implement other things, too.”Jeremy: That's right, yeah. I mean, then we're going to go use some bespoke company's own way of doing IAC. No, I think there's an element here where—I mean, it goes back to still using best-in-class. I think Hudson, which eventually became Jenkins, after you know, Cisco—was it Cisco? No, it was Sun—after Sun, you know, got their hands all over it, it was the thing. It's kind of, well, we're just going to spin this up and do it ourselves.But as the industry changes, we do more and more things on the cloud and we do it primarily because we're relocating the things that we don't want to have to manage ourselves with all of the overhead and all of the other stuff. We're going to go spit it over to the cloud for that. And so, I think there's been this shift in the industry that they still do, like you said, look at their pipelines with a little bit of embarrassment [laugh], I think, yeah. I chuckle when I think about that, but there is a piece where more and more people are recognizing that there is a better way and that you can—you don't have to look at your pipelines as this thing you hate and you can start to look at what better options there are than something you have to host yourself.Corey: What I'm wondering about now, though, because you've been fairly active in the space for a long time, which is a polite way of saying you have opinions—and you should hear the capital O and ‘Opinions' when I say it that way—let's fight about DevRel. What does DevRel mean to you? Or as I refer to it, ‘devrelopers?'Jeremy: Uh, devrelopers. Yes. You know, not to take from the standard DevOps answer, but I think it depends.Corey: That's the standard lawyer answer to anything up to and including, is it legal for me to murder someone? And it's also the senior consultant answer, to anything, too, because it turns out the world is baked and nuanced and doesn't lend itself to being resolved in 280 characters or less. That's what threads are for.Jeremy: Right [laugh]. Trademark. That is ultimately the answer, I think, with DevRel. For me, it is depending on what your company is trying to do. You ultimately want to start with building relationships with your developers because they're the ones using your product, and if you can get them excited about what they're doing with your product—or get excited about your product with what they're doing—then you have something to stand on.But you also have to have a product fit. You have to actually know what the hell your product is doing and is it going to integrate with whatever your developers want. And so, DevRel kind of stands in that gap that says, “Okay, here's what the community wants,” and advocates for the community, and then you have—it's going to advocate for the company back to the community. And hopefully, at the end of the day, they all shake hands. But also I've been around enough to recognize that there comes that point where you either a have to say, “Hey, our product for that thing is probably not the best thing for what you're trying to do. Here, you should maybe start at this other point.”And also understanding to take that even, to the next step to finish up the answer, like, my biggest piece now is all the fights that we have constantly around DevRel in the space of what is it and what is it not, DevRel is marketing. DevRel is sales. DevRel is product. And each of those, if you're not doing those things as a member of the company, you're not doing your job. Everybody in the company is the product. Everybody in the company is sales. Everybody in the company is marketing.Corey: Not everyone in the company realizes this, but I agree—Jeremy: Yes.Corey: Wholeheartedly.Jeremy: Yes. And so, that's where it's like yes, DevRel is marketing. Yes, it is sales. Because if you're not out there, spreading whatever the news is about your product and you're not actually, you know, showing people how to use it and making things easier for people, you're not going to have a job. And too often, these companies that—or too often I think a lot of DevRel teams find themselves in places where they're the first that get dropped when the company goes through things because sometimes it is just the fact that the company has not figured out what they really want, but also, sometimes it's the team hasn't really figured out how to position themselves inside the business.Corey: One of the biggest, I'll call it challenges that I see in the DevRel space comes down to defining what it is, first and foremost. I think that it is collectively a mistake for an awful lot of practitioners of developer relations, to wind up saying first and foremost that we're not marketing. Well, what is it that you believe that marketing is? In fact, I'll take it a step beyond that. I think that marketing is inherently the only place in most companies where we know that doing these things leads to good results, but it's very difficult to attribute or define that value, so how do we make sure that we're not first up on the chopping block?That has been marketing's entire existence. It's, you know that doing a whole bunch of things in marketing will go well for you, but as the old chestnut says, half your marketing budget is wasted and you'll go broke figuring out which half it is.Jeremy: Yeah. And whenever you have to make cuts, generally, they always, you know, always come to the marketing teams because hey, they're the ones spending, you know, millions of dollars a quarter on ads, or whatever it is. And so yeah, marketing has, in many ways figured this out. They're also the team that spends the most money in a company. So, I don't really know where to go with that isn't completely off the rails, but it is the reality. Like, that's where things happen, and they are the most in touch with what the direction of the company is going to ultimately be received as, and how it's going to be spoken about. And DevRel has great opportunities there.Corey: I find that when people are particularly militant about not liking sales or marketing or any other business function out there, one of the ways to get through them is to ask, “Great. In your own words, describe to me what you believe that department does. What is that?” And people will talk about marketing in a bunch of tropes—or sales in a bunch of tropes—where it is the worst examples of that.It's, “Terrific, great. Do you want me to wind up describing what you do as an engineer—in many cases—in the most toxic stereotype of Uber and 2015-style engineer I can come up with?” I think, in most cases if we're having a conversation and I haven't ended it by now, you would be horrified by that descriptor. Yeah. Not every salesperson is the skeezy used car salesman trying to trick you into something awful. Actual selling comes down to how do we wind up taking your pain away. One of my lines is, “I'm a consultant. You have problems and money. I will take both.”Jeremy: That's right [laugh]. Yeah, that's right.Corey: If you don't have a painful problem, I have nothing to sell you and all I'm doing is wasting my breath trying.Jeremy: Yeah, exactly. And that's where—I'll say it two ways—the difference between good marketing teams are, is understanding that pain point of the people that they're trying to sell to. And it's also a difference between, like, good and bad, even, DevRel teams is understanding what are the challenges that your users are having you're trying to express to, you're trying to fix? Figure that out because if you can't figure that out, then you or your marketing team are probably soon to be on the block and they're going to bring someone else in.Corey: I'm going to fight you a little bit, I suspect, in that a line I've heard is that, “Oh, DevRel is part of product because we are the voice of the community back into the development cycle of what product is building.” And the reason that I question that is I think that it glosses over an awful lot of what makes product competent as a department and not just a function done by other people. It's, “Oh, you're part of the product. Well, great. How much formal training have you had as part of your job on conducting user research and interviews with users and the rest?”And the answer invariably rounds to zero and, okay, in other words, you're just giving feedback in a drive-by fashion that not structured in any way and your product people are polite enough not to call you out on it. And that's when the fighting and slapping begins.Jeremy: Yeah. I don't think we're going to disagree too much there. I think one of the challenges, though, is for the very reason you just mentioned, that the product teams tend to hear your product sucks. And we've heard all the people telling us that, like, people in the community say that, they hear that so much and they've been so conditioned to it that it just rolls off their back, like, “Okay, whatever.” So, for DevRel teams, even if you're in product, which we can come back to that, regardless of where you're at, like, bringing any type of feedback you bring should have a person, a name associated with it with, like, Corey at Duckbill Group hates this product.Corey: Uh-oh [laugh]. Whenever my name is tied to feedback, it never goes well for me, but that will teach me eventually, ideally, to keep my mouth shut.Jeremy: Yeah. Well, how's that working for you?Corey: I'll let you know if it ever happens.Jeremy: Good. But once you start making the feedback like an actual person, it changes the conversation. Because now it's like, oh, it's not this nebulous, like, thing I can not listen to. It's now oh, it's actually a person at a specific company. So, that's one of the challenges in working with product that you have to overcome.When I think about DevRel in product, while I don't think that's a great spot for it, I think DevRel is an extension of product. That's part of where that, like, the big developer experience craze comes from, and why it is a valuable place for DevRel to be able to have input into is because you tend to be the closest to the people actually using the product. So, you have a lot of opportunities and a big surface area to have some impact.Corey: This episode is sponsored in part by our friends at Strata. Are you struggling to keep up with the demands of managing and securing identity in your distributed enterprise IT environment? You're not alone, but you shouldn't let that hold you back. With Strata's Identity Orchestration Platform, you can secure all your apps on any cloud with any IDP, so your IT teams will never have to refactor for identity again. Imagine modernizing app identity in minutes instead of months, deploying passwordless on any tricky old app, and achieving business resilience with always-on identity, all from one lightweight and flexible platform.Want to see it in action? Share your identity challenge with them on a discovery call and they'll hook you up with a complimentary pair of AirPods Pro. Don't miss out, visit Strata.io/ScreamingCloud. That's Strata dot io slash ScreamingCloud.Corey: I think that that is a deceptively nuanced statement. One of the things I learned from an earlier episode I had with Dr. Christina Maslach, is contributors to occupational burnout, so much of it really distills down—using [unintelligible 00:16:35] crappy layman's terms—to a lack of, I guess what I'm going to call relevance or a lack—a feeling like you are not significant to what the company is actually doing in any meaningful way. And I will confess to having had a number of those challenges in my career when I was working in production environments because, yeah, I kept the servers up and the applications up, but if you really think about it, one of the benefits of working in the system space—or the production engineers base, or DevOps, or platform engineering, or don't even start with me these days—is that what you do conveys almost seamlessly from company to company. Like, the same reason that I can do what I do now, I don't care what your company does, necessarily, I just know that the AWS bill is a bounded problem space and I can reason about it almost regardless of what you do.And if I'm keeping the site up, okay, it doesn't matter if we're streaming movies or selling widgets or doing anything, just so long as I don't find that it contradicts my own values. And that's great, but it also is isolating because you feel like you're not really relevant to the direction of what the company actually does. It's, “Okay, so what does this company do?” “We make rubber bands,” and well, I'm not really a rubber band connoisseur, but I could make sure that the website stays up. But it just feels like there's a disconnect element happening.Jeremy: That is real. It is very real. And one of the ways that I tried to kind of combat that, and I help my team kind of really try and keep this in mind, is we try to meet as much as possible with the people that are actually doing the direction, whether it be product marketing, or whether it's in product managers, or it's even, you know, in engineering is have some regular conversations with what we do as a company. How are we going to fit with that in what we do and what we say and all of our objectives, and making sure that everything we do ties to something that helps other teams and that fits within the business and where it's going so that we grow our understanding of what the company is trying to do so that we don't kind of feel like a ship that's without a sail and just floating wherever things go.Corey: On some level, I am curious as to what you're seeing as we navigate this—I don't know if it's a recession,' I don't know if it's a correction; I'm not sure what to call it—but my gut tells me that a lot of things that were aimed at, let's call it developer quality of life, they were something of a necessity in the unprecedented bull market that we've seen for the last decade at some point because most companies cannot afford to compete with the giant tech company compensation packages, so you have to instead talk about quality of life and what work-life balance looks like, and here's why all of the tools and processes here won't drive you to madness. And now it feels like, “Oh, we don't actually have to invest in a lot of those things, just because oh yeah, like, the benefits here are you're still going to be employed next week. So, how about that?” And I don't think that's a particularly healthy way to interact with people—it's certainly not how I do—but it does seem that worrying about keeping developers absolutely thrilled with every aspect of their jobs has taken something of a backseat during the downturn.Jeremy: I don't know. I feel like developer satisfaction is still an important piece, even though, you know, we have a changing market. And as you described, if you're not happy with the tool you're using, you're not going to be as productive than using the tool or using—you know, whether it's an actual developer productivity tool, or it's even just the fact that you might need two monitors, you're not going to be as productive if you're not enjoying what you're doing. So, there is a piece of it, I think, the companies are recognizing that there are some tools that do ultimately benefit and there's some things that they can say, we're not going to invest in that area right now. We're good with where we're at.Corey: On some level, being able to say, “No, we're not going to invest in that right now,” is the right decision. It is challenging, in some cases, to wind up talking to some team members in some orgs, who do not have the context that is required to understand why that decision is being made. Because without context, it looks like, “Mmm, no. I'm just canceling Christmas for you personally this year. Sorry, doesn't it suck to be you? [singing] Dut, dut.” And that is very rarely how executives make decisions, except apparently if they're Elon Musk.Jeremy: Right. Well, the [Muskrat 00:21:23] can, you know, sink any company—Corey: [laugh].Jeremy: — and get away with it. And that's one thing I've really been happy with where I'm at now, is you have a leadership team that says, “Hey, here's where things are, and here's what it looks like. And here's how we're all contributing to where we're going, and here's the decisions we're going to make, and here's how—” they're very open with what's going on. And it's not a surprise to anybody that the economic time means that we maybe can't go to 65 events next year. Like, that's just reality.But at the end of the day, we still have to go and do a job and help grow the company. So, how can we do that more efficiently? Which means that we—it leaves it better to try and figure that out than to be so nebulous, with like, “Yep, nope. You can't go do that.” That's where true leadership comes to is, like, laying it out there, and just, you know, getting people alongside with you.Corey: How do you see DevRel evolving? Because I think we had a giant evolution over the past few years. Because suddenly, the old vision of DevRel—at least in some quarters, which I admit I fell a little too deeply into—was, I'm going to go to all the conferences and give all of the talks, even though most of them are not related to the core of what I do. And maybe that's a viable strategy; maybe it's not. I think it depends on what your business does.And I don't disagree with the assertion that going and doing something in public can have excellent downstream effects, even if the connection is not obvious. But suddenly, we weren't able to do that, and people were forced to almost reinvent how a lot of that works. Now, that the world is, for better or worse, starting to open up again, how do you see it evolving? Are we going right back to a different DevOps days in a different city every week?Jeremy: I think it's a lot more strategic now. I think generally, there is less mountains of money that you can pull from to go and do whatever the hell you want. You have to be more strategic. I said that a few times. Like, there's looking at it and making sure, like, yeah, it would be great to go and, you know, get in front of 50,000 people this quarter or this year, whatever you want to do, but is that really going to move the bottom line for us? Is that really going to help the business, or is that just helping your Delta miles?What is really the best bang for the buck? So, I think DevRel as it evolves, in the next few years, has to come to a good recognition moment of we need to be a little bit more prescriptive in how we do things within our company and not so willy-nilly return to you know, what we generally used to get away with. That means you're going to see a lot more people have to be held to account within their companies of, is what you're doing actually match up to our business goal here? How does that fit? And having to explain more of that, and that's, I think, for some people will be easy. Some people are going to have to stretch that muscle, and others are going to be in a real tough pickle.Corey: One last topic I want to get into with you is devopspartygames.com, an online more or less DevOps, quote-unquote, “Personality” assortment of folks who wind up playing online games. I was invited once and promptly never invited back ever again. So first, was it something I said—obviously—and two what is that and how—is that still going in this post-pandemic-ish era?Jeremy: I like how you answered your own question first; that way I don't have to answer it. The second one, the way it came about was just, you know, Matty and I had started missing that interaction that we would tend to have in person. And so, one of the ways we started realizing is we play these, you know, Jackbox games, and why can't we just do this with DevOps tech prompts? So, that's kind of how it kicked off. We started playing around doing it for fun and then I was like, “You know, we should—we could do this as a big, big deal for foreseeable future.”Where's that now is, we actually have not done one online for—what is it? So probably, like, eight, nine months, primarily because it's harder and harder to do so as everybody [laugh]—we're now doing a little bit more travel, and it's hard to do those—as you know, doing podcasts, it takes a lot of work. It's not an easy kind of thing. And so, we've kind of put that on pause. But we actually did our first in-person DevOps Party Games at DevOpsDays Chicago recently, and that was a big hit, I think, and opportunity to kind of take what we're doing virtually, and the fun and excitement that we generally would have—relatively half-drunk—to actually doing it actually in-person at an event. And in the different—like, just as giving talks in person was a different level of interaction with the crowd, the same thing is doing it in person. So, it was just kind of a fun thing and an opportunity maybe to continue to do it in person.Corey: I think we all got a hell of a lot better very quickly at speaking to cameras instead of audiences and the rest. It also forced us to be more focused because the camera gives you nothing in a way that the audience absolutely does.Jeremy: They say make love to the camera, but it doesn't work anyways.Corey: I really want to thank you for spending as much time as you have talking to me. If people want to learn more about who you are and what you're up to, where should they go?Jeremy: Well, for the foreseeable future, or at least what we can guess, you can find me on the Twitters at @Iamjerdog. You can find me there or you can find me at, you know, LinkedIn, at jeremymeiss, LinkedIn. And you know, probably come into your local DevOpsDays or other conference as well.Corey: Of course. And we will, of course, put links to that in the show notes.Jeremy: Excellent.Corey: Thank you so much for being so generous with your time. It is always appreciated. And I do love talking with you.Jeremy: And I appreciate it, Corey. It was great beyond, finally. I won't hold it against you anymore.Corey: Jeremy Meiss, Director of DevRel at CircleCI. 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, irritated comment talking about how CI/CD is nonsense and the correct way to deploy to production is via the tried-and-true method of copying and pasting.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.

About Chris Chris Farris has been in the IT field since 1994 primarily focused on Linux, networking, and security. For the last 8 years, he has focused on public-cloud and public-cloud security. He has built and evolved multiple cloud security programs for major media companies, focusing on enabling the broader security team's objectives of secure design, incident response and vulnerability management. He has developed cloud security standards and baselines to provide risk-based guidance to development and operations teams. As a practitioner, he's architected and implemented multiple serverless and traditional cloud applications focused on deployment, security, operations, and financial modeling.Chris now does cloud security research for Turbot and evangelizes for the open source tool Steampipe. He is one if the organizers of the fwd:cloudsec conference (https://fwdcloudsec.org) and has given multiple presentations at AWS conferences and BSides events.When not building things with AWS's building blocks, he enjoys building Legos with his kid and figuring out what interesting part of the globe to travel to next. He opines on security and technology on Twitter and his website https://www.chrisfarris.comLinks Referenced: Turbot: https://turbot.com/ fwd:cloudsec: https://fwdcloudsec.org/ Steampipe: https://steampipe.io/ Steampipe block: https://steampipe.io/blog TranscriptAnnouncer: 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.Corey: Tailscale SSH is a new, and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices, Tailscale takes care of the rest. So you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, and uses that same key for SSH authorization and encryption. So basically you're SSHing the same way that you're already managing your network.So what's the benefit? Well, built-in key rotation, the ability to manage permissions as code, connectivity between any two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security to keep the compliance folks happy. Try Tailscale now - it's free forever for personal use.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone that I have been meaning to invite slash drag onto this show for a number of years. We first met at re:Inforce the first year that they had such a thing, Amazon's security conference for cloud, as is Amazon's tradition, named after an email subject line. Chris Farris is a cloud security nerd at Turbot. He's also one of the organizers for fwd:cloudsec, another security conference named after an email subject line with a lot more self-awareness than any of Amazon's stuff. Chris, thank you for joining me.Chris: Oh, thank you for dragging me on. You can let go of my hair now.Corey: Wonderful, wonderful. That's why we're all having the thinning hair going on. People just use it to drag us to and fro, it seems. So, you've been doing something that I'm only going to describe as weird lately because your background—not that dissimilar from mine—is as a practitioner. You've been heavily involved in the security space for a while and lately, I keep seeing an awful lot of things with your name on them getting sucked up by the giant app surveillance apparatus deployed to the internet, looking for basically any mention of AWS that I wind up using to write my newsletter and feed the content grist mill every year. What are you doing and how'd you get there?Chris: So, what am I doing right now is, I'm in marketing. It's kind of a, you know, “Oops, I'm sorry I did that.”Corey: Oh, the running gag is, you work in DevRel; that means, “Oh, you're in marketing, but they're scared to tell you that.” You're self-aware.Chris: Yeah.Corey: Good for you.Chris: I'm willing to address that I'm in marketing now. And I've been a cloud practitioner since probably 2014, cloud security since about 2017. And then just decided, the problem that we have in the cloud security community is a lot of us are just kind of sitting in a corner in our companies and solving problems for our companies, but we're not solving the problems at scale. So, I wanted a job that would allow me to reach a broader audience and help a broader audience. Where I see cloud security having—you know, or cloud in general falling down is Amazon makes it really hard for you to do your side of shared responsibility, and so we need to be out there helping customers understand what they need to be doing. So, I am now at a company called Turbot and we're really trying to promote cloud security.Corey: One of the first promoted guest episodes of this show was David Boeke, your CTO, and one of the things that I regret is that I've sort of lost track of Turbot over the past few years because, yeah, one or two things might have been going on during that timeline as I look back at having kids in the middle of a pandemic and the deadly plague o'er land. And suddenly, every conversation takes place over Zoom, which is like, “Oh, good, it's like a happy hour only instead, now it's just like a conference call for work.” It's like, ‘Conference Calls: The Drinking Game' is never the great direction to go in. But it seems the world is recovering. We're going to be able to spend some time together at re:Invent by all accounts that I'm actively looking forward to.As of this recording, you're relatively new to Turbot, and I figured out that you were going there because, once again, content hits my filters. You wrote a fascinating blog post that hits on an interest of mine that I don't usually talk about much because it's off-putting to some folk, and these days, I don't want to get yelled at and more than I have to about the experience of traveling, I believe it was to an all-hands on the other side of the world.Chris: Yep. So, my first day on the job at Turbot, I was landing in Kuala Lumpur, Malaysia, having left the United States 24 hours—or was it 48? It's hard to tell when you go to the other side of the planet and the time zones have also shifted—and then having left my prior company day before that. But yeah, so Turbot about traditionally has an annual event where we all get together in person. We're a completely remote company, but once a year, we all get together in person in our integrate event.And so, that was my first day on the job. And then you know, it was basically two weeks of reasonably intense hackathons, building out a lot of stuff that hopefully will show up open-source shortly. And then yeah, meeting all of my coworkers. And that was nice.Corey: You've always had a focus through all the time that I've known you and all the public content that you've put out there that has come across my desk that seems to center around security. It's sort of an area that I give a nod to more often than I would like, on some level, but that tends to be your bread and butter. Your focus seems to be almost overwhelmingly on I would call it AWS security. Is that fair to say or is that a mischaracterization of how you view it slash what you actually do? Because, again, we have these parasocial relationships with voices on the internet. And it's like, “Oh, yeah, I know all about that person.” Yeah, you've met them once and all you know other than that is what they put on Twitter.Chris: You follow me on Twitter. Yeah, I would argue that yes, a lot of what I do is AWS-related security because in the past, a lot of what I've been responsible for is cloud security in AWS. But I've always worked for companies that were multi-cloud; it's just that 90% of everything was Amazon and so therefore 90% of my time, 90% of my problems, 90% of my risk was all in AWS. I've been trying to break out of that. I've been trying to understand the other clouds.One of the nice aspects of this role and working on Steampipe is I am now experimenting with other clouds. The whole goal here is to be able to scale our ability as an industry and as security practitioners to support multiple clouds. Because whether we want to or not, we've got it. And so, even though 90% of my spend, 90% of my resources, 90% of my applications may be in AWS, that 10% that I'm ignoring is probably more than 10% of my risk, and we really do need to understand and support major clouds equally.Corey: One post you had recently that I find myself in wholehearted agreement with is on the adoption of Tailscale in the enterprise. I use it for all of my personal nonsense and it is transformative. I like the idea of what that portends for a multi-cloud, or poly-cloud, or whatever the hell we're calling it this week, sort of architectures were historically one of the biggest problems in getting to clouds two speak to one another and manage them in an intelligent way is the security models are different, the user identity stuff is different as well, and the network stuff has always been nightmarish. Well, with Tailscale, you don't have to worry about that in the same way at all. You can, more or less, ignore it, turn on host-based firewalls for everything and just allow Tailscale. And suddenly, okay, I don't really have to think about this in the same way.Chris: Yeah. And you get the micro-segmentation out of it, too, which is really nice. I will agree that I had not looked at Tailscale until I was asked to look at Tailscale, and then it was just like, “Oh, I am completely redoing my home network on that.” But looking at it, it's going to scare some old-school network engineers, it's going to impact their livelihoods and that is going to make them very defensive. And so, what I wanted to do in that post was kind of address, as a practitioner, if I was looking at this with an enterprise lens, what are the concerns you would have on deploying Tailscale in your environment?A lot of those were, you know, around user management. I think the big one that is—it's a new thing in enterprise security, but kind of this host profiling, which is hey, before I let your laptop on the network, I'm going to go make sure that you have antivirus and some kind of EDR, XDR, blah-DR agents so that you know we have a reasonable thing that you're not going to just go and drop [unintelligible 00:09:01] on the network and next thing you know, we're Maersk. Tailscale, that's going to be their biggest thing that they are going to have to figure out is how do they work with some of these enterprise concerns and things along those lines. But I think it's an excellent technology, it was super easy to set up. And the ability to fine-tune and microsegment is great.Corey: Wildly so. They occasionally sponsor my nonsense. I have no earthly idea whether this episode is one of them because we have an editorial firewall—they're not paying me to set any of this stuff, like, “And this is brought to you by whatever.” Yeah, that's the sponsored ad part. This is just, I'm in love with the product.One of the most annoying things about it to me is that I haven't found a reason to give them money yet because the free tier for my personal stuff is very comfortably sized and I don't have a traditional enterprise network or anything like that people would benefit from over here. For one area in cloud security that I think I have potentially been misunderstood around, so I want to take at least this opportunity to clear the air on it a little bit has been that, by all accounts, I've spent the last, mmm, few months or so just absolutely beating the crap out of Azure. Before I wind up adding a little nuance and context to that, I'd love to get your take on what, by all accounts, has been a pretty disastrous year-and-a-half for Azure security.Chris: I think it's been a disastrous year-and-a-half for Azure security. Um—[laugh].Corey: [laugh]. That was something of a leading question, wasn't it?Chris: Yeah, no, I mean, it is. And if you think, though, back, Microsoft's repeatedly had these the ebb and flow of security disasters. You know, Code Red back in whatever the 2000s, NT 4.0 patching back in the '90s. So, I think we're just hitting one of those peaks again, or hopefully, we're hitting the peak and not [laugh] just starting the uptick. A lot of what Azure has built is stuff that they already had, commercial off-the-shelf software, they wrapped multi-tenancy around it, gave it a new SKU under the Azure name, and called is cloud. So, am I super-surprised that somebody figured out how to leverage a Jupyter notebook to find the back-end credentials to drop the firewall tables to go find the next guy over's Cosmos DB? No, I'm not.Corey: I find their failures to be less egregious on a technical basis because let's face it, let's be very clear here, this stuff is hard. I am not pretending for even a slight second that I'm a better security engineer than the very capable, very competent people who work there. This stuff is incredibly hard. And I'm not—Chris: And very well-funded people.Corey: Oh, absolutely, yeah. They make more than I do, presumably. But it's one of those areas where I'm not sitting here trying to dunk on them, their work, their efforts, et cetera, and I don't do a good enough job of clarifying that. My problem is the complete radio silence coming out of Microsoft on this. If AWS had a series of issues like this, I'm hard-pressed to imagine a scenario where they would not have much more transparent communications, they might very well trot out a number of their execs to go on a tour to wind up talking about these things and what they're doing systemically to change it.Because six of these in, it's like, okay, this is now a cultural problem. It's not one rando engineer wandering around the company screwing things up on a rotational basis. It's, what are you going to do? It's unlikely that firing Steven is going to be your fix for these things. So, that is part of it.And then most recently, they wound up having a blog post on the MSRC, the Microsoft Security Resource Center is I believe that acronym? The [mrsth], whatever; and it sounds like a virus you pick up in a hospital—but the problem that I have with it is that they spent most of that being overly defensive and dunking on SOCRadar, the vulnerability researcher who found this and reported it to them. And they had all kinds of quibbles with how it was done, what they did with it, et cetera, et cetera. It's, “Excuse me, you're the ones that left customer data sitting out there in the Azure equivalent of an S3 bucket and you're calling other people out for basically doing your job for you? Excuse me?”Chris: But it wasn't sensitive customer data. It was only the contract information, so therefore it was okay.Corey: Yeah, if I put my contract information out there and try and claim it's not sensitive information, my clients will laugh and laugh as they sue me into the Stone Age.Chris: Yeah well, clearly, you don't have the same level of clickthrough terms that Microsoft is able to negotiate because, you know, [laugh].Corey: It's awful as well, it doesn't even work because, “Oh, it's okay, I lost some of your data, but that's okay because it wasn't particularly sensitive.” Isn't that kind of up to you?Chris: Yes. And if A, I'm actually, you know, a big AWS shop and then I'm looking at Azure and I've got my negotiations in there and Amazon gets wind that I'm negotiating with Azure, that's not going to do well for me and my business. So no, this kind of material is incredibly sensitive. And that was an incredibly tone-deaf response on their part. But you know, to some extent, it was more of a response than we've seen from some of the other Azure multi-tenancy breakdowns.Corey: Yeah, at least they actually said something. I mean, there is that. It's just—it's wild to me. And again, I say this as an Azure customer myself. Their computer vision API is basically just this side of magic, as best I can tell, and none of the other providers have anything like it.That's what I want. But, you know, it almost feels like that service is under NDA because no one talks about it when they're using this service. I did a whole blog post singing its praises and no one from that team reached out to me to say, “Hey, glad you liked it.” Not that they owe me anything, but at the same time it's incredible. Why am I getting shut out? It's like, does this company just have an entire policy of not saying anything ever to anyone at any time? It seems it.Chris: So, a long time ago, I came to this realization that even if you just look at the terminology of the three providers, Amazon has accounts. Why does Amazon have Amazon—or AWS accounts? Because they're a retail company and that's what you signed up with to buy your underwear. Google has projects because they were, I guess, a developer-first thing and that was how they thought about it is, “Oh, you're going to go build something. Here's your project.”What does Microsoft have? Microsoft Azure Subscriptions. Because they are still about the corporate enterprise IT model of it's really about how much we're charging you, not really about what you're getting. So, given that you're not a big enterprise IT customer, you don't—I presume—do lots and lots of golfing at expensive golf resorts, you're probably not fitting their demographic.Corey: You're absolutely not. And that's wild to me. And yet, here we are.Chris: Now, what's scary is they are doing so many interesting things with artificial intelligence… that if… their multi-tenancy boundaries are as bad as we're starting to see, then what else is out there? And more and more, we is carbon-based life forms are relying on Microsoft and other cloud providers to build AI, that's kind of a scary thing. Go watch Satya's keynote at Microsoft Ignite and he's showing you all sorts of ways that AI is going to start replacing the gig economy. You know, it's not just Tesla and self-driving cars at this point. Dali is going to replace the independent graphics designer.They've got things coming out in their office suite that are going to replace the mom-and-pop marketing shops that are generating menus and doing marketing plans for your local restaurants or whatever. There's a whole slew of things where they're really trying to replace people.Corey: That is a wild thing to me. And part of the problem I have in covering AWS is that I have to differentiate in a bunch of different ways between AWS and its Amazon corporate parent. And they have that problem, too, internally. Part of the challenge they have, in many cases, is that perks you give to employees have to scale to one-and-a-half million people, many of them in fulfillment center warehouse things. And that is a different type of problem that a company, like for example, Google, where most of their employees tend to be in office job-style environments.That's a weird thing and I don't know how to even start conceptualizing things operating at that scale. Everything that they do is definitionally a very hard problem when you have to make it scale to that point. What all of the hyperscale cloud providers do is, from where I sit, complete freaking magic. The fact that it works as well as it does is nothing short of a modern-day miracle.Chris: Yeah, and it is more than just throwing hardware at the problem, which was my on-prem solution to most of the things. “Oh, hey. We need higher availability? Okay, we're going to buy two of everything.” We called it the Noah's Ark model, and we have an A side and a B side.And, “Oh, you know what? Just in case we're going to buy some extra capacity and put it in a different city so that, you know, we can just fail from our primary city to our secondary city.” That doesn't work at the cloud provider scale. And really, we haven't seen a major cloud outage—I mean, like, a bad one—in quite a while.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other; which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io/screaminginthecloud. Observability: it's more than just hipster monitoring.Corey: The outages are always fascinating, just from the way that they are reported in the mainstream media. And again, this is hard, I get it. I am not here to crap on journalists. They, for some ungodly, unknowable reason, have decided not to spend their entire career focusing on the nuances of one very specific, very deep industry. I don't know why.But as [laugh] a result, they wind up getting a lot of their baseline facts wrong about these things. And that's fair. I'm not here to necessarily act as an Amazon spokesperson when these things happen. They have an awful lot of very well-paid people who can do that. But it is interesting just watching the blowback and the reaction of whatever there's an outage, the conversation is never “Does Amazon or Azure or Google suck?” It's, “Does cloud suck as a whole?”That's part of the reason I care so much about Azure getting their act together. If it were just torpedoing Microsoft's reputation, then well, that's sad, but okay. But it extends far beyond that to a point where it's almost where the enterprise groundhog sees the shadow of a data breach and then we get six more years of data center build-outs instead of moving things to a cloud. I spent too many years working in data centers and I have the scars from the cage nuts and crimping patch cables frantically in the middle of the night to prove it. I am thrilled at the fact that I don't believe I will ever again have to frantically drive across town in the middle of the night to replace a hard drive before the rest of the array degrades. Cloud has solved those problems beautifully. I don't want to go back to the Dark Ages.Chris: Yeah, and I think that there's a general potential that we could start seeing this big push towards going back on-prem for effectively sovereign data reasons, whether it's this country has said, “You cannot store your data about our citizens outside of our borders,” and either they're doing that because they do not trust the US Silicon Valley privacy or whatever, or because if it's outside of our borders, then our secret police agents can come knocking on the door at two in the morning to go find out what some dissidents' viewings habits might have been, I see sovereign cloud as this thing that may be a back step from this ubiquitous thing that we have right now in Amazon, Azure, and Google. And so, as we start getting to the point in the history books where we start seeing maps with lots of flags, I think we're going to start seeing a bifurcation of cloud as just a whole thing. We see it already right now. The AWS China partition is not owned by Amazon, it is not run by Amazon, it is not controlled by Amazon. It is controlled by the communist government of China. And nobody is doing business in Russia right now, but if they had not done what they had done earlier this year, we might very well see somebody spinning up a cloud provider that is completely controlled by and in the Russian government.Corey: Well, yes or no, but I want to challenge that assessment for a second because I've had conversations with a number of folks about this where people say, “Okay, great. Like, is the alt-right, for example, going to have better options now that there might be a cloud provider spinning up there?” Or, “Well, okay, what about a new cloud provider to challenge the dominance of the big three?” And there are all these edge cases, either geopolitically or politically based upo—or folks wanting to wind up approaching it from a particular angle, but if we were hired to build out an MVP of a hyperscale cloud provider, like, the budget for that MVP would look like one 100 billion at this point to get started and just get up to a point of critical mass before you could actually see if this thing has legs. And we'd probably burn through almost all of that before doing a single dime in revenue.Chris: Right. And then you're doing that in small markets. Outside of the China partition, these are not massively large markets. I think Oracle is going down an interesting path with its idea of Dedicated Cloud and Oracle Alloy [unintelligible 00:22:52].Corey: I like a lot of what Oracle's doing, and if younger me heard me say that, I don't know how hard I'd hit myself, but here we are. Their free tier for Oracle Cloud is amazing, their data transfer prices are great, and their entire approach of, “We'll build an entire feature complete region in your facility and charge you what, from what I can tell, is a very reasonable amount of money,” works. And it is feature complete, not, “Well, here are the three services that we're going to put in here and everything else is well… it's just sort of a toehold there so you can start migrating it into our big cloud.” No. They're doing it right from that perspective.The biggest problem they've got is the word Oracle at the front end and their, I would say borderline addiction to big-E enterprise markets. I think the future of cloud looks a lot more like cloud-native companies being founded because those big enterprises are starting to describe themselves in similar terminology. And as we've seen in the developer ecosystem, as go startups, so do big companies a few years later. Walk around any big company that's undergoing a digital transformation, you'll see a lot more Macs on desktops, for example. You'll see CI/CD processes in place as opposed to, “Well, oh, you want something new, it's going to be eight weeks to get a server rack downstairs and accounting is going to have 18 pages of forms for you to fill out.” No, it's “click the button,” or—Chris: Don't forget the six months of just getting the financial CapEx approvals.Corey: Exactly.Chris: You have to go through the finance thing before you even get to start talking to techies about when you get your server. I think Oracle is in an interesting place though because it is embracing the fact that it is number four, and so therefore, it's like we are going to work with AWS, we are going to work with Azure, our database can run in AWS or it can run in our cloud, we can interconnect directly, natively, seamlessly with Azure. If I were building a consumer-based thing and I was moving into one of these markets where one of these governments was demanding something like a sovereign cloud, Oracle is a great place to go and throw—okay, all of our front-end consumer whatever is all going to sit in AWS because that's what we do for all other countries. For this one country, we're just going to go and build this thing in Oracle and we're going to leverage Oracle Alloy or whatever, and now suddenly, okay, their data is in their country and it's subject to their laws but I don't have to re-architect to go into one of these, you know, little countries with tin horn dictators.Corey: It's the way to do multi-cloud right, from my perspective. I'll use a component service in a different cloud, I'm under no illusions, though, in doing that I'm increasing my resiliency. I'm not removing single points of failure; I'm adding them. And I make that trade-off on a case-by-case basis, knowingly. But there is a case for some workloads—probably not yours if you're listening to this; assume not, but when you have more context, maybe so—where, okay, we need to be across multiple providers for a variety of strategic or contextual reasons for this workload.That does not mean everything you build needs to be able to do that. It means you're going to make trade-offs for that workload, and understanding the boundaries of where that starts and where that stops is going to be important. That is not the worst idea in the world for a given appropriate workload, that you can optimize stuff into a container and then can run, more or less, anywhere that can take a container. But that is also not the majority of most people's workloads.Chris: Yeah. And I think what that comes back to from the security practitioner standpoint is you have to support not just your primary cloud, your favorite cloud, the one you know, you have to support any cloud. And whether that's, you know, hey, congratulations. Your developers want to use Tailscale because it bypasses a ton of complexity in getting these remote island VPCs from this recent acquisition integrated into your network or because you're going into a new market and you have to support Oracle Cloud in Saudi Arabia, then you as a practitioner have to kind of support any cloud.And so, one of the reasons that I've joined and I'm working on, and so excited about Steampipe is it kind of does give you that. It is a uniform interface to not just AWS, Azure, and Google, but all sorts of clouds, whether it's GitHub or Oracle, or Tailscale. So, that's kind of the message I have for security practitioners at this point is, I tried, I fought, I screamed and yelled and ranted on Twitter, against, you know, doing multi-cloud, but at the end of the day, we were still multi-cloud.Corey: When I see these things evolving, is that, yeah, as a practitioner, we're increasingly having to work across multiple providers, but not to a stupendous depth that's the intimidating thing that scares the hell out of people. I still remember my first time with the AWS console, being so overwhelmed with a number of services, and there were 12. Now, there are hundreds, and I still feel that same sense of being overwhelmed, but I also have the context now to realize that over half of all customer spend globally is on EC2. That's one service. Yes, you need, like, five more to get it to work, but okay.And once you go through learning that to get started, and there's a lot of moving parts around it, like, “Oh, God, I have to do this for every service?” No, take Route 53—my favorite database, but most people use it as a DNS service—you can go start to finish on basically everything that service does that a human being is going to use in less than four hours, and then you're more or less ready to go. Everything is not the hairy beast that is EC2. And most of those services are not for you, whoever you are, whatever you do, most AWS services are not for you. Full stop.Chris: Yes and no. I mean, as a security practitioner, you need to know what your developers are doing, and I've worked in large organizations with lots of things and I would joke that, oh, yeah, I'm sure we're using every service but the IoT, and then I go and I look at our bill, and I was like, “Oh, why are we dropping that much on IoT?” Oh, because they wanted to use the Managed MQTT service.Corey: Ah, I start with the bill because the bill is the source of truth.Chris: Yes, they wanted to use the Managed MQTT service. Okay, great. So, we're now in IoT. But how many of those things have resource policies, how many of those things can be made public, and how many of those things are your CSPM actually checking for and telling you that, hey, a developer has gone out somewhere and made this SageMaker notebook public, or this MQTT topic public. And so, that's where you know, you need to have that level of depth and then you've got to have that level of depth in each cloud. To some extent, if the cloud is just the core basic VMs, object storage, maybe some networking, and a managed relational database, super simple to understand what all you need to do to build a baseline to secure that. As soon as you start adding in on all of the fancy services that AWS has. I re—Corey: Yeah, migrating your Step Functions workflow to other cloud is going to be a living goddamn nightmare. Migrating something that you stuffed into a container and run on EC2 or Fargate is probably going to be a lot simpler. But there are always nuances.Chris: Yep. But the security profile of a Step Function is significantly different. So, you know, there's not much you can do there wrong, yet.Corey: You say that now, but wait for their next security breach, and then we start calling them Stumble Functions instead.Chris: Yeah. I say that. And the next thing, you know, we're going to have something like Lambda [unintelligible 00:30:31] show up and I'm just going to be able to put my Step Function on the internet unauthenticated. Because, you know, that's what Amazon does: they innovate, but they don't necessarily warn security practitioners ahead of their innovation that, hey, you're we're about to release this thing. You might want to prepare for it and adjust your baselines, or talk to your developers, or here's a service control policy that you can drop in place to, you know, like, suppress it for a little bit. No, it's like, “Hey, these things are there,” and by the time you see the tweets or read the documentation, you've got some developer who's put it in production somewhere. And then it becomes a lot more difficult for you as a security practitioner to put the brakes on it.Corey: I really want to thank you for spending so much time talking to me. If people want to learn more and follow your exploits—as they should—where can they find you?Chris: They can find me at steampipe.io/blog. That is where all of my latest rants, raves, research, and how-tos show up.Corey: And we will, of course, put a link to that in the [show notes 00:31:37]. Thank you so much for being so generous with your time. I appreciate it.Chris: Perfect, thank you. You have a good one.Corey: Chris Farris, cloud security nerd at Turbot. 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 insulting comment, and be sure to mention exactly which Azure communications team you work on.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.Announcer: This has been a HumblePod production. Stay humble.

Software developers are integral in the development of modern-day applications. However, many are unaware of the role of a developer relations advocate. A developer advocate (DevRel) is crucial in connecting software developers with their peers and customers. This job encompasses bridging communication between the two parties, understanding customer needs, and advocating for the software product.… Continue reading 48: What Is a Developer Advocate? The post 48: What Is a Developer Advocate? first appeared on Deeper Than Tech.

DevRel at Vercel, Steven Tey, joins us to talk about Platforms Starter Kit, a new template for site builders. We talk about Vercel, multi-tenant platforms, and low-code tools. Links https://twitter.com/steventey https://oneword.domains https://dub.sh https://podrocket.logrocket.com/next-13 https://demo.vercel.pub/platforms-starter-kit https://vercel.com/templates https://nextjs.org/conf https://precedent.dev https://vercel.com/docs/concepts/edge-network/edge-config Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Steven Tey.

In this episode we discuss how DevRel is organized at Supabase, why Supabase decided to build their own PostgreSQL extension, and new capabilities enabled by Supabase's Edge Functions. Jon Meyers Homepage Twitter GitHub YouTube Egghead Supabase Homepage Twitter GitHub YouTube Discord Links Supabase with Paul Copplestone (FSJam33) Open Source Stacks with Ant Wilson (FSJam52) pg_graphql: A GraphQL extension for PostgreSQL GraphQL is now available in Supabase pg_graphql v1.0 pg_graphql Documentation Launch Week Updates for Supabase Functions Supabase Edge Functions Edge Function Examples Supabase Integrations Supabase Series B Made with Supabase Show Outline01:25 - Jon Meyers Introduction04:44 - How is the DevRel team at Supabase organized?06:41 - What is Supabase?07:55 - Building and Using Postgres Extensions10:46 - How does the GraphQL Postgres Extension Work?12:15 - What is Supabase Launch Week?14:19 - Supabase Edge Functions22:31 - Supabase Integrations24:11 - Supabase Series B25:27 - What are people building with Supabase?27:24 - Jon's Favorite FSJam Episodes30:03 - Closing Thoughts-------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.

About AlyssAlyss Noland is the head of Developer Relations Relations and Product Marketing at Common Room, an intelligent community-led growth platform. She previously led product marketing for Developer Experience at GitHub where she focused on open source community investment and helping engineering teams find success through development metrics and developer-focused research. She's been working in tech since 2012 in various roles from Sales Engineering and Developer Advocacy to Product Marketing with companies such as GitHub, Box, Atlassian, and BigCommerce, as well as being an advisor at Heavybit. Links Referenced: Common Room: https://www.commonroom.io/ Heavybit: https://www.heavybit.com/ Twitter: https://twitter.com/PreciselyAlyss Twitch: https://www.twitch.tv/PreciselyAlyss TranscriptAnnouncer: 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.Corey: Tailscale SSH is a new, and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices, Tailscale takes care of the rest. So you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, and uses that same key for SSH authorization and encryption. So basically you're SSHing the same way that you're managing your network.So what's the benefit? You'll get built-in key rotation, the ability to manage permissions as code, connectivity between two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security. Try Tailscale now - it's free forever for personal use forever.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I often wonder how to start these conversations, but sometimes it's just handed to me and I don't even have to do a whole lot of work. My guest today is Alyss Noland, who's the Head of Developer Relations Relations and Product Marketing at Common Room. Alyss, thank you for joining me.Alyss: Thanks for having me, Corey. I'm really excited to be here.Corey: So, developer relations relations. It feels like an abstraction that has been forced to be built on top of another abstraction that has gotten too complicated, so as best I can tell, you are walking around as a human equivalent of Kubernetes.Alyss: Oh, gosh, I would really hope not to be a human equivalent of Kubernetes. I think that would make me an octopus. But—Corey: Yeah, “What did you say about me?” Yeah.Alyss: [laugh].Corey: “I didn't come here to be insulted, Quinn.” Yeah.Alyss: No, like listen, I love octopodes. Which [tattoo 00:01:24] is which? So, developer relations relations. Yes, it's an abstraction on an abstraction. A really critical level, it is how do I relate? Can I relate to people that are in the developer relations profession at large?We are at the point at which this is a somewhat poorly-defined area that is continuing to grow. And there's a lot of debates in that space and so I'm really excited to be at an organization that will give me a platform to try and move the industry forward.Corey: Your relatively recent career history is honestly fascinating to me. You spent about a year and a half as a senior developer advocate at Box. And as anyone who's ever tried it knows, it's very hard to beat Box [beatboxing noises]. But you tried and went to GitHub, in which case, you basically transitioned pretty quickly from a Senior Product Marketing Manager to Director of Product Marketing, where you were the go-to-market lead for GitHub Copilot.Alyss: Yeah, that was a really interesting project to be on. I started off at the technical preview back in 2021, launching that too—it ended up being with about a little over a million, two million folks in technical preview. And it's fairly new to the market. There was nothing else—or at the time, there had been nothing else that was using a descendant of GPT-3. There was nothing else using a descendant of GPT-3 to generate suggestions for code to—there were a couple that were using GPT-2, but the amount of language coverage they had was a little bit limited, what they were suggesting was a little bit limited.And it's hard to say, like, highlight of my career, but at that point in time, I would say probably, highlight of my career to be able to work on something with that opportunity for impact.Corey: As someone who was in the technical preview and now tried to be a paying customer of it, but I can't because of my open-source work, it wound up giving it to me for free. I found it to be absolutely transformative. And I know I'm going to get letters and I don't even slightly care because it's not, “I'm going to tab-complete my application.” If a tool can do that, your application is probably not that complex. No, for me, what I find incredibly valuable is the ability to tab-complete through obnoxious boilerplate. CloudFormation, I am not subtweeting you; I am calling you out directly. You are wordy and obnoxious. Fix yourself.And especially in languages that I don't deal with day-to-day—because I'm not a full-time developer—I forget certain parameters or argument order or things like that and being able to effectively tab-complete is awesome for that use case. It's not doing my job; it's automating the crappy part of my job. And I absolutely love it for that.Alyss: Yeah, and was really interesting working on a common portion of product marketing work is that we build messaging houses. We try to identify where's the value to the user, to the organization at large, depending on, like, who it is we're trying to sell to, how does that ladder up from, like, an IoT to a manager. And so, one of the things that I got really excited about as we started to see it—and there's some great work that Dr. Eirini Kallaimvakou has published that I would definitely refer to if you're interested in diving deeper into it—is the way in which Copilot and this, like, ability to improve the boilerplate experience, improve the boring shit—automate the boring shit, if you will—is about developer satisfaction. It's not about making you build your commits faster or about having more lines of code that you like get deployed out; it's about making your jobs suck less.Corey: Well, if you spent, what was it roughly two years, give or take, at GitHub between your various roles—and yes, I'm going to pronounce it ‘GIF-ub' because that's my brand of obnoxious, so I'm going to go for it—you went to Common Room. Let's begin there. What does Common Room do, exactly?Alyss: So, Common Room is an intelligent community-led growth platform. And there's a few things kind of packed into that really short description, but the idea is that we've seen all of these product-lead grows businesses. But at a critical point, and something we've seen at GitHub, which is a product-led growth company, it's something that we've seen at Atlassian, Asana, you name half a dozen different, like, SaaS companies, self-hosted software, open-source, community is at the heart of it. And so, how do you nurture that community? How do you measure that community? How do you prove that the work that you're doing is valuable?And that's what Common Room is setting out to do. And so, when I saw—like, they're not the only person or organization in the market that's doing this, but I think they're doing it exceptionally well, and with really great goals in mind. And so, I'm enthused to try and facilitate that investment in community for more organizations.Corey: One of the challenges that I have seen of products in the community space is it tended, historically, to go in really, I guess I'll call them uncomfortable directions. In the before times, I used to host dinner parties near constantly here, and someone confide into me once—after, you know, six beers or so, because that's when people get the excitingly honest—they mentioned that, “Yeah, I'm supposed to wind up putting these dinners into Salesforce”—or whatever the hell it was—“To track the contacts we have with influencers in this space.” And that made me feel so profoundly uncomfortable. It's, you're invited here to spend time with my friends and my family. You're meeting my kids, it's, yeah, this is just a go-to-market motion and you can [BLEEP] on out of here and never come back.And I did not get that sense to be clear and I'm told the company wound up canceling that horrifying program, but it does feel like it's very easy to turn an authentic relationship into something that feels remarkably sleazy. That said, Common Room has been around for a while and I have yet to hear a single accusation that you folks have come within a thousand miles of doing that. How do you avoid the trap?Alyss: It's a slippery slope, and I can't say that Common Room creates any kind of like enforcement or silos or prevents organizations from falling into this trap. Fundamentally, the way in which community can be abused, the way in which these relationships can be taken advantage of, at least from the perception of the parties that initially built the relationship, is to take the context out of them, to take the empathy out of them, take the people out of them. And so, that is fundamentally left to the organization's principles, it's left to how much authority does community have within the business relative to a sales team. And so first, being able to elevate community in such a way to show that they are having that impact already without having to turn the community into a prospect pool is, I think, one of the critical first steps, and it's something that we've been able to break through initially by connecting things like Slack, Discord, Twitter to show, here's all these people talking about you, here's all the things that they're saying, here's the sentiment analysis, and also, now we're going to push that into Salesforce. So, you can see that this started out in community and it was fostered there. Now, you can see the ROI, you don't need to go hitting up our community contacts to try and sell to them because we're doing it on your behalf in a very real way.Corey: Part of the challenge, I think, is that—and you've talked to me about this in previous conversations we've had—that so much of community is distilled down to a sales motion, which let's be direct, it kind of sucks at, in some levels, because it's okay, great, I'm here to talk to you about how community works. Well, in the AWS community, for example, the reason that formed and is as broad and fast as it is because AWS's documentation is Byzantine and there's a sort of shared suffering that we all get to commiserate over. And whenever AWS tries to take, “Ownership,” quote-unquote, of its community, right, that doesn't actually work that way. They have community watering holes, but to my understanding, the largest AWS-centric Slack team is the Open Guide to AWS's Slack team, which now has, at last count, 15,000 people in it. I'm lucky enough to be the community lead for that project.But it was pre-existing before I got there and it's great to be able to go and talk to people who are using these things. It doesn't feel like it is owned, run, or controlled—because it's not—by AWS themselves. It's clear from the way that your product has evolved, that you feel similarly around that where it's about being aware of the community rather than controlling the community. And that's important.Alyss: Absolutely. And one of the ways in which we, like, highlight this as soon as you're in the product, is being able to show community responsiveness and then what percentage of those responses are coming from my team members. And frankly, as someone who's previously set strategy for developer relations teams, for developer communities, what I want to see is community members responding to each other, community members knowing what's the right place to look, what's the right answer, how am I ensuring that they have the resources that they need, the answers that they need. Because at the end of the day, I can't scale one-to-one; no one can. And so, the community being able to support itself is at the heart of the definition of community.Corey: One of the other problems that I've seen historically, and I'll call it the Chef problem because Chef had an incredibly strong community, and as someone who is deep in the configuration management space myself, but never use Chef, it was the one that I avoided for a variety of reasons at the time, it was phenomenal. I wound up going to ChefConf, despite not being a Chef user, just to spend time with some of the great people that were involved. The blunder that they made before they were acquired into irrelevance by progress—and to be fair, the industry changed direction toward immutable infrastructure in ways that were hard to foresee—but the problem is, they made was hiring their entire community. And it doesn't sound like that would be a bad thing, but suddenly, everyone who was talking about the product had a Chef email address, and that hits very differently.Alyss: It does. And it goes back to that point of trying to maintain those authentic relationships. And if we're to step outside of tech, I have a background prior to tech in the video game industry, and that was a similar problem. Nearly every single community-made application, extension ends up getting acquired by some organization, like Curse, and then piped full of ads, or the person that you thought you could ask or to see build some other better experience of version control software, or a Git client ends up getting consumed into a large business and then the project never sees the light of day. And frankly, that's not how you run community in my estimation.My estimation is, if the community is doing things better than you are, take notes. Product management, pay attention. That's something that is another aspect of doing developer relations is about checking in with those teams, about showing them evidence. And like, it so often ends up being qualitative in a way that doesn't change people's minds or their feelings, where people want to see quantitative numbers in order to say, “Oh, this is the business justification. Like, this is the ROI. This proves that this is the thing we should invest in.” And frankly, no. Like, sometimes it is a little bit more about stepping back and letting the organic empathy and participation happen without having to own it.Corey: There's a sense, I think that a lot of companies feel the need to own every conversation that happens around them, their product, et cetera, and you can't. You just can't, unless—to be direct—your company is failing. Just because if no one's talking about you, then great, you're the only ones talking about you. And you can see this from time to time and it's depressing as hell when you have people who work for a company all tweeting the same cookie-cutter statement, and they get zero interaction except from a bot account. It's sad.Alyss: Yeah. And I've unfortunately seen this more times than I can count in community Slacks where people just, like, copy-paste whatever marketing handed to them, and I would be shocked if they got any engagement at all. Because that's… cool. What do I know about you? Why do I care about this event? Have you personalized it to me?And yeah, you don't want the organization to be the only one talking about you. If you are then you've already failed in this, you know, product-led growth motion. You've kind of—if we want to get into the murky water of NPS, like, nobody's going and telling their friends about your product [laugh]. And the thing that's so valuable is the authentic voice. It's the, “I'm excited to talk about this and I like it enough to tell you what I like about it.” I like it enough to tell you about this use case that might never seen the light of day, but because we're having a conversation between ourselves, it can all be personalized. It can all be about what's going on between us and about our shared experiences. And that is ten times more powerful than most Twitter-promoted ads you'll ever see.Corey: So, I want to unpack a little bit about not developer relations as such, but developer relations relations because I can mostly understand—badly—what product marketing is, but developer relations relations—or as you'd like to call it developer relations squared—that's something new. I've always called DevRel to be devrelopers, and people get annoyed enough at that. What is that newfound layer of abstraction on top of it?Alyss: Well, there's several things that I'm going to end up—and I say end up; I'm six weeks into the role, so I have a lot of high hopes for where I hope this goes. And one of those is things, like, we don't have a very shared understanding and shared definition of what developer advocacy even is, what is developer relations? Does developer marketing belong under that umbrella? How should organizations approach developer relations? How should they value it? Where should it, you know, belong in terms of business strategy?And there's an opportunity for a company whose business it is to elevate this industry, this career path, if you will, where we can spend the time, we can spend the money to say, here's what success looks like. We've interviewed all these groups, we've talked with the leaders in this space that are making it their jobs to think about this. Here's a set of group-developed recommendations for how the industry should mature. Or here's an open-source set of job descriptions and requirements. And like, let's get to some level of shared understanding.So, as an example of, kind of, where I'm leading to with all of this, and some of the challenges that developer relations faces is the State of Developer Relations report that just came out. There's a significant number of people that are coming into developer advocate, developer relations roles for the first time, they have one to two years of experience, they're coming into programs that have been around for one to two years, and so what does that tell you? That tells you you're bringing in people with no experience to try to establish brand new programs, that they're being asked to by their business, and they don't have the vocabulary, the tools, the frameworks in which to establish that for themselves. And so, they're going to be swayed by, you know, the tides of business, by the influences of their leadership without having their own pre-built notions. And so, how do we give them that equipment and how do we elevate the practice?Corey: Cloud native just means you've got more components or microservices than anyone (even a mythical 10x engineer) can keep track of. With OpsLevel, you can build a catalog in minutes and forget needing that mythical 10x engineer. Now, you'll have a 10x service catalog to accompany your 10x service count. Visit OpsLevel.com to learn how easy it is to build and manage your service catalog. Connect to your git provider and you're off to the races with service import, repo ownership, tech docs, and more. Corey: It feels like so much of the DevRel discourse has turned into, one, we define it by what is not, and two, it doesn't matter how you're measuring it, you're measuring it wrong. I feel like that is, I guess we'll call it counterproductive, for lack of a better descriptor. It feels like there's such a short-sighted perspective on all of this, but at the same time, you've absolutely got to find ways to articulate the value of DevRel slash community to the business otherwise, it turns into a really uncomfortable moment when, okay, time to cut costs. Why should we keep your function over a different function? If there's not a revenue or upside or time to market or some form of value story tied to that, that the business can understand that isn't just touchy-feely, it's a very difficult path forward from there. How do you see it?Alyss: I agree with you and I've, frankly, run into this problem several times in my career, and every time I've been a developer advocate. It's, you know—and where I've found the most success is not in saying, “Here's exactly the numbers that I'm going to be constantly looking at. I'm going to try to produce this many pieces of content, or I'm absolutely not speaking at events. And that's not my job. Or I'm not writing code. That's not my job.”It's about understanding what is driving the business forward. Who do I need participation and buy-in from and where am I hoping to go? Like, what does a year out from this look like? What does three years out from this look like? At Box, we do not want to be the API governance standard. That is not our job. That's not where we sit within engineering.That's frankly, if you really want to get into it, internal developer advocacy because it can influence the impact on the community. It is not the core focus and there are probably people better equipped and better educated on the core application. Big commerce, platform ecosystem, platform flywheel developers are fundamentally a part of continuing to grow the business and how do I go make that point to sales, how do I go make that point to partners, how do I go make that point to customer success, so that I can build a function that has more than one person. And so, I think to kind of bring it back to the larger question, that is where I see our greatest challenge is that we haven't given ourselves the vocabulary or the framework to understand the level of complexity that DevRel has become in being across so many industries, and being in B2B, and being in business to developer, and being in business to consumer. No one size fits all and we need to stop trying to treat it as though it can be.Corey: I think that there is a, how to put it, a problem in terms of how Twitter views a lot of these things. Someone wound up finally distilling it down for me in relatively recent times with a very resonant quote, which was simply put, that Twitter is not where you go for nuance. Twitter is where you go to be righteous. And I realized, oh, my God, that describes a good 80% of the things I've put up there. Like when I talk about how when companies do this thing to their staff and it's crappy, I am not necessarily for a nuanced debate, although of course there's always nuance and edge cases in the rest.As a counterpoint, whenever I wind up talking about things on Twitter and speak in generalities, I get a whole bunch of people pushing back with a, “Well, what about this edge case? That renders your entire point invalid.” And, ugh, not really. It feels like one of the casualties of the pandemic has been a sense of community in a sense of humans relating to other humans. I think we're all tired of the Zoom calls from hell I got to see you a couple of weeks before this recording at Monktoberfest in Portland, Maine, and oh, my God, dealing with people face to face, it was so much richer, at least from my perspective, compared to everything that we've been able to do during the pandemic. Am I alone on that? Are you seeing this across the board? Where companies are talking about this?Alyss: I will say with confidence, you're not alone in this. Whether or not companies are talking about it is also across the board. How rich are those understandings? How rich are those conversations? Because trying to step back as a brand is not really a way.Like, having nuance, being real, been community members, like that's not a way in which I think companies can participate in a way that feels truly authentic. That's why you need faces. That's why you need people. That's why you need folks whose job it is to do this. But in terms of things are lost, like, Twitter is not the right place to be having these conversations. It's not the right place in which to necessarily relate to people, absolutely.When you get distilled down all of your interactions into oh, I've got a notification. Oh, I have a checkmark, and so I have, like, better moderation tools. Oh, like, I made a statement and I don't want to hear a solution for it. We get all of these, uncurated experiences that are so dissatisfying that it does make us miss being around people who can read body language, that can understand my immediate relationship to them in spaces that we choose to be in, whereas Twitter is this big panopticon where we can just get yelled at and yell at each other. And it loves to amplify those conversations far more than any of the touchy-feely, good news success stories.Corey: When you take a look across the entire landscape of managing DevRel programs and ensuring that companies are receiving value for it, and—by which I mean, nurturing the long-term health of communities because yes, I am much more interested in that than I am in next quarter's numbers, how do you see that evolving, particularly with the recent economic recession or correction or drawback or everything's on fire, depending upon who it is you talk to? How do you see that evolving?Alyss: It goes back to what I said earlier about, I can speak in generalities, there will be specifics to various organizations, but at a fundamental part, like, I'll kind of take a step back and maybe make some very strong statements about what I think DevRel is, in a regard, which is, without documentation, without support, you don't have a product. And if you don't have folks going out and understanding what it is your customers need, and especially when those customers are maybe all the time or sometimes developers, and understanding what it is that they're saying and truly how having empathy for what's going on in their day-to-day, what task are they trying to complete, how relevant is this to them, if you don't invest in that, when that happens, you've lost the plot. And so, in those instances, unfortunately, that's a conversation with leadership team. Your leadership doesn't fundamentally understand the value and maybe it's worth it to make the argument in favor of to illustrate that without this feedback loop, without this investment in the educational journey of developers, without the investment in what is going on in our product, and where have we allowed ourselves to remain ignorant of what is happening in the day-to-day of our users. We need those folks.Product managers are in sprints, they're in standups. They're doing, like, strategic planning and their yearly planning. We need a group who is rewarded to care about this but also is innately driven to do so as well. And that's not something that you can make. And it's not something that we otherwise see. It's part of why we have such an absence in good developer marketing is because marketers aren't paid well enough to ever have learned the skills to be developers, and so there's no skills transfer.Corey: One last topic that I want to get into something you've only been doing for a short while, but you've become an advisor at Heavybit, which is a VC firm. How did that come about and what do you do?Alyss: So currently, I—I'll do the super-high level. What I do right now is I host office hours with seed startups and Series A that are in the dev tool space. And we generally talk about developer relations, a little bit in developer marketing go-to-market strategies. And it's super enriching for me because I love hearing about different experiences and problems and, like, areas of practice. But it was really interesting, and a little bit of a make-your-own-luck-and-opportunity type deal.Where I live in Austin, Texas; I do not live in the Bay Area, I don't have all those connections, I've been a bit distant from it. And I saw someone who had accepted a role that I had interviewed for, end up in some of their content. And I was like, “They're doing a great job. They definitely deserve to be there, but I also had similar qualifications, so why should I also be there?” And I found someone, his name's Tim, on LinkedIn, who runs their events. And I reached out and I said, “Hey, Tim, how would you like a new advisor?” And so, Tim responded back and we—Corey: Knock knock. Who's there? It's me.Alyss: Yeah, exactly. It's—and it was just, I want this thing to happen. How do I make it happen? I ask.Corey: And what does it day-to-day that look like? How much time does it take? What do you do exactly?Alyss: Yeah. I mean, right now, it's about five hours every quarter. So, I spend anywhere between 30 minutes to an hour with various organizations that are a part of Heavybit's portfolio, talking with them through their motion to go general availability, or they want to start participating in events, or they want to discover what are the right events for them to—or, like, DevOpsDays, should we participate in that? Should we hire a DevRel person? Should we hire a product marketing person? Just helping them sort wheat from chaff in terms of, like, how to proceed.And so, it's relatively, for me, lightweight. And Heavybit also gives us the opportunity to contribute back in blog posts, participate in podcasts and be able to have some of those richer conversations. So, I have a set of bookmarks, so there's over 100, bookmarks long, that is fully curated across several different categories. That was my first blog post was diving into a few of those where I think are critical areas of developer relations. What are some of the conversations on DevRel metrics? How do I think about setting a DevRel strategy for the first time? How do I do my first DevRel hire? And so, I wouldn't even call it a second job. It's more of a getting to, again, enrich my own experience, see a wider variety of different problems in this space and expand my own understanding.Corey: I really want to thank you for being so generous with your time. If people want to learn more about what you're up to, how you view the world, and basically just come along for the ride as you continue to demonstrate a side of tech that I don't think we get to see very often, where can they find you?Alyss: I am@PreciselyAlyss on Twitter, as well as Twitch. Aside from that, I would not recommend looking for me.Corey: Excellent. Always a good decision. I will put links to that in the [show notes 00:30:00]. Thank you so much for your time. I appreciate it.Alyss: Thanks, Corey.Corey: Alyss Noland, Head of Developer Relations Relations and Product Marketing at Common Room. 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, insulting comment belittling community and letting the rest of us know by observation just why you've been thrown out of every community to which you've ever been a part.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.Announcer: This has been a HumblePod production. Stay humble.

To kick off 2023 in style, PJ spoke with several DevRel practitioners to get their advice to fellow folks in DevRel and people new to the industry looking for more information on how to do the best they can. Ranging from practical, to witty, to inspirational, these words of wisdom should help anyone on their journey. Enjoy the podcast? Please take a few moments to leave us a review on iTunes (https://itunes.apple.com/us/podcast/community-pulse/id1218368182?mt=2) and follow us on Spotify (https://open.spotify.com/show/3I7g5WfMSgpWu38zZMjet?si=565TMb81SaWwrJYbAIeOxQ), or leave a review on one of the other many podcasting sites that we're on! Your support means a lot to us and helps us continue to produce episodes every month. Like all things Community, this too takes a village. Photo by frame harirak (https://unsplash.com/it/@framemily?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash (https://unsplash.com/it/@framemily?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

Nader Dabit, Director of Developer Relations at Aave and Lens ProtocoI talks with Brian Friel about his journey moving from developing in web2 to web3. From creating educational content and authoring one of the first "Intro to Solana" programming articles, to founding Developer DAO and building the infrastructure for the next generation of web3 social apps. Show Notes:00:49 - Intro02:43 - Origin story / Background  06:13 -  AHA moment in Web 3.0 ?10:49 - Lens and Aave                18:30 - Composability between blockchains  21:45 - Advice to newcomers24:15 - A builder he admires in the Web3 ecosystem Full Transcript:Brian (00:00):Hey, everyone, and welcome to The Zeitgeist, the show where we highlight the founders, developers, and designers who are pushing the Web3 space forward. I'm Brian Friel, developer relations at Phantom. And I'm super excited to introduce our guest, Nader Dabit, the director of developer relations at Aave & Lens Protocol. Nader, welcome to the show. Nader (00:25):Hey, thank you for having me. Good to be here. Brian (00:27):I'm really excited to talk to you today. A lot of folks may know you from Crypto Twitter. You've been around a lot of different places in the Web3 ecosystem. But for some folks who might not know, you actually wrote one of the earliest intro to Solana programming articles that there were at the time, back in, I believe, summer 2021. And it's special to me, because this is actually the first article that I found on Solana that got me working at Phantom full time. So, before we dive into everything, I want to say thank you and welcome, and it's great to be talking to you today. Nader (00:58):Yeah, I remember very clearly when I wrote that article, because at the time I was trying to learn how to build on Solana. And I had a hard time finding all of the pieces that I needed to build out the types of application that I was used to building, just for a hello world type of thing. And I was actually traveling at the time from Croatia, and also Mexico during that week. And I remember just staying up sometimes all night, just trying to figure out what I thought was some basic stuff. And I was like, I have to document this stuff. It has to be documented somewhere, in a way that I would want it. (01:32):Because it's probably documented in other ways, like bits and pieces. But putting it all together, I was like, okay, this is going to be what I wanted to find. And I remember when I tweeted it out, it was one of the most popular tweets that I maybe have ever had, in the top five. That tutorial, the reception was just enormous. So, there was a lot of interest in Solana for developers, and I think that this was one of the things that enabled a lot of developers at the time to just get up and running, and see how it felt to build a full-stack application on Solana. Brian (02:02):No, I couldn't agree more. It was a time where there was a ton of demand, and just not enough resources or infrastructure. And it's been really cool, to just see all the derivative pieces that have come from that. A ton of folks have taken that article, built their own version, extended it in some ways. And view that and the initial paulx escrow tutorial as the two sparks that kicked off Solana development, and DevRel and all that. But before we get into everything today, you have a really interesting background. You were early to Solana, but then you worked across a number of different protocols already in the Web3 ecosystem. And before that, you were deeply involved in React and Web2 land. Could you walk us through a little bit about who you are and your background? Nader (02:43):Yes, so I've been a developer for about 10 years now, a little over 10 years. And I've specialized in, I would say four main areas of specialization during that time. I started off as a front end and single page application developer, I would call it, working with stuff from just plain JavaScript and HTML, to Angular, to React. And then, I moved into mobile development for a little over three years, specializing in cross platform application development with React native. (03:16):One of those years I was running a company called React Native Training, where I would train teams of engineers, where they had these siloed teams that were focused on either iOS or Android, and I would introduce them to React Native. And there was quite a bit of demand for that. So, a lot of the clients that I had, were large companies that had a lot of overhead with their developer budgets, and they were trying to find ways to not only have less resources needed to build out applications, but also to be able to build faster, and also to have a better singular code base, so we don't have to have two separate code bases. (03:54):So yeah, I had clients like Amazon and Teams at Microsoft, or individual engineers from Microsoft that would come to my training. Teams like Warner Brothers, and banks and stuff, were also my clients. So, that was really fun for about a year. And then, the next thing that I did is, I got interested in cloud computing. So, I ended up moving and working at AWS for a little over three years. And during that time I was doing developer relations there, which is what I'm doing now as well. And after a little over three years there, I got interested in the blockchain space. And I thought that while the work that we were doing at AWS was super important and very real world, there was a lot of applications and companies using it. I thought that the blockchain space was a little more exciting, just because it was newer. I thought the opportunities that were available for this technology, once it became mature enough to actually be usable for the ideas that we had, were really powerful and stuff. (04:50):And I felt like it was so early that there was a lot of room for growth, because a lot of these ideas were there and the technology... The primitives were there, but the maturity of those primitives weren't quite there. So, being part of that growth and stuff, to me it seemed really exciting. So yeah, I moved into blockchain space. Brian (05:07):And what year was that, Nader, real quick before you jumped in? Nader (05:11):So, I joined the blockchain world in April of 2021. So, a year and eight months ago, I guess, seven months ago. Brian (05:22):You made a huge impact in just that little time. I would've put you back at least a couple years on that, but that's really cool. Nader (05:28):Yeah, definitely the first time I got into this from the perspective of a developer was then, I had dabbled in crypto as an investor before that, but knew nothing about anything actually until then. And then, in that time, in the last 18 months, I've worked at the graph protocol, I've worked with Celestia, which is the first modular blockchain. And now, I'm working with Aave and Lens Protocol. Brian (05:48):That's great. And was there anything at that time, you had this great job at AWS, you've written a number of books, React Native in Action, all of these great resources that are used across a number of traditional companies. But was there anything about Web3 in particular that was an aha moment for you, or just made you just say, "I have to work in this space"? Or do you think it was more of a culmination of just years of watching it off to the side? Nader (06:13):Yeah, there was a few things. I'll look at this technology as a new way to build certain applications that wasn't possible in the past. I don't look at it as, oh, Web3 is going to replace everything that we had before. Instead, I think I look at it as it's going to probably disrupt certain types of industries, but it also just opens the door for new types of applications that are really exciting to me. And I think the one thing that stood out the most to me, is that we had public immutable and permanent infrastructure that developers could share, and use, and build on top of, almost like the way that we have code that is open source, that everyone can share, and use it, and clone it, and fork it, and do whatever. If we applied those same principles to actual software infrastructure, that was instead of the... We're kind of used to brittle infrastructure. (07:02):Most of the time when you're building on top of someone else's API, you don't know if it's going to be there tomorrow or even later today. You also have no control over the access of that. Someone can shut you off, someone can prevent you from using it at any time. So, you can't really share backend infrastructure. So, everyone's out there building out their own backend infrastructure for their own ideas, which is great if you need something custom. But there's a lot of things, I think, that would be very valuable for other people to share and not have to rebuild themselves. But it's just not possible through the traditional software infrastructure primitives that we have. Because a database can go down, someone can go and delete things from a database. You can't depend on that data being there, but with blockchain infrastructure you actually have those properties. (07:49):And that's really exciting to me, because what we're seeing exactly I think with Lens, is that if you provide a really high quality backend, and you bring a really high quality API that enables developers to build on top of it, you've done away with a large majority of the work that's needed to build an app, building out the backend. Just imagine if you only had to build out the front end, and you didn't have to worry about this, and everyone could share that backend infrastructure. (08:16):And that's what excited me the most. There weren't really a lot of real world implementations of this though at the time. There was NFTs and DeFi stuff, which is great, but I don't think the coming to market use case is going to be that. I think that will be things that are used a lot in the future, but not that. (08:32):And then, the other thing that excited me about this stuff, it's payments. And I think that also stablecoins, this idea of stablecoins, and offering stability to currencies around the world that don't have that, was pretty exciting to me. And also, just being able to permissionlessly access and send payments was revolutionary, as someone who has a lot of family in the Middle East and stuff, and is also familiar with what's going on in different parts of the world. I think one thing that was an aha moment for me, was someone was a cryptocurrency is very volatile. And I realized that some people in parts of the world, like the United States and Europe, they don't realize that everyone else's currencies are also volatile. If they think that everyone's currency is the US dollar, just is always... But they don't realize that the majority of the world lives in places that where their currency is just as volatile as cryptocurrency. (09:20):So, realizing that so many people just don't understand that, and there's so much privilege in the world that there's opportunities to build out these things, that bring equality around the world for stuff, just having stability in their currencies. So, stable coins to me, are really exciting. And that's again, one of the things that excites me actually about working at Aave is, we're going to be launching a stable coin. So, being able to be part of something like that, is pretty cool. Brian (09:44):Yeah, no, I couldn't agree more. And for folks who might be based in the US, or don't have the privilege, not having to worry about their own currency not being stable, even just having to go through the pain of sending a bank wire somewhere across different countries, it's like pulling teeth. And once you send something over crypto rails, and it's near instant, you're paying near nothing, and you realize it's on this public infrastructure that you just talked about. It's like an aha moment, where it's like how could we not use this in some capacity? It's pretty incredible. (10:15):So, you hit on a couple different things there. You hinted at Lens Protocol and Aave, both of which you are the director of DevRel at. Could you talk us through a little bit about what each of those two protocols are? For folks who have been in crypto for a little while, they probably know Aave, it's a household name. Darling of the DeFi Summer days. But it's quite interesting that then Lens is also under the same house as Aave, two very different protocols. Could you walk us through a little bit about what each of those are doing, and maybe why the similar teams are building both of them? Nader (10:50):Yeah, basically I'm working a lot more closely with Lens. Just the first couple of months that I've been here to get a lot of the ideas that I personally had off the ground, as someone who's been building on Lens. And I think we're going to be doing a lot of work in Aave though, starting at the beginning of next year. A lot of work actually is happening right now in Aave, but from the DevRel perspective, we're launching some stuff. So, we're going to use DevRel power to help bring that to market. But yeah, Aave is basically a Defi protocol, and allows people to lend and borrow crypto and real world assets, without having to go through a centralized intermediary. So, that's the main value prop of Aave. And then, Lens is a Web3... Or I wouldn't even bucket in that. It's essentially a social media protocol and social media application API, that allows developers to build social graph applications. (11:41):And with Lens, you can have a lot of this backend infrastructure, like I mentioned, already there, ready for you to use to build out applications. And I think that when we think of the five billion or so people on the internet today, we might say there isn't maybe a single thread that ties everyone online together. But if you do look at the most widely used applications in the world today, you could almost probably assume that a high nineties percent of those five billion people around the world, have used a social application so far. So TikTok, YouTube, Instagram, Facebook, Twitter, all of these applications, are social graph applications. And they have very similar characteristics. You go to the app, and you have to create a profile. So you do that, you have a profile. You then have the opportunity to create content. You then have the opportunity to follow people. You're then given a feed of content based on who you follow, and then people that are following you, your content is put into their feed. (12:39):So, if you think about an application from that perspective, you can actually bucket a large majority of internet traffic into social graph applications. And they all literally copy, and have these exact same characteristics. So, what if we could abstract some of that away, and make it to where people could actually have those features in their application, without having to build all of that from scratch. And that's what Lens is doing. And I think that from the sheer user adoption perspective, it's the first real world use case to me, that actually appeals to people without having to teach them anything off the bat. (13:15):And that's just one thing, but making that accessible, is another story, because historically blockchain applications are very not approachable by the average person. In fact, the UX is terrible for most blockchain applications. And I don't think people understand how much friction is involved in most web three applications, for the average person I know at AWS, we would literally spend weeks and months with customers. Sometimes those customers would spend millions of dollars just to remove a couple of hundred milliseconds of latency from one of their APIs, because that latency was costing them millions of dollars in revenue, because they would drop customers or whatever. (13:56):So, when you think about a few hundred milliseconds of latency being a huge issue for a real world application. Imagine telling a new customer that they have to first download this wallet that's going to give them these private keys and these seed phrases, and they have to understand how that works. Then, they're going to have to go and find this token somewhere on the internet, and they're going to have to find out how to purchase that token. Then they're going to have to learn which network that token is on, and they're going to have to transfer that token from the place that they bought it, into that new wallet, on the right network that they bought. (14:30):Then they're going to have to pay for every transaction that they make on the network. It's crazy to think that the average person is going to be interested in this stuff. And down the road, when people start using DeFi, and stuff like that, they might understand the value that you do probably want to have that security for paying for a transaction, and understanding how all that stuff works. But for onboarding new people, it's just crazy to think that we're going to onboard millions of people this way. (14:54):So, the approach beyond having an actual use case that makes sense for the average person, also lowering the barrier to entry for that UX, is a huge thing that we're trying to solve as well. And we have some stuff rolling out next year, that's going to address that. But we've already done some stuff. Or when I say we, I'm really speaking of the Aave engineering team, and the Lens engineering team, who is just really, really incredible. They've already done a lot of stuff. I think that lowers the barrier to entry for users. Gasless transactions, meaning that the user doesn't have to pay for the transaction on the network. Low cost networks like Solana, like Polygon, others out there, make this possible for the first time where you can actually subsidize transactions the same way you can subsidize software infrastructure like AWS. (15:38):When you use an app by Twitter, you're incurring cost on their backend, but it's so small that the company eats that, and pays for that software infrastructure themselves. You don't expect to pay for a tweet. When you tweet, you don't expect to have to pay them to do that. It's like that would be crazy. So, that's where we're getting, I think, with more scalable blockchain infrastructure. And that's one of the things that they implemented into Lens. And then, the other thing is that they implemented, is a dispatcher that allows you to delegate your signing to an abstraction that allows you to do certain things on chain, but not everything. So, you don't want to be able to send money without having to sign a transaction. That would be a security concern. But posting something to a social network that's delegated without you having to sign, makes a lot of sense. Because you could always go back. (16:24):And obviously, we've never even really, that I know I've had any issues with this, but let's say that you did something wrong and then posted a post that you didn't like. We have a soft delete feature in the API, you can go and delete something. But I guess my general point is that being able to post, and comment, and stuff, you shouldn't have to sign for all of these different interactions. And that's what the delegator allows you to do. You just have the same user experience that you would in a traditional Web2 app. Brian (16:49):Yeah, totally. You touched earlier on just a couple milliseconds, a hundred milliseconds of latency, makes the difference in user attention spans. Imagine having to go find that browser extension pop up. It's going to make you not want to tweet as much, second guess some of your actions. And then I agree as well, even we've seen this from a wallet side, a lot of... I think this is definitely where the space is going. Having some permissioned system right now, if you think of permissions with wallets, pretty much all of them just, it's a connect. And then by default, you could have any permissions, but it requires manual approval. And I think we're almost training users negatively in that sense, when everything's a pop-up action, they start to not take pop-ups as seriously. (17:31):But if we could make a system where we know certain actions are safe, we don't even have to alert you about this. But then, there is a transaction that potentially you'll be exchanging funds in this transaction, you should review this manually before sending it, that's definitely moving in the right direction. So, that's really cool to see that you guys are already building on that front. (17:49):You touched a little bit too about just how these blockchain ecosystems, up until now, have been largely inaccessible. And I would argue, also largely siloed from one another. There's a lot of different ecosystems out there. You've spent time at other projects that touch multiple different blockchains, multiple different layers. You're at the graph, you're at Celestia. Now you're at Aave and Lens, which is all over the EVM ecosystem. Can you speak a little bit to how you see everything that we're building in Web3, all these different blockchains, how some of these might compose over time? What is your worldview when you're working across all these different siloed ecosystems today? Nader (18:31):The thing that really turned me off a little bit when I started really understanding the ecosystem in general, was this Maximalism that you see. And I thought it was really toxic and stuff. And I didn't really like that at all. And so, that was one of the reasons I went to work with Celestia. I really liked their approach to technology, and I like the solution that they're bringing to the table and stuff. But I also really liked the founders, I would say anti-maximalist approach to their communications and stuff like that. And I just think that being so bought into a single idea, prevents you from seeing and understanding everything else that's out there. So, I don't know... Not only think it's just toxic in general, but I also think it's very limiting for your own career and your own understanding of the whole landscape. (19:18):Because if you box yourself in, you're preventing yourself from doing any research or understanding everything else out there in the world. So, my take has always been to really try to do due diligence on all of the different technologies that are out there, and try to truly understand them, and not have any bias to the way I look at something new. And really try to get to the bottom of it. But it's hard, because there's just so many different things that are happening at a given time. And there's also so many people that are shilling their own thing, without being very honest about what are the trade-offs sometimes. So, it is challenging to understand everything that's going out there. But yeah, my take is to always try to say, "Okay, this thing is here. I'm going to do some research." And once I understand it, I want to know the trade-offs, and I want to speak honestly about those trade-offs in the future. (20:10):Because nothing is perfect, and very rarely is something legitimate actually not worth anything at all. You'll see people that try to talk about certain technologies, as if they're completely worthless. When in reality, there's a trade-off there, that's actually being made, and they're just trying to make their thing look better by talking negatively about the other thing. But I think most of the technologies... Not all, but most of the technologies that make it into the mainstream, do have a good value proposition. The question is whether or not that is the right long term trade off to make. Those are the questions that I think that we don't always know the answer to. Brian (20:47):No, couldn't agree more. And I think it times up really well with what we're doing over here at Phantom. I think by the time this episode is live, we'll be taking the first few people off our beta wait list, for a multi chain Phantom, where it's all going to be one aggregated view of switching chains, and we agree that we want to get past the maximalism front. There's a lot of really awesome work being done across the VM ecosystem, across the Solana space, and everything in between. And I think it's a really cool time for the industry to be bringing this all together. I couldn't be more excited. (21:17):So, a few more questions here for you as we wrap up. You've hit on a lot across your journey through Web2 to Web3, everything that's going on now in Web3, across Lens and Aave. If you were a new dev coming in here, let's say you have TypeScript experience, your classic what you would need for some Web3 JS work, how would you point new developers who are interested in the space and coming into the space, and wanting to potentially contribute, and end up working full-time in this industry? Nader (21:46):Yeah, I think front end developers are just very uniquely suited, but also they are in a great position, and huge opportunities lie to them without having to learn a lot of new stuff, which is really cool, and really exciting. At least for me, as someone who is for the most part, just a front end or a mobile developer. I thought that it was very approachable to get into this space, because every application still needs a front end. The only difference is that instead of sending an HTTP or GraphQL request, a traditional HTTP request, you're sending an RPC request for the most part, to transact with these different networks and stuff. And I think that's the main thing that you would have to just try to dive into a little bit, and understand. And then, you probably would be ready to start doing some interviews. (22:29):And I think if you're a good front end engineer, even with the market as it is today, there's still a very good demand for that. I think the challenge has always been for junior engineers to get their foot in the door, unfortunately. I think it is still somewhat of a challenge if you're a junior, to land that first role. But beyond that, I think that if you have some skillset on the front end, you can get started with... Most companies that are hiring will probably give you a shot. If you've done just even the slightest amount of due diligence, to understand what are these client side libraries. So, you have things like Ethers.js, you have things like Solana.js. I believe we have WalletConnect, Rainbow Wallet. And then, I think that you probably know some of the more Solana specific wallet adapters, and stuff for JavaScript. (23:14):Anyway. So experiment, figure out which ecosystem you want to be in. Look at all the different client side libraries and stuff that are there. Just build out a couple of apps over the week, literally just building out two or three apps, and throwing on your GitHub, will probably set you apart from 99% of the people out there. And yeah, it's really not rocket science, I don't think, to get hired in this industry if you're a friend and developer. So, that would be my take, is just to realize that 95% of your skills are transferable. The other 5% is just understanding these blockchain specific interactions with RPCs, and the wallet stuff as well, which is the web3 blockchain version of identity. Brian (23:50):I couldn't agree more. Building in public, building out that resume, is such a stronger signal than anything else in this space. And it can be done. It's just a couple of weeks. If you put the hard work into it, you already have the skillset. It's just about showing your work at that point. Well Nader, this has been awesome. One closing question we ask all our guests, and I'd love to hear this from you, is who is a builder that you admire in the Web3 ecosystem? Nader (24:16):Wow, that's a good question. I think that there's not just a single one, there's just really so many. I would say that if I had to point out maybe a couple of people, one of them would definitely be the team I have here, that I've met here at Lance and Ave. They're not really that active, or as active on social media, I would say. But I want to give a shout-out to Josh, who is the main backend engineer on Lens. He's just incredible. He'll come up with a solution for what is a problem that maybe has never been solved before, an idea. And then, he'll actually have implemented that in sometimes days or weeks. And just seeing that done on a consistent basis, is just really wild. There's a lot of developers from within developer DAO, that I would shout out. I think that engineers over at Celestia, like Mustafa Al-Bassam, and the rest of the folks over there, are really incredible. There's a lot of high quality people that are building right now. It's hard to say anyone without feeling like I'm leaving a bunch of people out, to be honest. Brian (25:17):That's a good sign though. Nader (25:18):But yeah, but Armani Ferrante. Armani is in this salon ecosystem. He's definitely one of my favorites as well. Brian (25:24):Oh, that's awesome. Well, I couldn't agree more. Lots of great names all through that list. No shortage of folks in this industry, who are working hard every day to push this space forward. Nader, thanks so much for coming on the show. Where can folks go to learn more about what you're up to at Lens? Nader (25:39):Yeah, I would just say, you can go to my Lens profile. It's nader.lens, on any of the lens front ends, like Lenster, on Twitter, on DaBa3. And then, I have my personal webpage set up on RWE, that's my links to my YouTube and stuff. And that's on nader.rwe.dev. Brian (25:58):Awesome. Nader Dabit, thanks for coming on the Zeitgeist. Nader (25:59):Thank you for having me.