Podcasts about planetscale

I'm excited to work with Microsoft once again as the presenting sponsors of the AI Engineer World's Fair! We'll streaming live from MS Build today for a special crossover pod with our friends at No Priors and the one and only Satya Nadella. However we did not hold back with this interview - we asked all the burning questions about uptime and Copilot that we know you have in your minds. Lets go!For almost two decades, GitHub has been the home of software, where both open source and closed flow, through commits, pull requests, reviews, actions, etc.This ecosystem flourished as open-source maintainers and contributors would continue shipping code for the benefit of the community. However as coding agents began to ship mass quantities of code - growing 1400% in 2026, it marked a new era that was both extremely exciting and challenging for GitHub.While these agents help more people ship more projects, they also significantly increase the floor of how much code is shipped, how often it is shipped, how many people commit code, and basically orders of magnitude multiples in every dimension of GitHub infrastructure:Now GitHub inevitably experiences more pressure on their infrastructure which was originally designed around human developers moving at human speed. This has resulted in a very publicly notable uptime story:So it begs the question of whether current systems around code can absorb what AI produces. Can CI/CD keep up when every idea becomes a build? Can open source maintainers survive floods of AI-generated slop contributions? Can GitHub preserve the human social contract of software while becoming the operating layer for agents?Which brings us to the perfect person to answer these questions: GitHub COO Kyle Daigle. In this episode, he joins swyx to unpack what happens when AI doesn't just autocomplete code, but starts changing how companies operate, how open source works, how pull requests get reviewed, and how GitHub itself has to scale. We go deep on GitHub's internal AI workflows: micro-skills, WorkIQ, MCP, Slack, Teams, email, Copilot workflows, the new Copilot desktop app, CLI, cloud agents, and how Kyle uses agents to look backwards across company context before deciding what to do next. Kyle also reflects on GitHub's history building webhooks, APIs, Actions, npm, Dependabot, and Semmle, why the AI era is breaking GitHub in new ways, how Actions became a general-purpose compute layer, and what Copilot becomes after code completion.Full Video PodWe discuss:* Kyle's expanded role across GitHub* How AI got Kyle coding again after years in leadership* Why GitHub rolls out AI through existing workflows instead of forcing new tools* WorkIQ, MCP, Slack, Teams, email, and GitHub as company context* Why massive “mega-skills” are giving way to small, atomic micro-skills* How AI changes summarization, communications, marketing, and analyst work* Why former developers in leadership may have a unique advantage in the AI era* Kyle's “15 agents on Saturday” workflow* How Kyle built an AI-generated executive presentation for CRO/CFO teams* Why AI changes the chief of staff role without removing the human work* GitHub Actions, webhooks, arbitrary code execution, and secure agent compute* The npm acquisition, supply-chain security, 2FA, and token invalidation* Slop forks, vendoring, and whether AI agents change dependency management* What pull requests become when most PRs come from agents* Prompt requests, vouching, AI review, and trust in open source* What counts as a “developer” when AI lowers the barrier to building* GitHub Spark, low-code, and why GitHub refuses to hide the code* 14x commit growth, Actions load, databases, monorepos, and availability* Copilot's evolution from completion to CLI, desktop app, cloud agents, and SDK* Context, memory, rules, and making GitHub “act like Kyle wants it to act”* Ambient AI, OpenClaw, enterprise security, and the new operating system for agents* What swyx should ask Satya Nadella about Microsoft's AI futureKyle Daigle* LinkedIn: https://www.linkedin.com/in/kyledaigle* X: https://x.com/kdaigleTimestamps00:00:00 Introduction00:03:36 Why AI Got Kyle Coding Again00:07:04 Running GitHub with AI: WorkIQ, MCP, Slack, Teams, and Skills00:15:39 The Golden Age for Former Developers in Leadership00:17:31 15 Agents on Saturday and AI-Generated Executive Work00:20:20 How AI Changes the Chief of Staff Role00:21:45 GitHub's History: Actions, npm, Webhooks, and Open Source00:28:45 Slop Forks, Vendoring, and AI Dependency Management00:33:57 Pull Requests, Prompt Requests, and Trust in Agent-Generated Code00:41:21 GitHub Stars, 200M+ Developers, and the New AI Builder Wave00:45:15 GitHub Spark, Low-Code, and Why GitHub Still Shows the Code00:47:38 GitHub's Hardest Era: 14x Growth, Reliability, and Scale00:59:21 Actions as the Compute Layer for CI/CD and Automation01:02:04 The State and Future of GitHub Copilot01:08:24 Ambient AI, Background Agents, and the Future of the SDLC01:13:09 OpenClaw, Enterprise Security, and the New OS for Agents01:18:03 Build Announcements, WorkIQ, FoundryIQ, and Microsoft Context01:21:41 What Should swyx Ask Satya?TranscriptIntroduction: Kyle Daigle's Expanded Role at GitHub and MicrosoftSwyx [00:00:00]: We're here with Kyle Daigle, COO of GitHub. Welcome.Kyle [00:00:07]: Hey, thanks for having me.Swyx [00:00:08]: You're not just CEO of GitHub. People know you as that. You have a new role.Kyle [00:00:11]: So I have an expanded role now. I've been working at GitHub for thirteen years and doing all things developer. Joined as a developer myself. And now, I'm also responsible as the CMO of Developer for Microsoft. And so all the kind of learnings and passion for developers and how we work with them and how we communicate and how we bring our products to market, we're also bringing that expertise to the broader Microsoft ecosystem and helping every developer that uses a Microsoft product or would like to have a sort of similar experience that they've had with GitHub over the years. So it's a different role in some ways, but it's also just building on the experience that I've had at GitHub of just sort of tell the truth, be authentic, show people how to use it and then let the products speak for themselves. Now just doing that with, all of Microsoft.Swyx [00:01:09]: We'll be releasing this in conjunction with Build. You got lots of stuff planned, and we can sort of touch on that whenever it's appropriate. I think one of the interesting things is I rarely meet a COO who's also a CMO. I think you're a very outward facing and you're very confident publicly. That's rare. Do you actually view yourself as COO? What's What is your thing?From GitHub Developer to COO/CMO: Building the Platform and Operating GitHubKyle [00:01:33]: I think for me, it's been funny. The titles have always been, a— have always felt a little strange to me. I joined GitHub as a developer? I wrote so much of theSwyx [00:01:46]: Let's bring that up. You wrote the back ends?Kyle [00:01:48]: I was going through, I was going through, some old photos, when folks were talking about how things were being built or how there was a build GitHub. I built, webhooks and worked with teams building the API, built the platform layer. Anything that integrated with GitHub, up until really twenty eighteen, I built or ran the engineering teams. And that's kind of where my the beginning of my passion always was helping people build things, deliver them to, their customers. And so being a developer, building for developers was always super unique. In a— I think as my role expanded, it became my ability to talk to not just developers, but also enterprise customers or business leaders and have this translation layer. And then through all those years, GitHub has always operated pretty uniquely. Post-pandemic, working remotely was not as novel as it was when GitHub started in two thousand and eight. But all that expertise of running remote teams, doing it well, became this sort of bigger role, ultimately turning into the COO role of how do we operate GitHub in the way that GitHub's always operated after the Microsoft acquisition. And kind of so on from there. So like for me, I think the— I've, I still code. I love coding but the problem has always been, people. It's a much harder problem to both support our own employees, a harder problem to communicate to developers and enterprise buyers what we're building why it matters, ‘cause those are two very different messages. And so getting to work in the mix of COO, CMO, also just being a dev, I think is what's kept me at GitHub for so long.AI Workflows for Leadership: Commits, Retrospectives, and ContextSwyx [00:03:40]: Apparently, you have— your commits have gone up. What's this? What's going on?Kyle [00:03:45]: Rui's called me out pretty aggressively. So I think— as you can imagine, right, you can see my normal era of being a dev In the twenty thirteen, twenty fourteen era, and then moving into management, and then ultimately the COO role. I think what you see there is me, really getting back to coding thanks to AI. I— similar to, attaching problems between how to market and how to operate a business and how to code, I find, building agents and workflows that are connecting very disparate problems to be what's driving this. So that's, some of it's writing software. A lot of it is, connecting a ton of a different data sources to, help me out. But that is completely me really diving in on the AI side in trying out our tools, trying out everyone's tools, But building for me, building for the non-technical leader, though I'm technical and how we're, able to use these tools more than just the simple, call and response that I think a lot of the non-technical, your employers, you have to get— you have to use AI, and so everyone uses, ChatGPT or Copilot or Claude or whatever. To really get into, how is this going to help me out, it— I find that it's not the I need to write a blog post, I need to those simple examples. Helping people find the workflows of, “Okay, I need you to go through all the PRs today. I need you to go through everything that we've posted online. I need you to go through what we did the last three months. Go through all of my Obsidian notes for any mentions of this then go through my transcripts at work.” We use, Teams, so, using WorkIQ, go call that MCP server, grab all the transcripts, go through all the Slack, and then build me out the plan of, what this week's messaging actually was. That's something that was, impossible because for me, I find AI in a what most of this launch here is actually, less building forward. It's actually, a recursive loop backwards. I'm always looking at what had happened first. Go back through the week and tell me what we did, what worked, what didn't work? And then tell me in the next three or four days-What would you tweak based on this sort of like looking backwards and then looking ahead a little bit? I find that to be so much more valuable, especially for like non-technical, because that retrospection is actually LLMs are very good at that. Like finding all the patterns, pulling them out, and then applying that retrospection to just a couple of days or just like a short period of time. Is all a bunch of apps that I've built and launched a bunch of, internal tools. I use the new, GitHub Copilot app, the desktop app with workflows. Every time I crack open my laptop, it's running workflows for me. It's just a ton of different stuff and of course, it all ends up on, it all ends up on GitHub.Swyx [00:06:47]: Of course. That's where, that's where, stuff is hosted. Man, there's so much to ask you. I was going to leave the how do you run a company with AI thing at the end. I have to ask one— double click one thing. You said, you are looking back at the week. You're, you're understanding what happens. When you say we That's three thousand people. How?Rolling Out AI Internally: Skills, CLIs, and Company ContextKyle [00:07:09]: I think when we started rolling out AI internally beyond engineering, right? One of the things that I was really, passionate about is like we have to do this in a way where no one has to change how they work. I don't want to have to teach you a tool. I don't want to have to teach you something new. And so for us, we tried out a few tools. Most of them don't work because I got to get you on board? I got to teach you how to use it. What we've actually ended up doing is we've built like a set of skills internally. We have we each have our set of skills, and we've just been distributing even to the non-technical folks, the CLI. And then effectively, we're just giving it access to like read about everything that we're writing. So that's for us, that's usually GitHub, Teams, Email, and Slack. So Teams for, video chat, generally speaking.Swyx [00:08:03]: Teams and Slack?Kyle [00:08:04]: so we use Teams for video communication, but we don't use it for chat. W-we— GitHub for a long history, right? We're alwaysSwyx [00:08:13]: Also SlackKyle [00:08:14]: Talking about ChatOps and like everything is built into Slack. Like every command, every flow.Swyx [00:08:18]: So even though you have been acquired for I don't know, eight years nowKyle [00:08:22]: we stillSwyx [00:08:23]: You still use Slack?Kyle [00:08:23]: it's a purpose-built tool for us, and I think the reality is that moving off of it would be so bluntly expensive? Simply because all the tooling is, baked in with that paradigm. And they both have their pros and cons but they don't work the same way at all. We still use a bunch of different tools Because it's the purpose-built tools that We need. And thenSwyx [00:08:47]: Well, the same doesn't go for the rest of Microsoft, presumably.Kyle [00:08:50]: like the like various teams like operateSwyx [00:08:53]: They make their own decisionsKyle [00:08:54]: Various ways. I think it just matters what you're trying to what you're trying to do. But we do we do work across kind of every tool that we use, and then by giving everyone access to all of that context and the new WorkIQ MCP server, which is quite cool if you do live in the M365 like world. I can ask it all these backwards-facing questions, and it's incredibly important for our teams that are working remotely. There's a lot of stuff you miss when you're not in an office, and we are spread out all over the world. So most of that is looking back. And then we post, we post either auto-automatically into GitHub issues or discussions, these sorts of like findings or like our industry reports. Like what's happening this morning, today, yesterday. A little automation gets run. We'll use the app. We might use GitHub Actions like with, our agentic workflows just to go do that run, and then we push it into GitHub, and w-we keep having a conversation. So usually for us, it's about that sort of like looking back, looking forward on the non-technical side. And then of course for a lot of those folks, it's also building an app, pushing it to GitHub pages or pushing it somewhere to host it et cetera. But it's just like enabling everyone with that power of it's going to take me a week to figure this out. Instead, we're going “Okay I built a skill. Let's put it into a repo. We'll all share that skill together, and then we'll use the CLI or now the app-” “just to run it.”Micro Skills vs. Mega Skills: How GitHub Uses AI at WorkSwyx [00:10:26]: All right. I think, I think we're going straight into like the team management and productivity thing. I think a lot of people are getting various levels of LLM psychosis. How do you manage the bloat of skills? Like everyone Has their thing, and they're Like trying to promote it to the rest of their peers in their org, right? And obviously, whoever becomes a skill influencer internally becomes like an AI leader, right? Of sorts. I assume you have those.Kyle [00:10:50]: like I think we haveSwyx [00:10:52]: And I assume it's a mess a Yeah.Kyle [00:10:54]: there's like I— like I think the reality is there's two pieces. Like first is I think that we're ending the era of these like massive, beautiful, perfect skills that are just like not any of those things. ‘cause for a while, right every tweet every day is like go download the skills, the perfectly managed thing to do this entire workflow. And I think that like what we've found and what— I was just with my team, this week, and we were talking about the skill side, and we're really talking about these like incredibly micro skills that are just doing one thing for us very well Versus a skill that's going to do I said, that full report. That doesn't really exist on our side anymore. It's usually how do— like a single skill that's going to identify the most important marketing information given any MCP server. Like this is the most important thing. Less about stitch a bunch of tools together and have it produce this mega output because then weeks go by, months go by, things change, and you want to tweakSwyx [00:11:58]: It's brittleKyle [00:11:58]: Your mega skill and you're screwed? You can't do that. And so now we're really just talking about the Legos we're using and just letting the instruction book be something we're all putting together. Whereas I think a lot of AI skills for a while have been that mega instruction book style.Swyx [00:12:15]: I've, thought a lot about Postel's law. I don't know if that's a term that is, means things to folks. It's the idea that you should be liberal in what you accept and strict in what you output, right? And I think that's like a good framing principle for skills. This is my skills, obviously on GitHub. I feel like everyone should have like how like some repos In GitHub are special repos? I feel like we should sort of reify the slash skills and everyone like give it some kind of special presentation. Anyway, so, yeah, this is one of those like download Download anything, transcribe anything, and then you can string together the atomic skills that do one thing well Into like some kind of orchestration skill that calls other skills. I assume, does that match?Kyle [00:12:56]: I like I think so. I think that theSwyx [00:13:00]: Summarize anything.Kyle [00:13:01]: Like I think the- For me, summarizing something for I do communications and PR and analyst relations and marketing and customer activities, and so my summarize everything is very different for each one of those like Contexts. What ‘Cause if I'm summarizing something for an analyst, that's a very different thing than, probably how I'm going to summarize something for like a customer meeting or an engagement. So that's I think like the difference when we're talking about the like the tools I might use on Saturday or the skills I might use on a Saturday when it's just for Kyle. Yeah, those are kind of like they have an atomic actual tool underneath or maybe skill, and then Kyle cares about X. But I think when we're talking about work and enabling the the marketers, communicators there, it's the atomic, this is what good summarization is, and then this is what I care about as for marketing for communications For whatever. And that I think is like the interesting matrix problem when we go from like a developer set of concerns to all kinds of different professions, is that what that word means to me is different than it means to you is different than it means to the analyst or the salesperson, and that's where I think the matrix mess is that we're starting to like still starting to find. It's about these mega skills but they're all just slight permutations, but those permutations are really important. It's the difference between someone reading this and going “Did AI make this?” what Or “This makes total sense, and I would expect this when I'm giving a briefing to Gartner,” or like whatever else.Swyx [00:14:37]: I think the beauty of it maybe is that you don't have to be that careful about what goes in there. It doesn't have to exactly fit as long as it like roughly is contained in there. I used to complain about plugin hell, basically. Like when you have a framework and then you have a hundred things that you need to integrate, everyone does like the GitHub used to be bloated full of these things. And now we don't need them anymore ‘cause now you just use skills.Former Developers in Leadership: AI as a Creation MultiplierKyle [00:15:00]: And like I think the most magical thing is the just that like I can just also crack it open. Like Like yes, I could go like change the how the plugin is coded, or like I could go do that now with AI, but I think there's just something more magical about getting a response back and being “That's not right,” and then you just crack the skill open, you just type English words and it's different. That building block is just, I think very unique. Once I get everyone to kind of understand how to best how to best make those changes to get the most power out of them.Swyx [00:15:36]: Is there a— you have a your peer group that Of people like you. Is there a common framing for Something I'm feeling is, which is true, is that is this a golden age for former developers who are now in leadership? Because you can wield the tools, you would know the right words, you're maybe not too close to the details. Doesn't matter. But like you're more effective than someone who doesn't come from that background.Kyle [00:15:59]: I think that like the secret has always been your ability to identify patterns and solve problems, and I think that for folks that like myself that don't code day to day anymore, that has made me successful as a developer, made me successful as a COO and now CMO. And so now that I have access to get and write code, I'm now applying that sort of like pattern finding and problem solving, and I know enough still about how to then go and say, “Oh, I want to make an app, but I don't want to break into jail or create something that's not going to be able to work or to be deployed scale or whatever.” that ability to apply all that additional business knowledge and still code I think is what makes that so interesting to me. Slightly different than I think some of the other like technical leaders that became business leaders and now are going back to their apps and updating them. Good for them? But I think the more, much more interesting thing is, well, now I have this whole new set of expertise over ten plus years. Why not take that and use that as a developer with these AI tools? So I definitely think that makes me more powerful, but I think that's true for like every dev as well. Most of the dev friends I still have also have some other underlying skill and passion. There's really talented, very kind of linear computer science software devs, absolutely. I just find that the folks that came from a different career, went to school for something else, went off and did this random thing, and then became a software dev, or were a dev, did a random thing, came back. Learning that extra set of information, learning those extra skills, and now having the power of an AI where I can crank up fifteen agents on Saturday while my kids are doing lacrosse, That's like really powerful. And I think it gets me back to that feeling of like creation, and it's very hard to replicate that in most other senses? That first time you build an app and you click it and you show someone that's magical. And so being able to do that not just in code, but across all kinds of different assets that's, that's huge. We were doing we're doing our every year we do our revenue planning. We talk about okay, what is it going to look like for next year? And of course as you imagine, there's, slideshows everywhere talking about what are we going to talk about, what's the narrative, et cetera. And so as you said I'm “Okay, well, I could probably just like build something to build this and then that way I don't have to go build the whole spreadsheet or I have to pass it to my team.” So we went through this process, and I got all the information and used the skills I mentioned. I built like a little app just to make it so I could look at some of the information in a SQLite database, more easily. And I ultimately built this entire presentation without touching any of it and I was “Okay, I'm just going to present this to our CRO, the CFO, their teams,” without mentioning I'd built it with AI. I like built a skill to make it look very much not AI driven. Just not pretty.AI-Generated Presentations, Human Taste, and the Changing Chief of Staff RoleSwyx [00:19:03]: Like a design. Yeah.Kyle [00:19:03]: Not pretty. But just like very clearly not AI. Kind of like don't do anything interesting.Swyx [00:19:08]: That's, yeah, that is valuable.Kyle [00:19:08]: Just go Exactly. We did the whole thing through. It used my notes from Obsidian, it used all the context I mentioned before, the plans, and Never came up once that it was AI generated.Swyx [00:19:20]: It didn't matter.Kyle [00:19:20]: Never once. D It didn't matter. And so now I takeSwyx [00:19:23]: This is a toolKyle [00:19:23]: I can take that tool and go, “Look, I don't want you to go build slideshows.” They're just helping us share information with each other. If this thing can do it With a little bit of crafting from you and then we can look at it together, awesome. There's no value in all that extra work. I think that the ability to, make it look humanly bad and and build a little app to, manipulate the data I think is part of, that upside for devs that are now in leadership roles. Because, the thing that I feel like I said before, this that's all a people, that's all a people problem. I know if you've used a coworker or not to build a slide deck, unless you spent a bunch of time to not do it.Swyx [00:20:07]: I know, but like it was so, I think there's a certain charm to just being blatantly AI. ‘Cause I think that you're well, you're just honest about There may be mistakes here that I cannot vouch for. So how much value is there? But anyway I think, actually the real question I want to ask is, there's a— You were a chief of staff To Thomas. And in the pre-AI world, the that job would've been a chief of staff job of like Can you prep me these slides and all that? And now you do it yourself.Kyle [00:20:35]: I still, I still have a chief of staff. Because, the difference is it's sort of the discussion every time we have some sort of technology evolution is it's not that the jobs the roles don't all go away, they just change? And so yeah, I don't have someone spending all their time building out slides for me and presentations ‘cause I don't need that anymore. But now I need that person that is able to go and find all the different connections between humans in those discussions to help me find out, okay, I should be meeting with this group and this team, and they have an opportunity, and I'm going to be in San Francisco today, I'm going to be in Seattle tomorrow. Those sorts of human connection aspects are still incredibly valuable and has always been a big part of that chief of staff role. But now just like chiefs of staff are not opening up, letters to process, they're doing emails. What It's the same thing. And now they're, they're not building out as many of these presentations because they have the the ability to have a AI take it on for, and share that with me and great. Let's keep moving ‘cause it's allowing us to go faster and make better decisions more quickly.Swyx [00:21:45]: Awesome. Well, so we can dive into more sort of, Productivity insights as you go. I did want to do a little bit of a brief history of colleague and hub. Because, we started here. And then you also involved the NPM acquisition. I did, I do want to touch upon that. And then more recently, I just want to bring up to present day where we're having uptime issues Which transparently we've already Addressed publicly, but we'll, we'll discuss in the pod. Did I miss anything? Like what, any other major highlights? Obviously, it's, it's a lot of years to cover.A Brief History of GitHub: Webhooks, Actions, Acquisitions, and Platform EvolutionKyle [00:22:15]: No the I think one of one highlight was right before the acquisition closed in twenty eighteen, I got to launch the first version of ActionsSwyx [00:22:27]: OhKyle [00:22:27]: At GitHub Universe. So it was OSwyx [00:22:29]: They're that young?Kyle [00:22:30]: It was October of twenty eighteen, I think. Yeah. Yeah.Swyx [00:22:33]: Gee, Jesus.Kyle [00:22:34]: I got to I was the engineering leader on that project and got to launch that. And then, yeah, we did acquisitions of NPM you said, Semmle, Dependabot Pul Panda a whole bunch of things. That was a bigSwyx [00:22:47]: Pul Panda.Kyle [00:22:48]: Abi is doing well.Swyx [00:22:51]: DX. Holy crap.Kyle [00:22:52]: Did well on DX. I and like that was a that was the big shift, after the acquisition. I had to join the sort of business side.Swyx [00:23:00]: So I need to hit you on some of these things ‘cause you were there. Right? And how often do I get to talk to someone who was there? But yeah, Actions. Is that the number one source of security issues on GitHub?Kyle [00:23:11]: Oh, sh I think that the number one source of, security issues is probably like all, the literal code in everyone's like underlying repositories. I would say back further than that is, if you remember I had to show in this graph was this is, I'm, didn't say this before, this is ultimately webhooks.Swyx [00:23:30]: You yeah.Kyle [00:23:31]: Like circa whatever it was.Swyx [00:23:32]: It says Hookshot in there.Kyle [00:23:32]: I forget. Yeah. Yeah, Hookshot's in there. And so like back then, it says GitHub Services. Do you see, it says Hookshot FE for front end, and then it says GitHub Services. GitHub Services back in the old days, right? You we had a repository that was Ruby code, and you could write any Ruby code in there, and then we would execute that On your behalf As a service, and then that way if an if you were trying to integrate with something, it didn't we would run it for you.Swyx [00:23:57]: And of course no containers ‘causeKyle [00:23:58]: No, ‘cause it wasSwyx [00:23:59]: Well, no containersKyle [00:24:00]: Twenty fourteen. And so there was some isolation obviously, but it was mostly the separations on the server level. That's like an example as long as the very old version of Pages, which ran on its own containerization infrastructure, not on Actions.Swyx [00:24:15]: Which like all-time great product.Kyle [00:24:16]: Pages powers the internet at this point to some degree. Those were places where like clearly there were no like issues like to my knowledge. But it was those things where I'm looking at and going “Okay, well we can't be running arbitrary Ruby code,” like on everyone's behalf. Then containerizing all of that up intoUh into actions now where yeah the containerization, is r-really good. The pinning most folks aren't pinning it the like to a particularSwyx [00:24:48]: ImagesKyle [00:24:48]: Sha, et cetera like their workflows, and so that's a big that's a big place Of pain for folks if they're just doing similar to any dependency management, just V1 or newest or latest, I think. But, that journey from that day to “Okay, we're just going to run all this arbitrary code, and, it'll basically be okay,” to now, no, we have, really good containerization. We have a new, underlying, ag-agent, containerization, service. It's like we're using it under the hood. It's through Azure. They recently announced it. The Azure, Dev Compute, but it's, very fast, very fast compute to be able to, spin up your own cloud agents, or whatnot. We're using it under the hood for some parts of the new,Swyx [00:25:36]: Microsoft Dev Box?Kyle [00:25:37]: No. Dev Compute, yeah.Swyx [00:25:41]: Hmm. Not finding it just yet.Kyle [00:25:44]: Oh, it's, it's in there somewhere.Swyx [00:25:46]: All right. Well, we'll cut that out.Kyle [00:25:47]: Sorry. But with, Dev Compute, you can, run, really fast, spin up really, small VMs really quickly, so you're doing a tool callSwyx [00:25:58]: Same conceptKyle [00:25:58]: Just do it containerize exact-exactly. So we're using that so definitely moving that direction to protect us from every every piece of code that we're ultimately running.Swyx [00:26:07]: look, that grows into the full SDLC? Code hosting was just the start and and then it's grown beyond that. Let's talk about NPM may-maybe ‘cause I think that's also, a very major point in the industry. I do think, it was looking for a home. It was, kind of struggling as a business, right? I don't know, I don't know how you would characterize that whole acquisition and how itNPM, Package Security, and Keeping the Internet RunningKyle [00:26:33]: like when we were talking to the team, I think the big thing for the both of us was to find a way to keep NPM, which was basically powering the internet then and way more so now to some degree running. Keep it going keep continuing to scale. It was having scaling problems, if I recall, back at that time. They were doing some rewrites. ItSwyx [00:27:00]: that's cute compared to now.Kyle [00:27:01]: Well, that's the thing is like when I'm talking to folks now, there's there's so many more underlying uses of NPM than there were back when we had them join in with GitHub. But that was ultimately the goal. It was really okay, we used to have pages. We have, the world's code. Let's make sure that we can keep NPM running well for the world. And we put a bunch of time and investment into fixing some of the underlying backend, changes, some of which we talked about some of the manifest work, et cetera. And then now, really trying to bring the the security posture of NPM up to speed. But, it is a unique challenge in that every move that we make to make it more secure will break a lot of people. And security is paramount. And also, we take it very seriously. We're, the any time that we have a problem with GitHub or we make a change that makes us more secure but hurts, there's, a snow day for developers or a really bad fire that they have to go put out. And so we've, have changed the 2FA policies. We've changed the way the tokens work. When we find tokens that have been exposed or potentially, exposed, we invalidate them, andSwyx [00:28:22]: I love that feature in GitHub. Yeah, it's greatKyle [00:28:23]: That creates issues, but, the but that's the thing is we're trying to push the community, forward without necessarily, doing something that is going to break the contract that's been for 15 years or close to it or some amount of years on NPM.Slop Forks, Vendoring, and the Future of Open Source Supply ChainsSwyx [00:28:43]: I think the— So now we're talking about, open source and publishing. And I think there's something here with what people are calling slop forks, which, I think Malta from Vercel is doing. And, part of me thinks, well, the way to get past any vulnerabilities, we just, let's just get rid of the concept of NPM. And we only publish source code. And anytime you want to import it you have your coding agent look at it and then adapt whatever subset you're going to use into your vendor it. But, the AI vendor it. Is that realistic? I don't know. Is it— Will that solve all our security issues? I don't know.Kyle [00:29:24]: I don't think it'll solve I so Mitchell was just talking Mitchell Hashimoto Was just talking about this today, and I think that I-in some ways, it's all all things, old or new again? Yeah, absolutely vendoring everything. Like I do I do remember twenty thirteen, twenty fourteen.Swyx [00:29:42]: This is Yeah. Let's, we must return toKyle [00:29:43]: That's what is We were vendoring everything. We were having actual discussions around, or at least I remember we were “Should we take this full thing?” “Why is this so big? We only need this one file.” And so I do think there's something true there where having either taking only what you need or the dependencies just getting incredibly small over time, I think will help to some degree, but it's not going to solve the fundamental problem, I don't think, because the vulnerabilities in an agent looking at them, there's time and time again, there's a million different ways in which we can convince an agent that this thing is, secure or not and pull it in. Or we can do static code analysis or runtime testing to say whether the code works or not. That is, I think, the step that needs to continue to be, invested in. The question is just on, how much scope. Should it be this enormous project that I'm pulling down, or should it be this piece? Either most companies are running some amount of security checking on the on the packages that they're bringing in or vendoring. That I think won't change. That's like what advanced security does to some degree, Socket does some degree. Like everyone is doing a piece of that. How we each do that like especially when we're talking to enterprise customers, is just like very different. No there's no one wants one single way to do it. And I think that's always been GitHub's, unique position in the world. I talk a lot to maintainers, I talk a lot to folks about this. It's we're— we rarely start like a process and a practice and like push it onto the community. We usually wait for the sort of like RFC process socially or literally, everyone agreeing, and then we'll cement something in. Because otherwise we'reMaintainers, RFCs, Vouching, and the Social Layer of TrustSwyx [00:31:35]: That fits your role in the ecosystem, yeahKyle [00:31:36]: We're GitHub. Yeah, we don't want to shape the whole thing. We want it to be figured out. But like how do you balance that like sort of Role in the industry to keep everything as secure as is possible and make sure that you're you're not going to be compromised as a human, ‘cause that's usually how it all happens. And Not not create a process or lock us into a flow that you're not going to or like Mitchell's not going to or other open source projects aren't going to like. That's always been a tricky balance for us, and I think that's something that we haven't talked about enough is we're not going to be able to fix everything for everyone in a way that everyone is going to like. So tell, help us, tell us what is working. When Mitchell was talking about, the Upvote, the upSwyx [00:32:22]: I was going to bring up his thing. Yeah.Kyle [00:32:23]: I forget what it Yeah. When he's talking to us, I was chatting with him and talking to him about this and I put it on Twitter and we talked to, also over DM, was “We're going to keep working.” but I think the important thing is I do actually want to hear what isn't working for you. And as, be as specific and clear for your project as is possible. And to every piece of credit over the many years that we've known each other through the industry, he's always done that and I appreciate that ‘cause there are places that we need to fix up, and we hear from him, and we'll fix up just like we do all other kinds of maintainers. But that that process between making those types of improvements and being more secure and like creating, I forget what he calls it's not the proof process, not the claims process. Do what I'm talking about? He has that he his projects have a way for you to kind of like,Swyx [00:33:13]: VouchKyle [00:33:13]: Vouch. Thank you. Yeah. He has like the vouch system for saying, “Hey, you should accept my PRs.” That's beenSwyx [00:33:20]: I just built this into GitHub. I don't know.Kyle [00:33:22]: Well, see, but that's the thing is that you say that and like he and his community really likes this and then I'll go talk to other maintainers and other maintainers, globally, and they're “No, this doesn't work for me.” And that is the tension, but also the kind of beauty of GitHub, depending on which way you look at it is we want to help maintainers, so we create all these tools to let you have more control over how much you take in from AI and PRs. But you can also use this. What You can go use this project, and if it takes off and becomes the kind of mostly standard, then yeah, we probably wouldn't enforce it but we would add it in because that's the flow that we tend to do?Swyx [00:34:02]: I hear a lot of people don't know the history of the pull request. And like like that's how, that's something that GitHub standardized basically.Kyle [00:34:08]: Yeah. It was a very messy process Like beforehand, and now the we have the benefit of it being the process? And now we have to go and Figure out the next best process or what adaptations change, or what does a pull request look like when eighty percent of your PRs are just coming from your agents and not From other devs?Swyx [00:34:31]: Do you like the prompt request idea from Peter?Kyle [00:34:34]: like I think that for each like each idea I think has its merits. I'm not, I'm not avoiding saying anything good or bad, but I feel like I've seen a version of we have that we have entire Thomas' store. Take all the assets of what you've built and put that in. I think that's got great ideas. There's all these various permutations of the PR flow, but I think the reason why there's not a single answer is ultimately we're trying to codify trust. We're trying to say “Okay, if Sean reviews this I'm going to trust it because you're Sean or you're the senior dev or you're the whatever.” And right now, when we are working in a flow where an agent writes code and another agent reviews code and then Kyle goes and looks at it the trust is kind of diffuse. And most of the tools that we're talking about are talking more about verification flows. We have more assets to look at, so I can probably say whether this is a good PR or not. But that still doesn't solve, I think, the human problem of I'm looking at a PR and I want to know if I can trust it. And we're still, we still tend to use human signals for that? Mitchell approving it or Kyle approving it or whatever. And so I think that's, I think that's why most of these options haven't really solved it is because, it's a social problem ultimately. It's a it's a human problem to review it and agree. Or you fully trust the tool and you're imbuing that tool with full trust Which I think in some cases that absolutely exists.AI-Generated PRs, Trust, and the Waymo AnalogySwyx [00:36:08]: And so like in the same way that there will be a tipping point in society when we don't allow humans to drive anymore Because machines are measurably better than Than humans. I'm looking for that tipping point, right? Like Mythos is ridiculously expensive. Someday we'll have Mythos on a desktop. I don't know. Will, does that change the equation?Kyle [00:36:30]: I think it's more I took a Waymo here, and I was on my phone and not looking around at all. There are other, self-driving, vehicles that I would not trust while, staring at the road. And I think that trust is something that isSwyx [00:36:48]: Is this a Zoox thing? What is itKyle [00:36:50]: I think that is both. I think that is both. LikeSwyx [00:36:53]: There's Zoox in this robo taxi. That's it. It'sKyle [00:36:56]: Well, depending on what level Of self-driving. But, my point is sort of that I think part of that is I strongly believe that's, a mixture of verifiable proof. Like how many accidents, how much data, and so on, and the human aspect of how I feel when I'm in this car, what it tells me, et cetera. And so that's why I think some of the like Some of these some of our AI tools tend to, imbue me with more of that feeling of trust, even if the data says this is 100% accurate. I feel like it takes more time for us to go, “Should I trust this or not?” And that's in the soft sense of, startups with high agency, weekend projects, and open source. And then there's enterprises and regulated industries and everything else, and that is an even harder problem to go solve because even when it is fully verified, not only do you have to have trust from the humans on the team, you probably have to have trust from multinational,Swyx [00:37:55]: Oh my GodKyle [00:37:55]: Multi governments around the world and regulating agencies. And so that's where I feel like until we tip over to your point on the sort of like human EQ side of it. I feel okay this feels okay I've been proven enough. Then the ball will start to roll a lot faster, where we'll end up getting to the “Okay, we can trust this,” and feel good about it in the Most difficult of cases.Reputation, Sponsors, Stars, and Bot Activity on GitHubSwyx [00:38:18]: If human trust is the thing that matters, I feel like GitHub as the developer social network could maybe do more there. Like vouchers are one system But, we have star counts, and then we have Contributor rights, and that's it. And I feel like there should be more in that space. I don't know if there's any other design decisions there.Kyle [00:38:37]: I think that one of the places that we don't really expose right now in this sort of way is, some degree of like hard trust and support, which would like for me is like sponsors is a good example of that.Swyx [00:38:49]: Ah.Kyle [00:38:49]: It like costs you something. To prove that I believe in your project and I trust you To some degree or I want to support you at the very least.Swyx [00:38:56]: Solve payments for open source. Why not?Kyle [00:38:58]: I think that I think that like as we keep moving forward, right, there's more and more projects where I'm, adding more and more dollars into sponsors personally because I want to like support them, but I also like know of I've probably never met them in person, but, I know of enough of their work that I want to support them. I think the thing that I don't love about stars or commit counts or anything else is ultimately, even with all of the various, abuse and de-spamming and deduplication work that we do or anti-abuse work that we do, these are all, not active social signals. They're passive ones that are ultimately gamifiable. And you may trust me, but another open source maintainer may not. And on what heuristic should you be, trusting me? That I think, is kind of where some of our thinking is right now. What signal from me is most important to you? You— If you can define that potentially, honestly in an agentic workflow that's what we see some of these open source projects do, where you have GitHub actions, and then you have like an agentic workflow that's calling AI, and you're setting these rules. Like if Kyle has submitted and gotten accepted PRs across any given project and has a social handle tied to his account in GitHub, and that social account's older than a certain amount. Really complex measures that matter to you ‘cause most open source projects have that heuristic built into their heads, if not written down in the contributing guidelines. You could take that and then go apply that and then just say, “Oh, we're not going to accept this PR.” Building something that is, I think, malleable to everyone's needs, is a little bit better, rather than going “Hmm, this account's too young.” Because what happens? The attackers just go and go and create a multitude of accounts, and they wait Until it ages up. Needs to have a certain amount of stars. That's how star inflation happens. Need to have a certain amount of reposSwyx [00:40:46]: Oh my God. YeahKyle [00:40:47]: With PRs. They all just create repos and submit PRs to each other, and then they come in and do something nefarious. And so, it's hard. It's hard to find the measure. So I think we're, we're looking more at how can we provide you tools so you can kind of choose what's best for you. And of course, we'll give you some standards. But the trust vector, gets down to I don't know, some version of like human digital ID like everyone's been talking about. Like how do I prove that it's meSwyx [00:41:13]: Give me your eyeballsKyle [00:41:14]: On the internet. Give me your eyeballs. Exactly.Swyx [00:41:18]: The I got to keep moving on Topics, but obviously I can go all day on this stuff because, I've been involved in GitHub and open source My entire professional career. Stars. Very superficial. Everyone knows it. But I think time to one hundred thousand stars is the fastest I've ever seen. Like people just reached that in I don't know, months. And then like at the same time I don't trust it right? Like how many of these are real or bot or like whatever. I don't know how to ask this but like what can we do about it? LikeKyle [00:41:49]: JustSwyx [00:41:49]: Is stars broken? Is stars fine?Kyle [00:41:51]: I think that there's kind of two, there's like two pieces. Obviously we're constantly like trying to find ways in which like your users are producing spam, which would, I would include like be like only doing star gamification. When we find them, we pluck ‘em out and we,Swyx [00:42:08]: But it's like a Whac-A-MoleKyle [00:42:10]: It's a hundred percent like a Whac-A-MoleSwyx [00:42:11]: There's no wayKyle [00:42:11]: Now, powered by AI to be helpful. But I think more so what I'm seeing is, a lot of the like fastest time to X tends to be because we're now inviting so many more people into like software development on GitHub That like the zeitgeist is just swarming? And it'sSwyx [00:42:32]: It's not just developers anymoreKyle [00:42:33]: And it's not you and I. Like like however you want to say like what a developer is it's not just folks who have been coding for a very long time. It's folks that have maybe started coding or only joined in since the AI era. And nowSwyx [00:42:44]: what's the latest Octoverse number? I know eighty million was my lastRem- member that a number of developers on GitHubKyle [00:42:50]: Oh, we're over 200 million now.Swyx [00:42:53]: Okay. Well, so you see?Kyle [00:42:55]: Like over 200 million developers now.Swyx [00:42:56]: But it's not developers, right? It's, it's people with a GitHub account.What Counts as a Developer in the AI Era?Kyle [00:43:00]: So, so this is, this is the biggest debate that I would say, everyone loves to have at GitHub at this point. From my perspective, right, I think that there's, there's clearly a difference between, professional enterprise developer and then developers. But I think that I think that the idea that we should be I don't know, splitting hairs or segmenting developers in the early era of software development is, not worth our not worth the time. SoSwyx [00:43:29]: When you get into gatekeepingKyle [00:43:31]: 100%Swyx [00:43:31]: What is a developer?Kyle [00:43:31]: 100%. ‘Cause I wasn't a developer when I started writing code? I was going toSwyx [00:43:36]: Oh, no. I made— I cloned a thing, seven years before I learned to code. And then I and then I wrote about my learning to code journey, and people Just called me a fraud ‘cause I had a GitHub account. And I'm “Well, no, I just use GitHub, but I don't know-” “I didn't know what I was doing.”Kyle [00:43:49]: I I remember that. I remember those sets of posts, and like that's, that's b******t. So I fight very clearly on the line of, if you create code, if you have an idea and you create it into some way of, I'm, I'm going to run it and use the app right now, you may still use AI in that moment, but that's okay. At some point you're going to do the next thing. You're going to create a big— You're going to have to learn about this database. You're going to fix a bug, whatever. We're all on some same journey, and those people are also hearing about the great new agent skill package or a new CLI tool or a new whatever. And those projects are going up because you want to be a part of this moment, just like I wanted to be a part of the Ruby community when Ruby was popping off when I started becoming a developer, and now I can just click the star button. And so I think that yes, there's clearly some amount of like spamming and game gamification that we're working against, but I really think we're just seeing this whole new cohort of folks that are moving from technology to technology because they're not working on a 20-year-old software application. They're working on a side app that they built on the weekend for their friends or for their new idea or whatever. And that's how you see these enormous charts going up and to the right with With stars.Swyx [00:44:59]: I think something that's remarkable is the persistence or, that GitHub extends to those folks. Usually when I see platforms go into a new audience, they usually have to, have like a second platform with a different name that wraps the main platform. But somehow GitHub has been able to sort of persist and extend, and it's friendly and whatever? So it's, it's nice.Spark, Low-Code, and Always Showing the CodeKyle [00:45:19]: I that's partially why I think as we've tried to move into I don't know, more like low-code-y things. We so we started working on Spark as like a way to, build an app and run it. I think that the reality is that we anytime we try to, kind of put even a veneer on top of it without when we put a veneer on top of something, we still always show you the code. That's kind of like a tenant. We're never going to, hide the code from you ever, because whatSwyx [00:45:52]: Why would you?Kyle [00:45:52]: That's, yeah, that's the whole point? However, I think that what we learned with things like Spark is that really the value of Spark for most devs is, easy runtime. And you may have a runtime or a host that you're going to use for that or you just build something and run it but, the package of making that even more simple isn't really needed for folks that are trying to build software and not just trying to build, an app, which is, slightly different, a slightly different goal. So I want to get you in, I want to get you comfortable. I think the best thing for me as, someone that did not traditionally come into software dev way back, I want anyone to be able to breach that chasm and not be in the I don't know, I feel like we're, we're still in an era of, STEM. I've got a 12-year-old and an eight-year-old, and it's “We got to get ‘em into STEM,”? Over and over. And I like I do, I do the things that good parents do. I was “Oh, you want to do coding?” “Yes, I want to do coding.” Do coding classes. But now they're just not afraid of doing software. And that's, I think, the thing that's honestly kept me at GitHub for so long. Anyone should be able to go and build a thing, just like I can go change a light switch in my house. I'm not going to go into the breaker box ‘cause I'll probably kill myself? But, I can go change that light switch. Everyone should be able to go and say, “This fricking app doesn't do what I want. I want it to work like this.” And that I think, is what's kind of kept us all connected with GitHub through the years and some and during the easiest of times or in the hard times because of that opportunity of, we're the home for all developers, and we want everyone to be able to have that feeling that we've had of, had an idea, I created it and holy s**t here it is.Swyx [00:47:37]: Here it is. All right, I'm going to try to do more spicy questions.GitHub's Hardest Scaling Moment: Growth, Agents, and UptimeKyle [00:47:42]: Great.Swyx [00:47:42]: Is it an easy time now or a hard time?Kyle [00:47:45]: Oh at GitHub? It's a hard time. Like, it's a hard time and also, I was just with my team and I said, “This is also, the best and most exciting time that I think I can remember at GitHub.” BecauseSwyx [00:47:57]: Best of times, worst of times. It's never oneKyle [00:47:59]: ‘cause we've we were talking about Octoverse reports and, usually we do an Octoverse report once a year, and we look at the numbers, and we say, “Oh my goodness.” I was at Universe in October saying, “This was the fastest year of growth that we've ever had,” right? And now we're doing more in a month than we did in a year last year.Swyx [00:48:20]: You're talking about PRs.Kyle [00:48:21]: Commits.Swyx [00:48:21]: Commits, yeah.Kyle [00:48:22]: PRs. Kind of like you name it by roughly every measure that we're looking at, there's some amount of sort of growth that is much bigger, and that is breaking our system in new ways, not old ways. Like webhooks were always notoriously, unreliable over the years?Swyx [00:48:38]: Whose fault is that?Kyle [00:48:39]: not anymore mine, but for a period of time, I'm sure you could pull up a tweet that was “It was me. I'm sorry.” but, now, that got rewritten at a scale level that is still working and is not having problems today. Now what we're finding isn't just the isn't the-The simple stuff that folks are on the sometimes on Twitter or on the internet are “Hey, why is this like this?” Sure. There's absolutely silly problems that we shouldn't exist. But now we're talking about, unique, novel permission problems that happen only at a scale across all different objects or whatever, that now we have to go rewrite this underlying system. And so it's, there are problems that yeah, caught us off guard, which I think I said. Like the growth is astronomical, but also we're making such material progress in that I'm excited once we're once we've kind of like reimagined the underlying foundation layer, or pieces of it at least, what's going to be possible when it's not just all of us and all the new people that are being developers and all of their agents and all the tools like working together. Because that'll still happen in that in that GitHub tool, that GitHub community. But it's a it's a hard day anytime we can't give you what you're looking for. We have the same problem internally. We operate through github. Com. Of course, we have backups when things go down and whatnot for our own operations but we feel it too. If it's not working it's not working for us, and that's kind of like the promise of dogfooding for GitHub. It's always been true. We're using the same tool you're using. We're not using a super secret version. We and so we also need it to be great for us for our customers of course for open source. And now an exponential growth of agents, Doing it too.Swyx [00:50:32]: I wanted to load for audio listeners who maybe haven't seen your tweets, whatever. So one billion commits in twenty-five. Now it's two hundred and seventy-five million per week on pace for fourteen billion this year, if growth remains linear. Is that still the pace? I don't know. It's been aKyle [00:50:48]: it's, it's speedingSwyx [00:50:50]: Roughly.Kyle [00:50:50]: It's still speeding up.Swyx [00:50:51]: It's, it's April, so yeah.Kyle [00:50:51]: Exactly. This was in April.Swyx [00:50:53]: All right. So basically you have fourteen x growth, right? Year on year on year. And I think that's a scaling issue. I think, I'm going to like try to really steel man this thing. People have experienced fourteen x growth. They haven't had your downtime. And that's like— C-can we go dig into that? Why? Like what's the— what broke? What are we doing to fix it? Like just anything for the community to reassure them.Why GitHub Reliability Is Breaking in New WaysKyle [00:51:18]: so there's a Like I was saying, there's a couple different places that we've seen the growth issues. Some of the growth issues, which is why we're t— I was talking about pushing hard on more CPUs is in actions in particular. More tools, more agents, more PRs mean more builds, more builds mean more CPUs. And so we are expanding through not just our data center, but obviously we were talking about moving to Azure and moving to, adding an additional cloud compute because we simply need more CPUs. Not as much GPUs. We definitely need GPUs too, but now CPUs are becoming a factor.Swyx [00:51:53]: It's very CPU heavy.Kyle [00:51:54]: Underneath the hood when it comes to some of the underlying services, we've been breaking up over the years our database infrastructure, so that way we have, more cognitive separation between our the various services. The place that we continue to have pain is in, permissioning. And so right now m-many of our permissioning layers sit into a database that we like internally call MySQL One, and old Hubbers will know what I'm talking about. And so we've been pulling things out of MySQL One for many years, because like and we use we use Vitess and we use other technologies to shard and we do it as one bigSwyx [00:52:31]: Famous thing, PlanetScale was born from this andKyle [00:52:32]: A hundred percent. Sam Old Hubber and friend. And so finding these opportunities to like break this out and then do that globally. The other thing that I think is interesting and both a unique opportunity and tricky is we also run everything I just talked about in a black box container with GitHub Enterprise Server for people that work on-prem. So we take everything I just said, and we also do it on-prem, and we also do all of that and we do it in a data residence setup for customers that need to have their data in a single location. Each of these has the unique characteristic around how we're sort of storing that data in MySQL or in a permissioning setup. That's where some of these outages have oc-occurred, where you're seeing it more like across the board rather than just like the one pieceSwyx [00:53:17]: Filling the databaseKyle [00:53:17]: Isn't quite working. Exactly. And so part of it is that. I think there's been some other places where agents are much more or more projects appear to be moving towards monorepo versus we were going the other direction for many years in the industry. Repos were smaller, but there were more of them, and now we're seeing the opposite. Repos are bigger, and there's, not fewer of them per se ‘cause there's new growth, but, we're just seeing many more big repos. Big repos, big monorepos have always had, a unique performance problem. Because each one, is slightly different if, particularly if the underlying blobs are incredibly big Inside the repos. And so we've done a ton of work that you pro— like most people haven't probably experienced, unless you're in this case of the monorepo. But that Git, infrastructure layer improvement does help the overall, system because, many of the improvements that make monorepos work better make all repo infrastructure work better. And so, I could kind of keep going down the line where it's another thing where we're moving out of, We're changing how we do j I'll just say job queuing for lack of a better, explanation changing the underlying technologies there.Swyx [00:54:32]: I spent two years being a job queuing guy, so.Kyle [00:54:34]: And so it's kind of a little bit of a little bit of piece by piece, and it's mostly because as we were— as it was built, we built everything in a way that assumed, I guess in some ways that the size of the pipe of work was going to remain the same. There's just going to be more people coming through each of those pipes. But instead now in places whereA git push was, generally a certain size for example, is now, no longer true.Swyx [00:55:03]: Oh, yeah.Kyle [00:55:03]: OrSwyx [00:55:05]: I push a thousandKyle [00:55:06]: On the average. 100%Swyx [00:55:06]: A thousand line commits like dailyKyle [00:55:07]: Same thing with PRs. Like PRs same thing. And like we've talked about optimizing that and making changes where, and there were technology choices that did not work there? And it got slow, and it didn't It was not fast. It did not do what the users wanted. And so we've been reeling that all out and going “Okay, that's just not right. Let's stop putting good money after bad and do it the do it the right way or the right way now.” So there's It's a it's a lot of things, not quite when I've experienced scale at GitHub historically, it's almost always two options that we've used. We go vertical scaling, particularly with databases, right? And we go horizontal scaling. Oh, we just have more people using this service. Great. We're going to add more servers, and we rack them in our data center, or we use it in a cloud. And now we're sort of in a like diagonal, where like vertical doesn't really work anymore. Horizontal isn't work either because we're all We all have some CPU or GPU constraints in the world now, and now we have to go in and like crack open services that have been running for 10 or 15 years and go, “Okay, the rules of this service have legitimately changed, and now we have to rewrite them.” None of this is an excuse. This is like we're We have to do the work. We have to make it better.Swyx [00:56:22]: actually as an infra guy, I'm “This is like one of the most fascinating scaling challenges I've ever seen.”Kyle [00:56:26]: That's that's, that's the thing that's the thing that it's hard for Like when we weren't talking about it publicly, and I was like I came out, and I was “Hey, I just want to explain what's going on.” Part of it comes from a very old GitHub ethos, which is it's our it's our uptime. It's down. W What I know you're a developer, so you're, you're inclined to want to understand more what's going on. But at the same time us going “Hey, this service didn't, perform the way we expected, and now we have to go change it,” we weren't We're not trying to hide anything from you i

