Podcasts about developer advocacy

In this podcast episode, we talked with Will Russell about From Hackathons to Developer Advocacy.About the Speaker: Will Russell is a Developer Advocate at Kestra, known for his videos on workflow orchestration. Previously, Will built open source education programs to help up and coming developers make their first contributions in open source. With a passion for developer education, Will creates technical video content and documentation that makes technologies more approachable for developers.In this episode, we sit down with Will—developer advocate, content creator, and passionate community builder. We'll hear about his unique path through tech, the lessons he's learned, and his approach to making complex topics accessible and engaging. Whether you're curious about open source, hackathons, or what it's like to bridge the gap between developers and the broader tech community, this conversation is full of insights and inspiration.

In this Modern Web Podcast episode, hosts Rob Ocel and Danny Thompson chat with Bree Hall, developer advocate at HubSpot and content creator known as "Bytes of Bree." Bree shares her journey from front-end engineer to advocacy, offering insights on balancing travel, staying productive, and navigating the pressures of being "always on." They explore creating engaging content, short vs. long-form formats, and how to build trust with an audience. Bree also shares tips on learning, working, and sharing knowledge while staying authentic in the tech space. Key Points from the Episode: Transition to Developer Advocacy: Bree shares her experience moving from front-end engineer to developer advocate, highlighting the expanded ways to contribute beyond coding. Managing Travel and Productivity: Practical tips for balancing frequent travel with work, including maintaining a travel kit, planning small tasks, and adapting work hours. Specializing in a Tech Stack: Bree emphasizes the importance of mastering a specific tech stack deeply, choosing Astro, React, and Tailwind as her focus for 2025. Short vs. Long-Form Content: Discussion on how short-form content skills improve long-form storytelling, with platforms like TikTok emerging as powerful tools for learning and discovery. Chapters 0:00 - 0:21 Introduction to Popular Tech Content 0:21 - 0:57 Exploring Niche Technical Topics 1:03 - 1:26 Podcast and Guest Introduction 1:32 - 2:04 Transitioning to Developer Advocacy 2:04 - 2:41 Key Differences Between Engineering and Advocacy 3:07 - 3:48 Perceptions vs. Reality of Developer Advocacy 3:48 - 5:25 Navigating the Challenges of Always Being "On" 5:25 - 6:34 Travel Productivity Tips for Advocates 6:34 - 7:24 Balancing Work During Heavy Travel 7:24 - 8:46 Tips for Staying Organized on the Road 8:46 - 10:12 Personal Rituals to Stay Grounded 10:12 - 11:17 Optimizing Gear for Productive Travel 11:17 - 12:14 Reflecting on Priorities for 2025 12:14 - 14:22 Choosing and Mastering a Tech Stack 14:22 - 15:56 Advice for Junior Developers 15:56 - 18:10 Balancing Fun and Learning in Development 18:10 - 19:55 Sharing the Journey: Content Creation Insights 19:55 - 22:24 The Spectrum of Developer Passion 22:24 - 24:03 Finding Your Lane in Tech Content 24:03 - 25:02 Diverse Interests in Developer Content 25:02 - 26:31 Content Creation and TikTok Strategies 26:31 - 27:42 The Success of "Break into Tech" Content 27:42 - 30:15 The Role of TikTok as a Search Engine 30:15 - 32:01 Short Form vs. Long Form Content 32:01 - 33:56 The Art of Engaging Content 33:56 - 36:04 The Power of Short Form in Building Trust 36:04 - 37:39 Evolving as a Content Creator 37:39 - 39:01 Processing and Discussing Information in Content 39:01 - 40:30 Challenges of Live Content Creation 40:30 - 41:39 Closing Remarks and Guest Links Follow Bree on Social Media Twitter: https://x.com/bytesofbree Linkedin: https://www.linkedin.com/in/briannahall0/ Sponsored by This Dot: thisdot.co

Join us for an insightful conversation with Ceora Ford about the intersection of security, development, and community building. We explore why managing identity security is more complex than simple authentication, examine the trade-offs of Next.js's App Router in enterprise applications, and uncover strategies for effective technical content creation. Ceora shares her experience transitioning from digital marketing to developer advocacy, offering practical advice for building a presence across platforms like TikTok, Twitter, and LinkedIn.SponsorConvex is the backend for founders. Convex is the backend application platform for product-obsessed founders.Chapter Marks00:00 - Intro01:14 - Identity Security Discussion05:25 - Evolution of React and Next.js08:33 - Documentation and Developer Experience15:43 - Sponsor: [Convex](https://convex.dev)16:20 - Authentication in the App Router21:31 - Content Creation and Marketing Strategy27:50 - Social Media Platform Strategy34:51 - Analytics and Tool Discussion41:08 - Picks and PlugsBradPick: His dog Roman (who they had to say goodbye to at age 17)Plug: Social media accountsBrad on TwitterBrad on BlueSkyBrad on YouTubeBekahPick: "The Game" podcast with Alex HormoziPlug: Open Sauce (opensauced.pizza) and her team's upcoming feature launchCeoraPick: "The Good Place" (TV show on Netflix)Plug: Social media accountsCeora on LinkedInCeora on TwitterCeora on BlueSkyCeora on TikTokLinksAuth0 by OktaNext.jsAuth0 documentation for Next.js integrationGatsbyAstroConvexJekyllGraphQLOpen SaucedMark Techson

Brian Douglas is the founder and CEO of Open Sauced where he works on increasing the knowledge and insights of open-source communities. In the past he's lead Developer Advocacy at GitHub by fostering a community of early adopters through content creation showcasing the newest Github features. Open Sauced just joined the Linux Foundation and we learn how and why that move happened on this episode!https://opensauced.pizza/blog/bridging-the-gap-organizational-insights

This interview was recorded for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview here:https://gotopia.tech/articles/330Cassidy Williams - Senior Director of Developer Advocacy at GitHub Ben Hong - Staff Developer Experience Engineer at Pandan Studio  RESOURCESCassidyhttps://twitter.com/cassidoohttps://www.linkedin.com/in/cassidoohttps://github.com/cassidoohttps://cassidoo.coBenhttps://x.com/bencodezenhttps://m.webtoo.ls/@bencodezenhttps://github.com/bencodezenhttps://www.linkedin.com/in/bencodezenhttps://www.bencodezen.ioLinkshttps://obsidian.mdhttps://www.notion.sohttps://bear.apphttps://www.keyboardmaestro.comhttps://github.com/features/copilothttps://claude.aihttps://www.cursor.comhttps://www.tabnine.comDESCRIPTIONCassidy Williams and Ben Hong explore the intersection of aesthetics, functionality, and AI in the world of coding. They begin by examining how the design and feel of tools, from digital typewriters to customized keyboards, can significantly impact productivity and enjoyment. As they delve into AI's growing role, they assess various tools like GitHub Copilot, Claude.ai, and others, emphasizing how these technologies complement rather than replace human creativity.Their conversation highlights the balance between leveraging AI for efficiency and maintaining personal touch and critical thinking in coding. They argue that while AI advances, the human element remains crucial in driving innovation and crafting meaningful work. [...]RECOMMENDED BOOKSTaylor Royce • The 2024 Developer Productivity Guide • https://amzn.to/3XNAjqzUnni Panicker • The Software Developer's Guide to ChatGP • https://amzn.to/3MSpoWwAlex Castrounis • AI for People and Business • https://amzn.to/3NYKKToPhil Winder • Reinforcement Learning • https://amzn.to/3t1S1VZBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Annie Sexton, Developer Advocate at Fly.io, to discuss Fly.io's approach to simplifying cloud deployment. Annie shares Fly.io's unique position as a public cloud that offers the flexibility of infrastructure control with a streamlined developer experience. They explore Fly.io's private networking and distributed app capabilities, allowing developers to deploy applications close to users worldwide with ease. Annie also addresses common challenges in distributed systems, including latency, data replication, and the balance between global reach and simple, single-region projects. Chapters: - 00:00 - 01:32 Introduction to the Modern Web Podcast and Guests - 01:33 - 04:00 Overview of Fly.io and Annie's Role as Developer Advocate - 04:01 - 06:35 What Makes Fly.io Stand Out Among Cloud Platforms - 06:36 - 08:57 Distributed Applications: Benefits and Use Cases - 08:58 - 11:28 Understanding Distributed Web Servers and Private Networking - 11:29 - 13:49 Challenges in Distributed Data and Replication Techniques - 13:50 - 16:12 Fly.io's Unique Solutions for Data Consistency - 16:13 - 18:34 When to Consider a Distributed Setup for Your Application - 18:35 - 20:35 Tools and Tips for Evaluating Geographical Distribution Needs - 20:36 - 22:22 Simplifying Global Deployment with Fly.io's Command Features - 22:23 - 24:18 Considerations for Latency and Performance Optimization - 24:19 - 26:45 Balancing Simplicity with Advanced Control for Developers - 26:46 - 29:04 Easy Deployment for Hobbyists and Smaller Projects - 29:05 - 31:27 Getting Started on Fly.io with Fly Launch - 31:28 - 33:48 Developer Advocacy and Meeting Diverse Needs in the Cloud - 33:49 - 36:15 Catering to Beginners and Experienced Developers Alike - 36:16 - End Closing Remarks and Where to Find Fly.io and the Hosts Follow Annie Sexton on Social Media Twitter:https://x.com/_anniebabannie_ Linkedin: https://www.linkedin.com/in/annie-sexton-11472a46/ Github: https://github.com/anniebabannie

Chris Cooney is the Head of Developer Advocacy for Coralogix, a SaaS observability platform that analyzes logs, metrics, and security data in real time.In this episode, Chris returns to the podcast to discuss the modern state of agile. We talk about the difference between Agile versus agile and the conflicts that arise here, as well as the current industry trends and expectations about what the future holds.Links & mentions:agiledrop.com/podcast/chris-cooney-how-data-observability-helps-enable-digital-transformationtheregister.com/2024/06/05/agile_failure_rateslinkedin.com/in/chris-cooneychris.cooney@coralogix.com

To kick off Elixir Wizards Season 13, The Creator's Lab, we're joined by Zach Daniel, the creator of Igniter and the Ash framework. Zach joins hosts Owen Bickford and Charles Suggs to discuss the mechanics and aspirations of his latest brainchild, Igniter—a code generation and project patching framework designed to revolutionize the Elixir development experience. Igniter isn't just about generating code; it's about generating smarter code. By leveraging tools like Sourcerer and Rewrite, Igniter allows developers to modify source code and batch updates by directly interacting with Elixir's AST instead of regex patching. This approach streamlines new project setup and package installations and enhances overall workflow. They also discuss the strategic implications of Igniter for the broader Elixir community. Zach hopes Igniter will foster a more interconnected and efficient ecosystem that attracts new developers to Elixir and caters to the evolving needs of seasoned Elixir engineers. Topics discussed in this episode: Advanced package installation and code generation improve the developer experience Scripting and staging techniques streamline project updates Innovative methods for smoother installation processes in Elixir packages High-level tools apply direct patches to source code Progressive feature additions simplify the mix phx.new experience Chaining installers and composing tasks for more efficient project setup Continuous improvement in developer experiences to boost Elixir adoption Encourage listeners to collaborate by sharing code generation patterns Introduction of a new mix task aimed at removing the "unless" keyword in preparation for Elixir 1.18 You can learn more in the upcoming book "Building Web Applications with Ash Framework" by Zach and Rebecca Links mentioned: https://smartlogic.io/ https://alembic.com.au/blog/igniter-rethinking-code-generation-with-project-patching https://hexdocs.pm/igniter/readme.html https://github.com/ash-project/igniter https://www.zachdaniel.dev/p/serialization-is-the-secret https://www.zachdaniel.dev/p/welcome-to-my-substack https://ash-hq.org/ https://hexdocs.pm/sourceror/readme.html https://smartlogic.io/podcast/elixir-wizards/s10-e09-hugo-lucas-future-of-elixir-community/ https://github.com/hrzndhrn/rewrite https://github.com/zachdaniel https://github.com/liveshowy/webauthn_components https://hexdocs.pm/elixir/Regex.html https://github.com/msaraiva/vscode-surface https://github.com/swoosh/swoosh https://github.com/erlef/oidcc https://alembic.com.au/ https://www.zachdaniel.dev/ Special Guest: Zach Daniel.

