The Changelog: Software Development, Open Source - What even is a DevRel? (Interview)

Episode Date: June 20, 2022

This week Lee Robinson joins us to talk about his journey as a DevRel. We talk about what it means to be a DevRel, what orgs they fall under, how he runs his team at Vercel, Lee's three pillars of DevRel: education, community, and product, we compare the old days of DevRel vs now, and of course what makes a DevRel a good DevRel.

Welcome, friends. On this episode, Adam and I are joined by Lee Robinson to talk about his journey in developer relations. We discuss what it means to be a DevRel, what orgs they fall under, how he runs his team at Vercel, Lee's three pillars of DevRel, education, community, and product. We compare the old days to now, and of course, what makes a DevRel pillars of DevRel, education, community, and product. We compare the old days to now. And of course, what makes a DevRel a good DevRel? That's a whole lot of DevRel. Special thanks to our partners at Fastly for shipping our shows super fast to wherever you

listen. Check them out at Fastly.com. Okay, Lee Robb on the changelog. Let's go. to support Square sellers by building apps for today's business needs. And I'm here with Shannon Skipper, Head of Developer Relations at Square. Shannon, can you share some details about the opportunity for developers on the Square platform? Absolutely. So we have millions of sellers who have unique needs. And Square has apps like our point of sale app, like our restaurants app. But there are so many different sellers, tuxedo shops, florists, who need specific solutions for their domain. And so we have a node SDK written in TypeScript that allows you to access all of the backend APIs and SDKs that we use to power the billions of transactions that we do annually.

And so there's this massive market of sellers who need help from developers. They either need a bespoke solution built for themselves on their own node stack, where they are working with Square Dashboard, working with Square Hardware, or with the e-com, what you see is what you get builder. And they need one more thing. They need an additional build. And then finally, we have the app marketplace where you can make a node app and then distribute it so it can get in front of millions of sellers and be an option for them to adopt. Very cool. All right. If you want to learn more, head to developer.squareup.com to dive into the docs, APIs, SDKs, and to create your Square Developer account.

Start developing on the platform sellers trust. Again, that's developer.squareup.com. all right we have lee Lee Robinson here from Next. JS from Vercel. Hey. What's up, Lee? Thanks for having me. I'm really excited to come on and chat. We're excited to have you.

Now, I only ever have known you online as Lee Rob, which is like a bunch of E's. And I'm curious if Lee Rob is like your, just your online handle or has it trickled into the real world? Yeah, it's really funny. The first time I heard someone call me Lee Rob in real life was kind of funny.

It's the breakdown of your online persona to your real persona actually happened. But the context there is, you know, my name's Lee Robinson. Lee Rob's the combination of first and last name. Tried to find some kind of online handle that was unique. And it also related back to the domain name I was trying to grab. So I have leerob.io. And yeah, so people, my friends call me Lee. My coworkers all call me Lee Rob, but I really don't. It doesn't matter to me. It doesn't matter. So Adam, do people call you Adam Stack?

I think there's a few, yeah. I think I've called you that before, probably. They don't often call me Adam Stack. They'll call me Stack. Something with Stack. My nickname will either be Stack or Stacks. In the military, it was Stacks. Does anybody call you Daddy Fat Stacks? No. I might like that, though. That's kind of a cool nickname, I think.

Daddy Fat Stacks. I might start calling you that. Does that mean I got mad money or what? That's the hope, yeah. Okay. You got fat stacks. I'll take it, yeah. Whatever the stack I'm stacking, it'll be fat.

Well, we'll just leave that right there where it sits. So Lee Rob is with three E's, is that right? So Lee E E E Rob is your Twitter handle, at least. Lee Rob I O is not three E's. It's with three E's. Is that right? So Lee E E E Rob is your Twitter handle at least. Lee Rob IO is not three E's. It's just two E's. Yeah. Somebody on Twitter scooped up the. There's a chink in the armor.

Yeah. That's the only one that I don't have it. And the person who has it with two E's, like the account is suspended or something too. So I can't even. Can't even get it. You can petition for that. I'm sure. Maybe there's a way. You get that blue check mark, you can do whatever you want. That's right. Yeah, I don't know. We'll see. You're on your way.

Listen up, if you're a Twitter employee, hook up Lee. Let's get rid of that 30. It's cleaner. Let's compress that thing. That's right. It's like dropping the duh. We've been there before. Well, we have you here today. We should mention that you are not just a DevRel ever sell, you're director of DevRel, which I assume is even cooler. And we want to talk about DevRel. We had a listener write in. Now, I believe his name is Gustav Jorlov, but I'm going to give Gustav a little bit

of a hard time because, you know, on our forum where you request a show, we have another section for on-air credit where you can actually put the pronunciation of your name. And Gustav just put the exact same, he just put his name twice. Don't get it. Don't get it. Don't worry. I'll usually apologize for mispronunciations. I'm not going to apologize this time, Gustav.

You had an opportunity to help me out, but you didn't. Nonetheless, he asked to have you on the show. He wanted us to talk about DevRel. We talk to DevRels a lot. We talk around DevRel a lot. We've never talked about developer relations as a thing. So that's why you're here, Lee. Ever.

No. Ever. 13 years of history. Zero. Zero. Discussion of the actual title slash anything. I mean, nothing. Right.

Really. So we'll ask you. You can open it up. What even is a DevRel? Yeah. The meta conversation of what is DevRel. Yeah. Yes. Yeah. So the way that I run my developer relations team focuses on three different things. The first is around education. The second is around community. And the third is around the product. Now, the way DevRel teams or organizations are structured at companies kind of depends on where it falls in that company's priorities. So for a developer tooling company, right, where they're bread and butter,

like their main focus is talking to developers, it's probably going to have an elevated position in the company because it's incredibly important to their business and to their community. Maybe if the company is just like they have an API as part of their products, but that's not like the main thing they do. They might have a developer relations team who's helping with the adoption of the API and ensuring that people are successful with it, but it's not the main thing. So I like to give that caveat because it's hard to give a singular definition of what DevRel is, but there's multiple flavors we can be inspired from for teams who are trying to figure out, okay, how do I want to get into this space or how do I want to structure my organization to support developer communities? I talked to a lot of startup founders, early stage companies who are talking to me about when should I hire a DevRel? When should I hire these people to build

our communities or to help educate developers? And it gets tricky because not all companies are the same. It requires a little bit of nuance to dive into there. So to reel it back just a little bit back to the three pillars I talked about of kind of education, community, and product, I can dive into each one of those independently. So let's start with the first one of education. Vercel is a company that's like a front-end platform. You can deploy your code, build, deploy code, host around the world. And because of that, we also have frameworks like Next.js that allow you to write your code. So the nature of the products requires education. We have to teach developers how to use these tools. It's not always immediately obvious how you would build a global application.