Aaron is joined this week by Jesse Hanley, founder of Bento, to talk about building a seven figure business, why he feels less stress now than he did when he started, migrating from Heroku to Planetscale, and more.Sponsored by InterNACHI, Honeybadger, Bento, Vask, and NativePHP UltraInterested in sponsoring Mostly Technical?  Head to https://mostlytechnical.com/sponsor to learn more.Going to Laracon?  Sign up for the Mostly Technical Pre-Party!(00:00) - 5 TB of Data (11:12) - Laravel Live Japan (15:46) - Seven Figure Business (24:32) - Advice for Indie Hackers (28:57) - Pick Better Problems (32:50) - Friends of Bento (42:33) - Heroku to Planetscale (01:15:02) - What's Next Links:Jesse HanleySpeedshopJesse's Database School episodeTatamiDragonflyRedisShakeLaravel Live JapanDaniel Coulbourne

Your database is slow, your Sentry is screaming, and the backlog is full of “we'll fix it later.” What if an AI agent handled the boring but high-impact work while you slept and just opened a clean pull request for review the next morning?We're joined by Mike Coutermarsh, a software engineer who helped build GitHub Actions and later left GitHub for PlanetScale. We talk candidly about the trade-offs: walking away from big-company comfort, choosing impact over feeling like a cog, and learning to thrive in a flatter org where the best “process” is ownership. Mike shares how he leads the team responsible for everything users see at PlanetScale, from dashboards to APIs to CLIs, and why speeding up CI, reducing bugs, and protecting reliability can matter more than chasing the flashiest feature.Then we get practical about AI coding tools. Mike breaks down how Cursor, Claude Code, and MCP servers can connect production query patterns and Sentry errors to scoped “bot army” automations that propose fixes, optimize performance, and even keep error queues from becoming a garbage fire. We also dig into AI code review, responsibility (“if your name is on the commit, you own it”), and the uncomfortable question of whether code quality still matters when models can generate code fast. Along the way we touch token costs, local models, and why conventions like Rails can actually help AI work better.On the database side, Mike explains why PlanetScale started with MySQL via Vitess, how sharding changes operations like backups and restores, why Postgres demand forced a new product push, and what it could mean to bring Vitess-style scaling to Postgres. We wrap with a small but surprisingly powerful workflow upgrade: fast dictation using Spokenly and local speech-to-text.Subscribe, share this with a teammate who lives in dashboards and PRs, and leave a review with the one workflow you'd want an AI agent to automate next.Send us some love.JudoscaleAutoscaling that actually works. Take control of your cloud hosting. HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

