Monoliths, GraphQL, Next.js, and DevRel Insights

• Monoliths vs. API-driven Frontends: The pros and cons of each approach, including the challenges of maintaining large JSON payloads and ensuring API stability.
• GraphQL: A critical look at the limitations and complexities of GraphQL, including rate limiting and authorization issues.
• Next.js and Rails Integration: Strategies for connecting a modern frontend framework with a traditional Rails backend.
• Personal Projects: CJ's DIY solar pool heater project and the considerations involved in making it efficient and safe.
• Relay Race Preparation: Colin's training for the Reno Tahoe Odyssey and strategies for managing challenging race conditions.
• DevRel Strategies: The multifaceted role of Developer Relations and how to balance content creation, community engagement, and internal advocacy.

• Why I’m Over GraphQL
• Stack Recommendations for Connecting a Next.js App
• Taylor Otwell’s Tweet on Next.js and Laravel
• Rails Developer Survey 2024
• Unity Learn Pathways
• Chris Trag’s LinkedIn Post
• Remotion: Create Videos Programmatically

[00:00:00] Hey, how's it going, CJ? [00:00:06] Good. How are you doing, Colin? [00:00:07] Pretty good. We're back working on just work projects, taking a little break from personal projects. How about you? [00:00:14] Yeah, exactly. I was just joking with Mike that I am procrastinating my personal projects by doing work projects. So I don't know if that's a good thing or a bad thing, or if it's because the work projects are better organized and linear or they just feel more productive or something, but I've definitely got a list of stuff that I want to do on the side, for side projects, but it's just not happening. [00:00:36] But I think that's all good. [00:00:38] I bet Mike loves to hear that. Do you organize any of your personal things in like linear or projects or just rolling around in your head? [00:00:47] I just started putting like ideas for courses and, little projects in a personal linear, just to see if maybe that helps a little bit [00:00:54] nice. [00:00:56] So live customer support messaging [00:01:00] backed by LLMs with a little co pilot tool that works with Twilio, that works with email inbound and outbound, that works with voice inbound and outbound. yeah, it's gonna, I don't know. I think we've built something pretty cool at Craftwork and so I just want to show people how to do [00:01:16] That's cool. Yeah, that's very timely. It's a good way to take what you're doing in your day job and share with the world. [00:01:26] I hope, we'll see. It'll also be useful, later on when I happen to need to build this again, I just go back and look and,get the reminder. But, [00:01:35] you could release it as a once product. Just kidding. [00:01:38] Ooh, yeah, maybe. I was thinking, our, Craftwork is built on top of Jumpstart, and Jumpstart just gives you so many batteries included, and I was a little conflicted about should we start from jumpstart and then try to work it out with go rails and say okay, maybe you can only have the course, or maybe you get the course and jumpstart together or something so that, cause I don't want to give away the [00:02:00] jumpstart repo, but I do want to give people access to the [00:02:03] And you don't want to start from pure Rails. [00:02:06] yeah, exactly. Cause there's so much table stakes stuff that you need to build in order to, I feel like. I don't know. I feel like it would be weird to not Rails new at the beginning of a course like this, but [00:02:17] yeah, coming into it, if it had like authentication and a bunch of stuff already built, I think folks would be like, what the, like, how did that happen? [00:02:23] How did that [00:02:24] right. This is the, this is the how to draw an owl tutorial in reverse. [00:02:29] It's they're like, wait, where did you draw those two circles? We need the, [00:02:33] yeah, there's a bunch of courses that happen where you like, you follow them and then you're like, wait a minute, there's like a whole step missing here because I don't have that. [00:02:41] it's not, [00:02:42] you're not successful with it, but yeah. [00:02:45] Yeah. , at Stripe, we built this set of videos called the like Stripe fundamentals or something. It was basically just like teaching you how to use the SDKs. And we went from scratch, here's how you install it. Here's how you set up environment variables. Here's how [00:03:00] you do all the basic things with the SDKs. [00:03:03] And my intention with that was to like, build these foundational. Core concepts that we could then build from so that we didn't have to teach people, here's how you make the boilerplate HTML page with a, Stripe element on it every single time. and I want the same thing for rails, but there's just I don't know. [00:03:21] you almost need rails one on one and rails one on two and rails one on three, and then I want to teach you all like this other, Like [00:03:28] Yeah. You don't want to have to teach from zero to one every single time, zero to two. [00:03:33] Even the, it might be worth checking out. Unity has like pathways on their learn website. [00:03:41] And I really do like that idea of there is a point at which if I'm more advanced, I want to jump in and not be told, I don't want to have to skip around to figure out where I need to find things. And you can literally create what was, there was another really good rails. it's like Rails Mastery or something that was very [00:04:00] similar to that where it's okay, there's a fork in the road. Do you want to go learn, in the forest of authentication or, like it was all themed and fun and it was, like a dnd quest where you choose your own adventure. But then that way it's like revealed complexity. And then when they release a new thing, it's okay, here's how you add some LLM powered tool to your rails app. Instead of starting from rails new every single time. [00:04:24] Exactly. I Was also considering just like speed running part of it and then the other thought was like I'll call the first part like phase zero and if you're comfortable with like off and you know Setting up a brand new rails app. And you really just want to get into the meat and potatoes. [00:04:40] then you can just jump to phase one, which would be like, okay, here's where we're going to actually start implementing messaging, but I don't know, it's a hard problem in terms of instructional design. And I, yeah, when people are just making individual videos or even just like a, subset of videos, it's, I [00:05:00] feel like it's easier to just be like, okay, I'm going to gloss over certain topics or here's the prerequisites or whatever, but. [00:05:05] I want to make sure people are set up for success. And, yeah, it's just something I'm thinking about. Nice. [00:05:12] yeah. [00:05:12] is going on in the world of tech this week? [00:05:15] Oh my gosh. [00:05:16] what do you have here? [00:05:18] a couple of things like flew across my radar and it's interesting cause we've been talking about this internally too. So like how, what's the best way to implement your front end and your backend and should they be a monolith? And, there's a lot that goes into this. And so there was one, one article that came out today from someone that said, why I'm over GraphQL. [00:05:41] So like why not to use GraphQL anymore? And then there was another question on the Rails subreddit around recommendations for connecting a Rails app to an XJS app. And internally, we've been having conversations about how, like where we should build certain features. Should it be as part of the Rails app and like part of the [00:06:00] monolith, or should Rails expose an API and then we use a Next. [00:06:04] js front end to consume that? And so it's something I've been thinking a lot about. And, one of the core, I don't know, one of the core decision Pieces that go into this conversation is, finding qualified employees. And so I think a lot of people are tending to, choose react based solutions because there is this idea that there's a lot more react devs. [00:06:33] And so you can build more stuff with it. And I think there's, there is definite concern for picking rails because they're not sure if they're going to be able to find rails devs. And it's like a chicken and egg problem, right? Like maybe we're not supporting juniors enough to grow the community big enough and fast enough to make this like a really sustainable ecosystem, or maybe it's like a mismatch in terms of the expectation around, can you find a rails dev or not? [00:06:58] And, and yeah, [00:07:00] I don't [00:07:00] Have you seen, there's been a lot of conversation. I've been listening to like fairly technical with Ian Landsman and, Aaron Francis and some others. There was a post from Taylor Otwell from, from Laravel talking, it was like trying to compare Next. js and Laravel, which are very different things. [00:07:18] And what you're talking about is very true. But it also is like, how much of it is the shiny new with JavaScript stuff, like JavaScript seems to always have a new thing and people are jumping around and he had a shot fired at, it feels like an ad for clerk, for authentication as a service companies. [00:07:37] And whereas you go to jump into Laravel or rails and it's Batteries included. If you're, even if you're not using, jumpstart, you can jump into, devise and all these different things. And you'd I think a lot of JavaScript people when they're new to it, don't enjoy like how many files something might take to implement. But in a Laravel app and in a rails app where things are stored and kept, and it's like, what drawer is [00:08:00] this in? And in [00:08:01] JavaScript, Yes, there's probably a perception of more React devs and things because you have a lot more bootcamp grads, and, just a lot of courses and stuff teaching it. We talked about it last episode with the last RailsConf being next year, what does that mean for the perception of Rails? And you have all these, [00:08:18] React conferences, but I don't think most programmers are going to any of these conferences, right? it's a small subset of, very online people who are also going to these. [00:08:27] These conferences and you have developers all over the world, just being productive in their tools. it's an interesting argument. I don't know which one I'd go for. I do think like when we were at orbit, we were all rails based. We started before my, before I joined, it was a front end JavaScript app with a backend API separate. And apparently it took them way longer to do anything because they had to make sure they built that contract between the front end and the backend and they had to implement it. And it almost felt like you were implementing the same [00:09:00] features twice,to get things done. [00:09:02] One idea that I keep coming back to, whether you build your front end with React or not is around this idea of using stuff that's built into the browser as much as possible. And what I mean by that is that like, when you're building a form that is going to submit some data to the server, right? [00:09:22] there are conventions that have been around since the beginning of post requests on the internet. And if you choose to build a form that follows the same conventions that The internet has been using for a very long time. Then the code just feels so much more robust and reliable and dependable. [00:09:42] And so I find that when we start layering on these big, heavy front end frameworks like react or, and I would even put. In some regard, like Rails form helpers in this bucket. but anytime we start adding layers [00:10:00] into the front end, including turbo, including whatever, we are introducing complexity that is going to be hard to track down when things break, it's going to introduce complexity around like state management. [00:10:11] and yeah, it just gets, it gets gnarly. And so we're finding ourselves in a world where. There's just so many different options from the react side, what form library are you going to use and then what validation library are you going to use and how are you going to manage your HTTP requests? [00:10:27] Are you going to use, react query? Are you going to use a graph QL thing? And then that's all just assuming react is the front end. And if we talk about next JS, like maybe you're layering in. A server side component to your front end, where like maybe your next JS backend is the thing that's actually calling your rails API, or maybe your next JS front end is the thing calling rails API or whatever the backend API is. [00:10:52] But, one thing that I really like about Laravel and rails and Django and. Sort of these older [00:11:00] monolithic frameworks in a, in addition to all the batteries included stuff is. Because they've been around so long, they're built around the same fundamentals of the basics that you get from the browser, instead of layering on a lot of like additional meta framework stuff on top of JavaScript that's running in the browser. [00:11:20] And at least from a maintenance perspective, I'm finding that it's like the things that are built in the most basic ways are the ones that are the most maintainable. And there's always a time to play with the new stuff for new sake, but I have to wonder how much of it is like a lot of people are drawn to Laravel and rails because they need to, in some cases get the feature done because they have a business to run, A lot of [00:11:42] solo founders, a lot of, bootstrappers are doing that because they need to be able to sleep at night. [00:11:49] They need to know that,I'm going to try this new edge thing. Tool on this new edge platform. And yeah, you're not wanting to do deal with your own SEVs in the middle of the night. and I know, this is [00:12:00] where then you see the jokes about Oh my God, I can't believe how slow rails is. [00:12:03] Or it's we could make that call for almost anything. And for a lot of the [00:12:07] stuff on the internet, does it really need to be that fast? are you really going [00:12:11] to notice if it's, stable, but a little bit slower. and,I think that, even like we mentioned earlier, like RailsConf not being a thing, there's like a resurgence in Ruby meetups, which I know is not rail specific, but that gives me hope for the language and the tools around it, Laravel's. Going super hard, super strong. Like I almost want to go [00:12:32] to Laracon just to go see that world. cause I haven't touched PHP since WordPress, which is not, it's not the same, it's, I wouldn't even say WordPress is PHP anymore. Like it's its own thing. So [00:12:44] Yeah. Just as a, an exercise I went and built a couple things with Laravel and it is very nice. I found that there were a couple additional like layers and a couple additional, um,like components that you had to understand. [00:12:59] So it [00:13:00] wasn't just model view controller and a handful of routes. And here's how you write your views. There was like, some other concepts and, basic things like validation happened in a different spot, but there were some really nice things like out of the box, you get authentication out of the box, you get , framework specific deployment tools, which are slowly but surely making their way over to Rails. [00:13:20] But, yeah, I think of the three that I've worked with, Laravel's probably the most mature in terms of, at least first party tooling and support, and then Rails, and then probably Django last. But, Yeah. I don't know. I am curious your take on GraphQL though. I think, yeah, I know we messed around with it a little bit at PantyDrop, but, yeah, I think it was a fun idea, but, haven't used it since then. [00:13:46] So debate. I think it's just that it's really cool to be able to do these queries that you can reduce and return only what you want. There's a lot of promise there that,sometimes if, when you're doing rest, you don't get control over what [00:14:00] comes back and you might have to make multiple calls, to get what you need. [00:14:03] And then you're doing. Building your own little map on your, on the side to keep track of what you need. what happens if one of those requests fails? there's all sorts of things that can happen there. So I think it's really cool. I almost wish that we could just. In rest, define what fields we want back and stuff like that. [00:14:21] But then I guess you're like [00:14:22] rebuilding GraphQL. [00:14:24] so yeah, I hadn't had [00:14:26] time to read this blog post, but I think I, a lot of people are over GraphQL. [00:14:31] Yeah, there were, I think there's just like a handful of gotchas with GraphQL that this blog post I think articulates pretty well. And yeah, authorization rate limiting. If you just scan the headings here, we'll share the link in the show notes. But there is just a, a set of problems that you run into that are standard across the board. [00:14:53] And yeah, I don't think anyone's really found like a great answer to those. but yeah. , did you ever get your hands on [00:15:00] O data back in the day? Or, are you familiar with [00:15:02] think so, [00:15:03] Okay. I think this might have only been in Microsoft thing. And it's basically like a GraphQL thing, but from the front end, and you could write like these interesting queries that were passed basically in query string. And it would give you back. like your filtered data. and I remember when I first saw this, I was like, this is so cool. I love this. And, yeah, it's like similar idea to expand in a way, which is a feature of the Stripe API where you can pass okay, I want this object and I want to expand this other thing so that it's included in the response. [00:15:39] I love expand is so good. Yeah. [00:15:42] totally, but it's also insanely expensive. To maintain that because if you build your integration and you're expanding, but you don't actually need the expanded objects, [00:15:51] that's like increasing. Yeah, it's a waste. It's like increasing the latency and the overhead for the API and the maintenance of the API. [00:15:59] [00:16:00] One of the cool things that I've, that I love about GraphQL is that. I think there's this thing where you can say here's the properties I need and from the server, you can understand what the client is actually requesting, right? So if the client only tells you I need three fields and maybe another client tells you they need three different fields, but maybe you're returning like you're, Or you're generating potentially 20, that you can safely remove the fields that aren't included there, which gives you like these awesome performance gains so that you can just like strip down and understand that you're not going to break clients because they're being explicit about what exact fields they want from you. [00:16:39] And that's a problem we have today because now we are using, we have a rest API. on the rail side. And in order to avoid too much stitching together of different resources on the front end, some of our rest end points return these giant Blobs of here's your project and all the photos and all the tasks and all the statuses and all [00:17:00] the, people that are involved and all the whatever's with their avatars and all of their like work history and whatever. [00:17:05] and so you get these like huge things. It's like basically just a JSON blob of your database between certain date ranges or something. And that also isn't great. In fact, we like ran into an error the other day where, versus, Vercel and Next. js were throwing an error because. [00:17:20] The payload was too big. I was like, I don't know if it was five. Yeah. It was like five megs or something just for some, a TRPC call. and it was just crashing because there's just too much in the JSON blob. And yeah, it is a really, it's a really tough problem to solve. and. So that same resting point, right? [00:17:39] If we want to go and thin it out or make it more optimized or cache certain parts of it or whatever, we have to be super careful because we don't want to break, one of our calendars that's backed by that API. We also don't want to break the mobile app that's backed by that API. based on that API, we don't want to break the front end like marketing site that's based on that API. [00:17:55] it definitely makes it more challenging when just using vanilla rest and not understanding [00:18:00] what properties the front end is asking for. But it does make it a little easier to do things like rate limiting, authentic authentication, authorization, [00:18:10] And I assume you're not doing this in like a real, you have a JavaScript front end, right? So if you're doing this in rails, you would just access all the data that you need, but then you probably have a bunch of very interactive agent type behaviors and stuff that are happening or project management style. Yeah. [00:18:29] Yeah. So we have. We have we have what we call, like the dashboard basically that is for internal users to do all the project management and customer communication sales and whatever. And then we have in through there, that is like just vanilla rails app with hotwire. and a lot of that is working Great. [00:18:49] And has separate controllers from our API controllers. and then the API controllers drive the marketing site, the mobile app, and some other things. and they also [00:19:00] control the really interactive parts of the dashboard. So we have, we're using full calendar, which is this really nice react library for men working with calendars. [00:19:08] but. It's just, yeah, it's like a way that we can use our rails monolith, use hotwire as much as possible, but then where needed, we can drop in a react component and then build with react just for that one, like really interactive part. but yeah, now we, then we would have the calendar, the mobile app, the front end, and some other things that are all depending on the API, not changing. [00:19:31] Nice. [00:19:31] yeah. Yeah. [00:19:34] Good old. [00:19:34] know the answer. [00:19:36] It's at the end of the day, [00:19:37] everything is, HTTP [00:19:39] Yes, exactly. [00:19:41] always has been [00:19:43] fun side project though is building something else. I don't [00:19:47] What are you building? Yeah. Tell me. [00:19:49] yeah So we opened our pool as early as possible. It was like the day that we didn't see any more freezing temperatures on the calendar. [00:19:57] We opened it, but that means that it was like [00:20:00] 40 degrees or something when we opened it up. And the pool here in new England stays pretty cold throughout the summer. And it's a very old pool. it's built probably in the late seventies. Early eighties. And so it's very simple. It has a pump with a filter and two little inlets and outlets. [00:20:18] no heater. And so it's been my idea for a long time to build like some sort of heater for the pool so that we can make it,a temperature that is livable and that we're excited to go out and spend some time in. Right now it's very refreshing if you're out in the yard doing some work and you just want to take a dip you can splash in, but, yeah, pool heaters like if you buy like a proper pool heater it's pretty expensive and so I had these DIY ideas around building a couple different, iterations of this. [00:20:48] So the first one we're going to do is a solar based pool heater. So I got like a bunch of irrigation tubing, just like black irrigation tubing, and we're going to coil it up and [00:21:00] maybe we'll like, spray paint the thing we're going to mount it on black also. And then just like a solar panel, we'll point it at the sun and then we'll have a little pump that sucks the water out of the pool. [00:21:11] It runs it through these coils basically of irrigation piping and then goes back into the pool. and yeah, the idea being that ideally the pump is also solar powered. I don't want to spend electricity on this, but. [00:21:24] But you also want it to be safe. [00:21:25] And, yeah, I will. Is the plan to have it continuously? [00:21:31] I think it would, it depends on, yeah, I think it depends on the temperature outside. if the temperature drops below a certain mark, then it probably doesn't make sense to run it. And we do have a lot of gloomy days where it doesn't make sense to run it. And it might probably make [00:21:48] sense to have it heat up in a storage and then circulate out and then bring in new water. It's a little more complicated, because if it's constantly circulating, it probably isn't going to heat up [00:22:00] fast enough when it goes through the coils. [00:22:02] Yeah, it totally depends on how fast it's pumping through. Yeah, and so and how much, yeah, like you said, like how much storage. So if we end up building just like a giant black PVC pipe thing with [00:22:13] And if it's slow. Yeah. [00:22:16] Yeah, exactly. [00:22:17] So that's the first iteration and then the second iteration is a wood fired one where we'll just get like a drum, like a 50 gallon drum, and then wrap it with copper, and then put fire in it. [00:22:29] There's some really [00:22:29] good tutorials on this for hot tubs. [00:22:32] yes. Yes, that's where I got the idea. It's like the hot tub version. Yeah, that'll be fun too. I think like technically there's some physics where you can make it work without a pump, right? Where like just the heator [00:22:45] the heat. [00:22:46] it rises. Yeah. [00:22:47] Exactly. Yeah. [00:22:48] You're not going to get that with pure solar. I don't think, unless it's like really hot. [00:22:54] exactly. Yeah. There's also, I think like.the examples that I saw, at [00:23:00] least of the hot tub version, the top of the drum was always level with the hot tub. And so the water could come out the bottom of the hot tub and then go back in the top of the hot tub. [00:23:11] But the pool is in the ground. So like in order to get that same sort of like gravity fed, Piece to suck into the pipe. We would need to bury part of it or something, or I don't know. There's definitely some physics that needs to happen here. And so I think Chachapiti will help us work through all the different requirements. [00:23:30] But, [00:23:32] You're gonna learn about you're gonna learn about hydrostatic pressure over there [00:23:36] yes, exactly. And I don't want to burn the kids either. So if the, if the water going through the pipe, Flowing fast enough, but it heats up too quick. Then it might just shoot out like insanely hot steam, which would, [00:23:48] you're also gonna have a fire in your yard anytime you want to [00:23:52] yes. [00:23:52] Yeah. Which, yeah. Coming from Nevada, like it felt like, Oh man, you can't. We, no one's going to have a fire. It's so dangerous for [00:24:00] fire risk. I am not joking when I tell you, it took me three hours to get the fire going, to get the fire started. We did syrup because it's so wet here. It like, it is just always like misty foggy and like high humidity. [00:24:14] And [00:24:15] yeah, even your you need a place just to store your wood to make sure it's not wet. Yeah Dehumidifier [00:24:22] exactly. [00:24:23] and yeah [00:24:24] Yes. Yeah. Yep. You're, you got it. You got it. [00:24:28] amazing the homesteading continues [00:24:31] Yes. Yeah, I guess [00:24:33] You'll be sitting in, your hot tub with your maple syrup and you're on your way [00:24:40] Yep. Yep. Yep.all So you've got another race coming up. We've talked about your running in the past. I think even last year when you ran, the RTO, we talked about it. What's the plan this year? Is it the same crew? Do you know what legs you're running? [00:24:55] it's tomorrow. I've got same kind of crew. I'm part of [00:25:00] this beer running club called the McKellar running group, which has like meetups around the world. So we have a crew here. so I'm doing it with them because it's a pretty chill crew. They just want to run. They're not worried about how fast we do it. [00:25:13] But, I am doing the hardest leg this year. So we will see how that goes. But doing, the first, The first run of the first leg is eight miles and six of it is uphill and it will probably [00:25:26] be at the hottest time of the day tomorrow. So just going to get through that one. And then my other two are like at night and easy and we'll be good. [00:25:35] But I've got a bandana that you put ice in. it's like specially designed for that. So I've got that ready cause it's, there's a little bit of shade. But not until you get to like mile six. So I gotta run uphill in the sun for a good six miles. And I mean it's like 1500 feet, over six miles. So it's quite a bit. But yeah, ready for that. [00:26:00] took most of the day off tomorrow to do that and into the weekend. So we'll, we're estimating it'll take us about 24 hours like it usually does. [00:26:09] And are you, . Are you practicing running uphill right now? is [00:26:13] Yeah, I live downtown and so most of my running is usually like just getting it in is running on the river and there's no uphill whatsoever. And it's good to get out and get cardio, but you don't get any I forgot the phrase, but like you. You basically earn your stripes on the hills. [00:26:30] And then when you go do races, like usually they're not that insane. So I've been doing a lot of trail running up above, Reno where, some of them it's you can't run, you have to end up hiking, but you're still heart rates high.anytime you look at like ultra trail races, it's a lot of hiking and then you run when you can. And you've got like these really cool, like collapsible hiking poles that you need to take with you and stuff. So that it's not that bad. The run tomorrow is just like a gradual mountain, like fire [00:27:00] road. but it's good to go do those. And then makes other things feel easier. [00:27:05] that'll be good, but I'm actually moving up to that area soon. [00:27:09] So I'll be able to like, just run from my front door out into those trails, which is going to be nice. I'm trying to still balance the, like how much time I spend away from a computer, given how much time we spend in front of a computer. [00:27:23] Totally. Yeah. And what a great way to do it is get out, run around in nature. You're getting your exercise, you're getting your forest bathing, you're getting your, [00:27:32] yeah, I'll have some updates because I've been dealing with some breathing and heart rate stuff and I've been doing a lot of like health hacking to figure out like how do I get this fixed and I might have to go get an MRI or something if it doesn't fix on its own just to see is something not something torn is something not right because it's like lung and heart related but not in a way that's like dangerous just like sometimes I find it harder to breathe than normal but I've had [00:27:57] this since I had a really bad [00:28:00] bout of COVID. [00:28:00] So it could just be something I have to rebuild. so I have some things that I've been trying that we can talk about in a future episode. [00:28:08] Okay. I don't know. I feel like I've always just sucked at running. And so anytime I run, I feel heart and lung pain. [00:28:17] shouldn't be pain. Like being out of breath is one [00:28:19] thing, but hopefully no pain. But you do a Peloton stuff, right? And that's good cardio. [00:28:24] Yeah. Yes. Yeah. Now, yeah, it's. Yeah, I guess it's, I don't know. Maybe the other thing too, that I always wondered about was like how allergic I was to the stuff that was around me and outside. And so [00:28:36] a big factor [00:28:37] practice, like dying of can't breathe, but maybe I just allergic to the grass or [00:28:41] or asthma or yeah, something. [00:28:43] yeah, [00:28:44] Yeah.So yeah, another kind of in my world today is actually my one year anniversary at discord [00:28:53] Whoa. Congratulations. [00:28:55] that I think you also have an anniversary that recently happened or is coming up soon.[00:29:00] [00:29:00] Yeah, my one year at Kraftwerk was,30 days ago, [00:29:03] we, I know we both made that switch, which I'm not working on any side projects or personal projects right now. It's just been a lot of like travel and like onsites and life happening, getting ready for this race and stuff. So it's been nice to just I guess other than the game boys that we talked about last week,But I've been thinking a lot about this and actually a link to this post on LinkedIn from,Chris Trag. but I've been thinking a lot about DevRel, which is interesting. So developer relations for anyone who hasn't heard that term. But really like advocating for DevRel internally, and just making the case for, for this and Trag has this little cartoon that he put together on LinkedIn and the, office space meme of what is it that you do here, is very timely because DevRel is very different at every company. [00:29:54] And I think I came across a quote from, I think it was Kelsey Hightower. That was like, Debra is [00:30:00] whatever the person paying you says it is. And I understand that cause that's who's paying the bills. But I also think that there's some like first principles that you have to think about, yes. [00:30:11] And it's yes, it's whatever, every company is different, but at the same time, there's still these tried and true things. and we're very different. Different. I think we've talked about this before. Like we do a lot of product launches. We do a lot of working with engineers as they're developing products and features to like, make sure that they're going to have a good developer experience. And we don't do a lot of the content creation. And, going to talks type of DevRel, which is very, it's a different flavor. It's very valid. Some teams have the person who goes to conferences, the person who does content, the person who does the internal stuff, maybe slightly sales engineer, DevRel type thing too. [00:30:50] And there's only two of us at Discord. So we're doing like a roadshow where we go to all of our, all the different functions of the company. Teach people what we do [00:31:00] and how to like interface with us. And that's just making me think a lot more about what do we want it to be? What do we want to do in the future? [00:31:08] What do we, what have we always done? What are we doing today? And so immersing myself in DevRel. meta world for a little bit of go, we're going to go to DevRelCon in July. I've been reading a lot of this blog posts from, Slack and Stripe and all those kinds of things. I have my own opinions, but I'll start trying to evolve some of those opinions and maybe put them into action. Right. [00:31:34] I definitely struggled a little bit with how to balance between all those different flavors of DevRel and not just try to do all of them at once and lean into the ones that you're good at. [00:31:42] Also, something that I learned from Trag, When he was my manager, it was this fact about how common burnout is in dev rel and that like usually people only last 18 months or whatever, and then they switch that they came into it from a engineering role or they're going out of it into an engineering role or they came into [00:32:00] it from, product manager type role or technical writer or, Documentarian, And then, yeah. And then maybe they leave or maybe they leave as a documentarian, maybe they leave as a product manager, but, I think that he did a great job as the manager of making it, a marathon and making sure that everyone was feeling productive. And, I think his, mindfulness around that was really powerful for our team at that time. [00:32:28] And yeah, I've definitely seen some other organizations where that is not true. And it they have a lot more churn in the DevRel team. But, [00:32:37] like a discord, like we don't have a Debrel manager, like track, We are embedded on an engineering team, which is great. Like I would prefer to be on engineering over marketing. Marketing is important. But [00:32:50] unfortunately, like working at orbit, we saw DevRel teams of all sizes and types and making a single product for DevRel was hard when it doesn't look the same at [00:33:00] every company and the goals are different, even KPIs, like where we find it hard pressed to define actual metrics for what we do. Like we know what we do. It's, but then when you get asked, what do you do? It's so many little things. Like oftentimes it's reactive comms, sometimes it's proactive, long term thinking. Usually we don't get as much time for that as we all probably want. the burnout is interesting. [00:33:26] Cause if you're an engineer, like I would say that's, it's a difficult job, but. It's different in that you know what things you need to do. And maybe there's some surprises, but like for the most part, you have maybe tickets or things that you need to get done, but you don't have the community also, to think about as much, I think you still should, you hopefully have a connection to the customer and stuff like that. [00:33:49] But sometimes we just have to put out some fires in the community. And sometimes our tooling doesn't work. that something happens in our, in SDK, every SDK that we release, every new surface we release is [00:34:00] like more surface area. yeah, just trying to quantify that and I think it'll help when we get to like performance reviews again. [00:34:06] And just thinking backwards from that, what do we want to be able to say? We did instead of just reacting to things all the time and then trying to compile the list of all the things that we reacted to over the last six months. [00:34:18] In hindsight, I'm really grateful for, The flavor of DevRel that I tended to lean towards was the content creation one. And there's, that creates so many like publicly visible artifacts that at the end of the, at the end of the performance cycle or whatever, it was easy to be like, okay, here's, 35 videos that I made and five blog posts and whatever. [00:34:41] And, which is much harder when it's okay, yeah, I'm doing these internal docs things that we can't even release because the product isn't ready. That's or oh, I spent five weeks of my time this quarter. Triage and things in, yeah. In like discord support while working with developers, trying to help them integrate, that's like much harder to show [00:35:00] different activities. [00:35:00] Docs is even tricky because it's like, there is that can a developer do the thing, yes or no, but also different developers may not be able to do the thing just depending on their background. And they may not have used something similar. So like,I think like I got something similar when we really started SDK for activities. there was like a quote where it was like, the docs were a little weird before, and now they're not. Now they're good. I was like, okay, I'm going to put that in my performance review. I guess that's a good review. But, and I've seen like in Stripe, you have they've got all sorts of like things that each page where it's was this page helpful? [00:35:37] Was it missing anything? that kind of stuff I'd like us to do so that we can get a little bit better sense of the journey. And we know that if you land on the docks today, you need to go through. Yeah. World build on your own. And we need to do some world building ourselves, but, trying to get into some generation of reference docs and stuff so that right now they're all handwritten, it's pretty painful. [00:35:59] So if we [00:36:00] can clear our plate of that, then it gives us more time to write out. The customer like developer journey, maybe to start getting into video. we really want to do video, but video, as is expensive to maintain, expensive to create if anything goes out of date, the suddenly the videos are out of date and so they're not as easy to go find where and when and all of that. [00:36:22] someone can crack that nut, that would be great. just make a product that makes a maintainable video that you can push updates [00:36:28] It's it's like a bunch of. Road signs. It's get video, right? It's okay, we're [00:36:34] gonna we're gonna rebase this one merge This is good up until here and drop in the new one And this maybe this is where like using a vtuber avatar or something is usefullet's just edit the [00:36:47] script and drop in the new screenshots. [00:36:50] We're done. [00:36:50] Yeah. Yeah. So there, have you seen the react video thing or I think it's called react video, there's like some tool that lets you build [00:37:00] videos with react. [00:37:01] Here we are back on the react train. react. [00:37:04] it, I don't know if it's video react. It's like it generates, gosh.yeah, that's it. [00:37:12] Yeah. Remotion. um,this is pretty sweet. And my, like one of my ideas, long time ago was like, use remotion to build the video in code. And you could use like code snippets in all the different languages that you support for your SDK. Then write your script and then you can have your script translated to other like spoken languages. [00:37:34] And then you can just spit out just like this giant multiplexed, like set of videos that get uploaded. And it's just, it's the same simple topic. But. It's then generated and also then you could make a PR to it [00:37:46] And [00:37:46] then if you could drop in a new explainer, new screenshots. Yeah. Interesting. [00:37:52] It's there's always another thing to do. [00:37:54] yes, always. [00:37:57] Nice. [00:37:58] What do you say? Should we call it there?[00:38:00] [00:38:00] I think that'll do it. Enjoy. enjoy the heat pump experiments. I'm curious to follow along. definitely share, share your updates and don't,don't electrocute yourself. Don't blow yourself up. [00:38:13] We'll try not to. And, yeah, good luck on the race. Hopefully, you have a good first leg and then those other ones should be all downhill from there. enjoy. Yeah. All right. you can find all the links to the resources we talked about today over at buildandlearn. dev. Thanks for listening. [00:38:31] Bye friends. [00:38:36] ​ All audio, artwork, episode descriptions and notes are property of CJ Avilla, Colin Loretz, for Build and Learn, and published with permission by Transistor, Inc. Broadcast by