Screaming in the Cloud - The Future of Entertaining Developer Content with Jason Lengstorf

Episode Date: January 16, 2024

Jason Lengstorf, a developer media producer and host of the show Learn with Jason, joins Corey on this week’s episode of Screaming in the Cloud to layout his ideas for creative developer content. Jason explains how devTV can have way more reach than webinars, the lack of inspiration he experiences at conferences these days, and why companies should be focused on hiring specialists before putting DevRels on the payroll. Plus, Corey and Jason discuss walking the line between claiming you’re good at everything and not painting yourself into a corner as a DevRel and marketer.About JasonJason Lengstorf helps tech companies connect with developer communities through better media. He advocates for continued learning through collaboration and play and regularly live streams coding with experts on his show, Learn With Jason. He lives in Portland, Oregon.Links Referenced:Learn with Jason: https://www.learnwithjason.dev/Personal Website Links: https://jason.energy/links

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn.

Before I went to re-invent, I snuck out of the house for a couple of days to GitHub Universe. While I was there, I discovered all kinds of fascinating things. A conference that wasn't predicated on being as cheap as humanly possible was one of them. And a company that understood how developer experience might play out was another. And I also got to meet people I don't normally get to cross paths with. My guest today is just one such person. Jason Langsdorff is a developer media producer at Learn With Jason, which I have to assume is named after yourself. It is, yes. Or it's a dramatic mispronunciation on my part. Like,

no, no, it's Learn With Jason. And then it's basically this insane way of doing weird interchange formats. And you're just trying to sneak it through because, you know, I happen to be an XML purist. Right. I'm just going to throw you a bunch of yaml today. That's all I want to talk about. Exactly. It keeps things entertaining.

We're going to play with it. So let's back up a sec. What do you do? Where do you start? Where do you stop? I'm still learning how to answer this question, but I help companies do a better job of speaking to developer audiences. I was an engineer for a really long time.

I went from engineering into developer advocacy and developer experience. And as of the last year, I'm doing that independently with a big focus on the media that companies produce. Because I think that what used to work isn't working and that there's a big opportunity ahead of us that I am really excited to help companies move into. It feels like this has been an ongoing area of focus for an awful lot of folks. How do you successfully engage with developer audiences? And if I'm being direct and more than a little bit cynical, a big part of it is that historically the ways that company marketed to folks was obnoxious. And for better or worse, when you're talking about highly technical topics and you're being loudly incorrect, a technical audience is not beholden to some of the more common business norms and will absolutely call you out in the middle of you basically lying to them. Oh crap, what do we do now? Seemed to be a large approach. And the answer that a lot of folks

seemed to have come up with was DevRel, which I've talked about it before in a bunch of different ways. And my one-liner is generally, if you work in DevRel, that means you work in marketing, but they're scared to tell you that. I don't think you're wrong. And the joke that I've made for a long time is that they always say that developers hate marketing, but I don't think developers hate marketing. They just hate the way that your company does it. I wholeheartedly agree. Marketing done right is engaging and fun. A lot of what I do in public is marketing. Like, well, that's not true. You're just talking about how whatever dumb thing AWS did this week. Well, yes, but then you stick around to see what else I say. And I just become sort of synonymous with, oh yeah, that's the guy that fixes AWS bills.

That is where our business comes from, believe it or not. And I think this was sort of the heart of DevRel is that people understood this. They understood that the best way to get an audience engaged is to have somebody who's part of that audience engage with them. Because you want to talk to them on the level that they work. You're not, you know, a marketing message

from somebody who doesn't understand what you do is almost never going to land. It just doesn't feel relatable. But if you talk to somebody who's done the thing that you do for work and they can tell you a story that's engaging about the thing that you do for work, you want to hear more. You, you know, you're looking for a community. And I think that DevRel, the aim was to sort of create that community and give people a space to hang out with the added bonus of putting the company that employs that DevRel as an adjacent player to get some of that extra shine from wherever this community is doing well. I feel like 2019 was peak DevRel. And that's where I started to really see that you had effectively, a lot of community conferences were taken over by DevRel. And you wound up with DevRel pitching to DevRel.

And it became so many talks that were aligned with almost imagined problems. I think one of the challenges of working in DevRel is if you're not careful, you stop being a practitioner for long enough that you can no longer relate to what the audience is actually dealing with. I can sit here and complain about data center travails that I had back in 2011, but are those still accurate in what's about to be 2024? Probably not. And I think the other problem that happens too is that when you work in DevRel, you are beholden to the company's goals if the company employs you. And where I think we got really wrong is companies have to make money. We have to charge customers or the company ceases to exist.