This week's a non-AI episode!It's been a minute since we last discussed Bun, but the team is back with a new release. In v1.3.10, the REPL's completely rewritten in Zig, barrel imports are optimized, and the JavaScriptCore engine got upgraded for big perf gains.Npmx, a fast, modern browser for the npm registry has reached alpha version in less than 2 months of existence. Its goal is to make it easy for devs to find, evaluate, and manage npm packages, and boasts cool features like the ability to compare packages and even launch demo environments directly from package READMEs. Solid 2.0.0 jumped straight from experimental to beta this week, and it introduces changes like: async is first-class, derived state is a primitive, dev guardrails to prevent foot guns, and a DOM cleanup model.Timestamps:2:04 - Bun v1.3.108:39 - npmx13:03 - Solid 2.0 beta22:42 - PlanetScale bought Drizzle ORM23:46 - Safari is getting customizable s27:26 - Fire starter30:15 - What's making us happyNews:Paige - npmxJack - Solid 2.0 betaTJ - Bun v1.3.10Lightning News: Safari is getting customizable sPlanetScale bought Drizzle ORMFire Starter:Navigation API is baseline availableWhat Makes Us Happy this Week:Paige - Kytin Parasole shoesJack - ImmichTJ - Stratechery's coverage of the Anthropic v. DoW sagaThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or talk to us on X, Bluesky, or YouTube.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fireFollow us on Bluesky @front-end-fire.comSubscribe to our YouTube channel @Front-EndFirePodcast