Maybe you need some guidance along the way. And I think that education for developers is deeply rooted in basically everything we do. As we got started learning how to code, education was important. And being a lifelong learner or a continual learner is so rooted in the development journey, especially for web developers, where the types of technology go through cycles and you're learning new things over the years and kind of iterating on your knowledge and learning new techniques. So it's important that you're helping guide developers along the journey and teaching them the tools and the tricks that they need to be successful with the product. The second pillar I think a lot about is community,

because you can't, it's harder to replicate a community. Like you can purchase a product, you can, you know, acquire an audience, but that doesn't automatically mean you have a community. Community building requires dedicated effort and attention. And I think it's one of the most, the highest leverage things a developer focused company can have. If you have a community of developers who love your product, they kind of do the job for you. They advocate for your product for you. They're your outsourced DevRel team at that point, right? They're talking to the community about, wow, this product is amazing. You should be using it. And they love it so much that maybe they go talk to other developers about it.

And being very intentional about growing that community is a very important part of what a lot of DevRel teams focus on. And then the third one, and just a quick summary, and then the third one is really how it all relates back to the product. And I think it's important that developer relations roles or developer experience or developer advocate, there's multiple titles we can get into that nuance. All of these roles

play some part in giving feedback on what works well and maybe what's not very good on the product. And I think it's important to get that feedback internally before you hear it from your customers. So for example, if we're releasing a new product or a new feature, I would rather have some engineers internally who have this critical eye for what a good developer experience looks like, walk through the product, try to figure out how things could be broken, where beginners might struggle, where advanced people might struggle and get that feedback before we release it to everybody. And there's this continuous feedback loop

of community pain point, how do we solve it in the product? You know, community struggle, how do we better create educational material to help prevent that from happening in the future? Mm-hmm. In a lot of ways, it's a very nuanced dance between how to innovate and iterate and how to, you know, literally educate. But then also take that feedback because, I mean, that feedback assumes and sort of requires this person or many people to have empathy for

the direction the community's trying to go yeah and i think in particular because we kind of know vercell story and we should also say we have vercell as a sponsor of jsparty yeah not a sponsor of this show in particular that's not why you're on this show we truly are deeply uh i've known guillermo for many years guillermo i've been recently told that's exactly how you say his name but i've been calling him guillermo for many many years incorrectly of course yeah now I'm just going to say Guillermo every single time, but I've known him many years. Jared, you and I met up with him in San Francisco years ago. We went out to just meet up and we shared early days of our website and the direction.

So he's been in the community forever, you know, for a very long time. And I've been tracking his career and we have as an organization. But when you have, you know, the inertia of Rassel being make the web faster, that's sort of your, you know, the direction of your product, right? And so you're going to kind of pull community because you're trying to innovate and iterate the literal web and the way you do it is with your platform. And the way you also do it is with your software that enables a platform in the community that wants to build for the web. What I'm trying to make, though, is just that it's pretty interesting how you have to have this dance and this empathy and this sort of middle ground people that care to enable that feedback loop as necessary. What gets challenging is when, in your case, the organization is set up right.

The way you're directing it is right. What gets sort of like hard to believe or hard to trust is when there's KPIs and OKRs and sort of like salesy things attached to that organization. Where do you sit with that? What has been your experience with other dev rels that have these ambiguous, weird attachments like OKRs and KPIs and like sales-related goals attached to that feedback loop

that's so necessary for a dev-focused organization like Vercel? Yeah, going back to the first part of your question around empathy, that's actually one of the most critical things that I look for when I'm trying to hire people and I think is what separates great developer relations teams from maybe those who are just okay, is that you have to really care about the product that you're advocating for and the community that you're a part of. Like when I see people struggling with the product, I generally want to know what we can do better and how we could take that feedback and use it to provide a better experience. And you have to address that with a empathetic beginner's mindset

because not everybody has the context that you might have on years of using the product or years of being a front-end developer or a back-end developer. You have to embrace that. This is my first time learning how to code. Somebody told me I needed to learn Next.js. Now I'm reading the docs. What is this thing? I've never heard this term before. And like trying to solve for that case as well too. But then coming back to your question about

how do you define and measure success for developer relations? There's a few good resources out there right now that I'm fond of. And I think part of this question ties back to the organizational structure that sets up a DevRel team for success. So for example, if a DevRel team is under product, if they're under marketing, if they're under sales, if they're under their own organization, those KPIs and metrics might all be a little bit different. I think Swix has a good blog post about measuring developer relations

that I'd recommend checking out for those listening in. My view is that I'm not a big fan of the vanity metrics like a, this got 10,000 blog post views, or this got 200 retweets. Those are a by-product of making a good product and fostering a good community. So if you invest in listening to your customers and where they're succeeding and maybe where they're not, taking that negative feedback and incorporating it into building a better product and a better experience for those developers. The byproduct of that is the attribution towards more blog post views, more tweets, more engagement on Facebook or LinkedIn or whatever social platform you want. So personally, I don't think it makes as much sense for me as the

North Star of the metrics to look towards those traditional marketing focused KP personally, I don't think it makes as much sense for me as the North Star of the metrics to look towards those traditional marketing focused KPIs, I guess. I do think it is interesting to think about some of the sales goals, because at the end of the day, you're building a community of developers who are excited about a product. And that product is probably something that you pay for. And I don't think that you should be too abstracted from the reality of this is a product that people pay for. I think if you go too far in the other direction, you're actually doing a disservice to your community because you're almost being, you're being disingenuous about

the reality of what makes the business sustainable. So in the context of like a Vercel or a hosting platform, you know, we have a free tier. There's always a free tier. It's always going to enable developers to get started, build applications and be able to put content basically online around the globe really fast. And that works really great for, you know, many, many developers. But then there's also a part of our business that's catering to teams that pay, whether that's customers on like our pro tier or enterprise customers. And I think you're also

enabling those developers because they're also part of your community. Just because they're on an enterprise deal doesn't mean that they're not deeply embedded and care a lot about the community's success. It's interesting to see this role formalized so much so that you have a director of the role and so you have a fleet of dev rels. I'm sure Verso is not the only organization that has multiple dev rels, fleets of dev rels. It feels like a newish thing. I went to Wikipedia, did some reading, and it turns out no. Apple invented this back in the 80s. They called them software evangelists back then. It's this thing that's evolved and changed