So when we go out and tell stories, we're encouraged by the company to focus on the stories that have the highest ROI for the company. And that means that I'm up on stage talking about some far future, large-scale enterprise thing that very few companies need, but most of the paying customers of my company would need. And it becomes less relatable. And I think that that leads to some of the collapse that we saw that you mentioned, where dev events feel less like they're for devs and more like they're partner events, where DevRel is talking to other DevRels trying to get opportunities to schmooze partners and grow our partner pipeline. That's a big part of it, where it seems on some level that so much of what DevRel does, when I see them talking about DevRel, it doesn't get around to what DevRel is. Instead, it gets stuck in the weeds of what DevRel is not. We are not shills

for our employer. Okay, I believe you, but also I don't ever see you saying anything that directly contravenes what your employer does. Now, let me be clear, neither do I, but I'm also in a position where I can control what my employer does because I have the control to move in directions that align with my beliefs. I'm not saying that it's impossible to be authentic and true to yourself if you work for an employer, but I have seen a couple of egregious examples of people changing companies and then their position on topics they'd previously been very vocal on pulled an entire 180, where it really left a bad taste in my mouth.

Yeah, and I think that's sort of the trick of being a career dev rel, is you have to sort of walk this line of realizing that a DevRel career is probably short at every company. Because if you're going to go there and be the face of a company and you're not the owner of that company, they're almost inevitably going to start moving in a direction as business develops that's not going to line up with your core values. And you can either decide like, okay, that's fine. They pay me well enough. I'm just going to suck it up and do this thing that I don't care about that much. Or you have to leave. And so if you're being honest with yourself and you know that you're probably going to spend between 12 and 24 months at any given company as a dev rel, which by the history I'm seeing, that seems to be positioning and talking about things in a way that isn't painting you into that corner where you have to completely about face if you switch companies.

But that also works against your goals as a DevRel at the company. So it's, I think we've made some big mistakes in the DevRel industry, but I will pause to take a breath here. No, no, it's fine. It's weird that I view a lot of what I do as being very similar to DevRel, but I would never call myself that. And part of it is because it, for better or worse, it is not a title that tends to engender a level of respect from business owners, decision makers, etc. Because it is such a mixed bag.

You have people who have been strategic advisors across the board becoming developer advocates. That's great. You also see people six months out of a boot camp who have decided they don't like writing code very much. So they're going to just pivot to talking about writing code. And invariably, they believe more or less whatever their employer tells them because they don't have the history and the gravitas to say, wait a minute, that sounds like horsepucky to me. And it's a very broad continuum. I just don't like blending in. Where I think we got a lot of this wrong is that we never did define what DevRel is. As you say, we mostly define what DevRel is not. And that puts us in

a weird position where companies see other companies do DevRel. And they mostly pay attention to the ones who do DevRel really well. And they or their investors or other companies say, you need a great DevRel program. This is the secret to growth. Because we look at companies that have done it effectively, and we see their growth, and we say, clearly, this has a strong correlation. We should invest in this.

But they haven't done it themselves. They don't understand which part of it is that works. So they just say we're hiring for DevRel. The job description is nine different careers in a trench coat and the people applying. Oh, absolutely. It's nine different things. And people wind up subdividing into like, I'm an events planner. I'm not a content writer. Right. Okay, great. But then why not bill yourself as an events planner and not have to wear the DevRel cloak? Exactly. And this is sort of what I've seen is that when you put up a DevRel job, they list everything. And then when you apply for a DevRel job, you also don't want to paint yourself into a corner and say, my specialty is content or my specialty is public

speaking or whatever it is. And therefore you say, I do DevRel to give yourself more latitude as an employee, which I obviously, I want to keep optionality anywhere I go. I would like to be able to evolve without being painted into a small box of like, this is all I'm allowed to do. But it does put us in this really precarious position. And what I've noticed a lot of companies do is they hire DevRel, undefined, poorly written job description, poor understanding of the field. They get a dev rel who has a completely different understanding of what dev rel is compared to the people with the role open. Both of them think they're doing dev rel. They completely disagree on what those fundamentals are. And it leads to a mismatch, to burnout,

to frustration, to this high turnover rate in this field. And everybody then starts to say, well, DevRel is the problem. But really the problem is that we're not, we're defining a category, not a job. And I think that's the part that we really screwed up as an industry. Yeah.