For memberships: join this channel as a member here:https://www.youtube.com/channel/UC_mGuY4g0mggeUGM6V1osdA/joinExploring Cloud Databases, Scalability, and Simple Engineering with Sam Lambert, CEO of PlanetScaleIn this episode of The Geek Narrator podcast, we welcome Sam Lambert, CEO and Co-Founder of PlanetScale, known for creating the world's fastest and most scalable cloud database. Sam shares his insights on databases, operational excellence, and simple engineering. We discuss topics such as scalability, Postgres versus MySQL, and replication. Sam also talks about handling complexity in engineering, the unique features of Vites, and how PlanetScale achieves high availability. Don't miss this deep dive into the future of cloud databases. Like, share, and subscribe to support the channel!Chapters:00:00 Introduction and Episode Overview01:13 Meet Sam Lambert: Background and Career02:42 Balancing Work and Social Media05:48 The Philosophy of Simple Engineering14:21 The Slotted Counter Pattern at GitHub18:27 Postgres vs MySQL: Design Flaws and Philosophical Differences28:58 Sharding and Scaling with Vitess37:01 Database Branching and Schema Changes38:50 Common Practices in Startups39:07 Challenges with Data Branching40:45 Legal and Ethical Considerations42:31 Staging Environments vs. Dev Branches45:26 Trade-offs in Cloud Databases52:41 Replication and Durability01:00:02 Ensuring High Availability01:08:04 Backup Strategies and Testing01:10:41 Conclusion and Final ThoughtsLearn about PlanetScale: https://planetscale.com/For memberships: join this channel as a member here:https://www.youtube.com/channel/UC_mGuY4g0mggeUGM6V1osdA/joinDon't forget to like, share, and subscribe for more insights!=============================================================================Like building stuff? Try out CodeCrafters and build amazing real world systems like Redis, Kafka, Sqlite. Use the link below to signup and get 40% off on paid subscription.https://app.codecrafters.io/join?via=geeknarrator=============================================================================Database internals series: https://youtu.be/yV_Zp0Mi3xsPopular playlists:Realtime streaming systems: https://www.youtube.com/playlist?list=PLL7QpTxsA4se-mAKKoVOs3VcaP71X_LA-Software Engineering: https://www.youtube.com/playlist?list=PLL7QpTxsA4sf6By03bot5BhKoMgxDUU17Distributed systems and databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4sfLDUnjBJXJGFhhz94jDd_dModern databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4scSeZAsCUXijtnfW5ARlrsNStay Curios! Keep Learning!

Ben Dicken is a developer educator at PlanetScale, he's an incredible writer and teacher, who's made some amazing technical articles that developers actually love reading. We get into his reasons for working so hard on these articles, his process, and how he makes content that genuinely helps engineers understand complex ideas.This episode is brought to you by WorkOS. If you're thinking about selling to enterprise customers, WorkOS can help you add enterprise features like Single Sign On and audit logs.Links:   •  Ben's X   •  B-trees and database indexes article   •  IO devices and latency article

Ian and Aaron talk about PlanetScale, launching Aaron's new YouTube channels, traction tables that will change your life, and so much more.Sponsored by: Bento, Bifrost for NativePHP, and HoneybadgerInterested in sponsoring Mostly Technical?  Head to https://mostlytechnical.com/sponsor to learn more.(00:00) - Aaron Wanted It All (05:39) - YouTube Channel Launch (17:17) - Production Snafus (27:16) - Recreate The Magic (30:40) - Revamping MySQL for Developers (38:50) - Subscription Pricing (41:02) - Gotta Dream Big (50:55) - Traction Table Time Links:The future of this channel (Aaron's YouTube)Aaron's interview with PlanetScale CEO Sam LambertMySQL for DevelopersAaron's Traction Table

Sam Lambert, my former boss at PlanetScale, talks to me about PlanetScale moving from a MySQL company to now also having a Postgres offering. Sam shares why PlanetScale decided to move to Postgres, how MySQL and Postgres are different at a technical level, and how the change has impacted the company culture. Stay to the end for a special surprise!PlanetScale Metal Episode: https://youtu.be/3r9PsVwGkg4Join the waitlist to be notified of the MySQL for Developers release on Database School: https://databaseschool.com/mysqlFollow Sam: PlanetScale: https://planetscale.comTwitter: https://twitter.com/isamlambertFollow Aaron:Twitter:  https://twitter.com/aarondfrancis LinkedIn: https://www.linkedin.com/in/aarondfrancisWebsite: https://aaronfrancis.com - find articles, podcasts, courses, and more.Database School: https://databaseschool.comDatabase School YouTube Channel: https://www.youtube.com/@UCT3XN4RtcFhmrWl8tf_o49g (Subscribe today)Chapters:00:00 - Inaugural episode on this channel01:46 - Introducing Sam Lambert and his background03:04 - How PlanetScale built on MySQL and Vitess06:10 - Explaining the layers of PlanetScale's architecture09:57 - Node lifecycles, failover, and operational discipline12:02 - How Vitess makes sharding work14:21 - PlanetScale's edge network and resharding19:02 - Why downtime is unacceptable at scale20:04 - From Metal to Postgres: the decision process23:06 - Why Postgres vibes matter for startups27:04 - How PlanetScale adapted its stack for Postgres34:38 - Entering the Postgres ecosystem and extensions41:02 - Permissions, security, and reliability trade-offs45:04 - Building Ni: a Vitess-style system for Postgres53:33 - Why PlanetScale insists on control for reliability1:02:05 - Competing in the broader Postgres landscape1:08:33 - Why PlanetScale stays “just a database”1:12:33 - What GA means for Postgres at PlanetScale1:17:43 - Call to action for new Postgres users1:18:49 - Surprise!1:22:21 - Wrap-up and where to find Sam

Brian Scanlan, Senior Principal Engineer at Intercom, the company building Fin.ai, joins Corey Quinn on Screaming in the Cloud to discuss Intercom's move from AWS Aurora to PlanetScale's managed Vitess after years of scaling challenges with their Ruby on Rails monolith. He explains how 13 Aurora clusters created operational pain and why PlanetScale's white-glove, partnership-driven model won out over Amazon's building-block approach.The discussion also covers Intercom's volunteer-based on-call system, their pivot to AI agents after ChatGPT's launch, concerns about the shrinking pipeline of systems engineers, and how companies like PlanetScale and Snowflake are outpacing AWS by delivering superior user experiences.About Brian: Brian is an engineer based in Intercom's Dublin office. He fixes problems, builds things, and grows people. Show Highlights(01:34) The Digital Clippy Rant(2:16) The Good Chatbot vs. Bad Chatbot (03:51) The AI Chatbot Revolution (04:33) Unexpected Consequences of Good Chatbots (05:42) AI Support vs. Human Support (05:59) The Alexa Problem and Feature Discoverability (19:03) Amazon's Struggles Moving Up the Stack (26:55) The Unix Networking Society Origins (34:43) The Global On-Call Challenge(42:09) LinkedIn: The World's Largest Porn Site LinksIntercom: intercom.comBrian on LinkedIn: https://www.linkedin.com/in/scanlanb/Brian on Bluesky: https://bsky.app/profile/bscanlan.bsky.socialSponsor Wiz - Listen to Crying Out Cloud: wiz.io/crying-out-cloud

In this episode, Chris and Andrew discuss the recent release of Rails 8 and the improvements in upgrading processes compared to previous versions. They dive into specific technical challenges, such as handling open redirects and integrating configuration options, and chat about Chris's recent experience with Tailwind's new Elements library, Bundler updates, and JSON gem changes.  They also touch on Heroku's evolving infrastructure and the potential benefits of using PlanetScale's new Postgres offerings. The episode concludes with a discussion about life without internet and Andrew's countdown to his upcoming sabbatical.  Hit download now! LinksJudoscale- Remote Ruby listener giftRails World 2025Tailwind Plus- ElementsInvoker Commands APIByroot's Blog post-What's wrong with JSON gem API?PlanetScaleHetznerHoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.JudoscaleMake your deployments bulletproof with autoscaling that just works.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Chris Oliver X/Twitter Andrew Mason X/Twitter Jason Charnes X/Twitter

Sam Lambert is the CEO of PlanetScale - a cloud database provider.Sam shares:- Why dropping the free tier was one of PlanetScale's best decisions. But is not for every startup.- People solving serious problems appreciate serious content and if you can create meaningful content, that's a big advantage.- CEOs should be transparent and collaborative but assertive. Don't let your company die while enacting someone else's decision - Express hard-to-convey-benefits via your customers' experiencesThis episode is brought to you by WorkOS. If you're thinking about selling to enterprise customers, WorkOS can help you add enterprise features like Single Sign On and audit logs. Links:- Sam's Twitter- Sam's LinkedIn - PlanetScale - PlanetScale Postgres - Caching blog post - Ted Nyman - Snowflake - Vitess 

Sam Lambert, the CEO of PlanetScale, joins Dax for a candid discussion about the remarkable journey of launching the Postgres product and scaling the company's success. Discover how PlanetScale is on track to achieve a million dollars in ARR for their Postgres product, delve into the technical nuances of their groundbreaking infrastructure, and learn why PlanetScale is considered a reliable alternative to Amazon Aurora for large-scale database solutions. Sam shares his experiences and insights on navigating startup challenges, maintaining focus amidst tempting opportunities, and fostering a culture that thrives on innovation and reliability. Links:Announcing PlanetScale for Postgres – PlanetScaleThe principles of extreme fault tolerance – PlanetScaleSam Lambert (@isamlambert) / XDeath wrestling with ogresWhopKickCursor - The AI Code EditorConvex | The reactive database for app developersFigmaSponsor: Terminal now offers a monthly box called Cron.Want to carry on the conversation? Join us in Discord. Or send us an email at sliceoffalittlepieceofbacon@tomorrow.fm.Topics:(00:30) - Airline travel advice with a baby (02:32) - What was it like launching PlanetScale for Postgres? (08:00) - What was reused and what was new? (12:08) - Is the sharding from scratch? (17:27) - Is PlanetScale the main alternative to Aurora? (19:33) - Is there a link between Postgres and AI companies? (24:57) - What is your goal for PlanetScale? (27:13) - The joy of seeing other products running on your platform (30:00) - Is vibe coding worth paying attention on a services side? (45:39) - The regret of not enjoying what we get to do (49:09) - Intertwinning making money with running a business (53:24) - Playing the long game and avoiding temptations (58:49) - Remembering the era of database experimentation ★ Support this podcast ★

Today, Sam Lambert from Planetscale is back for a third time. Planetscale just announced Planetscale Postgres, so we had to get Sam back to tell us how and why they decided to add support for Postgres. It's always great to have Sam on -- he brings great stories about real customers and honest insight about the state of the database industry. In this episode, we talk about the road to Postgres and how operational excellence is the only true advantage in database providers. Sam walks us through the current Planetscale Postgres offering, along with details on Nova, a new sharded Postgres project that Planetscale is working on. Along the way, we get updates on Planetscale Metal, how demand has been for Planetscale Postgres, and future plans for Planetscale.

Justin Searls describes the "full-breadth developer" and why they'll win because AI, Cloudflare comes up with a way publishers can charge crawlers for access, Hugo Bowne-Anderson explains why building AI agents fails so often, the Job Worth Calculator tells you if your job is worth the grind, and Sam Lambert announces PlanetScale for Postgres.

Justin Searls describes the "full-breadth developer" and why they'll win because AI, Cloudflare comes up with a way publishers can charge crawlers for access, Hugo Bowne-Anderson explains why building AI agents fails so often, the Job Worth Calculator tells you if your job is worth the grind, and Sam Lambert announces PlanetScale for Postgres.

Justin Searls describes the "full-breadth developer" and why they'll win because AI, Cloudflare comes up with a way publishers can charge crawlers for access, Hugo Bowne-Anderson explains why building AI agents fails so often, the Job Worth Calculator tells you if your job is worth the grind, and Sam Lambert announces PlanetScale for Postgres.

In this episode, Matt and Mike dive into developer experience (DX) — what it is, why it matters, and how improving it can make you a better developer. They share personal stories of frustrating build processes, game-changing tools, and scripting away pain points. Whether it's speeding up deployments, eliminating unnecessary rebuilds, or embracing platforms like Vercel and PlanetScale, there's never been a better time to take your DX into your own hands. Show Notes: https://www.htmlallthethings.com/podcasts/why-developer-experience-matters Use our affiliate link (https://scrimba.com/?via=htmlallthethings) for a 20% discount!! Full details in show notes.

Sam Lambert returns to chat about the launch of PlanetScale Metal, the importance of looking past averages, constraints of working with Amazon, how building good software is like building an airline, thoughts on the standard software dev playbooks, advice for younger developers, and reflections on killing the free tier at PlanetScale.Links:Sam LambertMetal — PlanetScalePlanetScale DesignSponsor: Terminal now offers a monthly box called Cron.Want to carry on the conversation? Join us in Discord. Or send us an email at sliceoffalittlepieceofbacon@tomorrow.fm.Topics:(00:00) - The fun of building with paranoia (00:39) - The party (03:20) - How was the launch of PlanetScale Metal? (09:34) - How is Planetscale Metal different? (14:32) - The importance of looking beyond the averages (20:46) - Constraints of working within Amazon (27:48) - How do you know that a random bug won't bring everything down? (33:08) - Building good software is like building an airline (34:47) - PlanetScale changes one year later (40:41) - Is there a standard playbook for selling software you follow? (48:29) - Hype ruins so much software (01:01:30) - I have no advice to give to younger developers (01:08:09) - How do you reflect on killing the free tier? (01:18:30) - Playing the long game instead of listening to tech Twitter ★ Support this podcast ★

Today, we have Sam Lambert back on the show! Sam is the CEO of PlanetScale, and if you follow him on X, you know he's one of the sharpest voices in the database space—cutting through the hype with deep experience and a no-nonsense approach. In this episode, we dive into PlanetScale's new Metal offering, which has been battle-tested with PlanetScale's high-scale cloud business partners and is now GA. Sam also shares why staying profitable is crucial—not just for the business but for the stability and reliability it guarantees for customers. While many cloud infrastructure companies chase the next hype cycle, Sam prefers to keep it boring—delivering rock-solid performance with no surprises Finally, we close with Sam's thoughts on other happenings in the database space -- Aurora DSQL, Aurora Limitless, MySQL benchmarks, and multi-region strong consistency. Tune in for a deep dive into databases, cloud infrastructure, and what it takes to build a sustainable, high-performance tech company. Timestamps 01:34 Start 06:42 PlanetScale Metal 11:15 The problem with separation of storage and compute 15:02 EBS Tax 17:32 How does Vitess handle durability 22:58 Metal recommended for all PlanetScale users? 27:20 The hidden expense of IOPS for cloud databases 37:41 Timeline of creating PlanetScale Metal 41:32 Focus on profitability 47:52 Removal of hobby plan 57:45 Deprecation of PlanetScale Boost 01:00:24 DSQL 01:01:51 Aurora Limitless 01:04:15 AWS as a partner 01:07:00 The spectacle of AWS re:Invent 01:12:22 Benchmarks and benchmarketing 01:15:51 AWS Databases + multi-region strong consistency

Sam Lambert stops by to talk Unifi networking, cooking meat, microplastics, disease research, the history of the world, scaling at PlanetScale, and why people love PostGres.Want to carry on the conversation? Join us in Discord.The ultimate MySQL database platform — PlanetScaleUniFi - Introduction - UbiquitiNest Wifi Pro CoverageAztec EmpireBuddhas of BamiyanModern PostgreSQL BookTopics:(00:00) - Computers will always let you down (00:27) - Falling asleep to self driving Tesla chats (02:17) - Using Unifi networking gear (12:02) - Cooking meat (18:24) - Why are microplastics everywhere? (22:55) - Ordering diseases and cells for research from a JC Penny Catalogue (30:25) - American history with Adam and Dax (34:26) - South American history with Dax (38:24) - Could all the data get wiped out and we lose everything? (54:52) - Scaling and PlanetScale (01:08:48) - Why do people love PostGres?

Databases underpin almost every user experience on the web, but scaling a database is one of the most fundamental infrastructure challenges in software development. PlanetScale offers a MySQL platform that is managed and highly scaleable. Sam Lambert is the CEO of PlanetScale and he joins the show to talk about why he started the platform, The post Hyperscaling SQL with Sam Lambert appeared first on Software Engineering Daily.