over time and become more formal, become more obviously valuable for organizations to employ this type of a role or this set of roles, which really is like you said, community education and product, three distinct things that all work together. I'm curious your history though. Like how did you get into DevRel and what made you attracted to this kind of a role and then also make good at it? Like why would you get moved up to director of DevRel unless you were good at it? So I assume you are. Yeah. So what got me into DevRel was actually a long journey. So prior to joining DevRel, I had been working as a product engineer for many years

and primarily focused on the front end. And I've always really loved front end development. When I was learning how to code in college or university, I didn't really enjoy it until we started to use web development. And that was when I had this light bulb moment of, I can put code online and share it with anybody behind this URL. I looked at mobile apps and I was like, well, this process is overly complex versus just deploying and getting a URL and having it out there. And for the first good chunk of my career, I was really focused on just becoming the best front end developer I could possibly be. So that was going from individual contributor to leading a team of developers working on an e-commerce site. And at the same time, I've always really enjoyed the intersection between development and everything else that needs to happen at the company, which is ironic because I haven't worked at

a startup until I worked at Vercel. So I had seen some examples of how it doesn't work well when the development team is so siloed away from the other parts of the business. I get a lot of enjoyment out of the intersection between development and marketing and sales and product and all of these pieces that actually enable an end-to-end great experience. So that's some of my history that's led to me exploring what was DevRel before I knew it was DevRel. So I, because of my enjoyment of the intersection between these things and just a general enjoyment of helping teach others, whether that was writing or in-person, helping pair with other developers,

I started to kind of just create content and put it out there as my own person, as Lerop. I put out content online to help developers succeed with React or front-end, CSS, Next.js, whatever they wanted to use. And it was towards the relative beginning of Next.js. I think Next.js was created in 2016. And about 2018 is when I was starting to use Next.js at my previous company to help them build out their e-commerce experience. And at the time, with any new tool, there's just

not that much information out there or educational material to help developers succeed. And I thought, well, you know, I enjoy doing this stuff. I like writing. I like teaching developers how to succeed with this stuff. If this content isn't out there, why don't I just make it? Like, no, that's the great thing about the internet is that it's permissionless. I can publish that blog post if I want to, I can create that resource. And I, so I did. So I started making content, YouTube videos, blog posts, all sorts of stuff, courses to enable developers to really succeed. And eventually that wound its way towards me getting a job at Vercel to kind of further continue that goal. A key word you've said there a couple of times is succeed, which I think is kind of critical

to defining that DevRel role well, because like you had said, you can't hide the metrics of, you know, let's say a sales goal or something like that. Maybe that's where like you can get a little bit tricky, but being able to succeed in terms of helping the developer succeed, that's kind of key, right? Yeah. Which is naturally going to lead to a business success, succeed again. Right. Right. Cause that's a natural feedback loop to positive outcomes. You know what I mean? That's, That's kind of critical to the role. If you think about it like this, it doesn't matter if you spend millions of dollars on marketing, if the developer goes to the blog post and they say, all right, click here to try it out. And they go try out the product and it just doesn't work, then what are we doing here? You

know, like what was the point of all this? What was the point of all this work? It has to be in service of the success of the developer. And that's a very nuanced thing too, because it's not always just, was I able to get X thing done? It also might be, did I understand what I'm doing? Do I understand the context of this? Am I actually using it for the right thing? Am I providing the right resources to help this developer succeed with what they're trying to get done?

It kind of reminds me, too, of this inspiration of curiosity. You know, there's times I'll have this really cool tool. I'll be ambiguous in this case. And I have no idea what to do with it. I know it's got lots of capabilities, but I've got my own use cases, but I'm sort of like siloed and, you know, minimized by my own dreams, I suppose. And I almost need somebody else to help me dream bigger about the possibility. Oh, did you know this, this, and this could enable that? Yeah.

You know, so you're almost like a curiosity inspirer. And I almost think of it like a good analogy might be a box of Lego. You can get a box of Lego and you can watch Lego Masters on TV. And what they do with Lego may be way different than what you would do with the same box. that rel person, the dev rel or the Lego rel or somebody relling in there, this inspiration, this curiosity, here's the possibility of what you could do with this thing. And then also, and that might be the sort of community content piece of it, but also like, how do we learn from what you've done with it and hit those roadblocks or hit those anti-successes, those failures? And how can we improve the flow so that you don't have that hurdle, that roadblock anymore, your next try? Yeah, absolutely. This episode is brought to you by our friends at Fire Hydrant. Fire Hydrant is the reliability platform for every developer.

Incidents, they impact everyone, not just SREs. They give teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. What would normally be manual, error-prone tasks across the entire spectrum of responding to an incident, they can all be automated in every way with FireHydrant. They have incident tooling to manage incidents of any type with any severity with consistency, declare and mitigate incidents all from inside Slack. Service catalogs allow service owners to improve operational maturity and document all your deploys in your service catalog. Incident analytics

allow you to extract meaningful insights about your reliability over any facet of your incident or the people who respond to them. And at the heart of it all, incident runbooks, they let you create custom automation rules, convert manual tasks into automated, reliable, repeatable sequences

that run when you want. You can create Slack channels, Jira tickets, Zoom bridges instantly after declaring an incident. Now your processes can be consistent and automatic. The next step is to try it free. Small teams up to 10 people can get started for free with all Fire Hydrant features included. No credit card is required. Get started at firehydrant.io. started at firehydrant.io again firehydrant.io

let's go back a bit and talk about how this role has evolved. So not Wikipedia, 19-whatever. I can't go back that far personally, but we've been around as an organization since 2009, right? ChangeLog began around then, doing this 13-plus years. So our lens is around 13-ish years or more, not 25 or more. So I would say early dev roles that I'm aware of, the earliest might be, and this is by no means an exhaustive list, these are just like closer friends. Steve Klabnick was part of the changelog way back in the day. He used to be a host, used to be a contributor to the blog. The same with Kenneth Reitz,

who was also a contributor, host on the show etc etc and my experience with those two in particular was this level of burnout because the role kind of it did what you said but also kind of required a lot of speaking a lot of like real direct irl engagement yeah that meant flying that meant international flying in lots of cases. And then when JS Party came around, we had Rachel White on the show. Ojo, as she's called on Twitter. She's also a DevRel. I don't know if she still is anymore. I haven't caught up with her in a bit.

But similar, like this sentiment of like burnout, like always going kind of thing. Let's kind of go back and maybe share what your experience might be with this role and how it's evolved. It seems to have matured and maybe thanks to, in a spiteful way to COVID, that now we don't travel as much. We're kind of getting back to travel. This role sort of calmed down a bit and sort of maybe even had a chance to sort of reshuffle. What is your experience of like old days DevRel to like current modern day DevRel? And how's it changed? Yeah, so to first set the stage, I have been officially like by my job