I wish there were a better way around there, but I don't know what that might be. And because it requires getting a bunch of people to change some cornerstone of what's become their identity. This is the part where I, this is probably my spiciest take, but I think that DevRel is marketing, but it is a different kind of marketing. And so in a perfect world, like where things start to fall apart is you try to slot DevRel into engineering or you try to slot it into marketing as a team on these broader organizations. But the challenge then becomes, if you have DevRel in marketing, it will inevitably push more toward marketing goals, enterprise goals, top of funnel, qualified leads, etc. If you put them into engineering, then they have more engineering goals.

They want to do developer experience reviews. They want to get out there and do demos there. You know, it's, it's much more engineering focused, or if you're doing it right, it's much more engineering focused, but the best DevRel teams are doing both of those with a really good measure and really clear metrics that don't line up with engineering or marketing. So in a perfect world, you would just have a enterprise marketing team and a developer marketing team. And that developer marketing team would be an organization that is DevRel today. And you would hire specialists, event planners, great speakers, great demo writers, probably put your docs team in there and treat it as an actual responsibility that requires a larger team than just three or four

ex-developers who are now speaking at conferences. There were massive layoffs across DevRel when the current macroeconomic correction hit, and I'd been worried about it for years in advance because so many of these folks spent so much time talking about how they were not marketing. They were absolutely not involved in that. But marketing is the only department that really knows how to describe the value of these sorts of things without having hard metrics tied to it. DevRel spent a lot of time talking about how every metric used to measure them was somehow wrong. And if you took it to its logical conclusion, you would basically give these people a bunch of money because they are expensive and about that much money again, an annual budget

to travel more or less anywhere they want to go. And every time something good happened as a result to the company, they had some hand in it nebulously, but you could never do anything to measure their performance or just trust that they're doing a good job. This is tremendously untenable.

Mm-hmm. Yeah, I think when I was running the developer experience org at Netlify, most of my meetings were justifying the existence of the team because there weren't good metrics. You can't put sales qualified leads on DevRel. It doesn't make any sense because there are too many links in the chain after DevRel opens the door where somebody has to go from, I'm aware of this company to I've interacted with the landing page to, to I've actually signed up for something, to now I'm a customer, before you can get them to a lead. And so to have DevRel take credit is actually removing credit from the marketing team. And similarly, if somebody goes through onboarding, a lot of that onboarding can be guided by DevRel.

The APIs that new developers interface with can be, the feedback can come from DevRel. But ultimately, the engineering team did that work. The product team did that work. So DevRel is this very interesting thing. I've described it as a turbocharger, where if you put it on an engine that runs well, you get better performance out of that engine. If you just plop one on the table, not a lot happens.

Yeah, it's a good way of putting it. I see very early stage startups looking to hire a developer advocate or DevRel person in their seed stage or series A, and it's, there's something else you're looking for here. Hire that instead. You're putting the cart before the horse. What a lot of people saw is they saw, what they're thinking of as DevRel is what they saw from very public founders. And when you get a company that's got this very public facing, very engaging, charismatic founder, that's what DevRel feels like is, you know, this is the face of the company. We're showing you what we do on the inside. We're exposing our process. We're

sharing the behind the scenes and proving to you that we really are great engineers and we care a lot. Look at all this cool stuff we're doing. And that founder up on stage was, I think, the original DevRel. That's what we used to love about conferences is we would go there and we would see somebody showing this thing they invented or this new product they had built. And it felt so cool because it was these inspirational moments of watching somebody brilliant do something brilliant. And you got to follow along for that journey. And then we tried to-

Yeah, I mean, that's natural, but you see booths at conferences, the small company startup booths, a lot of times you'll be able to talk to the founders directly. As the booths get bigger, your likelihood of being able to spend time talking to anyone who's materially involved

in the strategic direction of that company gets smaller and smaller. Like the CEO of GitHub isn't going to be sitting around at the GitHub booth and reinvent. They're going to be, you know, talking to other folks if they're there and going to meetings and whatnot. And then you wind up with this larger and larger company. It's a sign of success, truly. But it also means that you've lost something along the way. Yeah, I think, you know, it's the perils of scale.

And I think that when you start looking at the function of DevRel, it should sort of be looked at as like, when we can't handle this anymore by ourselves, we should look for a specialty the same way that you do for any other function inside of a company. It wouldn't make sense on day one of a startup to hire a reliability engineer. You're not at the point where that makes sense. It's a very expensive person to hire and you don't have enough product or community or load to justify that role yet. And hopefully you will. And I think DevRel is sort of the same way. Like when you first start out your company, your DevRel should be the founding team. It should be your engineers