Databases underpin almost every user experience on the web, but scaling a database is one of the most fundamental infrastructure challenges in software development. PlanetScale offers a MySQL platform that is managed and highly scaleable. Sam Lambert is the CEO of PlanetScale and he joins the show to talk about why he started the platform, The post Hyperscaling SQL with Sam Lambert appeared first on Software Engineering Daily.

In this episode of the Business of Laravel podcast, host Matt Stauffer interviews Aaron Francis, co-founder of Try Hard Studios, beloved Internet personality, Laravel developer, and all-around Internet nice guy. Aaron shares his journey from his days at a property tax company to his bold leap into entrepreneurship, sharing insights into his evolution every step of the way. He discusses moving beyond the "hustle era" to what he terms the "Try Hard era," emphasizing the importance of concerted effort and determination in achieving success. Tune in to learn about Aaron's background, his passion for creating educational content, and the exciting ventures he's currently pursuing in the world of Laravel development.Matt Stauffer Twitter - Matt Stauffer (@stauffermatt) on XTighten Website - Tighten | Software Development for Web + Mobile | Laravel + Vue.jsAaron Francis Twitter - @‌aarondfrancisAaron Francis Website - aaronfrancis.comTry Hard Studios - tryhardstudios.comRadical Candor - https://www.radicalcandor.com/37 Signals - https://37signals.com/books/Brené Brown - https://brenebrown.com/-----Editing and transcription sponsored by Tighten.

A brief list of topics discussed in this brief episode: New Jersey follow up from last episode, PlanetScale layoffs and performative twitter responses, free tiers aren't going to last forever, the Devin AI demo, Astro's file format choices, Adam has no thoughts about capitalism, does online bitterness extend to real life, why aren't more of us using Cameo for shit posting, Adam needs more movies to watch, and Dax learns about Adam's LOTR obsession.Want to carry on the conversation? Join us in Discord.Aaron Francis (@aarondfrancis) / XHow About Tomorrow?Devin: AI EngineerCopilotAI Pair ProgrammerGPT Prompt PluginCursor Code EditorHomeI Am LegendI Am Legend 2007 Francis LawrenceFavorite Stars PersonalizedEx Machina Film ReviewOscar Best Picture Winners by NayanThe Wolf of Wall StreetKillers of the Flower MoonNolan's FilmsScorsese's FilmsQuentin Tarantino FilmsThere Will Be BloodNo Country for Old Men Film ReviewDune 2021 Film ReviewsDune: Part TwoGuillermo del Toro FilmsThe Fellowship of the RingIan Mckellen Hobbit BreakdownKing Kong 2005 Peter JacksonMulan TrailerMarley & Me Film ReviewsPlanetScale performs layoff and prioritizes profitabilityTopics:(00:00) - Adam leaves special messages for you on YouTube (00:37) - New Jersey slander on Twitter (06:00) - PlanetScale layoffs (14:37) - Performative Twitter and the stupidity of responses (21:14) - The free tier system (29:22) - Weird noises in the yard (31:52) - The Devin demo (41:07) - Astro choosing their own file format (45:01) - Adam doesn't think about capitalism (51:44) - Does online bitterness extend to real life? (57:58) - Is the future going to be cleaner or messier? (01:04:16) - Why is Twitter the best developer community? (01:05:20) - Cameo as an underutilized service for shitposting (01:09:10) - What movies should Adam watch? (01:17:08) - Miami plans (01:34:52) - Adam sold a domain

Look we all know there are things to talk about but we recorded this last week before any of that stuff happened!

Ian & Aaron discuss being laid off, what comes next for Aaron, why layoffs always go bad, good free tiers vs. bad free tiers, & more.Sponsored by LaraJobs & Screencasting.com.Sent questions or feedback to mostlytechnicalpodcast@gmail.com.(00:00) - We Don't Have Bosses (06:51) - Dune Part 2 Side Tangent (14:19) - The Main Character (26:13) - These Things Always Go Bad (32:44) - Free Tiers (42:50) - Have You Heard About Cloudflare? (48:32) - Thoughts on Content Marketing (56:34) - Face of the Organization (01:01:48) - The Future (01:15:18) - The Future, Continued (01:27:31) - I'm Hot & Rich Now! (01:34:14) - Aaron Francis Studio of Light & Sound (01:37:33) - Follow Up & An Interesting Idea Links:"...@ianlandsman, who is a gifted takesman" (on Twitter)Aaron got laid offAaron Francis Studio of Light and SoundAlamo DrafthouseStudio Movie GrillAaron's tweet about seeing Dune 2PlanetScale forever (blog post)PlanetScale's schema recommendationsLaracon US - tickets still available!Primeagen's breakdown of the PlanetScale layoffs (on YouTube)The Ramsey ShowCar TalkMike and the Mad DogAaron's tweet about a call in radio show 

2024 is the year of business accountability across all aspects of the software industry. This means that all variations of the free tier are going away in one way or another. SHOW: 802CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendSHOW NOTES:Linkerd changes publishing model of imagesPlanetScale discontinues Free Tier (“Hobby”) of serviceWHY DID THE FREE TIER(S) EXIST IN THE FIRST PLACE?Why do free tiers exist? Marketing awareness, experimentation, Why is talking about making money, or profitability considered taboo?Why do we reconcile the love of employees and the hatred of paying for software?WHAT ARE THE TRADE-OFFS WHEN THE FREE TIER GOES AWAY?Are free tiers and free open source software the same thing?Are “wants” and “value” the same thing? What should be free in the software world? Should end-users want the backers of a project or company to be successful?Will VCs continue to back companies that have free tiers, or companies that spend on marketing, or is the game needing new (undefined) rules? FEEDBACK?Email: show at the cloudcast dot netTwitter: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

The SM7B is everywhere. Adam and Dax can't wait for their AI coworkers to arrive, but should you be concerned about your job with AI? And what does E/ACC mean? Adam asks Dax about his tweets and rules for Twitter. And the US healthcare system is broken with no fix in sight.Want to carry on the conversation? Join us in Discord.SM7B - Vocal Microphone - Shure USAPerplexityDax on X: “you've all had co2 monitors for over a month now and i haven't seen an improvement”Query Insights — PlanetScale DocumentationIntroducing the Data API for Amazon Aurora Serverless v2 and Amazon Aurora provisioned clusters | AWS Database BlogAI description of this episode.(00:00) - Do it at the beginning (00:29) - Mics and mic technique (05:32) - AI developer coworkers (18:09) - What does the best programming language look like in the future? (24:39) - Are we too optimistic about AI's future? (29:28) - AI is great for cleaning up data (33:17) - You don't have to be human with AI (38:16) - What does E/ACC mean? (40:39) - The White House says we should write Rust (42:07) - Adam asks Dax about his tweets (44:00) - Dax's Twitter avatar rule (46:24) - What's PlanetScale Insights? (53:18) - The state of health care in America (01:02:13) - Interest rates going down - or up? (01:03:39) - Meta ask: leave us a rating please! (01:08:03) - Would you get Neuralink?

Michael and Nikolay are joined by Andrew Atkinson, author of High Performance PostgreSQL for Rails, to discuss how Rails and Postgres work together — where the limits are, how people use the ORM, things that are improving, and some things we can do as a Postgres community to make it even better. Here are some links to things they mentioned:Planet Argon survey https://rails-hosting.com/2022/#databasesActive Record https://guides.rubyonrails.org/active_record_basics.htmlPostgreSQL specific usage of Active Record https://guides.rubyonrails.org/active_record_postgresql.htmlMultiple Databases with Active Record https://guides.rubyonrails.org/active_record_multiple_databases.htmlschema.rb vs structure.sql https://blog.appsignal.com/2020/01/15/the-pros-and-cons-of-using-structure-sql-in-your-ruby-on-rails-application.htmlactiverecord-clean-db-structure (Ruby gem by Lukas Fittl) https://github.com/lfittl/activerecord-clean-db-structureGitLab's migration_helpers.rb https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/migration_helpers.rbSQLite https://www.sqlite.orgPlanetScale's foreign key support announcement video https://twitter.com/PlanetScale/status/1732070818958500083DoorDash Engineering Blog https://doordash.engineering/blograils-pg-extras https://github.com/pawurb/rails-pg-extrasBenoit Tigeot testing Peter Geoghegan improvement for large IN lists https://gist.github.com/benoittgt/ab72dc4cfedea2a0c6a5ee809d16e04dHigh Performance PostgreSQL for Rails (Andy's book, 35% discount code “postgres.fm”) https://pragprog.com/titles/aapsql/high-performance-postgresql-for-railsAndy's blog and website https://andyatkinson.com~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith special thanks to:Jessie Draws for the elephant artwork 

Come hang with us! Like what you hear? Connect with me - Website: gun.io/taylor Email: taylordesseyn@gun.io LinkedIn: Taylor Desseyn Tweet me: @tdesseyn Pics of the life, wife, daughter & dog: @tdesseyn