doing DevRel now for two years and then unofficially probably since 2016, I guess. But if we go back to 2011, 2012, I, so I started to learn how to code in 2011. And at the time, the DevRel that I really remember was from the new API companies. It felt like a generational change or a big enough shift in the industry that it required education and awareness to tell people about a different way of doing things. And that was kind of, for my eyes, that was like 2011 to 2015. I feel like there was a massive rise in the number of API companies or companies providing things as a service. And to do that, they had these members of their community, whether it was called DevRel or not at the time, actually go out and go to in-person conferences, go to meetups, go to anywhere around the world and tell people about how the product works, how the thing works,

do a workshop on how to actually use the thing. And at the time too, another thing I've realized in talking to a lot of teams is a lot of DevRel actually came from founders back in the day. The early employees at companies were essentially doing the majority of the product and community side of DevRel. And then eventually it scales to a point where they don't have a full-time job to do that. At some companies that actually turns into the product org. Like the PMs are just very good about that outreach. And then at some developer-focused companies, they really lean into DevRel for that stuff.

So if we fast forward a little bit and get closer to today, I think the thing that's been really interesting kind of pre-COVID, post-COVID that I've seen was the community understanding that virtual or online has a place if done right. And I think the distinction there is it has to be done tasteful and respectful of people's time. So I'll give an example of where it's maybe people are a little burnt out about online. You know, of course, everyone was sick of going to many virtual events, many conferences online in the past few years. And if you were going to do any sort of developer outreach or socializing with your community, it had to be something unique to make them feel like it was

not just another Zoom call, right? And an interesting side effect of this, looking at purely from like the viewership or the amount of traffic that you got, a lot of teams realized, wow, we can actually get more traffic by doing this online. We have a global community. Instead of doing just this one event in New York or San Francisco or London, we can actually broadcast this everywhere and be inclusive of our entire global community. We don't necessarily need to do 57 meetups to get this community activated and engaged. And also, you mentioned burnout, I guess, of developer advocates or people who were traveling for their job. It could definitely be a strenuous position to have to basically just go around all year living on the road, giving conference talks, going to meetups, interacting with the community, especially for those, a lot of those people, I think too,

maybe that was a viable thing for them to do at that point in their life, at the 2012 era. I think a lot of the original DevRelians, the DevRel folk have kind of evolved into something else. A good example, somebody that I look up to a lot is Kelsey Hightower. I think that he has a very interesting role now where he is kind of like, he's evolved from DevRel and, you know, he had obviously done a lot of stuff before doing DevRel work

too, but to a, somebody who really holistically thinks about an incredible product experience. And I think if you look around the industry, some of the other people who were well-known in DevRel, a lot of them have transitioned to do other related things still in the same arena, but with a little bit more focus. So the summary of all this is that when I look at DevRel in 2022, you don't necessarily have to fly to every conference in the world. You don't necessarily have to do a hundred meetups. You can be a little bit more strategic

about when and where you want to do those things. But as we start to now get back to doing in-person events, which I've now spoke at, I think four this year so far, and I have a few more coming up here in the next couple of months. So it's, it's definitely picking up. There is a, a re-appreciation of just getting people in a room together too, that one, I think people just missed because of not being around others in a, in a setting for some time, but also there's, there's something to be said about, you know, getting together and just having a casual chat about development stuff, like just talking about tech, talking about development.

And, you know, sometimes it's hard to recreate that spontaneity when you're in a online event. So I guess my philosophy and where I'm kind of taking our DevRel team is that I want to do both. I still think there's a place for, when we have a global community of developers, it's not feasible for me or others on my team

to be flying around the world all the time to go to a bunch of events. And I know that some really large DevRel teams solve this by having lots of employees all around the world. We're not there yet, but I think there's still a place for in-person as well too. So we can have online and we can also still go to some events and conferences. What I, my experience with the online events, and I only took part in a handful of them throughout the two years starting that lockdown, was you get big numbers.

You get big sign-ups. You might even get big numbers in the actual room. But the level of attention and engagement, even for myself personally, I'm in the room. I signed up. I'm there. It's just another tab in my browser or just another Zoom window.

I'm also playing wordle or something like i just don't i don't feel any connection really yeah even less so than this three-person call right here because i don't have to participate maybe i can i can raise a hand i don't know it was very superficial but obviously it was necessary and the point you spoke to with the accessibility was of everybody right the lower barrier of entry for people who live halfway around the world from where a real life event would be held or whatever reason the timing their life like it and it allowed everybody to come which was awesome but once we were all there, for me, it was kind of like, meh. Fell flat.

And so I'm very excited about getting back out. And I think, obviously, I think what we learned as hybrid is awesome. Moving forward, trying to find the best from both circumstances, bring them together for better events. And then I like your idea of like, hey, make it when you can. Don't kill yourself to be there at every conference, right?

Because I think that's what really burned out a lot of folks in the before times was this desire to be at everything and speak at everything and blog all the time. And there was just no end in their mind of the workload. I think there's also too, a tricky conversation to understand in the world of DevRel is the distinction between the individuals and the companies. Yes.

And we can really go in depth further on this. The way I think DevRel is evolving is the people who are taking these roles are almost like knowledge athletes. I've heard, I've heard these analogies made in other places. I don't really have the best way to describe it, but basically it's, they have their own thing going. They have their own brand or whatever you want to call that of their own community of people who care about what they say and how they act. And part of that affiliation is also representing a company sometime. So if you

give a sports analogy, right? Like maybe I am a professional basketball player who happens to play for, you know, the Atlanta team right now. But then maybe in the future I get drafted by, or I change teams to New York, right? That happens, right? That's just the nature of how people change jobs. And I think it's, it's interesting when you think about DevRel because the role is so public facing, like these are people who are advocating for your company. They're out talking on podcasts. They're out interacting with communities. So for that person to be kind of like a professional athlete for a company, it requires a little bit of nuance in how you, in how you work. Because you kind of care about their opinion, right? Yeah. Like they're good with Hadoop because they can curate the possibility and whittle it down to a point of focus.

And that's kind of the employment. The employment is sort of the point of focus. I care so much about the future of the web that I decided to put my focus and my attention on the Vercel platform as your direct example. In Kelsey's case, maybe it's Google with GCP or the direction of Kubernetes. And as you had said, he kind of transcended and I think he has as well. What I love most about Kelsey is his ability

just to look, like you said, holistically at the scenario and not think like, what should, should you buy Google or should you buy Direction? Exactly. Here's how software is evolving. Here's the way I think it makes sense for you to use it. And we happen to be putting products in place that help you use it that way kind of thing. Yeah. And I think what's important about that is when you start to get into situations where like people will ask me my opinion on something because of my experience