On this Screaming in the Cloud replay, we're looking back to our conversation with Cassidy Williams, a Senior Director of Developer Advocacy at GitHub and the co-founder and chief product officer of Cosynd, Inc. Prior to these positions, she worked as the principal developer experience engineer at Netlify, an instructor and senior engineer at React Training, director of outreach at cKeys, a senior software engineer at CodePen, head of developer voice programs at Amazon, and a software engineer at Venmo, among other positions. Join Corey and Cassidy as they reflect on what Netlify is and what a developer experience engineer does, how JavaScript started off as a toy language and why everything that can be built with JavaScript will be moving forward, the benefits of using low-code development tools, how discovering TikTok helped Cassidy drum up a major following on social media, how Cassidy's humor is never directed at people or organizations and why that's the case, the differences between recording a podcast and live streaming on Twitch from the speaker's point of view, and more.Show Highlights(0:00) Intro(0:22) Backblaze sponsor read(0:49) What is Netlify and its role of a principal developer experience engineer(2:50) Is JavaScript the future?(7:46) Using low-code tools for web development(12:12) Having a goofy internet presence in a serious field(17:23) Social platforms as a means to teach(24:50) Twitch streaming and its inherent challenges(28:16) Cassidy's online coursework and how she answers, “So, what do you do?”(32:12) Unique ways of tracking Twitter followers(37:15) Where you can find more from CassidyAbout Cassidy WilliamsCassidy is a Senior Director of Developer Advocacy at GitHub. She's worked for several other places, including Netlify, CodePen, Amazon, and Venmo, and she's had the honor of working with various non-profits, including cKeys and Hacker Fund as their Director of Outreach. She's active in the developer community, and was one of Glamour Magazine's 35 Women Under 35 Changing the Tech Industry and LinkedIn's Top Professionals 35 & Under. As an avid speaker, Cassidy has participated in several events including the Grace Hopper Celebration for Women in Computing, TEDx, the United Nations, and dozens of other technical events. She wants to inspire generations of STEM students to be the best they can be, and her favorite quote is from Helen Keller: "One can never consent to creep when one feels an impulse to soar." She loves mechanical keyboards and karaoke.LinksTikTok: https://www.tiktok.com/@cassidooNewsletter: https://cassidoo.co/newsletter/Scrimba: https://scrimba.com/teachers/cassidooUdemy: https://www.udemy.com/user/cassidywilliams/Skillshare: https://www.skillshare.com/user/cassidooO'Reilly: https://www.oreilly.com/pub/au/6339Personal website: https://cassidoo.coTwitter: https://twitter.com/cassidooGitHub: https://github.com/cassidooCodePen: https://codepen.io/cassidoo/LinkedIn: https://www.linkedin.com/in/cassidooOriginal Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/memes-streams-software-with-cassidy-williams/SponsorBackblaze: https://www.backblaze.com/ 

Welcome to another engaging episode of Maintainable! Robby sits down with Kate Holterhoff, Ph.D., a Senior Analyst at RedMonk and former front-end engineer, to explore the intricate world of software maintenance, documentation, and the future of developer roles. Kate brings her unique perspective from her time as a practitioner at a digital marketing agency, her academic background, and her current role in developer advocacy.Topics Explored[00:00:00] Introduction to Kate's Background: Robby and Kate discuss her journey from academia to front-end engineering and now to being a Senior Analyst at RedMonk. Kate shares how her experiences have shaped her perspective on software maintenance.[00:04:00] Well-Maintained Software: Kate dives into her definition of well-maintained software, emphasizing modularity, semantic readability, and the importance of considering future developers who will interact with the code.[00:11:30] The Challenges of Agency Work: Kate reflects on her time at a digital marketing agency, where she often worked on projects that had passed through many hands. She discusses the importance of balancing quick deliverables with maintainability.[00:20:45] The Role of Documentation: Kate shares insights on the value of documentation for distributed teams, highlighting her experience organizing documentation sessions ("documentation paloozas") to capture team knowledge and ensure maintainability.[00:30:00] RedMonk and Developer Advocacy: Kate explains her role at RedMonk and how the firm differs from traditional analyst firms like Gartner. She discusses RedMonk's focus on developers as key decision-makers in the tech landscape.[00:39:15] Front-End Developers as Kingmakers: Robby and Kate explore how front-end engineers are increasingly influencing the adoption of tools and technologies within organizations. Kate describes this trend as front-end developers becoming "kingmakers" in the industry.[00:49:50] AI and Developer Tools: Kate discusses the integration of AI into developer tools, the potential benefits, and challenges for junior developers. She emphasizes the importance of understanding how to read code in an AI-assisted world.Key Takeaways:Emphasize modularity and semantic readability to ensure code can be easily maintained by future developers.Documentation is crucial for maintainability, especially in distributed and contractor-heavy teams.Front-end developers are becoming key decision-makers, influencing tool and technology adoption.AI is increasingly integrated into developer workflows, making it essential for developers to focus on reading and understanding code.The definition of a 'developer' is evolving, with more abstracted tools and AI playing a larger role in development processes.Resources Mentioned:RedMonkKate Holterhoff on LinkedInKate Holterhoff on TwitterDarwin's The Origin of SpeciesEpisode Highlights:[00:00:00] Introduction to Kate's Background[00:04:00] Characteristics of Well-Maintained Software[00:20:45] The Importance of Documentation[00:30:00] What Does a Senior Analyst at RedMonk Do?[00:39:15] Front-End Developers as Kingmakers[00:49:50] The Role of AI in Developer ToolsThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

While Alex is at PragVue, Michael is joined by Developer Advocate Erik Hanchett who works at no other company than AWS. In this DejaVue episode, they discuss the different duties of a Developer Advocate and skills one need to become one, as well as everything around content creation and conferences.In addition, Erik shares how it is to write Vue code as a Software Engineer at AWS, which he did for multiple years. Enjoy the episode!Our GuestErik HanchettWebsiteTwitterYouTubeChapters(00:00) - Welcome to DejaVue (00:35) - How would you describe your job? (03:20) - Do you miss the deep technical problems? (09:41) - Duties when speaking at a conference (12:50) - What is Developer Advocacy? (23:30) - Which skills do you need to be a Developer Advocate? (26:40) - Your first content pieces doesn't have to be perfect (28:16) - First Five unreleased DejaVue episodes (29:44) - Putting yourself out there (32:09) - Erik's first podcast guest appearance ever (37:10) - Using Vue.js at Amazon Web Services (41:29) - How did you get into Vue? (43:16) - Working on AWS Open Source projects (45:06) - Migrating a library from Vue 2 to Vue 3 (49:48) - Nested Slot Bonanza (51:34) - Angular, React and Vue devs in the same project (52:15) - Wrapping up Links and ResourcesGet 15% OFF for your Vue Toronto ticket with code DEJAVUE *AWS AmplifyVueUseVue DemiXStateYour HostMichael ThiessenTwitterYouTubeWebsite---Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Hi, Spring fans! In this installment, I talk to Vaadin developer advocacy legend Marcus Hellberg about the lates-and-greatest in the wide and wonderful world of Spring.

The Developer Advocacy team continues to change – this time we've got a new team member and we're eager to get to know her better. So have a listen. Topics 00:00 Welcome/Introductions 07:10 Platform passion 07:53 Advocacy ideas 11:26 Challenges for Kristy 18:41 Any surprises? 19:36 Getting prepared for this role 21:29 Words of advice 22:30 Contact info 23:03 Outro Links Kristy's LinkedIn Check out the other ServiceNow podcasts. See omnystudio.com/listener for privacy information.

The Developer Advocacy team continues to change – this time we've got a new team member and we're eager to get to know her better. So have a listen. Topics 00:00 Welcome/Introductions 07:10 Platform passion 07:53 Advocacy ideas 11:26 Challenges for Kristy 18:41 Any surprises? 19:36 Getting prepared for this role 21:29 Words of advice 22:30 Contact info 23:03 Outro Links Kristy's LinkedIn Check out the other ServiceNow podcasts. See omnystudio.com/listener for privacy information.

Marc Hess, a Developer Advocate at Prisma, talks about the evolution of Prisma from an ORM tool to a comprehensive platform for database management. The discussion includes practical advice on using Prisma, optimizing documentation, and Marc's experience with developer advocacy. The team also explores the benefits of Prisma Pulse for real-time applications and how it compares to other ORM tools like Drizzle.Sponsor ConvexConvex is the backend for founders. Convex is the backend application platform for product-obsessed founders.Show Notes00:00 - Introduction and Sponsor Shoutout00:43 - Sponsor: Convex01:06 - Introducing Marc Hess from PrismaPrismaRedwoodJS04:04 - YouTube Content Creation Tips11:24 - Introduction to Prisma and Its Products14:19 - Deep Dive into Prisma Pulse19:06 - Best Practices for DocumentationPrisma DocumentationDivio's Documentation System29:13 - Client Extensions in PrismaPrisma Client Extensions37:13 - Prisma vs Drizzle DiscussionDrizzle44:00 - Picks and Plugs Segment

It's episode TWO HUNDRED! And what a two hundred episodes they've been, from public speaking, to Developer Advocacy, to our recent focus on the API space, it's been an incredible journey, and we want to thank you our listeners above all, for sticking with us, and inspiring us to stay curious, and keep seeking out those in the DevRel world and beyond, so we can all learn from them together. Today's guest couldn't be more appropriate, as we feel the wonderful Steven Coochin sums up so much of what we do here on the Fireside podcast, from his bold ideas, to his empathetic outlook and his staunch commitment to an open source world. Steven is the chief innovation officer at Lilypad. A returning guest of the podcast, he joins us with quite the update on his endeavours. Lilypad, as Steven describes it, is the way he and his team intend to democratise AI, doing off-chain compute, with on-chain guarantees. I*if you've ever dabbled in creating an AI product (and we have), you'll know the costs associated can be prohibitively expensive, due in large part to the heavy duty GPUs required. Well Lilypad acts as a sort of Airbnb for GPUs, leaving you free to build your product, instead of messing around with cloud providers who can barely support their own systems, let alone yours. They've recently exploded in popularity, and Steven talks us through his whiplash of seeing their user number collect a few extra zeroes at the end. And of course, it wouldn't be a Fireside with Voxgig episode without Richard and Steven diving into the DevRel aspects of his work, and how integral an open source model is to the heart of Lilypad. Thank you again to all of our listeners, and lastly to our wonderful guests. Here's to a hundred more! Reach out to Steven here: https://www.linkedin.com/in/developersteve/ Check out Lilypad here: https://blog.lilypadnetwork.org/ Find out more and listen to previous podcasts here: https://www.voxgig.com/podcast Subscribe to our newsletter for weekly updates and information about upcoming meetups: https://voxgig.substack.com/ Join the Dublin DevRel Meetup group here: www.devrelmeetup.com

Chris Cooney is the Head of Developer Advocacy for Coralogix, a SaaS observability platform that analyzes logs, metrics, and security data in real time.In this episode, we talk about data observability and how it helps enable digital transformation. We discuss why it's important to prioritize observability from the start, how to optimize observability-related costs, the importance of responsible data use, and the impact of AI technologies.Links & mentions:coralogix.comlinkedin.com/chris-cooney

Today, we have Talia Nassi on the show. Talia's been leading Developer Advocacy at Akamai. Akamai is in a really interesting space where they've been around for a long time, as a CDN provider, as a security provider, and now they acquired Linode, and acquired a bunch of other companies which has expanded them into more of like a full fledged cloud provider. We had a really interesting discussion talking about the expansion, we also talked about her thoughts on infrastructure as code, multi cloud, and just getting into DevRel and what that experience has been like for her.

In perhaps a very fitting way to wrap up the Career Pathways Series, we talk to Ian Douglas about Developer Advocacy, a role that really demonstrates how software development skills can be applied in a variety of meaningful ways. Ian dives into how different this role can look from company to company, the travel, the conferences, the content, the glamor. Are Developer Advocactes the influencers of software? You decide. If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a Try Coding class at turing.edu/try-coding.

Tracy Lee joins the Compressed.fm to discuss the integration of AI in development, the evolution of documentation practices, and her role in leading community projects and tech innovations.SponsorPostmanPostman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.Attend their Upcoming Conference - April 30 - May 1, 2024 in San Francisco. Amy and James will be there in person.Show Notes00:00:00 - Introduction and Overview00:00:38 - Sponsor: PostmanPostCon - April 30 - May 1, 202400:01:59 - Guest Introduction: Tracy Lee00:06:02 - Tracy Discusses Upcoming Talks at CityJS and CascadiaJS00:10:51 - Challenges with Documentation in DevelopmentMaterial Design (v3)Divio's Documentation System00:17:08 - The Value of Asking Questions and Community SupportEpisode 169 with Cory Miller, Not Knowing EverythingCode Stackr on YouTube (videos specifically on GitHub CoPilot alternatives)This VS Code AI Coding Assistant Is A Game Changer!I Cannot Believe How Good This VS Code AI Coding Assistant Is!Prompt Engineering GuidesOpenAIAnthropicImage Prompt EngineeringDallEGoogle Doc with Examples00:24:05 - Balancing Professional and Personal LifeTemplate for Annual Planning Spreadsheet00:26:41 - Picks and PlugsJames:Pick: KitchenAid mixerPlug: Learn Build Teach Community and Deals for Devs projectTracy:Pick: ToniesPlug: This.Dot and their engineering leadership resourcesThis Dot Labs is HiringAmy:Pick: Kidamento cameraPlug: Two Week BuildBekah:Pick: Coconut cashew crisps from AldiPlug: Virtual Coffee resources on open source00:31:15 - Closing

Today I had the pleasure of interviewing Daliana Liu. Daliana is the host of the Data Scientist Show. She also has experience in developer advocacy and working as a data scientist in large tech companies and startups. Today we talk about why she quit her job in tech, how developer advocacy could be improved, and much more! Podcast Sponsors, Affiliates, and Partners:- Pathrise - http://pathrise.com/KenJee | Career mentorship for job applicants (Free till you land a job)- Taro - http://jointaro.com/r/kenj308 (20% discount) | Career mentorship if you already have a job - 365 Data Science (57% discount) - https://365datascience.pxf.io/P0jbBY | Learn data science today- Interview Query (10% discount) - https://www.interviewquery.com/?ref=kenjee |  Interview prep questionsDaliana's Links:LinkedIn - https://www.linkedin.com/in/dalianaliu/Personal Website - https://dalianaliu.com/Podcast - https://www.youtube.com/c/thedatascientistshow

Follow: https://stree.ai/podcast | Sub: https://stree.ai/sub | New episodes every Monday! Join us as we dive into the fascinating intersection of API gateways and real-time analytics with Viktor Gamov, the new head of Developer Advocacy at StarTree. Viktor shares his insights from his recent experiences and explores how these technologies are transforming user-facing analytics. We also discuss Viktor's upcoming all-day Pinot training at the RTA Summit and delve into some intriguing topics like the "Hyperion Cantos" and the concept of a StarTree. Join us at the summit, visit rtasummit.com► Hyperion Cantos by Dan Simmons: https://www.amazon.com/Hyperion-Cantos-Book-Complete-Set/dp/B084ZB7SMP► The Four: The Hidden DNA of Amazon, Apple, Facebook, and Google by Scott Galloway: https://www.amazon.com/Four-Hidden-Amazon-Facebook-Google/dp/0525501223► The Movie Database: https://developer.themoviedb.org/docs/getting-started► Developer Voices episode ft. Bobby Calderwood: https://www.youtube.com/watch?v=V7vhSHqMxus

In this episode of The State of Developer Education, Jon is joined by Nicolas Grenié, a Developer Advocate for Typeform. Join them as they discuss Nicolas' coding origin story, the evolution of developer advocacy over the past decade, and the impact of low-code/no-code tools. Nicolas shares valuable insights into the value of content creation and partnerships, as well as the role of AI in the developer ecosystem.

In this week's episode, Jon is joined by Jacklyn Biggin, SJ Morris, and John Vajda. Jacklyn Biggin is a Developer Advocate at Automattic, SJ Morris is the Senior Manager of Developer Community at HubSpot, and John Vajda is DX and Growth Team Manager at Deepgram. In this episode, Jon and his guests discuss the evolving landscape of developer relations and how teams measure impact and success. They also delve into topics such as the shift towards virtual events and online communities, the importance of facilitating connections between developers, the role of content in developer relations, and how developer input influences product direction.

In today's episode, we delve into the surprising world where competitors and third parties outshine original services in documentation, with notable examples like Auth0 and AWS Cognito, and Logz.io's take on Elasticsearch. We also explore ServiceNow's impressive performance boost, fueled by generative AI. The episode further unpacks the future of software engineering as predicted by Gartner and the pivotal role of developer advocacy in ethical technology. Join us for a comprehensive discussion on the evolving landscape of tech development and corporate investment in AI.Stay updated with new weekly episodes every Thursday – and don't forget to subscribe! For more behind-the-scenes content, follow us @justshiftleft on Facebook, Instagram, Twitter, and LinkedIn.

Join Dan Vega and DaShaun Carter as they bring you the latest updates from the Spring Ecosystem. Are you passionate about technology and love engaging with communities or peers? Ever wondered how you could turn these interests into a fulfilling career or utilize them within your current organization? Look no further! In this episode, we'll demystify Developer Advocacy, a role that sits at the intersection of technology, community engagement, and education.

In this special episode of Tales at Scale - this is our final episode of our first season! - Peter Marshall, Director of Developer Relations at Imply joins the show to discuss the highlights of 2023 for Apache Druid. We dive into the significant feature releases and enhancements that have transformed Druid over the past year, including the SQL standardizaion, query from deep storage, experimental window functions, and the growing Druid community. Come for the retrospective, stay for the peek into the future of what's to come for us and for Druid in 2024. See you all next year!

In this episode, Jon talks to Kirk Kaiser, former Head of Developer Relations at Gitpod and author of Make Art with Python, a book that teaches programming fundamentals through art instead of print statements. In this episode, Kirk and Jon explore software development through the lens of creativity to uncover the intersections of art, coding, and AI. Join them as they provide practical insights into the world of technology by highlighting its connection to art.

What's the difference between developer advocacy, tech evangelism, and solutions architecture? A few years ago, all these job titles would have sounded made up. But in the mad rush we know as "cloud development", each of them have distinct roles and importance. Join Michael "Focus Otter" Liendo and Allen Helton as they dive into what makes developer advocacy unique and relevant. The two discuss "mid-funnel" advocacy, how teams should utilize DA's, and touch on imposter syndrome. About Michael Michael is a senior developer advocate for AppSync at AWS. He has a passion for educating others and does so via his blog, videos, and speaking at conferences. Michael focuses on fullstack development and is particularly interested in Micro-SaaS applications. He also goes by Focus Otter, which is his highly recognizable and influential tech brand. Links Twitter - https://twitter.com/focusotter LinkedIn - https://www.linkedin.com/in/focusotter Focus Otter blog - https://blog.focusotter.com Hammock-driven development video -https://www.youtube.com/watch?v=f84n5oFoZBc --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

On this episode of the AI For All Podcast, Ismaen Aboubakare, Head of Developer Advocacy at Airkit.ai, joins Ryan Chacon and Neil Sahota to discuss prompt engineering for businesses. They talk about what makes a good prompt, the role of prompt engineers, prompt engineering versus high level programming languages, domain expertise, who hires prompt engineers, getting started with prompt engineering, open source LLMs, and how businesses can start adopting AI. Ismaen Aboubakare is the Head of Developer Advocacy at Airkit.ai. Prior to joining Airkit, Ismaen worked at Microsoft as a Power Platform Customer Engineer and a Consultant. He worked as a software engineer at GE Capital. Ismaen also has several certifications from Microsoft, including Worldwide Communities - Community SME 2020, Accessibility in Action, Architecting Microsoft Azure Solutions, 70-534, and Microsoft 365 Certified: Security Administrator Associate. Airkit.ai, which was acquired by Salesforce, helps brands automate and scale their customer service capabilities using the latest AI agent capabilities powered by generative AI (GPT-4, specifically). Whereas most legacy ‘AI-powered' tools have operated as little more than generic FAQ respondents, businesses can now extend their customer service teams' reach by incorporating AI agents that can do everything from sending a replacement product and issuing a refund to changing an address and rescheduling an appointment. Discover more about prompt engineering and AI at https://ai-forall.com More about Airkit.ai: https://airkit.ai Connect with Ismaen: https://www.linkedin.com/in/ismaen-aboubakare/ (00:00) Intro (00:29) Ismaen Aboubakare and Airkit.ai (00:43) What is a prompt? (02:42) What is a prompt engineer? (05:07) Prompt engineering vs high level programming languages (08:17) The importance of parameters (09:43) The value of domain expertise (11:50) Who hires prompt engineers? (14:27) Getting started with prompt engineering (17:40) Is ChatGPT getting worse? (18:50) Open source LLMs (21:34) Best open source LLM? (23:48) How can businesses start adopting AI? (28:56) Handling privacy (30:55) Learn more about Airkit.ai SUBSCRIBE TO THE CHANNEL: https://bit.ly/43dYQV9 Listen to the Podcast: https://bit.ly/45rewGf Join Our Newsletter: https://newsletter.ai-forall.com Follow Us on Social: https://linktr.ee/aiforallofficial

Join Jon as he interviews Katie Hoesley, Senior Developer Advocate at BigCommerce. In this episode, they delve into the challenges that beginner developers face and explore how to creatively bridge the gap between technical leaders and the next generation of technologists. Drawing from her liberal arts background, Katie emphasizes the importance of creativity, communication, and community in developer advocacy. Don't miss out on their insightful discussion where they unpack the complexities of measuring the ROI of developer marketing the importance of relationships in DevRel, and much more!

In this episode, we explore the dynamic career of our guest Brian (bdougie) Douglas has left significant marks on the tech industry. Starting as a Developer Experience Lead at Netlify, he transitioned to GitHub as Director of Developer Advocacy, where he made major strides in community engagement and growing GitHub's online presence. Now, as the Founder & CEO of Open Sauced, he's pioneering his own path in open-source intelligence. His journey through well-known tech companies like Netlify, GitHub, and Open Sauced illustrates a blend of innovation, leadership, and impactful community involvement. OpenSauced: https://opensauced.pizza/ --- Support this podcast: https://podcasters.spotify.com/pod/show/chrisseantalks/support

In this episode of the Modern Web Podcast live at RenderATL, Tracy Lee interviews Michelle “Mish” Mannering. As an advocate for developers at GitHub, Mish emphasizes the importance of effective communication and creating tutorials that cater to developers of all levels. Get inspired as Tracy and Mish reveal their unconventional journeys into the tech industry, proving that diverse backgrounds can lead to remarkable success in Developer Relations. With their infectious enthusiasm, they describe the joy of engaging with the vibrant developer community, attending events, and witnessing awe-inspiring projects come to life. Tune in now to the Modern Web Podcast and join Tracy and Michelle as they delve into the exciting world of Developer Relations, uncovering valuable insights, and fostering a stronger developer community. Guest Michelle "Mish" Mannering, Developer Advocate at GitHub Hosts Tracy Lee, CEO of This Dot Labs This episode is sponsored by This Dot Labs.

This is an exciting episode: we're welcoming a new team member to PagerDuty's Developer Advocacy team, as well as an additional host for this podcast! Listen in to meet Tiago Barbosa and learn more about what he's excited to bring to the PagerDuty community going forward.

Brian Douglas, Founder and CEO at OpenSauced, learned to code while pursuing his MBA and stayed up-to-date with the latest trends and technologies by tuning into podcasts and blogs. Brian's passion eventually caught the attention of Netlify, where he joined as an advocate. Later, he became the first advocate at GitHub, building out a developer relations team. Brian shares insights into the open-source world and the challenges faced by maintainers. He introduces his current venture, OpenSauce.pizza, which aims to improve GitHub insights and provide valuable knowledge about open-source contributions and tech debt. Brian mentions plans to expand the platform's support to include other Git host providers like GitLab and Bitbucket.In this episode, Brian talks to Robbie and Chuck about his journey from developer to developer advocate, the importance of developer experience, and his current project, OpenSauce.pizza, focusing on GitHub insights with plans to expand to support other Git host providers. Key Takeaways [00:31] - Introduction to Brian Douglas. [01:59] - A whiskey review: Teeling Whiskey Wonders of Wood Single Pot Still. [08:42] - Tech hot takes. [15:03] - How Brian got into developer advocacy. [25:39] - Brian talks about OpenSauced. [32:15] - Future plans for OpenSauced. [37:09] - Chuck asks Brian to teach him how to Dougie. [38:06] - Brian explains how to start a podcast. [42:40] - What Brian is most excited about with AI. Quotes [21:08] - “Everyone complains about how many Spidermans have we seen or Batman origin stories we've seen, but it's the same thing on the web.” ~ Brian Douglas [26:53] - “We want to move away from the big brother-like tools that exist.” ~ Brian Douglas [39:11] - “My thing is, just do it. If it doesn't work out, use all that to start a new one.” ~ Brian Douglas Links Brian Douglas Twitter Brian Douglas LinkedIn Github OpenSauced Little Caesars Teeling Wonders of Wood Single Pot Still Jameson Irish Whiskey World Drinks Awards Josh Goldberg Tailwind CSS Angular React Netlify Jamstack Radio Supabase Firebase Google Flutter Apple Vision Apple Microsoft Netflix GitLab Chris Coyier Pizza Hut Spotify GitHub Copilot Alexa Stack Overflow RenderATL SXSW Ember Sauced Newsletter Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io.

In episode 5 of How It's Tested, Eden Full Goh speaks with Filip Grebowski. This conversation explores Filip's career journey, metrics for gauging the health of a product, insights on parsing vanity metrics from useful metrics, AI and content creation, and the future of developer advocacy.

In episode 5 of How It's Tested, Eden Full Goh speaks with Filip Grebowski. This conversation explores Filip's career journey, metrics for gauging the health of a product, insights on parsing vanity metrics from useful metrics, AI and content creation, and the future of developer advocacy.

Today, we have Liran Tal, Director of Developer Advocacy at Snyk, to talk about a security risk all developers should know about: path traversal. Links https://twitter.com/liran_tal https://lirantal.com/ https://github.com/lirantal https://lirantal.com/blog https://www.linkedin.com/in/talliran 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: Liran Tal.

In this episode of The Secure Developer, we delve into the subject of supply chain security across various ecosystems and languages, guided by industry experts Liran Tal and Roy Ram from Snyk. Liran is the Director of Developer Advocacy at Snyk and has a background working particularly in Node.js and JavaScript. Roy is a Senior Product Manager serving as part of the product team for Snyk Code, and has a background in cybersecurity and a solid understanding of C++. With a 20-year background in Java, host Simon Maple moderates the conversation. We discuss the challenges and differences between ecosystems, such as the use of third-party libraries and issues with typosquatting and malicious packages. We also talk about the volume of dependencies that each of our ecosystems pull in, whether you should stay on the latest version or pin to a version, and the importance of software bill of materials (SBOMs). For valuable advice on securing your supply chain in different languages and ecosystems, tune in today!

In this episode, Jesse Tomchak is joined by Sam Julien, Director of Developer Advocacy, for Auth0 at Okta. What is the day to day of someone in developer advocacy outside of what we see from blog posts and conference talks? Sam is passionate about helping developers become the best versions of themselves through Tiny Experiments book, and his current newsletter, Developer Microskills. We dive into the idea of self taught developers, developer productive that is actually effective, sustainable progress, and so much more.   Guest Sam Julien - Director of Developer Advocacy, Auth0 at Okta Host Jesse Tomchak - Architect and Engineering Lead at ThisDotLabs - @robocell   Developer Microskills newsletter (https://developermicroskills.com) Sam's website (http://www.samjulien.com/) How to Finish What You Start article (https://www.samjulien.com/how-to-finish-what-you-start) Guide to Tiny Experiments book (https://learn.samjulien.com/guide-to-tiny-experiments) Getting Started in Developer Relations book (http://www.gettingstartedindevrel.com)   Sponsored by This Dot Labs

Another intern has joined us in the studio, continuing the series of episodes where junior engineers chat with senior leaders. In this installment, Tito Reinhard joins us from Portland State University, and speaks with his team leader Pete Baker who is the VP of Customer and Developer Engineering. Topics in this show include sustainable engineering for climate/energy concerns, technical curiosity, and Tito's project involving data warehousing for customer performance benchmarking. Applicable buzzwords include: Great Teams, Great Culture, ARM Startup, Developer Outreach, Human Engineering, Retrospective Leadership, Customer Engagement, Customer Success, Developer Advocacy, Ampere Ambassadors, Building teams, Software, Leadership Empathy, Servant Leadership, Performance Benchmarking

When you think about the career journey of a software developer, teaching elementary school is not typically the first thing that comes to mind. But for Lucia Cerchie, Developer Advocate at Confluent, her elementary school teaching experience gave her a huge advantage in her work. In this episode, Lucia discusses her work with Kafka, a distributed event streaming platform, and how she creates content to introduce developers to Kafka more easily, especially for beginners. She explains Kafka's scalability and how it can handle large amounts of data in real-time, making it a great choice for processing high volumes of data. But Kafka isn't the answer for everyone. Lucia emphasizes the importance of understanding the "why" behind using it and knowing when to leverage it based on the problem at hand. Lucia talks to Robbie and Chuck about her journey from being an elementary school teacher to her career in developer advocacy, her work at Confluent with Kafka, and how she creates content to make complex technologies more accessible.  Key Takeaways [00:27] - Introduction to Lucia Cerchie. [01:46] - A whiskey review: Barrel Bourbon Batch 032. [06:45] - Hot takes from Twitter. [14:21] - Lucia's path to becoming a developer advocate. [19:58] - Lucia explains Kafka. [26:35] - Lucia explains Confluent and its business model. [39:15] - Programming languages Lucia has used in her tutorials. [44:17] - Chuck, Robbie, and Lucia talk about exercise. [47:45] - Lucia talks about her hobbies. Quotes [16:01] - “The motivation actually comes from back when I was teaching. Which is, I want to help other people learn and make teaching accessible.” ~ Lucia Cerchie [25:03] - “Kafka's use cases are not just event-driven web apps. It's things like main frame conversions, data pipelines.” ~ Lucia Cerchie [40:08] - “I think I would recommend Python to absolute beginners to coding just because of the human readability of the language.” ~ Lucia Cerchie Links Lucia Cerchie Twitter Lucia Cerchie LinkedIn Confluent Confluent Developer What is Apache Kafka®? (A Confluent Lightboard by Tim Berglund) + ksqlDB Apache Kafka Documentation Cerchie/learn-about-CLIs Cerchie/magic-byte-illustration Cerchie/git-cherry-pick-tutorial AIS demo Barrell Bourbon Batch 032 Band-Aid Twitter NPM Tailwind CSS Vanilla CSS Typescript Ember JS ThePrimeagen IBM GraphQL New York Times Wordle Facebook National Geographic Socket Vim Kinesis Ergo Dvorak Keyboard Windows Mac Linux Acquia Rust Elixir ChatGPT Daisy Jones & the Six Fleetwood Mac Stack Overflow Neovim CoffeeScript WebAssembly GitHub Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io.

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.

Interview with Hadi Hariri, VP of Developer Advocacy at JetBrains. He talks about the challenge of dealing with the constant influx of information, creating processes to manage information overload, and the importance of interpersonal skills in the workplace.Sign up to the Level-up Engineering newsletter!In this interview we're covering:Defining information overload Dealing with information overloadPossible drawbacks of poor information managementMethods to track relevant informationDealing with information overload as EMs and ICsJetBrain's approach to managing informationFinding the golden meanExcerpt from the interview:"Tooling doesn't help you decide what to push and what to pull, because the issue isn't rooted in your tech stack. It's a people problem, and it has to be approached as such. When we talk about leadership and management, one of the characteristics that a leader must have is being able to see the bigger picture. They don't just focus on the team they manage, but how their work relates to other teams' work inside the company, and how that relates to products and services. Having this company-wide vision contributes to deciding what's important and what's unnecessary noise for each team."Click here to read the full interview!

On today's episode, Saron speaks with Brian Douglas, founder and CEO of Open Sauced, where he works on increasing the knowledge and insights of open-source communities. In the past he's lead Developer Advocacy at GitHub by fostering a community of early adopters through conversations with the top open source maintainers on GitHub. Hear them discuss how Brain learned to code to start his own company, takeaways from working at startups, open source insights and learning through rejection. Show Links Turing (sponsor) Microsoft (sponsor) Stellar (sponsor) Open Sauced FreeCompute Electron React Native WebPack NoJS CSS SDK Node Angular 2.0 Angular JS JavaScript React API Linked List Go Open Source Ruby On Rails

Vertex AI Experiments with Ivan Nardini and Karthik Ramachandran Hosts Anu Srivastava and Nikita Namjoshi are joined by guests Ivan Nardini and Karthik Ramachandran in a conversation about Vertex AI Experiments this week on the podcast. Vertex AI Experiments allows for easy, thorough ML experimentation and analysis of ML strategies. Our guests start the show with a brief introduction to Vertex AI and go on to help us understand where Experiments fits in. Because building ML models takes trial and error as we figure out what architecture and data management will work best, Experiments is a handy tool that helps developers try different variations. With extensive tracking capabilities and analysis tools, developers can see what is working, what's not, and get ideas for other things to try. Ivan tells us about the two concepts to keep in mind before using Experiments: runs, which are training configurations, and experiments, adjustments you make as you look for the best solution. Vertex ML Metadata, a managed ML metadata tool, helps analyze Experiment runs in a graph, Ivan tells us. He takes us through an example ML model build and training using Vertex AI Experiments and other tools. He and Karthik also elaborate on the relationship between Vertex AI Experiments and Pipelines. We talk about the future of AI, including the foundational model, and some cool examples of what's happening in the real world with Vertex AI Experiments. Ivan Nardini Ivan Nardini is a customer engineer specialized in ML and passionate about Developer Advocacy and MLE. He is currently collaborating and enabling Data Science developers and practitioners to define and implement MLOps on Vertex AI. He is an active contributor in Google Cloud. Karthik Ramachandran Karthik Ramachandran is a Product Managed on the VertexAI team. He's been focused on developing MLOps tools like Vertex Pipelines and Experiments. Cool things of the week Expanding the Google Cloud Ready - Sustainability initiative with 12 new partners blog Large Language Models and how they are used with Natural Language Understanding. pdf Interview Vertex AI site Vertex AI Experiments docs Vertex AI SDK for Python docs Vertex ML Metedata docs Vertex AI Pipelines docs Vertex AI Workbench docs Vertex AI Tensorboard docs Track, compare, manage experiments with Vertex AI Experiments blog Vertex AI Experiments Notebooks site What's something cool you're working on? Anu is working on demos for Next. Nikita is testing new features for Vertex AI. Hosts Nikita and Anu Srivastava

Max Saltonstall and new host Anu Srivastava are in the studio today talking about Vertex Explainable AI with guests Irina Sigler and Ivan Nardini. Vertex Explainable AI was born from a need for developers to better understand how their models determine classifications. Trusting the operation of models for business decision making and easier debugging are two reasons this classification understanding is so important. Explainable models help developers understand and describe how their trained models are making decisions. Google's managed service, Vertex Explainable AI, offers Feature Attribution and Example Based Explanations to provide better understanding of model decision making. Irina describes these two services and how each works to foster better decision-making based on AI models. One or both services can be used in every stage of model building and to create a more precise model with better results. Example Based Explanations, Irina tells us, also makes it easier to explain the model to those who may not have strong technical backgrounds. Ivan runs us through a sample build of a model taking advantage of the Vertex Explainable AI tools. Presets provide easier setup and use as well. We talk more about the benefits of being able to easily explain your models. When decision-makers understand the importance of your AI tool, it's more likely to be cleared for production, for example. When you understand why your model is making certain choices, you can trust the model's outcomes as part of your decision-making process. Irina Sigler Irina Sigler is a Product Manager on the Vertex Explainable AI team. Before joining Google, Irina worked at McKinsey and did her Ph.D. in Explainable AI. She graduated from the Freie Universität Berlin and HEC Paris. Ivan Nardini Ivan Nardini is a customer engineer specialized in ML and passionate about Developer Advocacy and MLE. He is currently collaborating and enabling Data Science developers and practitioners to define and implement MLOps on Vertex AI. He also leads a worldwide hackathon community initiative and he is an active contributor in Google Cloud. Cool things of the week Unify data lakes and warehouses with BigLake, now generally available blog What it's like to have a hybrid internship at Google blog Interview Vertex AI site Explainable AI site Vertex Explainable AI docs Vertex Explainable AI Notebooks docs Feature Attribution docs AI Explanations Whitepaper site Explainable AI with Google Cloud Vertex AI article Why you need to explain machine learning models blog What's something cool you're working on? Anu just got back from a nice vacation and is picking back up on how to use our AI APIs with Serverless workflows. She's working on some exciting tutorials for our AI backed Translation API. Max just got back from family dance camp and is working to make excellent intern experiences. Hosts Max Saltonstall and Anu Srivastava

About BrandonBrandon West was raised in part by video games and BBSes and has been working on web applications since 1999. He entered the world of Developer Relations in 2011 as an evangelist for a small startup called SendGrid and has since held leadership roles at companies like AWS. At Datadog, Brandon is focused on helping developers improve the performance and developer experience of the things they build. He lives in Seattle where enjoys paddle-boarding, fishing, and playing music.Links Referenced: Datadog: https://www.datadoghq.com/ Twitter: https://twitter.com/bwest 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 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: This episode is sponsored in part by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone I've been trying to get on the show for years, but I'm very bad at, you know, following up and sending the messages and all the rest because we all struggle with our internal demons. My guest instead struggles with external demons. He is the team lead for developer experience and tools advocacy at what I can only assume is a Tinder for Pets style company, Date-A-Dog. Brendon West, thank you for joining me today.Brandon: Hey, Corey, thanks for having me. I'm excited to be here. Finally, like you said, it's been a couple of years. But glad that it's happening. And yeah, I'm on the DevRel team at Datadog.Corey: Yes, I'm getting a note here in the headset of breaking news coming in. Yes, you're not apparently a dog dating company, you are a monitoring slash observability slash whatever the cool kids are calling it today telemetry outputer dingus nonsense. Anyone who has ever been to a community or corporate event has no doubt been tackled by one of the badge scanners that you folks have orbiting your booth, but what is it that you folks do?Brandon: Well, the observability, the monitoring, the distributed tracing, all that stuff that you mentioned. And then a lot of other interesting things that are happening. Security is a big focus—InfoSec—so we're adding some products around that, automated security monitoring, very cool. And then the sort of stuff that I'm representing is stuff that helps developers provide a better experience to their end-users. So, things like front-end monitoring, real-time user monitoring, synthetic testing of your APIs, whatever it might be.Corey: Your path has been somewhat interesting because you—well, everyone's path has been somewhat interesting; yours has been really interesting because back in 2011, you entered the world of developer relations, or being a DevReloper as I insist on calling it. And you were in a—you call it a small startup called SendGrid. Which is, on some level, hilarious from my point of view. I've been working with you folks—you folks being SendGrid—for many years now. I cared a lot about email once upon a time.And now I send an email newsletter every week, that deep under the hood, through a couple of vendor abstraction layers is still SendGrid, and I don't care about email because that's something that I can pay someone else to worry about. You went on as well to build out DevRel teams at AWS. You decided okay, you're going to take some time off after that. You went to a small scrappy startup and ah, nice. You could really do things right and you have a glorious half of the year and then surprise, you got acquired by Datadog. Congratu-dolances on that because now you're right back in the thick of things at big company-style approaches. Have I generally nailed the trajectory of the past decade for you?Brandon: Yeah, I think the broad strokes are all correct there. SendGrid was a small company when I joined, you know? There were 30 of us or so. So, got to see that grow into what it is today, which was super, super awesome. But other than that, yeah, I think that's the correct path.Corey: It's interesting to me, in that you were more or less doing developer relations before that was really a thing in the ecosystem. And I understand the challenge that you would have in a place like SendGrid because that is large-scale email sending, transactional or otherwise, and that is something that by and large, has slipped below the surface level of awareness for an awful lot of folks in your target market. It's, “Oh, okay, and then we'll just have the thing send an email,” they say, hand-waving over what is an incredibly deep and murky pool. And understanding that is a hard thing requires a certain level of technical sophistication. So, you started doing developer relations for something that very clearly needed some storytelling chops. How did you fall into it originally?Brandon: Well, I wanted to do something that let me use those storytelling chops, honestly. I had been writing code at an agency for coal mines and gold mines and really actively inserting evil into the world, power plants, and that sort of thing. And, you know, I went to school for English literature. I loved writing. I played in thrash metal bands when I was a kid, so I've been up on stage being cussed at and told that I suck. So I—Corey: Oh, I get that conference talks all the time.Brandon: Yeah, right? So, that's why when people ask me to speak, I'm like, “Absolutely.” There's no way I can bomb harder than I've bombed before. No fear, right? So yeah, I wanted to use those skills. I wanted to do something different.And one of my buddies had a company that he had co-founded that was going through TechStars in Boulder. SendGrid was the first accelerator-backed company to IPO which is pretty cool. But they had gone through TechStars in 2009. They were looking for a developer evangelist. So, SendGrid was looking for developer evangelist and my friend introduced me said, “I think you'd be good at this. You should have a conversation.” My immediate thought was what the hell is a developer evangelist?Corey: And what might a SendGrid be? And all the rest. Yes, it's that whole, “Oh, how do I learn to swim?” Someone throws you off the end of the dock and then retrospect, it's, “I don't think they were trying to teach me how to swim.” Yeah. Hindsight.Brandon: Yeah. It worked out great. I will say, though, that I think DevRel has been around for a long time, you know? The title has been around since the original Macintosh at Apple in 1980-ish. There's a whole large part of the tech world that would like you to think that it's new because of all the terrible things that their DevRel team did at Microsoft in the late-90s.And you can go read all about this. There were trials about it. These documents were released to the public, James Plamondon is the lead architect of all of this nastiness. But I think there was then a concerted effort to memory-hole that and say, “No, DevRel is new and shiny.” And then Google came along and said, “Well, it's not evangelism anymore. It's advocacy.”Corey: It's not sysadmin work anymore. It's SRE. It's not on-prem, it's Sparkling Kubernetes, et cetera, et cetera.Brandon: Yeah, so there's this sense in a lot of places that DevRel is new, but it's actually been around a long time. And you can learn a lot from reading about the history and understanding it, something I've given a talk on and written a bit about. So.Corey: My philosophy around developer relations for a while has been that in many cases, its biggest obstacle is the way that it is great at telling stories about fantastically complex, deeply technical things; it can tell stories about almost anything except itself. And I keep seeing similar expressions of the same problem again, and again, and again. I mean, AWS, where you worked, as an example: they love to talk about their developer advocates, and you read the job descriptions and these are high-level roles with sweeping responsibilities, broad basis of experience being able to handle things at a borderline executive level. And then they almost neuter the entire thing by slapping a developer advocate title on top of those people, which means that some of the people that would be most effectively served by talking to them will dismiss them as, “Well, I'm a director”—or a VP—“What am I going to do talking to a developer advocate?” It feels like there's a swing and a miss as far as encapsulating the value that the function provides.I want to be clear, I am not sitting here shitting on DevRel or its practitioners, I see a problem with how it [laugh] is being expressed. Now, feel free to argue with me and just scream at me for the next 20 minutes, and this becomes a real short show. But—Brandon: [laugh].Corey: —It'll be great. Hit me.Brandon: No, you're correct in many ways, which makes me sad because these are the same conversations that I've been having for the 11, 12 years that I've been in DevRel now. And I thought we would have moved past this at some point, but the problem is that we are bad at advocating for advocacy. We do a bad job of relating to people about DevRel because we spend so much time worried about stuff that doesn't really matter. And we get very loud voices in the echo chamber screaming about titles and evangelism versus advocate versus community manager, and which department you should report up to, and all of these things that ultimately don't matter. And it just seems like bickering from the outside. I think that the core of what we do is super awesome. And I don't think it's very hard to articulate. It's just that we don't spend the time to do that.Corey: It's always odd to me when I talk to someone like, “Oh, you're in DevRel. What does that mean?” And their immediate response is, “Well, it's not marketing, I'll tell you that.” It's feels like there might be some trauma that is being expressed in some strange ways. I do view it as marketing, personally, and people who take umbrage at that don't generally tend to understand what marketing is.Yeah, you can look at any area of business or any function and judge it by some of the worst examples that we've all seen, but when someone tells me they work in sales, I don't automatically assume that they are sending me horrifyingly passive-aggressive drip campaigns, or trying to hassle me in a car lot. It's no, there's a broad spectrum of people. Just like I don't assume that you're an engineer. And I immediately think, oh, you can't solve FizzBuzz on a whiteboard. No, there's always going to be a broad spectrum of experience.Marketing is one of those awesome areas of business that's dramatically misunderstood a lot. Similarly to the fact that, you know, DevRel can't tell stories, you think marketing could tell stories about itself, but it's still struggles, too, in a bunch of ways. But I do believe that even if they're not one of the same, developer relations and marketing are aligned around an awful lot of things like being able to articulate value that is hard to quantify.Brandon: I completely agree with that. And if I meet someone in DevRel that starts off the conversation by saying that they're not in marketing, then I know they're probably not that great at their job. I mean, I think there's a place of tech hubris, where we want to disrespect anything that's not a hard skill where it's not putting zeros and ones into a chip—Corey: And spoiler, they're all very hard skills.Brandon: [laugh]. Yeah. And so, first off, like, stop disrespecting marketing. It's important; your business probably wouldn't survive if you didn't have it. And second of all, you're not immune to it, right?Like, Heartbleed had a logo and a name for vulnerability because tech people are so susceptible to it, right? People don't just wake up and wait in line for three days for a new iPhone because tech marketing doesn't work, right?Corey: “Oh, tech marketing doesn't work on me,” says someone who's devoted last five years of their life to working on Kubernetes. Yeah, sure it doesn't.Brandon: Yeah exactly. So, that whole perspective is silly. I think part of the problem is that they don't want to invest in learning how to communicate what they do to a marketing org. They don't want to spend the time to say, “Here's how the marketing world thinks, and here's how we can fit into that perspective.” They want to come in and say, “Well, you don't understand DevRel. Let me define DevRel for you and tell you what we do.” And all those sorts of things. It's too prescriptive and less collaborative.Corey: Anytime you start getting into the idea of metrics around how do you measure someone in a developer advocacy role, the answer is, “Well, your metrics that you're using are wrong, and any metrics you use are wrong, and there's no good way to do it.” And I am sympathetic to that. When I started this place, I knew that if I went to a bunch of events and did my thing, good things would happen for the business. And how did I articulate that? Gut feel, but when you own the place, you can do that.Whereas when you are a function inside of another org, inside of another org, and you start looking at from the executive leadership position at these things, it's, “Okay, so let me get this straight. You cost as much as an engineer, you cost as much as that again, in your expenses because you're traveling all the time, you write zero production code, whenever people ask you what it is you do here, you have a very strange answer, and from what we can tell, it looks like you hang out with your friends in exotic locations, give a 15-minute talk from time to time that mentions our name at the beginning, and nothing else relevant to our business, and then you go around and the entire story is ‘just trust me, I'm adding value.'” Yeah, when it's time to tighten belts and start cutting back, is it any wonder that the developer advocacy is often one of the first departments hit from that perspective?Brandon: It doesn't surprise me. I mean, I've been a part of DevRel teams where we had some large number of events that we had attended for the year—I think 450-something—and the director of the team was very excited to show that off, right, you should have seen the CFOs face when he heard that, right, because all he sees is outgoing dollar signs. Like, how much expense? What's the ROI on 450 events?Corey: Yeah, “450 events? That's more than one a day. Okay, great. That's a big number and I already know what we're spending. Great. How much business came out of that?”And that's when the hemming and hawing starts. Like, well, sort of, and yadda—and yeah, it doesn't present well in the language that they are prepared to speak. But marketing can tell those stories because they have for ages. Like, “Okay, how much business came from our Superbowl ad?” “I dunno. The point is, is that there's a brand awareness play, there's the chance to remain top of the mental stack when people think about this space. And over the next few months, we can definitely see there's been a dramatic uptick in our business. Now, how do we attribute that back? Well, I don't know.”There's a saying in marketing, that half of your marketing budget is wasted. Now, figuring out which half will spend the rest of your career, you'll never get even close. Because people don't know the journey that customers go through, not really. Even customers don't often see it.Take this podcast, for example. I have sponsors that I do love and appreciate who say things from time to time on this show. And people will hear it and occasionally will become customers of those sponsors. But very often, it's, “Oh, I heard about that on the podcast. I'll Google it when I get to work and then I'll have a conversation with my team and we'll agree to investigate that.”And any UTM tracking has long since fallen by the wayside. You might get to that from discussions with users in their interview process, but very often, they won't remember where it came up. And it's one of those impossible to quantify things. Now, I sound like one of those folks where I'm trying to say, “Oh, buy sponsorships that you can never prove add value.” But that is functionally how advertising tends to work, back in the days before it spied on you.Brandon: Yeah, absolutely. And we've added a bunch of instrumentation to allow us to try and put that multi-touch attribution model together after the fact, but I'm still not sure that that's worth the squeeze, right? You don't get much juice out. One of the problems with metrics in DevRel is that the things that you can measure are very production-focused. It's how many talks did you give? How many audience members did you reach?Some developer relations folks do actually write production code, so it might be how many of the official SDK that you support got downloaded? That can be more directly attributed to business impact, those sorts of things are fantastic. But a lot of it is kind of fuzzy and because it's production-focused, it can lead to burnout because it's disconnected from business impact. “It's how many widgets did your line produce today?” “Well, we gave all these talks and we had 150,000 engaged developer hours.” “Well, cool, what was the business outcome?” And if you can't answer that for your own team and for your own self in your role, that leads pretty quickly to burnout.Corey: Anytime you start measuring something and grading people based on it, they're going to optimize for what you measure. For example, I send an email newsletter out, at time of this recording, to 31,000 people every week and that's awesome. I also periodically do webinars about the joys of AWS bill optimization, and you know, 50 people might show up to one of those things. Okay, well, from a broad numbers perspective, yeah, I'd much rather go and send something out to those 31,000, folks until you realize that the kind of person that's going to devote half an hour, forty-five minutes to having a discussion with you about AWS bill optimization is far likelier to care about this to the point where they become a customer than someone who just happens to be in an audience for something that is orthogonally-related. And that is the trick because otherwise, we would just all be optimizing for the single biggest platforms out there if oh, I'm going to go talk at this conference and that conference, not because they're not germane to what we do, but because they have more people showing up.And that doesn't work. When you see that even on the podcast world, you have Joe Rogan, as the largest podcast in the world—let's not make too many comparisons in different ways because I don't want to be associated with that kind of tomfoolery—but there's a reason that his advertisers, by and large, are targeting a mass-market audience, whereas mine are targeting B2B SaaS, by and large. I'm not here shilling for various mattress companies. I'm instead talking much more about things that solve the kind of problem that listeners to this show are likely to have. It's the old-school of thought of advertising, where this is a problem that is germane to a certain type of audience, and that certain type of audience listens to shows like this. That was my whole school of thought.Brandon: Absolutely. I mean, the core value that you need to do DevRel, in my opinion is empathy. It's all about what Maya Angelou said, right? “People may not remember what you said, but they'll definitely remember how you made them feel.” And I found that to be incredibly true.Like, the moments that I regret the most in DevRel are the times when someone that I've met and spent time with before comes up to have a conversation and I don't remember them because I met 200 people that night. And then I feel terrible, right? So, those are the metrics that I use internally. It's hearts and minds. It's how do people feel? Am I making them feel empowered and better at their craft through the work that I do?That's why I love DevRel. If I didn't get that fulfillment, I'd go write code again. But I don't get that sense of satisfaction, and wow, I made an impact on this person's trajectory through their career that I do from DevRel. So.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: The way that I tend to see it, too, is that there's almost a bit of a broadening of DevRel. And let's be clear, it's a varied field with a lot of different ways to handle that approach. I'm have a terrible public speaker, so I'm not going to ever succeed in DevRel. Well, that's certainly not true. People need to write blog posts; people need to wind up writing some of the sample code, in some cases; people need to talk to customers in a small group environment, as opposed to in front of 3000 people and talk about the things that they're seeing, and the rest.There's a broad field and different ways that it applies. But I also see that there are different breeds of developer advocate as well. There are folks, like you for example. You and I have roughly the same amount of time in the industry working on different things, whereas there's also folks who it seems like they graduate from a boot camp, and a year later, they're working in a developer advocacy role. Does that mean that they're bad developer advocates?I don't think so, but I think that if they try and present things the same way that you were I do from years spent in the trenches working on these things, they don't have that basis of experience to fall back on, so they need to take a different narrative path. And the successful ones absolutely do.Brandon: Yeah.Corey: I think it's a nuanced and broad field. I wish that there was more acceptance and awareness of that.Brandon: That's absolutely true. And part of the reason people criticize DevRel and don't take it seriously, as they say, “Well, it's inconsistent. This org, it reports to product; or, this org, it reports up to marketing; this other place, it's part of engineering.” You know, it's poorly defined. But I think that's true of a lot of roles in tech.Like, engineering is usually done a different way, very differently at some orgs compared to others. Product teams can have completely different methodologies for how they track and manage and estimate their time and all of those things. So, I would like to see people stop using that as a cudgel against the whole profession. It just doesn't make any sense. At the same time, two of the best evangelist I ever hired were right out of university, so you're completely correct.The key thing to keep in mind there is, like, who's the audience, right, because ultimately, it's about building trust with the audience. There's a lot of rooms where if you and I walk into the room; if it's like a college hackathon, we're going to have a—[laugh], we're going to struggle.Corey: Yeah, we have some real, “Hello fellow kids,” energy going on when we do that.Brandon: Yeah. Which is also why I think it's incredibly important for developer relations teams to be aware of the makeup of their team. Like, how diverse is your team, and how diverse are the audiences you're speaking to? And if you don't have someone who can connect, whether it's because of age or lived experience or background, then you're going to fail because like I said that the number one thing you need to be successful in this role is empathy, in my opinion.Corey: I think that a lot of the efforts around a lot of this—trying to clarify what it is—some cases gone in well, I guess I'm going to call it the wrong direction. And I know that sounds judgy and I'm going to have to live with that, I suppose, but talk to me a bit about the, I guess, rebranding that we've seen in some recent years around developer advocates. Specifically, like, I like calling folks DevRelopers because it's cutesy, it's a bit of a portmanteau. Great. But it's also not something I seriously suggest most people put on business cards.But there are people who are starting to, I think, take a similar joke and actually identify with it where they call themselves developer avocados, which I don't fully understand. I have opinions on it, but again, having opinions that are not based in data is something I try not to start shouting from the rooftops wherever I can. You live in that world a lot more posted than I do, where do you stand?Brandon: So, I think it was well-intentioned and it was an attempt to do some of the awareness and brand building for DevRel, broadly, that we had lacked. But I see lots of problems with it. One, we already struggle to be taken seriously in many instances, as we've been discussing, and I don't think we do ourselves any favors by giving ourselves cutesy nicknames that sort of infantilize the role like I can't think of any other job that has a pet name for the work that they do.Corey: Yeah. The “ooh-woo accounting”. Yeah, I sort of don't see that happening very often in most business orgs.Brandon: Yeah. It's strange to me at the same time, a lot of the people who came up with it and popularized it are people that I consider friends and good colleagues. So hopefully, they won't be too offended, but I really think that it kind of set us back in many ways. I don't want to represent the work that I do with an emoji.Corey: Funny, you bring that up. As we record this through the first recording, I have on my new ridiculous desktop computer thing from Apple, which I have named after a—you know, the same naming convention that you would expect from an AWS region—it's us-shitpost-one. Instead of the word shit, it has the poop emoji. And you'd be amazed at the number of things that just melt when you start trying to incorporate that. GitHub has a problem with that being the name of an SSH key, for example.I don't know if I'll keep it or I'll just fall back to just spelling words out, but right now, at least, it really is causing all kinds of strange computer problems. Similarly, it causes strange cultural problems when you start having that dissonance and seeing something new and different like that in a business context. Because in some cases, yeah, it helps you interact with your audience and build rapport; in many others, it erodes trust and confidence that you know what you're talking about because people expect things to be cast a certain way. I'm not saying they're right. There's a shitload of bias that bakes into that, but at the same time, I'd like to at least bias for choosing when and where I'm going to break those expectations.There's a reason that increasingly, my Duckbillgroup.com website speaks in business terms, rather than in platypus metaphors, whereas lastweekinaws.com, very much leans into the platypus. And that is the way that the branding is breaking down, just because people expect different things in different places.Brandon: Yeah and, you know, this framing matters. And I've gone through two exercises now where I've helped rename an evangelism team to an advocacy team, not because I think it's important to me—it's a bunch of bikeshedding—but it has external implications, right? Especially evangelism, in certain parts of the world, has connotations. It's just easier to avoid those. And how we present ourselves, the titles that we choose are important.I wish we would spend way less time arguing about them, you know, advocacy has won evangelism, don't use it. DevRel, if you don't want to pick one, great. DevRel is broader umbrella. If you've got community managers, people who can't write code that do things involving your events or whatever, program managers, if they're on your team, DevRel, great description. I wish we could just settle that. Lots of wasted air discussing that one.Corey: Constantly. It feels like this is a giant distraction that detracts from the value of DevRel. Because I don't know about you, but when I pick what I want to do next in my career, the things I want to explain to people and spend that energy on are never, I want to explain what it is that I do. Like I've never liked those approaches where you have to first educate someone before they're going to be in a position where they want to become your customer.I think, honestly, that's one of the things that Datadog has gotten very right. One of the early criticisms lobbed against Datadog when it first came out was, “Oh, this is basically monitoring by Fisher-Price.” Like, “This isn't the deep-dive stuff.” Well yeah, but it turns out a lot of your buying audience are fundamentally toddlers with no visibility into what's going on. For an awful lot of what I do, I want it to be click, click, done.I am a Datadog customer for a reason. It's not because I don't have loud and angry opinions about observability; it's because I just want there to be a dashboard that I can look at and see what's working, what's not, and do I need to care about things today? And it solves that job admirably because if I have those kinds of opinions about every aspect, I'm never going to be your customer anyway, or anyone's customer. I'm going to go build my own and either launch a competitor or realize this is my what I truly love doing and go work at a company in this space, possibly yours. There's something to be said for understanding the customer journey that those customers do not look like you.And I think that's what's going on with a lot of the articulation around what developer relations is or isn't. The people on stage who go to watch someone in DevRel give a talk, do not care, by and large, what DevRel is. They care about the content that they're about to hear about, and when the first half of it is explaining what the person's job is or isn't, people lose interest. I don't even like intros at the beginning of a talk. Give me a hook. Talk for 45 seconds. Give me a story about why I should care before you tell me who you are, what your credentials are, what your job title is, who you work for. Hit me with something big upfront and then we'll figure it out from there.Brandon: Yeah, I agree with you. I give this speaking advice to people constantly. Do not get up on stage and introduce yourself. You're not a carnival hawker. You're not trying to get people to roll up and see the show.They're already sitting in the seat. You've established your credibility. If they had questions about it, they read your abstract, and then they went and checked you out on LinkedIn, right? So, get to the point; make it engaging and entertaining.Corey: I have a pet theory about what's going on in some cases where, I think, on some level, it's an outgrowth of an impostor-syndrome-like behavior, where people don't believe that they deserve to be onstage talking about things, so they start backing up their bona fides to almost reassure themselves because they don't believe that they should be up there and if they don't believe it, why would anyone else. It's the wrong approach. By holding the microphone, you inherently deserve to hold the microphone. And go ahead and tell your story. If people care enough to dig into you and who you are and well, “What is this person's background, really?” Rest assured the internet is pretty easy to use these days, people will find out. So, let them do that research if they care. If they don't, then there's an entire line of people in this world who are going to dislike you or say you're not qualified for what it is you're doing or you don't deserve it. Don't be in that line, let alone at the front of it.Brandon: So, you mentioned imposter syndrome and it got me thinking a little bit. And hopefully this doesn't offend anyone, but I kind of starting to think that imposter syndrome is in many ways invented by people to put the blame on you for something that's their fault. It's like a carbon footprint to the oil and gas industry, right? These companies can't provide you psychological safety and now they've gone and convinced you that it's your fault and that you're suffering from this syndrome, rather than the fact that they're not actually making you feel prepared and confident and ready to get up on that stage, even if it's your first time giving a talk, right?Corey: I hadn't considered it like that before. And again, I do tend to avoid straying into mental health territory on this show because I'm not an—Brandon: Yes.Corey: Expert. I'm a loud, confident white guy in tech. My failure mode is a board seat and a book deal, but I am not board-certified, let's be clear. But I think you're onto something here because early on in my career, I was very often faced with a whole lot of nebulous job description-style stuff and I was never sure if I was working on the right thing. Now that I'm at this stage of my career, and as you become more senior, you inherently find yourselves in roles, most of the time, that are themselves mired in uncertainty. That is, on some level, what seniority leads to.And that's fine, but early on in your career, not knowing if you're succeeding or failing, I got surprise-fired a number of times when I thought I was doing great. There are also times that I thought I was about to be fired on the spot and, “Come on in; shut the door.” And yeah, “Here's a raise because you're just killing it.” And it took me a few years after that point to realize, wait a minute. They were underpaying me. That's what that was, and they hope they didn't know.But it's that whole approach of just trying to understand your place in the world. Do I rock? Do I suck? And it's that constant uncertainty and unknowing. And I think companies do a terrible job, by and large, of letting people know that they're okay, they're safe, and they belong.Brandon: I completely agree. And this is why I would strongly encourage people—if you have the privilege—please do not work at a company that does not want you to bring your whole self to work, or that bans politics, or however they want to describe it. Because that's just a code word for we won't provide you psychological safety. Or if they're going to, it ends at a very hard border somewhere between work and life. And I just don't think anyone can be successful in those environments.Corey: I'm sure it's possible, but it does bias for folks who, frankly, have a tremendous amount of privilege in many respects where I mentioned about, like, I'm a white dude in tech—you are too—and when we say things, we are presumed competent and people don't argue with us by default. And that is a very easy to forget thing. Not everyone who looks like us is going to have very similar experiences. I have gotten it hilariously wrong before when I gave talks on how to wind up negotiating for salaries, for example, because well, it worked for me, what's the problem? Yeah, I basically burned that talk with fire, redid the entire thing and wound up giving it with a friend of mine who was basically everything that I am not.She was an attorney, she was a woman of color, et cetera, et cetera. And suddenly, it was a much stronger talk because it wasn't just, “How to Succeed for White Guys.” There's value in that, but you also have to be open to hearing that and acknowledging that you were born on third; you didn't hit a triple. There's a difference. And please forgive the sports metaphor. They do not sound natural coming from me.Brandon: [laugh]. I don't think I have anything more interesting to add on that topic.Corey: [laugh]. So, I really want to thank you for taking the time to speak with me today. If people want to learn more about what you're up to and how you view the world, what's the best place to find you.Brandon: So, I'm most active on Twitter at @bwest, but you know, it's a mix of things so you may or may not just get tech. Most recently, I've been posting about a—Corey: Oh, heaven forbid you bring your whole self to school.Brandon: Right? I think most recently, I've been posting about a drill press that I'm restoring. So, all kinds of fun stuff on there.Corey: I don't know it sounds kind of—wait for it—boring to me. Bud-dum-tiss.Brandon: [laugh]. [sigh]. I can't believe I missed that one.Corey: You're welcome.Brandon: Well, done. Well, done. And then I also will be hiring for a couple of developer relations folks at Datadogs soon, so if that's interesting and you like the words I say about how to do DevRel, then reach out.Corey: And you can find all of that in the show notes, of course. I want to thank you for being so generous with your time. I really appreciate it.Brandon: Hey, thank you, Corey. I'm glad that we got to catch up after all this time. And hopefully get to chat with you again sometime soon.Corey: Brandon West, team lead for developer experience and tools advocacy at Datadog. 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 and insulting comment that is talking about how I completely misunderstand the role of developer advocacy. And somehow that rebuttal features no fewer than 400 emoji shoved into it.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.

About MaishMaish Saidel-Keesing is a Senior Enterprise Developer Advocate @AWS working on containers and has been working in IT for the past 20 years and with a stronger focus on cloud and automation for the past 7.He has extensive experience with AWS Cloud technologies, DevOps and Agile practices and implementations, containers, Kubernetes, virtualization and, and a number of fun things he has done along the wayHe is constantly trying to bridge the gap between Developers and Operators to allow all of us provide a better service for our customers (and not wake up from pages in the middle of the night). He is an avid practitioner of dissolving silos - educating Ops how to code and explaining to Devs what the hell is OperationsLinks Referenced: @maishsk: https://twitter.com/maishsk duckbillgroup.com: https://duckbillgroup.com 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 Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm a cloud economist at The Duckbill Group, and that was a fun thing for me to become because when you're starting to set out to solve a problem, well, what do you call yourself? I find that if you create a job title for yourself, well, no one knows quite how to categorize you and it leads to really interesting outcomes as a result. My guest today did something very similar. Maish Saidel-Keesing is an EntReloper, or Enterprise Developer Advocate, specifically for container services at AWS. Maish, thank you for joining me.Maish: Thank you for having me on the show, Corey. It's great to be here.Corey: So, how did you wind up taking a whole bunch of words such as enterprise, developer, advocate because I feel like the way you really express seniority at big companies, almost as a display of dominance, is to have additional words in your job title, which all those words are very enterprise-y, very business-y, and very serious. And in container services to boot, which is a somewhat interesting culture, just looking at the enterprise adoption of the pattern. And then at AWS, whose entire sense of humor can be distilled down into, “That's not funny.” You have the flexibility to refer to yourself as an EntReloper in public. I love it. Is it just something you started doing? Was there, like, 18 forms of approval you had to go through to do it? How did this happen? I love it.Maish: So, no. I didn't have to go through approval, of course. Same way, you didn't call yourself a cloud economist with anybody else's approval. But I got the idea mostly from you because I love your term of coining everybody who's in developer advocacy or developer relations as a DevReloper. And specifically, the reason that I coined the term of an EntReloper—and actually looked it up on Google to see if anybody had actually used that term before, and no they haven't—it's the fact of I came into the position on the premise of trying to bring the enterprise voice of the customer into developer advocacy.When we speak about developer advocates today, most of them are the people who are the small startups, developers who write the code, and we kind of forget that there is a whole big world outside of, besides small startups, which are these big, massive, behemoth sort of enterprise companies who kind of do things differently because they've been around for many, many years; they have many, many silos inside their organizations. And it's not the most simple thing to open up your laptop, and install whatever software you want on, because some of these people don't even give you admin rights on your laptop, or you're allowed to ssh out to a computer in the cloud because also the same thing: everything is blocked by corporate firewalls where you have to put in a ticket in order to get access to the outside world. I worked in companies like that when I was—before I moved to Amazon. So, I want to bring that perspective to the table on behalf of our customers.Corey: Bias is a very funny thing. I spent the overwhelming majority of my career in small environments like you describe. To me a big company is one that has 200 people there, and it turns out that there's a whole ‘nother sense of scale that goes beyond that. And there's, like, 18 different tiers beyond. But I still bias based upon my own experiences when I talk about how I do things and how I think about things to a certain persona that closely resembles my own experiences where, “Just install this thing as a tool and it'll be great,” ignoring entirely, the very realistic fact that you've got an entire universe out there of people who are not empowered to install things on their own laptop, for example.How is developer advocacy different within enterprises than in the common case of, “We're a startup. We're going to change the world with our amazing SaaS.” Great, maybe you will. Statistically, you won't. But enterprises have different concerns, different challenges, and absolutely a different sense of scale. How is the practice of advocacy different in those environments?Maish: So, I think the fact is, mostly working on standardization from the get-go that these big enterprises want things to work in a standard way where they can control it, they can monitor it, they can log everything, they can secure it mostly, of course, the most important thing. But it's also the fact that as a developer advocate, you don't always talk to developers within the enterprise. You also have to talk to the security team and to the network team and to the business itself or the C-level to understand. And as you also probably have found out as well in your job, you connect the people with inside the business one to another, these different groups, and get them talking to each other to make these decisions together. So, we act as kind of a bridge in between the people with inside their own company where they don't really talk to each other, or don't have the right connections, or the right conduit in order for them to start that conversation and make things better for themselves.Corey: On some level, my line about developer relations, developer advocacy, has generally taken the track of, “What does that mean? Well, it means you work in marketing, but they're scared to tell you that.” Do you view what you do as being within marketing, aligned with marketing, subtly different and I'm completely wrong, et cetera, et cetera? All positions are legitimate, by the way.Maish: So, I think, at the position that I'm currently in, which is a developer advocate but for the service team, is slightly different than a marketing developer advocate. The marketing developer advocate—and we have many of them which are amazing people and doing amazing work within AWS—their job is to teach everybody about the services and the capabilities available within AWS. That is also part of my job, but I would think that is the 40% of my job. I also go on stage, I go on podcasts like this, I present at conferences, I write blog posts. I also do the kind of marketing work as well.But the other 60% of my job as a service developer advocate is to seek out the feedback, or the signals, or the sentiment from our customers, and bring that back into the service teams, into the product management, into the engineering teams. And, as I said, sit as the enterprise customer in the chair in those meetings, to voice their concerns… their opinions, how they would like the products to go, how we can make the products better. So, the 60% is mostly what we call inbound, which is taking feedback from our customers back into the service teams directly in order to have some influence on the roadmap. And 40% is the outbound work, which we do, as I said, conferences, blog posts, and things like this.Corey: I have a perception. And I am thrilled to be corrected on this because it's not backed by data; it's backed by my own biases—and some people tend to conflate the two; I strive not to—that there's a—I think the term that I heard bandied around at one point was ‘the dark matter developers.' These are folks that primarily work in .NET or Java. They work for companies that are not themselves tech companies, but rather tech is a supporting function, usually in a central IT-style organization, that supports what the business actually does, and they generally are not visible to a lot of traditional developer advocacy approaches.They, by and large, don't go to conferences, they don't go on Twitter to yell at people about things, they commit the terrible sin—according to many startup folks—of daring to view the craft of writing software as this artistic thing, and they just view it as a job and a thing to make money for—filthy casuals—as opposed to this higher calling that's changing the world. Which I think is wild take. But there are a tremendous number of people out there who do fit the profile of they show up, they do their jobs working on this stuff, they don't go to conferences, they don't go out into the community, and they just do their job and go home. The end. Is that an accurate perception? Are there large swaths of folks like that in the industry, and if so, do they centralize or congregate more around enterprises than they do around smaller companies?Maish: I think that your perception is correct. Specifically, for my experience, when I worked, for example, my first two years before I was a developer advocate, I was an enterprise solutions architect which I worked with financial institutions, which are banks, which usually have software which are older than me, which are written in languages, which are older than I am. So, there are people which, as they say, they come there to—they do their job. They're not interested in looking at Twitter, or writing blog posts, or participating in any kind of thing which is outgoing. And they just, they're there to write the code. They go home at the end of the day.They also usually don't have pagers that page them in middle of the night because that's what you have operations teams for, not developers because they're completely different entities. So, I do think your perception might be correct, yes. There are people like that when you say, these dark matter people, dark matter developers.Corey: And I don't have any particular problem. I'm not here to cast shade on anything that they're doing, to be very clear.Maish: Not at all.Corey: Everyone makes different choices and that's great. I don't think necessarily everyone should have a job that is all-consuming, that eats them alive. I wish I didn't, some days. [laugh]. The challenge I have for you then is, as an EntReloper, how do you reach folks in positions like that? Or don't you?Maish: I think the way to reach those people is to firstly, expose them to technology, expose them to the capabilities that they can use in AWS in the cloud, specifically with my position in container services, and gain their trust because that's one of the LPs in Amazon itself: customer obsession. And we work consistently in order to—with our customers to gain their trust and help them along their journey, whatever it may be. If it might be the fact, okay, I only want to write software for nine to five and go home and do everything afterwards, which most normal people do without having to worry about work, or they still want to continue working and adopt the full model of you build it, you own it; manage everything in production on their own and go into the new world of modern software, which many enterprises, unfortunately, are not all the way there yet, but hopefully, they will get there sooner than later.Corey: There's a misguided perception in many corners that you have to be able to reach everyone at all times; wherever they are, you have to be able to go there. I don't think that's true. I think that showing up and badgering people who are just trying to get a job done into, “Hey, have you heard the good word of cloud?” It's like, evangelists knocking on your door at seven o'clock in the morning on a weekend and you're trying to sleep in because the kids are somewhere else for the week. Yeah, I might be projecting a little bit on that.I think that is the wrong direction to go. And I find that being able and willing to meet people where they are is key to success on this. I'm also a big believer in the idea that in any kind of developer advocacy role, regardless whether their targets are large, small, or in my case, patently ridiculous because my company is in fact ridiculous in some ways, you have to meet them where they are. There's no choice around that. Do you find that there are very different concerns that you have to wind up addressing with your audience versus a more, “Mainstream,” quote-unquote, developer advocacy role?Maish: For the enterprise audience, they need to, I would say, relate to what we're talking to. For an example, I gave a talk a couple of weeks ago on the AWS Summit here in Tel Aviv, of how to use App Runner. So, instead of explaining to the audiences how you use the console, this is what it does, you can deploy here, this is how the deployments work, blue, green, et cetera, et cetera, I made up an imaginary company and told the story of how the three people in the startup of this company would start working using App Runner in order to make the thing more relatable, something which people can hopefully remember and understand, okay, this is something which I would do as a startup, or this is what my project, which I'm doing or starting to work on, something I can use. So, to answer your question, in two words, tell stories instead of demo products.Corey: It feels like that's a… heavy lift, in many cases, because I guess it's also partially a perception issue on my part, where I'm looking at this across the board, where I see a company that has 5000 developers working there and, like, how do you wind up getting them to adopt cloud, or adopt new practices, or change anything? It feels like it's a Herculean, impossible task. But in practice, I feel like you don't try and do all of that at once. You start with small teams, you start with specific projects, and move on. Is that directionally accurate?Maish: Completely accurate. There's no way to move a huge mothership in one direction at one time. You have to do, as you say, start small, find the projects, which are going to bring value to the company or the business, and start small with those projects and those small teams, and continue that education within the organization and help the people with your teaching or introducing them to the cloud, to help others within inside their own organization. Make them, or enable them, or empower them to become leaders within their own organization. That's what I tried to do, at least.Corey: You and I have a somewhat similar background, which is weird given that we've just spent a fair bit of time talking about how different our upbringings were in tech at scales of companies and whatnot, but we're alike in that we are both fairly crusty, old operations-side folks, sysadmins—Maish: [laugh]. Yep.Corey: —grumpy people.Maish: Grumpy old sysadmins. Yeah, exactly.Corey: Exactly. Because do you ever notice there's never a happy one? Imagine that. And DevOps was always a meeting of the development and operations, meaning everyone's unhappy. And there's a school of thought that—like, I used to think that, “Oh, this is just what we call sysadmins once they want a better title and more money, but it's still the same job.”But then I started meeting a bunch of DevOps types who had come from the exact opposite of our background, where they were software developers and then they wound up having to learn not so much how the code stuff works the way that we did, but rather how systems work, how infrastructure works. Compare and contrast those for me. Who makes, I guess, the more successful DevOps engineer when you look at it through that lens?Maish: So, I might be crucified for this on the social media from a number of people from the other side of the fence, but I have the firm belief that the people who make the best DevOps engineers—and I hate that term—but people who move DevOps initiatives or changes or transformations with organization is actually the operations people because they usually have a broader perspective of what is going on around them besides writing code. Too many times in my career, I've been burned by DNS, by a network cable, by a power outage, by somebody making a misconfiguration in the Puppet module, or whatever it might have been, somebody wrote it to deploy to 15,000 machines, whatever it may be. These are things where developers, at least my perception of what developers have been doing up until now, don't really do that. In a previous organization I used to work for, the fact was, there was a very, very clear delineation about between the operations people, and the developers who wrote the software. We had very hard times getting them into rotations for on-call, we had very hard times educating them about the fact that not every single log line has to be written to the log because it doesn't interest anybody.But from developer perspective, of course, we need that log because we need to know what's happening in the end. But there are 15, different thousand… turtles all the way down, which have implications about the number of log lines which are written into a piece of software. So, I am very much of the belief that the people that make the best DevOps engineers—if we can use that term still today—are actually people which come from an operations background because it's easier to teach them how to write code or become a programmer than the other way round of teaching a developer how to become an operations person. So, the change or the move from one direction from operations to adding the additional toil of writing software is much easier to accomplish than the other way around, from a developer learning how to run infrastructure at scale.Corey: This episode is sponsored in part by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: I once believed much the same because—and it made sense coming from the background that I was in. Everyone intellectually knows that if you're having trouble with a piece of equipment, have you made sure that it's plugged in? Yes, everyone knows that intellectually. But there's something about having worked on a thing for three hours that wasn't working and only discover it wasn't plugged in, that really sears that lesson into your bones. The most confidence-inspiring thing you can ever hear from someone an operations role is, “Oh, I've seen this problem before. Here's how we fixed it.”It feels like there are no junior DevOps engineers, for lack of a better term. And for a long time, I believed that the upcoming and operational side of the world were in fact, the better DevOps types. And in the fullness of time, I think a lot of that—at least my position on it—was rooted in some level of insecurity because I didn't know how to write code and the thing that I saw happening was my job that I had done historically was eroding. Today, I don't know that it's possible to be in the operation space and not be at least basically conversant with how code works. There's a reason most of these job interviews turn into algorithm hazing.And my articulation of it was rooted, for me at least—at least in a small way—in a sense of defensiveness and wanting to validate the thing that I had done with my career that I defined myself by, I was under threat. And obviously, the thing that I do is the best thing because otherwise it's almost a tacit admission that I made poor career choices at some point. And I don't think that's true, either. But for me, at least psychologically, it was very much centered in that. And honestly, I found that the right answer for me was, in fact, neither of those two things because I have met a couple of people in my life that I would consider to be full-stack engineers.And there's a colloquialism these days, that means oh, you do front-end and back-end. Yeah. The people I'm thinking of did front-end, they did back-end, they did mobile software, they did C-level programming, they wrote their own freaking device drivers at one point. Like, they have done basically everything. And they were the sort of person you could throw any technical issue whatsoever at and get out of their way because it was going to get solved. Those people are, as it turns out, the best. Like, who does a better job developer or operations, folks? Yes. Specifically, both of those things together.Maish: Exactly.Corey: And I think that is a hard thing to talk about. I think that it's a hard—it's certainly a hard thing to find. It turns out that there's a reason that I only know two or three of those folks in the course of my entire career. They're out there, but they're really, really hard to track down.Maish: I completely agree.Corey: A challenge that I hear articulated in some cases—and while we're saying things that are going to get us yelled out on social media, let's go for the fences on this one—a concern that comes up when talking about enterprises moving to cloud is that they have a bunch of existing sysadmin types—while we're on the topic—and well, those people need to learn to work within cloud. And the reality is, in many cases that first, that's a whole new skill set that not everyone is going to be willing or able to pick up. For those who can they have just found that their market rate has effectively doubled. And that seems, on some level, to pose a significant challenge to companies undergoing this, and the larger the company, the more significant the challenge.Because it's my belief that you pay market rate for the talent you have whether you want to or not. And if companies don't increase compensation, these people will leave for things that double their income. And if they raise compensation internally, good for them, but that does have a massive drag on their budget that may not have been accounted for in a lot of the TCO analyses. How do you find that the companies you talk to wind up squaring that circle?Maish: I don't think I have a correct answer for that. I do completely agree—Corey: Oh, I'm not convinced there's a correct answer at all. I'm just trying [laugh] to figure out how to even think about it.Maish: I… have seen this as well in companies which I used to work for and companies that were customers that I have also worked with as part of my tenure in AWS. It's the fact of, when companies are trying to move to the cloud and they start upskilling their people, there's always the concern in the back of their mind of the fact, “Okay, I'm now training this person with new technology. I'm investing time, I'm investing money. And why would I do this if I know that, for example, as soon as I finish this, I'm going to have to just say, I have to pay them more because they can go somewhere else and get the same job with a better pay? So, why would we invest amount of time and resources into upscaling the people?”And these are questions which I have received and conversations which I've had with customers many times over the last two, three years. And the answer, from my perspective always, is the fact is because, number one, you're making the world a better place. Number two, you're making your employees feel more appreciated, giving them better knowledge. And if you're afraid of the fact of teaching somebody to become better is going to have negative effects on your organization then, unfortunately, you deserve to have that person leave and let them find a better job because you're not taking good care of your people. And it's sometimes hard for companies to hear that.Sometimes we get, “You know what? You're completely right.” Sometimes I don't agree with you because I need to compete there, get to the bottom line, and make sure that I stay within my budget or my TCO. But the most important thing is to have the conversation, let people hear different ideas, see how it can benefit them, not only by giving people more options to maybe leave the company, but it can actually make their whole organization a lot better in the long run.Corey: I think that you have to do right by people because reputations last a long time. Even at big companies it becomes a very slow thing to change and almost impossible to do in the short term. So, people tell stories when they feel wronged. That becomes a problem. I do want to pivot a little bit because you're not merely an EntReloper; you are an EntReloper specifically focusing on container services.Maish: Correct.Corey: Increasingly, I am viewing containers as what amounts to effectively a packaging format. That is the framework through which I am increasingly seeing. How are you seeing customers use containers? Is that directionally correct? Is it completely moonbat stuff compared to what you're seeing in the wild, or something else?Maish: I don't think it's a packaging format; I think it's more as an accelerator to enable the customers to develop in a more modern way with using twelve-factor apps with modern technology and not necessarily have their own huge, sticky, big monolith of whatever it might be, written in C# or whatever, or C++ whatever it may be, as they've been using up until now, but they now have the option and the technology and the background in order to split it up into smaller services and develop in the way that most of the modern world—or at least, the what we perceive as the modern world—is developing and creating applications today.Corey: I feel like on some level, containers were a radical change to how companies envisioned software. They definitely provide a path of modernizing things that were very tied to hardware previously. It let some companies even just leapfrog the virtualization migration that they'd been considering doing. But, on some level, I also feel like it runs counter to the ideas of DevOps, where you have development and operations working in partnership, where now it's like, welp, inside the container is a development thing and outside the container, ops problem now. It feels almost, on some level, like, it reinforces a wall. But in a lot of cultures and a lot of companies, that wall is there and there's no getting rid of it anytime soon. So, I confess that I'm conflicted on that.Maish: I think you might be right, and it depends, of course, on the company and the company culture, but what I think that companies need to do is understand that there will never be one hundred percent of people writing software that want to know one hundred percent of how the underlying infrastructure works. And the opposite direction as well: that there will never be people which maintain infrastructure and understand how computers and CPUs and memory buses and NUMA works on motherboards, that they don't need to know how to write the most beautiful enticing and wonderful software for programs, for the world. There's always going to have to be a compromise of who's going to be doing this or who's going to be doing that, and how comfortable they are with taking at least part of the responsibility of the other side into their own realm of what they should be doing. So, there's going to be a compromise on both sides, but there is some kind of divide today of separating, okay, you just write the Helm chart for your Kubernetes Pod spec, or your ECS task, or whatever task definition, whatever you would like. And don't worry about the things in the background because they're just going to magically happen in the end. But they do have to understand exactly what is happening at the background in the end because if something goes wrong, and of course, something will go wrong, eventually, one day somewhere, somehow, they're going to have to know how to take care of it.Corey: I really want to thank you for taking the time to speak with me today about, well, I guess a wide ranging variety of topics, some of which will absolutely inspire people to take to their feet—or at least their Twitter accounts—and tell us, “You know what your problem is?” And I honestly live for that. If you don't evoke that kind of reaction on some level, have you ever really had an opinion in the first place? So, I'm looking forward to that. If people want to learn more about you, your beliefs, call set beliefs misguided, et cetera, et cetera, where's the best place to find you?Maish: So, I'm on Twitter under @maishsk. I assume that will be in the [show notes 00:26:31]. I pontificate some time on technology, on cooking every now and again, on Friday before the end of the weekend, a little bit of politics, but you can find me @maishsk on Twitter. Or maishsk everywhere else social that's possible.Corey: Excellent. We will toss links to that, of course, in the [show notes 00:26:50]. Thank you so much for being so generous with your time. I appreciate it.Maish: Thank you very much, Corey. It was fun.Corey: Maish Saidel-Keesing, EntReloper of container services at AWS. 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 it, please leave a five-star review on your podcast platform of choice along with an angry comment that your 5000 enterprise developer colleagues can all pile 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.