sharing the things that they're building so that the community can see the brilliance of your engineering team sharing with the community, obviously being invested in that community. And when you get big enough that those folks can no longer manage that and their day-to-day work, great. Then look into adding specialists. But I think you're right that it's cart before the horse to make a dev rel your day one hire that you just don't have enough yet. Yeah. I wish that there were a, an easy way to skin the cat. I'm not sure there is. I think instead we wind up with people doing what they think is going to work, but I don't know what the truth is. That's where I land on it. Yeah. I mean, every company is, is unique and every experience is going to be unique. So I think to say,

do it exactly like this is that's got a lot of survivorship bias and, and do, as I mean, every company is unique and every experience is going to be unique. So I think to say, do it exactly like this, that's got a lot of survivorship bias and do as I say. But at the same time, I do think there are some universal truths. Like, it doesn't really make sense to hire a specialist before you've proven that that specialty is the secret sauce of your business. And I think you grow when it's time to grow, not just in case. I think companies that overhire end up doing some pretty painful layoffs down the road. And, you know, obviously there's an opposite end of that

spectrum where you can grow too slowly and bury your team and burn everybody out. But I think, you know, we leading into the pandemic, I guess we had a lot of free money and I think people were thinking, let's go build an empire and we'll grow into that empire. And I think that is a lot of why we're seeing this really painful downsizing right now as companies hired just in case and then realized they actually that in case didn't come to be. What does the future of this look like? Easy enough to look back and say, well, that didn't work. Well, sure. What is the future? The playbook that we saw before in like 2019 and before was very event-driven, very webinar-driven.

And as we went into 2020 and people were at home, we couldn't travel. We got real sick of Zoom calls. We don't want to get on another video call again. And that led to that playbook not working anymore. I don't want to get on a webinar with a company. I don't want to go travel to a company event, you know, or at least not very many of them. I want to go see the friends I haven't seen in three years. So travel priorities changed. Video call fatigue is huge. So we need something that people want to do that is interesting and that is, you know, it's worth making in its own right so that people will engage with it. And then you work in the company goals as an incidental, not as a minor incidental, but it's got to be part of the story. It can't be

the purpose. People won't sign up for a webinar willingly these days, I don't think, unless they have exactly the problem that your webinar purports to solve. And even if they do, it becomes a different story. Right. It's high buying signal, but people are constantly besieged by requests for attention. This is complicated by what I've seen over the last year. When marketing budgets get cut, arguably too much, but okay, you see now that there's this follow-on approach where, okay, what are we going to cut? And people cut things that in many cases work, but are harder to attribute success to. Events, for example, are doing very well

because you have someone show up at your booth. You scan their badge. Three weeks later, someone from that company winds up signing up for a trial or whatnot. And ah, I can connect those dots. Whereas you advertise on, I don't know, a podcast as a hypothetical example that I'm pulling out of what's right in front of me.

And someone listening to this and hearing a message from a sponsor, they might be doing something else. They'll be driving, washing dishes, et cetera. And at best, they'll think, okay, I should Google that when I get back to a computer. And they start hearing about it a few times and, oh, okay, now it's time for me to go and start paying serious attention to this. Cause that

sounds like it aligns with the problem I have. They're not going to remember where they initially heard it. They're going to come in off of a Google search. So it sounds like it's all SEO's benefit that this is working and it's, it is impossible to attribute. I heard some marketer once say that 50% of your marketing budget is wasted, but you'll go bankrupt trying to figure out which half. It all ties together. But I can definitely see why people bias for things that are more easily attributed to the metric you care about. Yes.

And I think that this is where I see the biggest opportunity because I think that we have to embrace that marketing signal is directional, not directly attributable. And if you have a focused campaign, you can see your deviation from baseline signups and general awareness and all of the things that you want to be true. But you have to be measuring that thing, right? So if we launch a campaign where we're going to do some video ads or we're going to do some other kind of awareness thing, the goal is brand awareness. And you measure that through like, does your name get mentioned on social media? Do you see a deviation from baseline signups where it is trending upward? And each of those things is signal that the thing you did worked. Can you directly attribute it? No. But I think a functional team can, you know, we did this at Netlify all the time where we would go and look, what were the efforts that were made? What were the ones that got discussion on different social media platforms? And what was the change from baseline? And we saw certain things always drove a non-trivial deviation from baseline in the right direction. And that's one of the reasons that I think the future of this is going to be around,