with the front end. And sometimes that answer is for sale because it is the best choice for what they want to use. And sometimes it's not. And it's disingenuous if I were to not give that response to people. But I think it's hard for some companies to realize that's the type of role that this position is. It's not necessarily a paid spokesperson that's going to advocate only good things for the company. Like I'm very well aware of what's great about our product and what needs improvement. And I hear that feedback from the community and I take that and I try to translate that into making the best product. But if somebody

asks me what's the best way to do this, this or this, I try to be as honest as I can because that's how you build trust with the community. Mm hmm. Do you personally struggle or wrestle with that relationship where your work is so much tied up into your identity or your personal brand, so to speak? Yeah. Because, you know, some of us are out there coding for a health care company. And it's like, I care about my work. I'm a craftsperson, et cetera. I'm a software company. It's like, I care about my work, I'm a craftsperson, et cetera. I'm a software developer, I do my

eight to five, or maybe I work harder, whatever it is, and I care about my work, and I take pride in it. But at the end of the day, it's like a healthcare company, I want it to do well, but it's not my identity. And where, I think, as a dev rel, almost necessarily it gets tied up in your identity

because you are promoting this thing yes or representing i should say maybe more so than promoting and so there's like this like you said it's very gray lines and i wonder if you struggle like where does lee end and and the director of dev rel at vercell begin yeah i think that this is why DevRel requires a very specific type of person. And why I also would recommend for anybody listening, thinking about wanting to get into DevRel, you should be picky about the thing that you want to advocate for. Like, I don't think that people wanting to get into DevRel will be satisfied trying to advocate for something they don't genuinely care about or for a space that they're not really interested in. Like I could

probably, like if I went and did developer relations work for, I don't know, some other kind of unrelated part of the development workflow, I could probably do it, but I wouldn't have as much enjoyment out of it. And I wouldn't feel as aligned with the front end. I just love the front end. That's what I've always enjoyed doing, the intersection between front end and design. But to your point about the barrier or the line between, you know, Lee as a person and Lee as a representative of the company can be tricky when people will, you know, send me a tweet asking for something, Hey, why does this Purcell feature not work? Or why does this next thing happen? And can you help me figure that out? It can be tricky to like, I'm watching stranger things, you know, uh, trying to take my dog for

a walk or like these other things. Right. Yeah. Especially with, you know, trying to take my dog for a walk or like these other things, right? Yeah. Especially with, you know, when I talk, my wife comes home from work and just never thinks about it again. And I'm like, that's awesome. Sometimes I'm, you know, thinking about something. Maybe right before I go to bed, I'm just like thinking about, hmm, you know, I wonder if we could do this thing better. It's like it makes it a little harder to turn off. So I have to be very intentional about how I do turn off. I have to make sure that I take time to step away

and to close the laptop, close the tweets and just have separation too. Because you have to be intentional about so that you don't burn out because having that healthy breakdown is important what you sound like right now lee is you sound like a business owner because as a person who's own businesses adam you can speak to this like the the turning it off part is the the part that we all as business owners struggle with because just because you're not nine to five

doesn't mean you're not thinking about the business and that's very much what you're talking about now as business owners we also own the business and so in that sense i mean i'm sure you have access to part ownership in these companies but it sounds like maybe that leads to some of the burnout because there's a lot of the downsides of being attached first and foremost or in the front of a entity without some of the perks of the ownership which we could also speak to as well but you definitely sound like a business owner when you're talking about this that's why i think that the best dev rel for early stage companies has to start with the founder. It has to start there.

Like they have to learn whether they do consulting or they learn themselves, they have to figure out how to be that person first before they replicate themselves with somebody else. But to your point, yeah, it would be hard. It would be harder in my opinion to do DevRel, to be a DevRel leader at a company where you didn't have a stake in its success. That's one of the nice things about a startup and getting alignment in that regard.

Granted, sure, you could have a lot of stock in a public company, but it feels like you have a little bit more say in the startup ownership. But, I mean, you make a valid point, which is it doesn't always have to be like that for individuals in DevRel. So maybe not a DevRel leader, but just somebody who is doing advocacy work. They maybe can not think about it as much because they're not defining direction for how we talk about our products.

Right. I've been thinking about your athlete analogy because it definitely lines up to a certain extent where it starts to break down, especially with like an NBA player, is like a lot of the places where they play, okay, there's contractual agreements and stuff, but it's like kind of over their head.

And it's like, well, I landed here. I play here. I'm going to speak well of the place, maybe. I'm going to, but it's just like, this is where I play now. I'm going to go play my best game. Whereas as contracted, self-governed entities, humans that we are, it's like you're there because you want to be there 100%, etc. My point there is I think the mobility for a dev rel

is even more fraught than it would be for a professional athlete whose job is to play the game. Because your job is not just to play the game, it's actually to pick what's good and represent what's good. People trust your opinion, your taste, your curation, your focus. And so I think mobility is troublesome. Because if Lee was at five different businesses in five years, and it's like, well, are these all amazing? Or is it just like, it's tough to hold a spotter.

We know that in software, the best way to move up oftentimes is to not go vertically in your same org, but actually switch companies. You're going to get more money, more benefits, et cetera. It's the smarter play. But for DevRel, maybe that backfires. Well, there's two things there. One, because DevRel is such a public role,

it's kind of hilarious. I didn't really think about it until I was actually involved with it. But how would you discreetly talk about your job hiring process? I've talked to a bunch of people in DevRel. It's really hard to do. A lot of these companies talk to each other too.

So they're gonna know if you're interviewing at another company for the public spokesperson of that role, right? Like it's kind of obvious at that point. So it does make it tricky, I think, for DevRel leaders who are looking to move around depending on what level they're at at the company. It's a challenge.

Yeah. This episode is brought to you by Honeycomb. Find your most perplexing application issues. Honeycomb is a fast analysis tool that reveals the truth about every aspect of your application in production. Find out how users experience your code in complex and unpredictable environments. Find patterns and outliers across billions of rows of data and definitively solve your problems.

And we use Honeycomb here at Change. That's why we welcome the opportunity to add them as one of our infrastructure partners. In particular, we use Honeycomb to track down CDN issues recently, which we talked about at length on the kaizen edition of the ship it podcast so check that out here's the thing teams who don't use honeycomb are forced to find the needle in the haystack they scroll through endless dashboards playing whack-a-mole they deal with alert floods trying to guess which one matters and they go from tool to tool to tool playing sleuth trying to figure out how all the puzzle pieces fit together.