Danilo Campos, Proprietor of Antigravity, joins @quinnypig on Screaming in the Cloud to discuss his philosophy behind building tools that not only enhance developer experience but also improve the future of our world. Danilo shares his thoughts on how economic factors have influenced tech companies and their strategies for product, open source, and more. He also shares what he thinks is another, better way to approach these strategies, without ignoring the economic element. About DaniloDanilo Campos wants a world where technology makes us more powerful and expressive versions of ourselves. He worked with GitHub and the White House to deliver coding platforms to public housing residents, supported Glitch.com in its last days as an independent, and developed products for multiple early-stage startups, including Hipmunk. Today Danilo offers freelance developer experience services for devtools firms through Antigravity DX.Links Referenced: Antigravity DX: https://antigravitydx.com/ Blog: https://redeem-tomorrow.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: Welcome to Screaming in the Cloud. I'm Corey Quinn, and periodically on this show, we like to gaze into the future and tried to predict how that's going to play out. On this episode, I want to start off by instead looking into the past, more specifically my past. Before I started this place, I wound up working at a company called FutureAdvisor, which was a great startup for all of three months before we were bought by a BlackRock. I soon learned what a BlackRock actually was.While I was there, I encountered an awful lot of oral tradition around a guy named Danilo, and he—as it turned out—was a contractor who had been brought in to do a fair bit of mobile work. Meet my guest today, Danilo Campos, who is at present, the proprietor of a company called Antigravity DX. Thank you so much for joining me, I appreciate it.Danilo: Hey, Corey, it's good to be here.Corey: It's weird talking to you, just because you were someone that I knew by reputation, and if I were to take all the things that were laid at your feet after you no longer had been there, it feels like you were there for 20 years. What did you actually do there, and how long were you embedded for?Danilo: I loved the FutureAdvisor guys. I thought they were such a blast to work with. I loved what they were working on. I learned so much about how finance and investing works from FutureAdvisor, and somehow it was only seven months of my life. I'd been introduced to the founders as a freelance iOS developer at the time—this was 2014—and a guy I had worked with at Hipmunk actually put me in touch with these guys, and we connected. And they needed to get started doing mobile. They'd never done any mobile stuff, they didn't have anyone on staff who did mobile stuff.And by that point, I'd shipped I think, must have been half a dozen iOS native apps, and so I knew this stuff pretty well. I understood the workflows, I understood the path to getting from idea to shipped product, and they just wanted occasional help. How do we wireframe this? How do we plan the product that way? How do we structure this thing? And so, it started off as this just, kind of, occasional troubleshooting consulting thing.And I think about August 2014. They call me in for a meeting, they said, “Hey, we're stuck. We don't know how to get this thing off the ground. Could you help us get this project moving so that we actually ship it?” And so, I just came and embedded for seven months, and by the end of it, I was just running the entire iOS engineering team. We had a designer working with us. We had, I think it was four folks who were building the product. We had QA. It was a whole team to get this thing out the door. And we got it out the door after seven months of really working at it. And like I said, it was a blast. I love those folks.Corey: I have to be clear, when I say that I encountered a lot of what you had done. It was not negative. This was not one of those startups where there's a glorious tradition of assassinating the character out of everyone who has left the company—or at least Git repos—because they're not there to defend themselves anymore. There were times where decisions that you had made were highlighted as, “We needed to be doing things more like this.” There were times it was, “Oh, we can't do that because of how you wound up building this other thing.”And it was weird because it felt like you were the hand of some ancient deity, just moving things back and forth in your infinite wisdom of the ancients. It was unknowable, and we had to accept it as gospel, whether we liked it or not, at different times. In practice, I now know this was honestly just the outgrowth of a rapidly expanding culture where you've got to go from a team of five people to the team of 50 and keep everyone rowing in the same direction, ideally. But it was a really interesting social dynamic that I got to observe as a result, and I'm just tickled pink to be able to talk to you now. What are you doing these days?Danilo: Thank you for the context, by the way, because you know, I move on, as you do in a contract capacity, and you hope things work out.Corey: Yeah. To be clear, it was never a context of, “There's the bastard. Get him.” Like, that is not the perspective we are coming at this from at all.Danilo: Yeah, yeah, yeah. No, and it's hard because it was a very strange, alien codebase compared to the rest of the company. I get how it ended up in that spot. These days, I am a freelance developer experience consultant, and I spent a year-and-a-half at Glitch.com. And developer experience was always something that I really cared about. I did some work at GitHub that was about getting people—specifically teenagers living in public housing—into computing and the internet, and I'd had to do a bunch of DX work to make that happen because I had an afternoon to get people from zero to writing code.And that is not a straightforward situation, especially in a low-income housing environment, for example, right? So, I cared about this stuff a lot. And then I spent a year-and-a-half at Glitch.com, and it was like getting a graduate degree on everything about the leverage for creating outcomes in developer tools. And I just, I felt like I was carrying some gift from the Gods. I just, I felt the need to get this out to the wider world, and so that's what I do with Antigravity.Corey: When I got to catch up with you in person for the first time at the excellent and highly recommended Monktoberfest conference—Danilo: Excellent.Corey: —that the folks over at RedMonk put on every year, it was interesting, in that you and I got to talking very rapidly, not about technology as such, but about culture and the industry and values and the rest. It was a wonderfully refreshing conversation that I don't normally get to have so soon after meeting someone. I think that one of the more interesting aspects of our relatively wide-ranging conversation in a surprisingly brief period of time focused, first off, among the idea of developer tools and what so many of them seem to get wrong. I know that we basically dove into discussing about our violently agreeing opinions around the state of developer experience, for example. What are the hills you're willing to die on in that space?Danilo: I think that computing generally exists to amplify and multiply our power. Computing exists to let us do things that we could not do with the simple, frail flesh that we're born with, right? Computers augment our ambitions because they can do things with infinite iteration. And so, if you can come up with something that you can bottle in the form of an algorithm that repeats infinitely, you can have incredible impact on the world. And so, I think that there's a responsibility to find ways to make that power something that is easy to hand to other people and let them pick up and run with.And so, developer tools, to me, has this almost sacred connotation because what you're doing is handing people the fire of the Gods and saying, “Whatever you can come up with, whatever your imagination allows you to do with these tools, they can repeat infinitely and make whatever change you want—for good or for ill—in the world.” And that's very special to me. I think we've gotten bored of it because it's just, you know, it's a 50-year-old business at this point. But I think there's still a lot of magic to it, and the more we see the magic, the more magical outcomes we can coax out of everyday people who become better developers.Corey: From my perspective, one of the reasons I care so much about developer experience is that the failure mode of getting it wrong means that the person trying to understand the monstrosity you've built feels like they're somehow not smart, or they're just not getting it in some key and fundamental way. And that's not true. It's that you, for whatever reason, what you have built is not easily understandable to them where they are. I go back to what I first heard in 2012, at a talk that Logstash creator, Jordan Sissel wound up saying, where his entire thesis was that if a user has a bad time, it's a bug.Danilo: Yeah.Corey: And I thought that that was just a wonderfully prescient statement that I wanted to sign onto wholeheartedly. [That was 00:09:08] my first exposure to it. I know that's not the entirety of developer experience by a long shot, but it's the one where I think you lose the most mind share when you get it wrong.Danilo: Well, and I'm glad that you bring that up because I think that kind of defines the spectrum of the emotional experience of interacting with developer tools. On one end of the spectrum, you've got, “I feel so stupid. This has made me feel worse about myself. This has given me less of a sense of confidence in myself than I had when I started.” And at the other end of the spectrum, the other extreme is, “I cannot believe I am this cool. I cannot believe that my imagination has been made manifest in this way that now exists in the world and can go out and touch other people and make their lives better.”Those are the two, kind of, extremes of the subjective emotional experience that can come from developer tools. And so, I think that there is a business imperative that really pushes us toward the extreme of making people feel awesome. I think about this in the context of Iron Man, you've seen Iron Man, yeah.Corey: Oh, yes.Danilo: All right. So, the Iron Man suit is the perfect metaphor for a developer tool that is working correctly for you, right? Because on its own, the suit is not very interesting, and on his own, Tony Stark is not all that powerful, but you combine the suit and the person, and suddenly extraordinary emergent outcomes come out. The ambition of the human is amplified, and he feels so [BLEEP] cool. And I think that's what we're looking to do with developer tools is that we want to take a person, amplify their range, give them a range of motion that lets them soar into the clouds and do whatever they need to do up there so that when they come back down, they feel transformed. They feel like more than what they started.Corey: I would agree with that. There's a sense of whimsy and wonder as I look through my career trajectory, going from a sysadmin role, where you there was a pretty constant and hard to beat ratio in most shops—and the ratio [unintelligible 00:11:29] varied—but number of admins to the number of servers. And now with the magic of cloud being what it is, it's a, “Well, how many admins does it take to run X number of servers?” Like, “Well, as an [admin done 00:11:39] right, I can manage all of them because that's how programming languages work.” And that is a mystical and powerful thing.But lately, it seems like there's been some weird changes in the world of developer tooling. Cynically, I've said a couple of times that giving a toss about the developer experience was in fact a zero interest rate phenomenon. Like, when you're basically having to fend off casual offers of 400 grand a year from big tech, how do you hire and retain people at a company that has one of those old, tiny profit-generating business models and compete with them? And a lot of times, developer experience was part of how you did that. I don't know that I necessarily believe that that is as tied to that cynical worldview as I might pretend on the internet, but I don't know—I do wonder if it's a factor because it seems like we've seen a definite change in the way that developer tools are approaching their community of users and customers.Danilo: Well, my immediate reflex is to open up the kind of systems theory box and look at what's inside of that. Because I think that what we are experiencing, if we use the interest rate lens, is a period of time where everyone is a little bit worried that the good times are over for good. And I feel the sense of this in a lot of places. I think developer experience is a pretty good avatar to try this on with because I definitely also perceive it in that sphere.During the heyday of 0% interest rates, everything was about how much totalizing growth can you achieve? And from a developer tools perspective, all right, well, we need to make it so that the tools, kind of, grow themselves, so let's invest a lot in developer experience so that people very quickly get onboarded, without us having to hold their hand, without us having to conduct a sales call, let's get them to the point where they can quickly understand—because the documentation is so good and the artifacts are so good—exactly how to use these tools to maximum effect. Let's get them to a point where it's very easy for them to share the results of their work so that other people see the party and really want to join in. And so, all kinds of effort and energy and capital was being invested in this kind of growth strategy.And now I think that people are, again, a little bit afraid that the good times are over, and so we see this really sales-driven culture of growth, where it's like, all right, well, for this company to succeed, we have to really make sure that we're going and closing these big sales, and if individual developers can't figure out how the hell this works, well, that's their problem, and we're not going to worry about it. And we've talked about this: this fear of the good times being over drives people, I think, to all kinds of bad behavior. The rug-pulling that we've seen in open-source licensing where somebody's like, “All right, I've taken a bunch from this community, and now I'm going to keep it, and I'm not going to give anything back.” This is the behavior of people who are afraid that the good times are behind them. I don't have the luxury of being that pessimistic about the future, and I don't think our industry can afford it either.[midroll 00:15:03]Corey: The rules changing late in the game is something that has always upset me. It feels inherently unfair, and it's weird because you can have these companies say that, “Look, we've never done anything like that. Why wouldn't you trust us?” Right up until the point where they do. Reddit is a great example, where for years, they had a great API—ish—that could do things that their crap-ass mobile client natively couldn't. And Apollo was how I interacted with Reddit constantly. I was a huge Reddit user. I was simultaneously, at one point, moderator of the legal advice subreddit and the personal finance subreddit. I was passionate about that stuff, and it was great.And then they wound up effectively killing all third-party clients that don't bend the knee, and well, why am I going to spend my time donating content and energy and time to a for-profit company that gets very jealous when other people find ways to leverage their platform in ways that they don't personally find themselves able to do. Screw ‘em. I haven't been back on Reddit since. It's just a, “Fool me once, shame on me story.” Twitter did the exact same thing. I built a threading Twitter client simultaneously deployed to 20 AWS regions, until they decided they didn't want people creating content through their APIs and killed the whole thing with no notice. Great. Now, they're—I got an email asking me to come back. Go to hell. I tried that once. You've eviscerated people's businesses and the rest.And you see it with licensed changes as well. But it all comes down to the same thing, from my perspective, which is an after-the-fact changing of the rules. And by moving the goalposts like that, I wonder what guarantees a startup or a project that doesn't intend to do those things can offer to its community. Because, look, HashiCorp made its decision to change the licensing for Terraform. Good for them. They're entitled to do that. I'm not suggesting, in any way shape or form, that they have violated any legal term.And I don't even know they're necessarily doing anything that doesn't make sense from their point of view. And the only people I really see that upset about it are licensing purists—which I no longer am for a variety of reasons—people who work at HashiCorp, obviously, and their direct competitors who are not sympathetic in that particular place. But as a counterpoint, if they wind up building a new open-source project, of course, I'm not going to contribute. I mean, that's a decision I get to make. And I don't know how you square that circle because otherwise, if that continues, no one will be able to have a sense of safety around contributing to anything open-source unless they're pleased to wind up doing volunteer work for a one-day unicorn.Danilo: So, I really appreciate the economical survey of the landscape that you just provided because I think that captures it really well. The Reddit case in particular breaks my heart. I will go to my grave absolutely loving Steve Huffman. Steve Huffman gave me my first break as a paid developer and product designer, and he was an enormous pain in the ass to work with, and I loved every minute of it. Like, he's just an interesting, if volatile, character.And I see that volatility playing out with Red Hat in the incredible hostility that they were conveying around being held to account for these changes. And I have a lot of sympathy for that crew because they've built all this value, they kind of missed the euphoria boat in terms of, you know, getting the best price for an IPO, for example, and they've got to figure out, all right, how do we scrape together value from what we've got within the constraints that we have? How do we build a fence around the value that we've got and put a tollbooth in front of it so that the public markets are excited about this and give us our best bang for the buck? That's Steve Hoffman's job. That's his crew's job. I understand the pressures and I respect that.And I think that the way they went about it this year was short-sighted because what it does is it undervalues everybody who isn't in the boardroom, making decisions with them. I think what we have to understand that when we build software, Metcalfe's law applies to developer tools just as much as any other network here. And so, the people who are stakeholders, who are participants, who are constituents of your community, are load-bearing members of the value chain that you are putting together, and so when you just cut them out, you might be nicking an artery that bleeds out very, very, very slowly. And the sentiment that you just expressed here about how your experience of Reddit was soured, I mean you're the enthusiast type, right? Like, who wants to sign up for the drama of flame wars and moderation except if you really just love it?And so, what they were able to do was take people who, for years, absolutely loved it, and just drain away their love and enthusiasm for it. And the thing is, over time, that harms the long-term value that you are trying to actually protect. When we live in a world where computers can do all of this stuff infinitely, when they will provide us with extraordinary scale, when information can be copied and distributed at near-zero marginal cost, what we're doing is setting up chains of incentives to get people to do stuff, essentially, for free. You were unpaid labor doing that moderation, and the reason that you did it for free was because it was fun, was because it spoke to something inside of you that really mattered, and you wanted to provide for a community of other people who also cared about these topics. And that fun was taken away from you. So, there's a bunch of this stuff that doesn't fit into a spreadsheet, and if we make decisions exclusively on what fits into a spreadsheet, we're going to turn around someday and find that we have cut off some of the most valuable parts of what makes this industry great.Corey: I agree. I feel like companies have a—they launch, and they want the benefits of having an open-source community, but as they grow and get to a point of success and becoming self-sustaining, it's harder to see those benefits because at that point, it just feels like it's all downside: you are basically giving what you built away to your direct competitors, you are seeing significant value scattered throughout the ecosystem that you are capturing a very small portion of, and it becomes frustrating—especially in historical environments—where you have the sense of—back when you built the company years ago, it's well, obviously we'd be the best place to host and run this because no one's going to run this as well as the people who built it. And then cloud companies, with their operational excellence, come in and put the lie to that, in many cases [laugh]. It's like, oh dear. Not like that.And I understand, truly, the frustration and the pain and the fear that drives companies in that position. And I don't have a better answer, which is my big problem because I'm just sitting here saying, “You're doing it wrong. Don't do it like that.” “Okay, well, what should they do instead?” “No, I just want to be angry. I'm not here to offer solutions.” And I feel for them. I do. I have a lot of empathy for everyone involved in this conversation. It just sucks, but we need a better outcome than the current state, or we're going to not see the same open innovation. Even these days, when I build things, by default, I don't build in the open, not because I'm worried about competitive threats, but because I don't want to deal with people complaining to me about things that I've built and don't want to think about this week.Danilo: I think that we're living through the hangover of—I mean, if you looked at the crypto craze as an example of this hangover, right—here we were with the sky the limit. We can sell monkey pictures for extraordinary amounts of money and there's nothing behind it. We went from euphoria to fear in the space of a handful of quarters. And so, that has put all of us, even the most optimistic, in a place where we feel our backs are against the walls. But I think the responsibility we have is, again, computing fundamentally changes the economics of so many categories of labor, and it changes the economics of information generally.And so, we can do a bunch of stuff that doesn't cost that much over the long-term, relative to the value it creates. But it only works if we have a really clear thesis of the value we're creating. If we don't value the contributions of a community, if we don't value the emergent outcomes that arise from building something that's very expressive, that then lets outsiders show up and do things that we never predicted, if we're not building strategies that look at this value as something that is precious instead of something to be cut off and captured, then I think that we just continue to spiral down the drain of paranoia, and greed, and fear instead of doing things that actually create long-term sustainable growth for our business.Corey: I really wish that there were easier, direct paths. Like on some level, too, it's—I feel like this is part of the problem, that every company views going public as its ultimate goal.Danilo: Yeah.Corey: At least that's what it feels like. Like The Duckbill Group. If we ever go public, my God, I will have been so far gone from this company long before then, just because at that point, you have given control over to people who are not aligned, in many cases, with the values that you founded the company with. Like, one of the things I love about being a small business is that I don't need to necessarily think the next quarter's earnings. I can think longer-term. “Okay, in two or three years, what do I want to be doing?” Or five or ten. I'm not forced into this narrow, short-sighted treadmill where I have to continually show infinite growth in all areas at all times. That doesn't sound healthy.Danilo: I agree, and I think that this is a place where I can give you a lot of hope because I look at a handful of economic tailwinds that are really going to make it possible to build businesses in a different way than was practical before. If we look at the last cycle, one of the absolute game changers was open-source. So, you showed up and there was already a web server written for you, and there was already a database written for you, and so you would just pull these things off the shelf instead of having to hire a team that would build your web server from scratch, that would build your database from scratch. And so, that changed the economics of how companies could be made, and that created an entire cycle of new technology growth.And if we look for an analogy of that kind of labor savings for the next technology cycle, we're going to see things like cloud-based serverless services, right? So like, now you don't need to even administer a Linux server. You don't need to know how the server works under the hood. You pay one company for an API that gives you a database, and they manage the stuff. So, I'm thinking of companies like Neon, or PlanetScale, right? You give them cash, they give you a database, they worry about it, they do all of the on-call stuff, you don't have to think about. So, this makes it even cheaper to build things of higher complexity because you are outsourcing much of the management of that complexity to other firms. And I think that that pattern is going to change the overall costs of starting and scaling and maintaining any sort of web-based product. And so, that's number one.And then number two, is that when we look at stuff like large language models, the stuff that you can do with ChatGPT in terms of figuring out how to solve a broad array of problems that maybe you don't have a lot of domain expertise in, I think that means that we're going to see smaller teams get even further than we expect. And so, the net result of these trends is going to be, you don't need to take vast amounts of venture funding in order to get to a company that serves a large number of people at a meaningful scale, with meaningful returns for the principles involved, and then they don't have to go all the way down to the IPO route. They don't have to figure out some sort of mega-scale unicorn exit; they can just build companies that work, that solve customer problems, keep it close, and then you don't have the totalizing endless need for growth. I think we're going to see a lot more of that this cycle.Corey: I sure hope you're right. I think that there's been a clear trend toward panic, or at least if not panic, then at least looking at current conditions and assuming that they'll persist forever. We just saw ten years of an unprecedented bull run, where people tended to assume that interest rates would be forever low, growth was always going to be double-digit at least, and there was no need to think about anything that would ever argue against those things. For the first few years of my consulting company, it was a devil of a problem trying to convince people to care about their AWS bills because frankly, when money is free, there is no reason for someone to. They are being irrational if they do. Now, of course, that's a very different story, but at the time, I felt for a while like I was the one who was nuts.Danilo: So, the interest rate conditions are always going to make people behave a certain way. That's why they exist, right? We have monetary policy designed to influence business behavior. And if we look at that zoom, then we say, “All right, look, this stuff is all cyclical. We know there's going to be good times, we know there's going to be lean times, but at the end of the day, we care about building stuff.” Right?I don't spend a lot of time with the sort of venture capitalist set who's really obsessed with building, but I really love building. I just, I can't stop building things. It is what I was put on this planet to do, and I think that there are so many people who feel exactly the same way. And so, regardless of the larger interest-rate phenomenon, we have to find a path where we can just build the stuff that we need to build. Build it for our reasons, for the right reasons, not because we just want to cash out. Although, you know, getting paid is great. I don't begrudge anyone that.Corey: You can't eat aspirations, as it turns out.Danilo: That's right, right? We've got to worry about the economics, and that's reasonable. But at the end of the day, making things happen through technology is its own mission and its own reward, regardless of what some sort of venture fund needs to make return happen. So, I think that we are going to get past this moment of slump and return to the fundamentals of we need to build technology because building technology makes us feel good and creates impact in the world that we absolutely need. And those are the fundamentals of this business.Corey: I agree with you wholeheartedly. I think that I've been around too many cycles—this is a polite way of saying I'm old—and you learn when that happens that everything that feels so immediate and urgent in the moment, in the broad sweep of things, so rarely is. Not everything can be life or death because you'll die lots of times.Danilo: Yeah.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Danilo: If you want to engage me for my thinking and strategy around humanist technology tools growth, you should find me at antigravitydx.com. And if you want to read more about what I think about, I maintain a blog at redeem-tomorrow.com, and you can learn all about my thinking about the last cycle, and the coming one as well.Corey: And I will absolutely include a link to that in the [show notes 00:31:52]. Thank you so much for taking the time to speak with me. I appreciate it.Danilo: It's a pleasure, Corey. Thank you for having me. Really great to chat.Corey: Danilo Campos, proprietor at Antigravity DX. 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 taking care within that comment to link to a particular section of the FutureAdvisor code repo.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

In this episode of Syntax, Wes and Scott talk about the lessons they learned while launching the new Syntax website including launching now, transcription bugs, error monitoring, black text on black backgrounds, and more. Show Notes 00:10 Welcome to Syntax 01:41 Syntax Brought to you by Sentry 02:43 Don't wait. Launch! 04:28 Transcript bug Most Powerful Speech-to-Text API | Deepgram 09:01 Error monitoring is a must 12:36 Timestamp error 16:20 Black text on black background might hide things 17:33 WASM Vercel file system 21:18 Things have gotten easier to launch PlanetScale: The world's most advanced database platform — PlanetScale 23:36 Switching from OpenAI to Anthropic Claude and AI Responses aren't always JSON 25:34 Local dev is fast Navigation API 31:37 Mind your payloads 32:41 GitHub Milestones 33:57 Almost forgot the Robots.txt 36:17 Chron job timeout Inngest 40:06 TypeScript errors don't need to be zero to launch 42:25 GitHub Actions pipeline bug 43:23 Basic testing will do Playwright 44:56 Have a designer to work with Airbase 52:07 Sick Picks Sick Picks Scott: Dog Poop Bags With Dispenser Wes: Resistance band Shameless Plugs Scott: Sentry Wes: Wes Bos Courses Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads

The near-cinematic trailer for the backend banter podcast. Featuring The Primeagen, Melkey, TJ Devries, Miriah Peterson, Bill Kennedy, and Brian Morrison from PlanetScale. Hope you like the pod!

PHP used to suck, but Aaron Francis, content creator and developer at PlanetScale, is on a mission to change the narrative. We talk about why PHP doesn't suck anymore and the features that have improved it. Links https://twitter.com/aarondfrancis https://www.youtube.com/@aarondfrancis https://aaronfrancis.com https://www.linkedin.com/in/aarondfrancis https://www.youtube.com/watch?v=ZRV3pBuPxEQ&ab_channel=AaronFrancis 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: Aaron Francis.

We're delighted to welcome Lorynn Boland to our program! She is an EA who has navigated both sides of the aisle, so to speak, having spent five years at Kleiner Perkins, the legendary venture capital firm, and now the last six months supporting the CEO of PlanetScale, a database platform for developers with infinite scalability. Today we'll be learning about Lorynn's experiences of supporting in these environments which, while different, are also inextricably linked and symbiotic. We feel this is an important conversation to have, as there is definitely a compatibility and common language between these respective industries, as well as some noteworthy differences. For anyone curious to understand these difference or for someone who is perhaps preparing for a job interview or transition from one side to the other, today's conversation will be particularly valuable.

Lane and Brian talk about scaling databases, particularly MySQL, Vitess, and the PlanetScale platform. Brian is a developer educator at PlanetScale, and he breaks down how you can think about scaling databases for your own projects, or for the companies you work for. PlanetScale is used for cloud MySQL deployments in the new CI/CD course on Boot.dev that just dropped!Brian on Twitter: https://twitter.com/brianmmdevPlanetScale: https://planetscale.com/

On today's episode, Chris and Andrew have an early start and catch up on their lives. Then, they dive deep into the latest developments in the Rails community, including the release of Rails 7.0.6, bug fixes, and changes to Active Record.  They share their experiences with GitHub deployments, documentation issues, and how they navigate through its challenges. They discuss the benefits of MySQL and Postgres, as well as the ongoing advancements in Postgres, specifically Crunchy Data's contributions.  Chris and Andrew share their views on working in different company sizes, the joys of learning new things, dealing with burnout, and the slower pace of feature shipping in larger companies. There's a discussion on Reddit's recent actions, its impact on subreddit moderations, and the discontinuation of the Reddit API. We'll also hear about Chris's cooking adventures, experimenting with different flavors, and making some Texas Twinkies. Hit download to hear more! [00:02:00] Chris and Andrew talk about the release of Rails v7.0.6 with bug fixes and changes in libraries like Action Cable and Active Record, including subqueries and associations with polymorphic relationships.[00:06:10] Andrew is curious about the GitHub deployment stuff and expresses his desire to create GitHub deploys from Heroku. They talk about the complexities of setting up GitHub deployments and the lack of clear information from GitHub, and how the documentation with Checks API can be confusing to set up. [00:09:49] Chris discusses the challenges of figuring out GitHub's deployment process and the lack of documentation. He expresses frustration with the lack of clarity and support for smaller accounts. [00:14:41] PlanetScale is brought up and its association with MySQL, and they discuss the benefits of MySQL and Postgres, and the new features and advancements in Postgres, including Crunchy Data's contributions and the potential use of Postgres in web environments. [00:17:43] Chris shares a fun story about working on implementing jump server support in the new Hatchbox.  They encountered unexpected complexities with the net-ssh gem to address the problem. [00:29:51] Chris emphasizes the importance of being mindful of memory usage and performance trade-offs and how it becomes more critical when building large-scale products. [00:31:59] Andrew mentions that releasing features can be challenging and Podia is currently facing that challenge with releasing a feature while also building onto it. He emphasizes the importance of coordination, communication, and learning from code to recognize and solve problems faster. [00:33:46] Chris reflects on his experience working at a consulting agency and how it allowed him to learn quickly by facing different projects and finds joy learning new things as a programmer. [00:34:43] We hear Andrew talk about feeling stuck in a job, comparing small companies which offer more challenges, to big companies where employees get stuck doing the same tasks, and Chris tells us he's happiest when learning new things and how it accelerates burnout.[00:35:57] Chris discusses the challenges faced by big companies when it comes to feature shipping due to the need to ensure existing users are not negatively impacted, and Andrew highlights the varying levels of impact when breaking code and emphasizes the importance of being able to find and fix bugs quickly. [00:39:00] We hear about Chris's mad cooking skills with pulled pork and experimenting with smoked cream cheese which he hopes to use in some Texas Twinkies. [00:43:53] The conversation shifts to Reddit and its recent actions regarding subreddit moderation and the discontinuation of the Reddit API, and they express frustration with Reddit's handling of the situation and the negative consequences it's had on the community. [00:51:30] We end with Chris needing to attend to his cooking tasks and Andrew mentions his responsibility to lead Podia in Jason and Jamie's absence.   Panelists:Chris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRails 7.0.6 PlanetScaleCrunchy DataReddit Won't Be the Same. Neither Will the Internet (WIRED)What the Heck is a Texas Twinkie?