how do you go broader with your reach? And my big idea to nutshell it is like dev TV. I think that developers want to see the things that they're interested in, but they want it to be more interesting than a straight webinar. They want to see other developers using tools and getting a sense of what's possible in an entertaining way. They want stories. They don't want straight demos. So my thinking here is, let's take this and steer into it. We know that developers love when you put a documentary together. We saw the Vue documentary and the React documentary and the GraphQL documentary and the React documentary and the GraphQL documentary and the Kubernetes documentary

coming out of the Honeypot team. And they've got hundreds of thousands and in some cases, millions of views because developers really want to see good stories about us, about our community. So why not give the dev community a Great British Bake Off, but for web devs? Why not create an Anthony Bourdain

Parts Unknown style travel show that highlights various web communities? Why not get out there and make reality competition shows and little docu-series that help us highlight all the things that we're learning and sharing and building? Every single one of those is going to involve developers talking about the tools they use, talking about the problems they solve, talking about what they were doing before and how they've made it better. That's exactly what a webinar is. That's what a conference talk is. But instead of getting a small audience at a conference or 15 to 30 people signing up for your webinar, now we've got the potential for hundreds of thousands or even millions of people

to watch this thing because it's fun to watch. And then they become aware of the companies involved because it's presented by the company. They see the thing get used or talked about by developers in their community. I think there's a lot of magic and potential in that. And we've seen it work in other verticals. And part of the problem comes down as well to the idea that, okay,

you're going to reach some people in person at events, but the majority of engineers are not going to be at any event, or any event at all, for that matter. They just don't go to events for a variety of excellent reasons. How do you reach out to them? Video can work, but I always find that requires a bit of a different skill than, I don't know, podcasting or writing a newsletter. So many times it feels like it's, oh, and now you're just going to basically stare at the camera, maybe with someone else. And it looks like the Zoom call to which the viewer is not

invited. Right. They get enough of that. There has to be something else. And I think this is where the, the new skillset I think is going to come in. It exists in other places. We see this happen in a lot of other, of other industries where they have in-house production teams. They're doing collaborations with actors and athletes and bringing people in to make really entertaining stories that drive underlying narratives. I mean, there's the ones that are really obvious, like the Nikes of the world, but then there are far less obvious examples. Like there was this show called Making It. It was Nick Offerman and Amy Poehler were the hosts. It was a same format as the Great British Bake Off,

but around DIY and crafting. And one of the permanent judges was the Etsy trend expert, right? And so every single episode, as they're judging this, the Etsy trend expert is telling all of these crafters and contestants, you know, what you built here is always a top seller on Etsy. This is such a good idea. It's so well executed and people love this stuff. It flies off the shelves in Etsy stores. Every single episode, just perfectly natural product placement where a celebrity that you know, Nick Offerman and Amy Poehler are up there lending like you want to see them. They're so funny and engaging.

And then you've got the credibility of Etsy's trend expert telling the contestants of the show, if you do DIY and crafting, you can make a great living on Etsy. Here are the things that will make that possible. It's such subtle but brilliant product placement throughout the entire thing. We can do that. We have the money. We just spend it in weird places. And I think that as an industry, if we start getting more creative about this and thinking about different ways we can apply these marketing dollars that we're currently dumping into very expensive partner dinners or billboards or getting custom swag or funding yet another $150,000 conference sponsorship, we could make a series of a TV show for the same cost as throwing one community event and we would reach a significantly larger group. Yeah. Now there is the other side of it too, where Lord knows I found this one out the fun way, that creating content requires significant effort and focus and, oh, it's a five minute video. Great.

That could take a day or three to wind up putting together done right. One of the hardest weeks of my year is putting together a bunch of five minute videos throughout the course of reInvent. So much of that is done in advance. That is basically breaking the backs of the editing team who are phenomenal, but it still turns into more than that, where you still have this other piece of it of the actual content creation part. And you can't spend all your time on that because pretty soon I feel like you become a talking head who doesn't really do the things that you are talking to the world about. And that content gets pretty easy to see when you start looking at,

well, okay, what does someone actually do? Oh, they were a developer for three years and they spent the next seven complaining about development and how everyone's doing it wrong on YouTube. It starts to get a little, how accurate is this really? So for me, it was always critical that I still be hands-on with things that I'm talking about because otherwise I become a disaster.