It's this context switching and tool sprawl that are slowly killing teams' effectiveness and ultimately hindering their business. With Honeycomb, you get a fast, unified, and clear understanding of the one thing driving your business. Production. With Honeycomb, you guess less and you know more. Join the swarm and try Honeycomb free today at honeycomb.io slash changelog. Again, honeycomb.io slash changelog. And by our friends at Retool.

Retool helps teams focus on product development and customer value, not building and maintaining internal tools. It's a low-code platform built specifically for developers. No more UI libraries. No more hacking together data sources. Thank you. Best teams out there trust Retool, Brex, Coinbase, Plaid, DoorDash, LegalGenius, Amazon, Allbirds, Peloton, and so many more. The developers at these teams trust Retool as their platform to build their internal tools, and that means you can too. It's free to try, so head to retool.com slash changelog. Again, retool.com slash changelog. So Lee, obviously it's been a journey for the role. It's been a journey for you. And I think one thing that we're very keyed in on is listeners first.

So listeners, hey, we love you, by the way. But we do this show because we know our listeners have a curiosity for certain aspects of the process of creating software, the direction it goes in the future, how to innovate, how to iterate. But we also have to adopt great tooling. And as part of that, we have to listen to certain people, aka dev roles and folks like you. The question that becomes is how do we trust those people? How do we trust who we're hearing from? I don't even know what question to really ask you, but more like just a layer of trust.

How do we trust folks like you? I mean, how does that work? Well, when you're hired to say a thing and then you say the thing and then it's like, well, are you just saying that because you're hired? Precisely. Or not.

And I think good DevRel's, they earn trust and other ones were like, I don't know if I trust this person. So your angle into that, Lee, let us know what you're thinking. Yeah, there's a observed pattern of someone in DevRel where you can kind of get an understanding of, is this somebody that I can trust?

And I think it comes back to, are you willing to admit when you're wrong? Are you publicly, are you willing to admit when your product might not be the best case for something? And are you willing to advocate for something else if necessary? And that last one is painful. Like it's painful for a company to think that you would hire somebody that might not always preach for your product. But great DevRel teams with great founders who have trust in their DevRel teams understand that the best product should win.

If our product isn't better, I don't want somebody selling me snake oil for something that's supposed to solve all of my problems. That's disingenuous to the company itself and to the product itself. So something that I've noticed really great DevRel leaders and teams do is they are very aware of when you should use the product and they can also give just as compelling of a pitch of when you should not use the product. Because so much of software evaluation and purchasing comes down to knowing what trade-offs you're making

and knowing the constraints of how you're building your system. And if you arm developers with the confidence to know when it's the right tool and when it's not the right tool, you're passing along the knowledge they need to advocate for your tool. This has been observed with Gishamo in particular.

He's been on Founders Talk, he's been on this show before, he's been on JS Party before. We've had many conversations with him way before it was even for sale, before it was even Zite. Like Learn Boost days, back in the day. Early tools tools for gishamo for example mongoose right yeah i mean just lots of different history with gishamo and i think hyper terminal hyper terminal yeah that was that was zeit days and that was still around still being used still out there yeah that might have been pre-zeit but okay fair enough yeah Yeah. It was early days of Zite.

I think maybe even early next days even, too. It was a while back. Point is, I think he's a great example of a founder who has done the role. Yes. Just by nature. He wasn't even DevRel. He was just founder. He was just idea creator, inspirer, follow me, this is the way to go, I believe in this way.

That kind of thing. And many people have obviously followed him through to make Vercel the success it is today, to employ you and many others to do the role you do. A lot of engineers making Vercel what it is today. I think Guillermo is a great example of someone who has done the role by necessity, and then also been able to pass that trust torch on to you all. That's challenging. It's not like you get that every day. But Guillermo began as a developer, turned CEO, which is also, I guess, more common these days. But I would say that Guillermo is more of a unique individual, let's just say. Yeah.

Very unique because he's so capable and was so well-spoken as well. A developer to CEO, but also a developer who really understands how to build a great product. And the core theme of Deverell I talked about of being empathetic, I think he exemplifies as well too. Totally. You'll see him in the trenches talking to customers. How can we make this better?

We want to know your feedback on how we can make this product the best it possibly can be. I think that trends ends throughout the entire company. We want our entire company to be thinking customer first. How do we do everything at Bracel in the service of our customers being successful? That word success keeps coming up. And I think that's kind of core because you said the reason why you got into it was because you saw lack of documentation, lack of education to enable developers to have success on the front end. And that obviously is just sort of part of it. But this word success means like you care. And this role is very similar in nature to sales. If sales is done right, it's to help.

One of the things I get to do here in organization is I get to really help us partner with the right brands. That means selling ads, basically. It's a very basic premise, but really it's like choosing the right horses to attach ourselves to. It's maybe a bad analogy. Jared, help me out if I'm butchering this. But there are certain brands we want to work with and there are certain brands we don't because we see where they're trying to go, what they're trying to do for developers, the kind of future they care about, the way they involve themselves in the community. And we do choose, we say no often. And it's back to that,

you know, I can trust a dev rel if they know when to tell me it's the right thing to use or not. But this idea of success really is rooted at desiring to help people, which is crucial, crucial to having trust. Like if I can trust Lee to be someone who wants to help me, maybe you should make that shirt. Lee can't help me, you know, just truly want to help me. Cause that's what it comes down to. Cause like for in our business, when I speak to the different folks who want to part with our brand and do what we do and share their brand with our audience and whatnot it comes down to can we actually help them do we want to help them are they you know do they speak the right way you know can we actually truly help them and really it's like if we can help them i want to help them

you know what i mean and it's i didn't say sell them i said help them if we can help them i want to help them. You know, and the word help and success kind of go hand in hand there. Yeah. Help them succeed. Yeah. So obviously this desire to, this empathetic desire to help others succeed in a specific domain is key here to being a DevRel, a good DevRel.

What are other things you look for now that you're probably hiring DevRels? If you're out, if a listener is out there thinking, ah, this sounds like a pretty cool thing to do. Lots of fame and fortune that we had. Maybe I could be a dev rel. What are the traits? I assume some sort of technical writing skills. Give us some of the basics of like, well, you would be a good dev rel if.

Yeah, I like that. Jeff Foxworthy, you might be a dev rel if. There you go. Yeah. You mentioned technical writing, and I would rank that up there as one of the most important things, close to empathy. Specifically, it's writing and communication, because so much of our role is interfacing virtually and in person through written communication, that the more succinctly, the more clear you can deliver your message, the better off you're going to be. And that's just in the comms. That's not even talking about the educational material. Like if you're,