Summary Data engineering is all about building workflows, pipelines, systems, and interfaces to provide stable and reliable data. Your data can be stable and wrong, but then it isn't reliable. Confidence in your data is achieved through constant validation and testing. Datafold has invested a lot of time into integrating with the workflow of dbt projects to add early verification that the changes you are making are correct. In this episode Gleb Mezhanskiy shares some valuable advice and insights into how you can build reliable and well-tested data assets with dbt and data-diff. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management RudderStack helps you build a customer data platform on your warehouse or data lake. Instead of trapping data in a black box, they enable you to easily collect customer data from the entire stack and build an identity graph on your warehouse, giving you full visibility and control. Their SDKs make event streaming from any app or website easy, and their extensive library of integrations enable you to automatically send data to hundreds of downstream tools. Sign up free at dataengineeringpodcast.com/rudderstack (https://www.dataengineeringpodcast.com/rudderstack) Your host is Tobias Macey and today I'm interviewing Gleb Mezhanskiy about how to test your dbt projects with Datafold Interview Introduction How did you get involved in the area of data management? Can you describe what Datafold is and what's new since we last spoke? (July 2021 and July 2022 about data-diff) What are the roadblocks to data testing/validation that you see teams run into most often? How does the tooling used contribute to/help address those roadblocks? What are some of the error conditions/failure modes that data-diff can help identify in a dbt project? What are some examples of tests that need to be implemented by the engineer? In your experience working with data teams, what typically constitutes the "staging area" for a dbt project? (e.g. separate warehouse, namespaced tables, snowflake data copies, lakefs, etc.) Given a dbt project that is well tested and has data-diff as part of the validation suite, what are the challenges that teams face in managing the feedback cycle of running those tests? In application development there is the idea of the "testing pyramid", consisting of unit tests, integration tests, system tests, etc. What are the parallels to that in data projects? What are the limitations of the data ecosystem that make testing a bigger challenge than it might otherwise be? Beyond test execution, what are the other aspects of data health that need to be included in the development and deployment workflow of dbt projects? (e.g. freshness, time to delivery, etc.) What are the most interesting, innovative, or unexpected ways that you have seen Datafold and/or data-diff used for testing dbt projects? What are the most interesting, unexpected, or challenging lessons that you have learned while working on dbt testing internally or with your customers? When is Datafold/data-diff the wrong choice for dbt projects? What do you have planned for the future of Datafold? Contact Info LinkedIn (https://www.linkedin.com/in/glebmezh/) Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ (https://www.pythonpodcast.com) covers the Python language, its community, and the innovative ways it is being used. The Machine Learning Podcast (https://www.themachinelearningpodcast.com) helps you go from idea to production with machine learning. Visit the site (https://www.dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com (mailto:hosts@dataengineeringpodcast.com)) with your story. To help other people find the show please leave a review on Apple Podcasts (https://podcasts.apple.com/us/podcast/data-engineering-podcast/id1193040557) and tell your friends and co-workers Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Links Datafold (https://www.datafold.com/) Podcast Episode (https://www.dataengineeringpodcast.com/datafold-proactive-data-quality-episode-205/) data-diff (https://github.com/datafold/data-diff) Podcast Episode (https://www.dataengineeringpodcast.com/data-diff-open-source-data-integration-validation-episode-303/) dbt (https://www.getdbt.com/) Dagster (https://dagster.io/) dbt-cloud slim CI (https://docs.getdbt.com/blog/intelligent-slim-ci) GitHub Actions (https://github.com/features/actions) Jenkins (https://www.jenkins.io/) Circle CI (https://circleci.com/) Dolt (https://github.com/dolthub/dolt) Malloy (https://github.com/malloydata/malloy) LakeFS (https://lakefs.io/) Planetscale (https://planetscale.com/) Snowflake Zero Copy Cloning (https://www.youtube.com/watch?v=uGCpwoQOQzQ) The intro and outro music is from The Hug (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/Love_death_and_a_drunken_monkey/04_-_The_Hug) by The Freak Fandango Orchestra (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/) / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/) Special Guest: Gleb Mezhanskiy.

#210: If you're feeling frustrated and overwhelmed due to your current database deployment and management process not working as expected, then you are not alone! Think about how many times you've needed to maintain the schema of your database and then you give up because it's either going to break things or it's going to take too long for a migration to happen.  In this episode, we speak with Sam Lambert, CEO of PlanetScale, about how running your own database should be considered a thing of the past and that you really shouldn't be scared to make changes to your database schema when it's as simple as doing a rewind.   Sam's contact information: Twitter: https://twitter.com/isamlambert LinkedIn: https://www.linkedin.com/in/isamlambert/   YouTube channel: https://youtube.com/devopsparadox/   Books and Courses: Catalog, Patterns, And Blueprints https://www.devopstoolkitseries.com/posts/catalog/   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/   Connect with us at: https://www.devopsparadox.com/contact/

Sugu Sougoumarane discusses how to face the challenges of horizontally scaling MySQL databases through the Vitess distribution engine and Planetscale, a service built on top of Vitess. The journey began with the growing pains of scale at YouTube around the time of Google's acquisition of the video service. This episode explores ideas about topology management, sharding, Paxos, connection pooling, and how Vitess handles large transactions while abstracting complexity from the application layer.

Jake and Michael discuss all the latest Laravel releases, tutorials, and happenings in the community.This episode is sponsored by Honeybadger - combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform and making you a DevOps hero. (05:34) - Laravel 10.5 released (10:47) - Everything you can test in your Laravel application (13:38) - Replace raw query calls with Laravel Query Expressions (19:12) - Validated DTO package for Laravel (22:14) - Sponsor: Honeybadger (23:16) - PlanetScale database migrations for Laravel (28:47) - Laravel expectations plugin for Pest (32:06) - Useful Laravel date scopes for Eloquent models (35:06) - Pest architecture plugin (36:11) - Let's talk about form requests

Sam Lambert is originally from the UK, and has lived quite a few places during his life. He went to school in India, but now resides in San Francisco. He finds software to be a creative, playful process, and sees people trying to build that away from the process. He feels very lucky to building something that provides fruit and solves problems. Outside of tech, he is married with a 4 year old, and is into cooking and art. I asked about NFT's, given his tech background, but he's not super into that form of art at this time.Sam spent time working at Github as a VP of Engineering, specifically focusing on infrastructure. He and his team came across Vitess, the backend that ran YouTube, and he took this amazing framework into his current venture to remix their approach of design and scalability.This is the creation story of PlanetScale.SponsorsAirbyteDopplerHost.ioIPInfomablSupportZebraLinksWebsite: https://planetscale.com/LinkedIn: https://www.linkedin.com/in/isamlambert/Support this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy

Malware infecting widely used security appliance survives firmware updates IceFire Ransomware Portends a Broader Shift From Windows to Linux Thousands scammed by AI voices mimicking loved ones in emergencies Personal details of U.S. House members exposed in health data breach Biden FCC nominee withdraws, blaming cable lobby and "unlimited dark money" Nick Van Wiggeren, VP of Engineering with PlanetScale talks about fully managed database-as-a-service. Hosts: Louis Maresca, Brian Chee, and Curtis Franklin Guest: Nick Van Wiggeren Download or subscribe to this show at https://twit.tv/shows/this-week-in-enterprise-tech. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: GO.ACILEARNING.COM/TWIT ZipRecruiter.com/twiet kolide.com/twiet

Databases are key to almost any project, large or small.  Most database systems in the cloud are designed for heavy use and the costs can get expensive quickly, but database-as-a-service is a rapidly growing area, where many databases can share the same hardware for a much reduced rate, or even for free!  Sam Lambert, CEO of PlanetScale, joins Jason and Patrick to discuss database-as-a-service.00:01:41 Introductions00:02:34 Sam's Github learning lesson00:07:08 The day after00:10:57 Getting started with databases00:14:21 Schema change difficulties00:19:47 Database transactions00:31:15 Why data recovery matters00:38:35 Planetscale00:49:24 Greetings from the past01:02:01 How Jason discovered Planetscale01:06:53 Branching01:14:00 The vision for Planetscale01:18:12 The rationale behind Planetscale's work setup01:24:29 Careers at Planetscale01:28:06 Amp It Up01:33:10 FarewellsResources mentioned in this episode:Links: Sam Lambert:Linkedin: https://www.linkedin.com/in/isamlambert/ PlanetScale: Website: https://planetscale.com/ Twitter: https://twitter.com/planetscaledata Linkedin: https://www.linkedin.com/company/planetscale/ Github: https://github.com/planetscale Careers: https://planetscale.com/careers Amp It Up (Amazon): Paperback: https://www.amazon.com/Amp-Unlocking-Hypergrowth-Expectations-Intensity/dp/1119836115 Audiobook: https://www.amazon.com/Amp-Hypergrowth-Expectations-Increasing-Elevating/dp/B09QBRBKFB/ If you've enjoyed this episode, you can listen to more on Programming Throwdown's website: https://www.programmingthrowdown.com/Reach out to us via email: programmingthrowdown@gmail.com You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM  Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Fouad Matin, Co-founder & CEO of Indent, joins Corey on Screaming in the Cloud to discuss how to get data security right without creating unnecessary barriers for your development team. Fouad and Corey discuss how getting admin access as a developer can be time consuming and vague, when it should be efficient and come with an easily defined reason for granting access. Fouad also explains why he feels most breaches are due to not getting the basics right, and why he feels storing customer and sensitive data should be done with the same principles as dealing with hazardous waste.About FouadFouad Matin is the co-founder and CEO of Indent, a security company that enables teams to perform mission-critical operations faster and more securely. With Indent, organizations like HackerOne, Modern Treasury, Vercel, and PlanetScale are able to grant secure, time-bound user and admin permissions for cloud apps and infrastructure through Slack.Prior to Indent, Fouad worked as an engineer at Segment, a customer data platform helping companies secure their pipelines for handling customer data. He co-founded a non-partisan non-profit in 2016 to help people register and get out to vote through easy-to-use, privacy preserving tools. In 2018, while validating Indent's mission, partnered with Vote.org to build tools for users to find their polling place and preview their ballot using client-side encryption.Links Referenced: Indent: https://indent.com Nobody Should Have Production Access: https://indent.com/blog/production Fouad on Twitter: https://twitter.com/fouadmatin Indent on Twitter: https://twitter.com/indent Unplanned Maintenance: https://unplannedmaintenance.com Least Privilege in Practice Blog Post from Indent: https://indent.com/blog/least-privilege Additional Links Referenced: Email: mailto:fouad@indent.com Fouad LinkedIn: https://www.linkedin.com/company/indentinc/ Indent LinkedIn: https://www.linkedin.com/in/fouadmatin/

Iheanyi Ekechukwu and Mike Coutermarsh talk about PlanetScale, what Vitess is, if PlanetScale is for both side and big projects, what read only regions are, what schema changes are, and how PlanetScale compares to other projects.

Matt Robenolt is a part of the infrastructure team at PlanetScale. Matt joins us today to talk about his blog post titled Faster MySQL with HTTP/3. Links https://twitter.com/mattrobenolt https://www.linkedin.com/in/mattrobenolt https://mattrobenolt.com https://github.com/mattrobenolt https://planetscale.com/blog/faster-mysql-with-http3 https://www.mysql.com https://planetscale.com Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Matt Robenolt.