And I agree. One of the things that my predecessor at Netlify, Sarah Drasner, put in place was what she called an exchange program, where we would rotate the DevRel team onto product and we rotate product onto the DevRel team. And it was a way of keeping the developer experience engineers actually engineers. They would work on the product. They didn't do any DevRel work. They were exclusively focused on doing actual engineering work inside our product to just help keep their skills sharp, keep them up to date on what's going on, build more empathy for the engineers that we talk to every day, build more empathy for our team instead of us. You never want to hear a DevRel throw the engineering team under the bus for not shipping

a feature everybody wants. So these sorts of things are really important and they're hard to do because we had to, you know, that's a lot of negotiation to say, Hey, can we take one of your engineers for a quarter and we'll give you one of our engineers for a quarter. And you got to trust us that that's going to work out in your favor, right? Like there's a, there's a lot that goes into this to make that sort of stuff possible. But I absolutely agree. I don't, I don't think you get to make this type of content. If you fully stepped out of engineering, you have to keep it part of your, your practice. There's no way around it it. You have to be hands-on. I think that's the right way to do it. Otherwise it just leads to frankly disaster. Very often you'll see people who are like, oh,

they're great in the DevRel space. What do they do? And they go to two or three conferences a year and they have a blog post or so it's like, okay, what are they doing with the rest of that time? Sometimes the answer is fighting internal political fires. or so it's like okay what are they doing the rest of that time sometimes the answer is fighting internal political fires other times it's building things and learning these things and figuring out where they stand there are some people i don't want to name names although an easy one is kelsey hightower who has since really left the stage that he's retired but when he went up on stage and said something despite the fact that he worked at google it was eminently clear that he believed in what he was saying or or he would not say it. He was someone who was very clearly aware of the technology about which he was speaking. And that was great. I wish that it were not such a standout moment to see him

speak and talk about that. But unfortunately, he kind of is. Not as many people do that as well as we'd like. Agreed. I think it was always a treat to see Kelsey speak. And there are several others that I can think of in the community who, when they get on stage, you want to be in that audience and you want to sit down and listen. And then there are a lot of others who, when they get on stage, it's like that this book could have been a blog post or this could have been an email, that kind of thing. Like you could have sent me this repo because all you did was walk through this repo line by line or something that it doesn't feel like it came from them. It feels like it's being communicated by them. And I think that's, again, like when I criticize conferences, a lot of my criticism comes from the fact that coming up, I feel like every speaker that I saw on stage, and this is maybe just memory playing favorites for me, but I feel

like I saw a lot of people on stage who were genuinely passionate about what they were creating and they were genuinely putting something new into the world every time they got on stage. And I have noticed that I feel less and less like that. Also, I feel like events have gotten less and less likely to put somebody on stage unless they've got a big name DevRel title. Like you have to work at a company that somebody's heard of because they're all trying to get that draw because attendance is going down. And right. It's a, like having run some conferences myself, the trick is, is you definitely want some ringers in there. People, you know, will do well, but you also need to

give space for new voices to arise. And sometimes it's a, it always bugs me when it's, it seems like, oh, they're pure because their company's a big sponsor. Of course they have the keynote. Other times it's a, I hate the actual shill talks, which I don't see as much, which I'm thankful for. I'd stop going to those conferences, but geez. Yeah. And I think it's definitely one of those, like, this is a thing that we can choose to correct. And I have a suspicion that this is a pendulum, not a, not like the denouement of, is that the right way you say that word? Denouement, denouement, whatever. Denouement is my understanding, but that might be the French element. Absolutely butchering that. Yeah. I don't think this is the end of conferences. Like we're seeing them taper into oblivion. I think this is a lull. I think that we're going to realize

that we want to, we really do love being in a place with other developers. I want to do that. I love that, but we need to, we need to get back to why we were excited to go to conferences in the first place, which was this sharing of knowledge and inspiration where you would go see people who were literally moving the world forward in development and creating new things so that you would walk away with insider info. You had just seen the new thing up close and personal, had those conversations, and you went back so jazzed to build something new. I feel like these days, I feel more like I went and watched a handful of product demos and now I'm really just waiting to the hallway track, which is the only the only like actually interesting part at a lot of events these days. 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?

Most of what I share is on learnwithjason.dev. Or if you want a big list of links, I have jason.energy slash links, which has a whole bunch of fun stuff for you to find. Awesome. And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it.

Yeah, thanks so much for having me. This was a blast. Jason Langsdorf, developer media producer at Learn With Jason. 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 that will no doubt become the basis for somebody's conference talk.

If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.