if you're creating educational material courses, blog posts, video scripts, any of this stuff, the more well-written and polished and clear that can be, the better your content's going to be. So the written element is extremely important because it usually, great writing usually comes from great thinking and good refined thoughts and working through the drafts that maybe weren't as good. So that's something I definitely look for a lot. An up and coming one is people who are great with video. I think in the past, video didn't play as much of a role in DevRel positions, but video is so important to how the world works today that those who have been involved with some aspect of video succeed pretty well. It's definitely something that can be learned, but it's something to look

for as well too. I think with engineering and with being a developer, it's a desire to want to learn and explore new tools that is a good fit for developers. Like in wanting to dive in a little bit further than just the surface level, you try out some new tool. Wow. This seems really interesting, but why did they make this choice? And like, why is it set up in this way? Like going a step further so that you have enough understanding that you can relay back the value to others who are curious more than just the tagline, more than just the boilerplate. Like, tell me really why it matters. Those are a couple things I look for. As you've been talking about this, I was reminded of our conversation

with Jessica Kerr, who's DevRel now at Honeycomb. And she was mentioning some pitfalls or blind spots DevRels have. Specifically, one that she mentioned, I'm curious if this resonates with you. I wonder if you have others as well, is that they rarely go through, for instance, the purchasing process of their product or service because they have staff accounts. And a lot of times your first run experience actually is, how do I actually onboard? My onboard experience is my experience first time on, unless we have free trial, et cetera, even that's part of it.

And she said that people who work in this domain they should like put their credit card into the website and like just purchase an account because now they have empathy with the people how to do that whereas you're used to having this like staff account that's kind of like goes through this other subsection that was one that she mentioned the other one that i think happens but i I'm not doing it, but I would imagine happens, is you spend most of your time building toy apps, experiments, examples, and can live in that land of throwaway things versus big products that would be built with a tool. So those are two that I thought of.

First of all, do those resonate? And then secondly, are there other areas where diverse can be blinded to what their customers are actually doing yeah i love this topic and that first one on billing is so accurate like you just reminded me that after this i'm gonna go spin up a new vercel account and throw my credit card on there because i because yeah it's it's the the little the little errors you might get with a billing message that can really, really destroy customer trust when it's... Because that's such a... Or stop them dead in their tracks.

Yes. Right. Yes. That's a great one. I love that one. I think that to combat your point about maybe some developer advocates are building a lot of hello world starter applications, not really getting into the larger applications. A good way to offset this, I've found is I try to make a point of spending time talking to our largest customers. And these

are people who are building really large applications. Their needs and pains are quite different than the rest of the customers on our platform. You know, they're an order of magnitude in difference in how they construct their app. They might have an order of magnitude more engineers as well, too. And you just you uncover different insights that might be rooted back in fundamental product deficiencies elsewhere. So for example, maybe one of your really large customers is struggling with a specific way of how they want to organize their code base. And what you realize in really digging into this customer feedback and getting involved in the actual product experience when you're out in the field talking to these people is that there's a common thread between all of this other feedback

you've been hearing about the getting started experience. But because you weren't paying attention to the day 500 experience and we're only looking at the day two experience, you might have missed that along the journey. So you can't take for granted or lose track of those customers who have grown with you and been around for a while. And part of that is a good relationship between the developer relations team and then what teams, a customer success team or whatever you want to call that in an organization, but the team responsible for interfacing with the actual customers, the accounts that they manage.

Jared, something you had said there reminded me of something else that we talked about Jessica with. And then Lee, in the first segment, you mentioned DevRel teams and which org they're under. And so something that Jessica talked about was that her org is under marketing.

And then in the first segment, you mentioned how that can kind of play a role in how they are successful, I assume, to some degree with their roles or their mission for the brand. How do you – it seems like you know what you're talking about, basically. You know how to operate an organization. You know how to direct an organization that's doing DevRel for a Vercel or a large organization like that. When it comes to setting up a DevRel organization, whether it's one person or many, let's just say tech-focused brands, because, I mean, obviously healthcare might be different.

What are the right ways to organize the hierarchy? Do you put it under marketing? Do you put it under sales? How do you attach OKRs and KPIs? We talked about metrics a little bit, but how do you set it up right so that listeners of the show do trust them and products can get adopted and be useful and enable success and help all these fun things we're talking about? How does that work? How do you make it work? Yeah, I wish there was a great, simple answer for this. Unfortunately, there's not really, because I think my next question, if following

up to this would be how large is the company, what's the current focus is like, is the current focus. They're just getting started with product market fit is the current focus. They're just getting into enterprise sales. Are they already at a hundred million ARR and now they're trying to move into the next phase of the company. Like all those different phases of the company's lifespan might require different outreach. So for context, when I joined Vercel, I was employee 34 and we were a much different company than we are today. And the type of outreach I was doing is a little bit different today than it was at the start, but the core values are all the same.

So if you hire the right people, which that's kind of hand wavy, right? But if you hire people that are empathetic, that are great writers, that are passionate about tech, then a lot of that can translate back to, well, it doesn't really matter like what org or what KPI, because they're going to thrive in whatever environment or what stage the company is at. So that's some of the things that organizations can think about with regards to successful dev rel. What about the content specifically? If you were going to define what's a good piece of promotional content? Surely you've had lots

of wins, lots of losses things that have like blown up things that have been ignored yeah are there attributes of good content that devrel people can create that's like sticky or interesting or viral that you found is like reproducible yeah i think i'll segment this into two buckets of content because I've seen DevRel get involved in both buckets. Let's say on one hand, it's the traditional marketing content. This is like the press release. This is the announcement of the thing. It's more targeted towards a larger audience. And then there's the engineering developer focused content. And this is targeted directly at the individual developers, whether some kind of how-to or tutorial or guide

or some kind of explainer on how something works. The separation of audiences there is really important on what makes the content great. Because if we start talking with the engineering content, developers don't want you to skimp on the details. They want to know behind the scenes what is making this thing work. Otherwise, it feels like a sales pitch.

It feels like a marketing pitch. Like you're telling me about this thing, but you're not giving me any of the underworkings of how the system works. Now I have questions. Now I don't feel like you're being truthful with me. This seems too good to be true, right? If you read something and it's like, hmm, this feels like a silver bullet. Like this feels like there were no trade-offs discussed at all. It's only good

that it's probably not a very good engineering blog post. Like some of the best engineering blog posts actually document that, you know, here's what worked, here's what didn't work and why it didn't work. And here's what we learned from it and actually improved on that. And that's, I think, how you can do engineering content really well, focus for individual developers. Then there's also the press release announcement style material. And I think where DevRel can play a role in that is making sure you're doing justice to your community. So let's say you're announcing a new feature for your product, right? In how you talk about this feature, you should try to tie it back to the actual customers using it, the community involved around it. Maybe they've surfaced some feedback that's helped make it successful. Maybe you've actually surfaced this with them ahead of time so you can get feedback on the announcement or on the feature

that you're launching. And I think the DevRel persona can help bring the lens of maybe this is a first time viewer of the product. Maybe this is somebody really advanced. How do we make sure that this content lands with all of the developers in our community? Curious about specific social platforms and what you all are investing in like is Instagram, you know, we have them, they're all stealing each other's features, you know, are you going heavy into TikTok? Are you ignoring this? You know, what as a team do you guys look at and say, here's where we're going to reach our people? Cause you got to reach them. Yeah. Yeah. 100%. I feel like we're involved in, you know, almost all the major social platforms. And I'll say that I do think that video is just continuing to get more and more popular, which I think is why TikTok is, is so popular. It's interesting though, the type of content that

does well on different platforms. It's, it's quite type of content that does well on different platforms, it's, it's quite different. Like people don't want to see the YouTube video, just copy pasted and repost on Tik TOK. It needs to feel like it's built for that platform. And in strangely enough, I don't know if this is a generational thing, but like the, uh, some of the content that does best on platforms like Tik TO TikTok, like it feels like it was just shot on your iPhone. It's actually better when it's just shot on your iPhone. It's not super professional. It's not like, they don't want to see the super polished press release style, like announcement keynote video. They want to see Lee, you know, doing a

dance to a song. Like you doing that stuff? Uh, no, no, they want to see it, but I'm not giving it to them. I like to see that as well. Nobody wants to see me do it. Um, I have seen some people do it. Well, some people who use tech talk as an educational tool and just, and I think that's what it comes back down to, like find your audience, whether they're on tech talk or LinkedIn or in Facebook, the the black hole of developers there's so many developers on facebook they're just waiting for you to talk to them but a lot of people don't engage with those with those groups and as long as you make educational resources like they will listen like because all developers are always trying to learn something new. And even experts want to

hear something explained like a beginner can understand it. Well said. There's somebody out there that's thinking, I'm a dev rel. I've got my singular org or I want to evolve my organization. I want the business side to help me evolve it. Where do you get, like, what resources do you look to? Blog posts, YouTubes, whatever it might be, talks. What resources do you use to kind of become wise? I think you're pretty wise. Where do you get your wisdom? Where can you point some of the folks who might want to evolve or upgrade their dev organizations to become a bit more like yours or just have some of the attributes you've been talking about today? Yeah, I'm very fortunate to have people on the

Vercel team who've helped our organization grow and provide a lot of good feedback. And I think outside of the Vercel team, I try to connect with other folks leading DevRel at developer-focused companies. So my recommendation for people wanting to get kind of a pulse on how DevRel is going is to connect with the individuals. It's more about the people than it is the brand or the company, because that's where you're going to gain insights on how their worldview is shaping how they interface with their communities. So I would find some of the tools

that you're interested in, maybe the tools that you use, uh, that help make your, your life easier and, and see who those developers are who are leading the communities there and DM them, you know, they might be more open to your, uh, your outreach than you might imagine. There you go. Are your DMs open? They are. Yeah, there you go. I have people DM me about all different types of stuff and you know, it's, I believe it's, it's helpful. You know, it's, I, it can be, I acknowledge it can be difficult for certain people to have DMS open just due to the, the way the internet is. So it doesn't work for everyone, but yeah, it's a good venue for feedback sometimes. Gotcha. What about things unsaid? I'm sure we've talked a lot about the process,

the history, you know, the do's and don'ts, you know, code smells for lack of better terms of good and bad organizations slash individuals you can trust or not trust and reasons you can't is there anything we haven't asked you that you're like man i really wish i could talk about this before we close this show um i think i think y'all have done a great job this has been this has been really fun lots of in uh thought-provoking questions i don't usually get to talk about devRel in the meta sense. So it's been interesting to reflect on why we do the things we do. There you go. Well said.

One thing we didn't talk about, which we want to talk about, but we'll probably have to do it on JS Party, is I want to talk more about Next.js, where it's at, where it's headed. And so we completely sidelined that. That's a big part of what you do. And so we'll have to have you on JS Party where you're going to hit the audience right on the head. Oh yeah. Don't actually hit our audience on the head, but you know, metaphorically the nail and the hammer.

The nail head. He's a hammer. And so I'll have to bring you on JS party to talk about that. So we can give it its full, its full time. Sound good? Yeah, that'd be great. I think it'd be fun. Cool. Well, Lee, thank you so much for your time your leadership your wisdom and just showing up here just being real we really appreciate that thank you so much yeah thank you this has been fun all right that is our show for this week now is a great time to subscribe if you're new to the pod head to changelog.fm for all the ways. And if you're a longtime listener,

do us a solid and share the changelog with a friend. That is by far the best way you can help us help more people by sharing great stories and conversations like this one with Lerob. Speaking of good combos, I took my producer cap off and joined GoTime recently for a panel discussion on an episode titled The Myth of Incremental Progress. Here's a quick taste of that one where I'm encouraging

cargo culting. Yes, I am. Sometimes you just have to follow the other person's path until you realize when it doesn't actually work for you. So I'm totally fine with like cargo culting, some sort of rule. I was going to say the law of the meter, but that one's too hard to explain. What's a very simple dry, right? Everybody can remember that one. We all get it wrong, but we all remember the acronym. All of us here, I think, would all talk about how dry is not the best principle in many cases.

I think I've heard you guys talk about that. But we didn't realize that until we had tried to dry the crap out of everything for a while. And then it came back to bite us. And so I think it's okay to go through that process of like I was saying in the post, go ahead and paint by numbers for a little while. Don't live there. Don't stay there. But until you can start to realize actually blue doesn't look great on the number four, a little bit lighter blue would look nicer there. You start to develop your taste, your experience, your own history of

that working well in this context, not in that context, then you don't need it quite as much. But I think, you know, we do need to start somewhere. And I think that a lot of these idioms, best practices, rules, clean architecture, whatever that means, those are decent starting places. That's from episode number 232 of GoTime. One listener called it the best episode they've heard in a long time. Another one called it the absolute worst. Maybe take a listen and let us know what you think. You can find it at gotime.fm.

Changelog++ subscribers, stick around for a quick bonus on LEGO vs. LEGOs that gets surprisingly gruesome. If you aren't a Plus Plus member, now's a great time to join. Drop the ads, get fun bonuses like this one, and we've even thrown in a free pack of Changelog stickers shipped straight to your door. Not bad, right? Thanks once again to Fastly for having our CDN back, to Breakmaster Cylinder for keeping our beat supply chain secure, and to you for listening. We appreciate you spending time with us each week. Okay, that's it. This one's done.

We'll talk to you next time.