About TaylorTaylor Barnett is a Staff Developer Advocate at PlanetScale. She is passionate about building great developer experiences emphasizing empathy within product, documentation, and other developer-facing projects. For the past decade, Taylor has worked at various data and API-focused startups in software development and developer relations. In her free time, as a firm believer in "touching grass," she's either gardening, taking long walks, climbing rocks with friends, trying to find the funkiest sour beers, or hanging out with her corgi, Yoda, and spouse in Austin, Texas.Links Referenced: PlanetScale: https://planetscale.com/ Twitter: https://twitter.com/taylor_atx Personal website: https://taylorbar.net 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: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.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'm joined this week by Taylor Barnett, Staff Developer Advocate at PlanetScale. Taylor, you're one of those people that I'm ashamed I haven't had on the show before now. Thanks for joining me.Taylor: You're welcome. Yeah, I'm glad to be here.Corey: We've been traveling in similar circles for a while now. And I lost track of a lot of those areas when the pandemic hit, you know, the global plague o'er the land. And during that time, it seemed like there was a lot of question that folks had about what is developer advocacy. What does DevRel become now? And now that we're largely on the other side of it—at least business is pretending that we're behind it—do we have an answer yet?Taylor: I hope so. I mean, I have an answer. Not sure if other businesses have figured that out yet. But no, I mean, to me, advocacy is still just that glue between company and a community. But I think one of the things that the pandemic has really, like, pushed that, you know, when there were no in-person events, was that it questioned what activities that actually looks like.You know, I see advocacy as a ton of different levers and you can tweak those levers to different levels. Before, it was largely a lot of in-person stuff—I will say I was doing less in-person, actually before than most; I was doing a little bit more content—then it had to become so content-focused. And I think now we're in this awkward place where in-person events have come back and we're still, like, figuring out, like, how do we do those? What does that look like? And we've actually—I think part of it is we've over-indexed now on content.I think part of that is because it is visible and it is measurable, and that's always a big topic [laugh] in developer relations is metrics. But also, I think we've lost track of the actual advocacy part: how do we actually advocate for users internally? It's just disappeared a little bit because we were so content-focused during the pandemic.Corey: I would say that's been a recurring theme with every DevRel person that I've spoken to that metrics are the bane of their existence. And I want to be clear, I'm not just talking about developer advocates, I'm talking about people who manage and run developer advocacy teams, I'm talking about executives who are trying to bring the appropriate context to strategic-level discussions around these things. All of the metrics that I have been able to uncover are wrong. But it's like the, ‘all models are wrong, but some models are useful' type of approach, where—Taylor: Yeah.Corey: Every time you start putting a metric around it and measuring people based upon the outcome of that metric, it ends in disaster. My one and only interview for a DevRel job in my past was my question for them was how do you measure success? “Well, we want to see you have talks accepted at some of the big tier-one conferences.” And they list a few examples, and it's, yeah, “I've spoken at for the ones you just listed in the past year, so… do I get a raise?” It's one of those areas where there's no right answer, but a lot of wrong ones.Taylor: Yeah. And one of the other troubling patterns that I've started to see also more is that in these cloud startups, they have DevRel programs now that are fairly young, we're talking not even a year old. Some in the recent DevRel survey results, it was about, like, 29% of programs are less than a year old. Within those programs, 43% of those people have not even been in a DevRel role for more than a year. So, not only do we have folks that haven't done this before, the startup has not done this before.And so, the metrics conversation is basically a shit show. People with the right experiences aren't in these roles and so they're not able to craft strategies and actually look at good metrics. And so, then we then over-index on the things like, “Oh, you wrote a blog post.” Great, you know, that's, like, some kind of metric. “It got X number of page views.” Great, that's some kind of metric.And it often incentivizes some of the wrong things. And so, then it just incentivizes more and more of this content creation, to just get those pageviews up. And it's scary to me because then we're just going back to the more evangelist type of developer relations and less of the advocacy type stuff where we're actually advocating for users internally.Corey: I would agree. I'd say that there's a problem where we have a, almost across the board, lack of understanding about—let's even start at the very beginning of when DevRel is required or when it's not. I mean, take where you work now at PlanetScale. You're effectively managed Vitess-as-a-service. That's a little on the technical side and is not the sort of thing that's going to necessarily lend itself to a mass-market marketing approach.This is not something to put on billboards outside of most highways, for example, but it does require engaging with people on a technical level. I keep joking but also serious when I refer to DevRel as meaning you work in marketing, but they're scared to tell you.Taylor: Yeah. No, I mean, I actually sometimes say, “Well, like, I'm secretly probably a pretty good product marketer, but I don't want developers to know that because then I'll lose my street cred from my actual development and engineering background.” And I have a computer science degree and, like, I'm actually, like [laugh], very, very technical. But the reality is, like, you know, somebody's got to write the words, sometimes.Corey: The words are harder when they go into people then they are into computers. At least with computers—Taylor: Exactly.Corey: It's pretty—it's a bounded problem space to some extent. With people, oh no, no, there's no consistency at all.Taylor: Yeah. And like, words mean different things to different people, especially, like, my favorite one lately is, like, what does edge mean? Nobody actually has one [laugh] definition of that word.Corey: Oh, I think most of them do. Edge always means, “Oh, it's a way of describing the thing that we've been doing for 15 years, but now want to sell into a hype cycle.”Taylor: Yeah, yeah. I mean, CDNs have been around for a while. You know, and that's really—like, what PlanetScale, it is, in some ways, we're challenging what people expect from their database. We think you can actually expect more from your database platform, and so there are things you know, to teach people about some of these newer ways of working with a database. And that requires needing to think about how we present that to users, but also hearing back from users how do we work within their applications, their stacks.We're MySQL. That's, you know, a trusted standard. It's been around for a while, so it works with many, but also, we're in this whole new paradigm of how to use a database. These are all new ideas and they require both a two-way street of both putting things out there—so content, not bad; it's still needed—but also things coming in and taking that, making it actionable, and talking about it internally.Corey: When you take a look at the DevRel world, what do you think that most organizations are missing or getting wrong about it? And yes, I understand that I'm basically asking you to start beef with a whole bunch of companies out there, but that's all right. It's what we do here.Taylor: Yeah, one of the things I love, [Matty 00:07:44] Stratton had this thing where I tweeted out a few months ago that we've over-indexed on content, and matty's reply was that we've over-indexed on being able to do cool shit that isn't connected to revenue because that somehow is dirty for DevRel to somehow be connected to revenue. I think, you know, a lot of times, there are ways that we can look at how do users actually get value from our products. Like, are they actually getting value? One way they express that is by paying for it. So therefore, we are then somehow connected to revenue.I mean, I want to build things, I want to work on platforms that deliver value, that people actually want to pay for because they see this is makes my life easier, somehow. But to do that, and again, we've got to talk to our users. We've got to figure out where do they actually value. What are the things that are just fluff? There's a lot of fluff out there.Sometimes if we don't listen to them, then we don't have to find out that what we're building is fluff. So, that's probably the part that could start some beefs. But it's the reality of lots of VC money and tooling and being able to build things super easily, it's a bunch of different factors coming together in this time.Corey: One of the things that I don't pretend to understand, but I'm going to roll with it anyway, is there's been a lot of discourse on where DevRel does not belong in an org chart. I don't have a terrific answer at this, but I do know that most of the answers I get from practitioners in the space are deeply dissatisfying. It seems that—not to be unkind or cast aspersions where they don't belong, but whenever I ask the question, everyone has a whole laundry list of wrong answers and very few right ones.Taylor: I honestly will say I don't care [laugh]. I mean, that's the reality.Corey: Corporate IT. Got it.Taylor: Do I want to be on a team that makes me directly responsible for qualified leads? No. That does not necessarily say anything about the team itself. That is just a metric. That is—you know, and that team exists in a larger system that has put certain pressures on it.Like, you know, there's, like, things, like, it's more about how a team looks at just doing the DevRel stuff and doing marketing in general, or how they do sales. You know, I know lots of developers hate to hate on sales—marketing, too—and I don't necessarily think sales and marketing are a bad thing, I think is the way we incentivize those roles create bad behaviors, and so maybe we should look at how we incentivize them. And so, I don't care what team I'm honestly on most of the time. I've been on a few different ones. As long as I get to do the developer advocacy work that I actually think is impactful for developers and actually making developers' lives better, I'm cool.Corey: It's my belief, on some level, that it's very easy to internalize a bad expression of it. You can have phenomenally well-empowered DevRel teams working in marketing—Taylor: Yep.Corey: —at some companies, and in other places, it can be an absolute disaster because they start putting metrics like number of qualified leads around you. And I can't shake the feeling that people internalize, “Well, we've reported marketing once and it was terrible,” without realizing the context of yeah, but in a terrible way, and an org that didn't really understand what you do. That doesn't necessarily mean that you should throw that whole baby out with the bathwater.Taylor: Yeah, I mean, we've all had bad managers. So, we're not going to say we're just never going to have a manager.Corey: Some people try that.Taylor: Is that what you've done [laugh]?Corey: Indirectly. No, I was talking about more about the holacracy companies where oh yeah, no one reports to anyone. It's really? Because everyone makes different amounts of money, so one wonders about that.Taylor: Yeah. But by far, we just go find better managers is what we often do, you know? And there's the whole phrase that, like, people don't leave companies, they leave managers. It's very true in my experience. And we don't just say, “All marketing teams bad, so I'm never going to join a marketing team.” We should say, “Let's just go find one that fits better.”Corey: I was very frustrated in my last couple of real jobs because so much of what I was doing was DevRel-like, but this was before that was an established and accepted thing in the places that I worked, so there were questions like, “Well, what is the value of you going to give a keynote at this conference?” And the honest answer was, “Yeah, I have no idea how to quantify it, but I know that if I do it, good things come out of it.” And that was a difficult battle to fight, whereas now when I decided to go work for myself, it's, “Yeah, I'm going to go speak there. I don't know what the ROI is. I know good things and maybe some useful things will come out of it. Maybe I'll learn something, but this is how we experiment and learn.” And that looks an awful lot to most traditional management types. Like I'm trying to justify a trip somewhere.Taylor: Yeah. And I think, you know, what's been also interesting, as I noticed, some people are starting to notice a lot of more junior people wanting to get into developer relations. And we sometimes actually are wondering, some of us in developer relations, if we've not always shown like the negative parts of that. What happens when you go do that keynote? What does that mean for your week leading up to that keynote? What does travel look like? What is, like, running across an airport wearing a mask and carrying your luggage look like?I think we don't always get to see that and so it looks a little bit less glamorous when people see that. And maybe they would be slightly less interested in the role or just, like, how do you handle working with, like, five different teams across a company to try to be like that glue piece between all of them to get something done? Like, there's a lot less glamorous parts that I'm hoping more people talk about because, like you said, it just looks like you're trying to go get a trip somewhere. I think the other thing is, like, even if you are having a keynote, I think one of the things that some people—they think one keynote is going to just wreck a budget. The reality is for our business, it will not do that, so why can't we, like, have a better balance of extremes?Like, you're not going to be giving ten of those keynotes in a year, maybe experiment doing two and see what comes out of doing two of them. But the other thing is, it's a long-term game and so you're not going to see something maybe the week after. It could be six months later. I had this one experience where someone actually told me—it was probably, like, a whole year after I had given a talk—that him and his teammates—this was back when people you know, went into offices—sat in an office and watched one of my old talks together. And I was just like, what, like, y'all, like, got together and did that?Corey: Yeah, you could have invited me and I could have delivered it for you in person and answered questions, but all right.Taylor: Yeah. It was like, what I was just like, oh my gosh, that is literally never happened to me. This was a few years ago. And then, too, I was like, that just made it worth it. If you asked a CEO, would you like to have an advocate go give a talk for a whole team at a company, they'd be like, “Yes, I want you—” especially if that's a big company and the name is shiny and they would love to have that as a customer, they would be, like, a hundred percent, “Go give that talk.”And so, I think many times, leadership needs to actually kind of check in on, like, is this really that much of a cost if it's just, like, one keynote? I've seen battles over really feels like stupid things sometimes. But everything in moderation is kind of the way I approach it.[midroll 00:15:17]Corey: One problem that I tended to see and I don't know how closely your experience mirrors my own, but it seemed, especially in the before times, right before the pandemic hit, that we were almost trapped in a downward spiral at a lot of the conferences because it felt like it was mostly becoming DevRels speaking to DevRel. And that wasn't the most inclusive thing for folks who used to wind up going to a lot of local conferences to learn from their local community and see how other people were solving the problems that they were solving. Instead, it felt like a bunch of DevRel types getting up there, in most cases giving a talk that was heavily alluding to why you should buy their product, if not an outright sales pitch for it. And it just felt like we're losing something. Do you think that's something that we've avoided, that we've pressed pause on, with the pandemic and now the recession, or do you think there's something else afoot?Taylor: I think that's still happening today, especially with, like, engineers wanting sometimes to travel less, you know, some people still have personal and family reasons for not traveling, so even less of them are wanting to speak. I don't think I saw, like, a huge swath of engineers, like, really excited to speak once conferences started in person again. They thought, “Oh, my gosh, I have to go talk to people in person again?” And so, it's still happening. I've seen it from an organizer's perspective.I used to organize the API specifications conference. There's tons of DevRel submissions in there, so you know, we really tried to spend time reaching out to companies that were member companies of the OpenAPI Initiative and get them to actually have member engineers from their teams come speak. I think DevRel has a role to internally advocate for engineers who are doing the day-to-day work, go speak at conferences. You know, I think many times engineers feel like, “Oh, what I have to talk about is not very interesting.” And I have to tell them, it is very interesting, and I would love to have you speak, and I'm here to help you, and you know, need help writing a CFP? I'm there. You need help putting together slides, practicing talks? I'm there.And I think DevRel can be kind of like these coaches for folks to go speak at conferences because the reality is attendees want to hear from them. They want to hear engineers from especially major companies or companies just doing really interesting engineering challenges speaking. And I think DevRel has a part in helping that happen. I've personally backed away from speaking the last six months, partially because I'm kind of not seeing as much value for myself doing it before I was doing a lot more, so I'm using that effort to try to advocate internally to help people CFPs. Last week, I helped a bunch of people KubeCon submissions, and then next week, I have other conferences I would love to—I have engineers that I've kind of picked out that I would love to have speak. And yeah, I'm glad to play a part in trying to improve that. And I think other advocates should, too.Corey: Where do you think that we're going as an industry? Because it became pretty clear for a couple of years that so much of what we were doing and how we were discussing it, it felt like there was a brief moment in time that we could really transform what we were doing and start to have a broader awareness that DevRel was more than giving talks on stage at conferences. And it feels like we squandered that opportunity and it mostly turned into, oh, now we're going to give the same talks, we're just going to do it to webcams, either pre-recorded—which was the better approach—or we're going to do it live, even though there's no interactive component to it, just introduce a whole bunch of different failure modes. I was disappointed. I liked some of the early stuff I saw coming out, like Desert Island DevOps, where they did it inside of Animal Crossing. Like I wanted to see more stuff like that, but it just seems like we didn't.Taylor: Yeah, I mean, the reality is, I think a lot of the online events have disappeared a lot in the last three or four months. And we're also seeing events trying to be hybrid. To me, a hybrid event is, like, throwing two events. Do you have an organizing team that can actually handle two concurrent events? It's hard.And API Specifications Conference, we did two years in person. Pretty niche conference. It's like the API nerds of the API nerds. And so, we still had pretty engaged attendees because there weren't any other sources of this, but then when everyone was starting to do the same content, attendees started checking out. They got tired of sitting in front of their monitors and watching talks.You know, we're seeing things coming back in person. I think it's going to be very interesting for the Spring because the Fall for me, it was probably one of my busiest conference seasons in terms of us just also sponsoring things. And I'm unsure of the return on investment today. We will see over time how that return on investment comes out, but I think it's going to change the way we look at the Spring, it's going to change the way we look at next Fall, and I think other companies are having the same conversations, too. And so, it's going to be like, okay, what do we do instead if we don't focus on conferences? I don't know. For me, that's focusing on the actual advocacy part, the user feedback, talking to users, building a product that people find value in. But for other teams, their team might not be in the place to do that. They might be expected to still produce this content in different ways, in-person, written, online.Corey: So, one of the burning questions that I think is not asked or addressed particularly well in the space has been, how do you get users to trust you? And to be clear, I am not saying you personally. It's like, “Well, given your history of flagrant lying and misleading people and scam after scam after scam, that is honestly impressive—” No, no, no, none of that. It's how do you—the indefinite you—build user trust?Taylor: Yeah, I think this is something we've seen, lots of companies of all sizes really struggle with. You know, the obvious thing I think many times companies think of is like, oh, if I'm open and transparent and have great docs, users will trust me. You know, I think that's part of it. I think the other thing that many often forget is that you need to listen to them, you need to take their feedback that they give you when you ask questions—and there's a whole, like, asking questions; I'm learning myself, like, how to ask better questions—how do you then make that actionable internally?You know, you have to understand who makes product decisions. Who do I need to talk to about this feature versus this other feature, and there's all these internal dynamics that you're then wading into. So, you have to get good at that. And then when you finally actually get some kind of change, whether that be some small paper cut of a thing related to a feature, or a big feature that you release, you actually go back to the user and you tell them, “Hey, look, we did this.” And what blows my mind is I do this, I take notes on who told me what feedback, and when that issue gets closed out, I go back to them and they're just shocked that I replied. They are shocked that I actually followed up. And to me, it's like such a basic thing, just following up. Doesn't seem, like, that hard.But it actually is hard but also useful. And you know, I think we've seen this so many times. We see—this is one example that I think about a lot, and I think you're familiar with this one too, Corey, the Aurora Serverless Data API in V1, people loved that. Then they came out with V2. There was no data API.And if you search that people are upset everywhere. And AWS keeps on telling them, “Nope, it's not going to happen.” And it's like, it's such an easy win if they actually listened to the user base. But there's countless examples of this, you know? There's things that we do at PlanetScale that we could improve on, you know, that users are telling us.There's only so much time in the day, but I think part of an advocate's job to wade through this feedback and figure out where can we bring the biggest value and the most impact. And, you know, I think all companies could benefit just from listening more and doing something about it.Corey: I wish that were a message that would get in front of the right people to make them a little bit more receptive. It feels like that's a message that is bandied around—to be direct—in DevRel circles an awful lot, but it doesn't seem to gain traction outside of that.Taylor: This kind of goes back to what we were talking about earlier with what team you're on. Sometimes that makes a huge difference, especially in larger companies. If you were siloed away in a marketing org—nothing bad about marketing, to be clear, but internally, you're seen as marketing—engineers, developers, see you as marketing. When you come with product feedback, they're kind of, “That's not your box. Go back to your box. Go back to your silo.”And you know, I think the reality is, we can't look at advocacy like that. I have users tell me things that they would never tell salesperson, they would never tell someone on our leadership team, they might tell someone in support. They tell me things. They send me emails that are multiple paragraphs long, giving positive and negative feedback. Many times it's positive, but I'm just shocked they'll even write that much, you know, positive. Like, they actually took out the time to do it.And they trusted that it was worth their time. I've done something right there if they're willing to do that at that point. And I, you know, I make sure I respond to every single one of those emails. I had someone ask me like, “Oh, do you want us to forward you all of them?” And I'm like, “Yes. Every single one. No matter what it says, I'm going to reply to this email.”Because then if I lose that trust, it's everything for me as an advocate. It's how I can help them, you know, see the value in the product, and help them with adoption, and bring them along to eventually paying, potentially—dirty word, revenue—but otherwise, I wouldn't have a job. So, you know, I think it's really something that startups, they think they see DevRel advocacy as content farms and not enough of the part that actually helps them make money.Corey: I really want to thank you for being so generous with your time. If people want to learn more, where's the best place for them to find you?Taylor: So, for now, I'm on Twitter as @taylor_atx. But if anything happens with that, as we know right now, you can also find me at taylorbar.net is my website. I'll always try to keep links of where I am on there. Trying to write more. We'll see if I accomplish that over the holidays. But yeah, that's the two places you can find me.Corey: And we will, of course, include links to that in the [show notes 00:26:27]. Thank you so much for your time. I appreciate it.Taylor: Yeah, thanks, Corey, for letting me rant, ramble, kind of have all these thoughts about advocacy. I'm hoping we can have a good 2023 in the world of DevRel and advocacy and make progress on some of these things.Corey: I sure hope you're right.Taylor: [laugh]. I hope I'm right, too, for the happiness of my job [laugh].Corey: Taylor Barnett, Staff Developer Advocate at PlanetScale. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment channeling a late Christmas spirit to tell us what the true meaning of DevRel was all along. Which will be wrong. Because it includes metrics.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.

In this supper club episode of Syntax, Wes and Scott talk with Nikolas Burke from Prisma about the role an ORM plays in a tech stack, how Prisma has changed over the years, ways to query data in Prisma, and how migrations work with Prisma. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Storyblok - Sponsor Storyblok is a headless component-based CMS with a real-time visual editor. It offers the flexibility for developers to craft their perfect tech stack, but it also empowers content creators to make changes independently. The result is that every team has the freedom to quickly and easily create the ideal website with limitless extensibility. Other key features include robust Storyblok SDKs and APIs, powerful internationalization options, and an eCommerce-ready platform. FireHydrant - Sponsor Incidents are hard. Managing them shouldn't be. FireHydrant makes it easy for anyone in your organization to respond to incidents efficiently and consistently. Intuitive, guided workflows provide turn-by-turn navigation for incident response, while thoughtful prompts and powerful integrations capture all of your incident data to drive useful retros and actionable analytics. Did we mention that FireHydrant is free? Get started at Firehydrant.com/syntax. Show Notes 00:35 Welcome 01:30 Guest intro @NikolasBurk on Twitter 04:56 How has Prisma evolved? Prisma Keystone GraphQL 10:44 What was Prisma V1? 17:04 Is there any GraphQL specific functions in Prismic? 21:26 Sponsor: Hasura 22:26 What role does an ORM play in a tech stack? 29:54 What is Planetscale? Planetscale The T3 Stack 32:22 Where does TRPC fit? tRPC 33:46 Sponsor: Storyblok 35:28 What is an ORM? Prisma VS Code plugin 42:00 How do migrations work with Prisma? 45:58 Query your data with Prisma client 49:43 Have you looked into alternative JavaScript environments? 55:16 Sponsor: FireHydrant 57:05 Supper Club questions 58:50 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Lichess Shameless Plugs Prisma blog Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

In this supper club episode of Syntax, Wes and Scott talk edge functions and Deno with Eduardo Bouças of Netlify. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Postlight Podcast - Sponsor Postlight is a strategy, design, and engineering firm that builds platforms for some of the biggest organizations in the world. The Postlight Podcast is hosted by senior leaders Rich Ziade, Paul Ford, Gina Trapani, and Chris LoSacco. If you're looking for answers to tough leadership questions, the Postlight Podcast has you covered. Listen to new episodes every Tuesday, wherever you get your podcasts. WP Mail SMTP - Sponsor Did you know that many WordPress sites are not properly configured to send emails? With WP Mail SMTP, you can easily optimize your site to send emails, avoid the spam folder, and make sure your emails land in the inbox every time. WP Mail SMTP comes with detailed email logs, email engagement tracking, visual email reports, weekly email summaries, integrations with popular email providers like SendLayer, Gmail, Outlook, and more! Try WP Mail SMTP Pro today and get 50% off or start with their free version by downloading it from the WordPress plugin directory. Show Notes 00:36 Welcome 02:31 Who is Eduardo? EduardoBoucas.com @eduardoboucas 04:29 What is a serverless function? 06:42 What is the edge and an edge function? Edge Functions Explained Deno 08:41 Sponsor: Hasura 09:18 The internet is global, and server locations matter 17:09 Chaining multiple edge functions 20:18 Sponsor: WP Mail SMTP 21:01 Why use Deno? 24:38 What are the limitations of using Deno? 27:44 Why not run NodeJS servers on the edge? 29:34 Do you see a future where people are writing packages that work anywhere? 31:32 Sponsor: Postlight Podcast 32:25 What about databases and serverless functions? Planetscale 37:46 What language does Netlify use to write apps in? Netlify Edge Handlers 43:39 Supper Club questions Warp S Town Podcast Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets