It dependencies

Welcome to Changelog and Friends, a weekly talk show about syndicating toots. A quick thank you to our sponsors for helping us bring you solid developer pods each and every week. You know who they are. Fassy .com, fly .io, and typesense .org. Okay, let's talk. I'm joined by Justin Searles, back for the fifth time. Holy cow. Five -timer club. You should feel honored, you know? I do feel honored. You know, I have friends who haven't invited me to hang out more than three times, so five is an honor. Well, do your friends put out weekly conversational shows? Because maybe they'd invite you over more often. Right, well yeah, they don't have the financial incentive to keep pumping out new content. That's true. But the fact that I can't shut up probably aligns well with your interests. It does. I like when I get you wound up and rolling and I just sit back and have a drink and listen to you go. So that's the goal here. Oh god. A little inside baseball for our listener. You know, this has changed all good friends. It's our talk show format. Prior to this, I had a different idea. We have tons of ideas around here. We rarely execute on them. Most of them are just bad. But once in a while, we have a good idea that we still don't execute on. I Think I Had a Good Idea last year was a focused show about, I don't know if you wanna say the craft of software development, but really the practice and the nitty -gritty decision -making. And it was gonna be one -on -ones, recurring guests, and I wanted to call it It Depends. I think we even purchased itdepends .fm, because that's just a great name for a podcast, I think. So I decided not to do that. We decided to change all good friends instead. And one of the reasons is because a talk show format, like that's a, this is a super set of an It Depends. And so when I was coming up with that concept, I was like, who would be a nice recurring guest? And I made a short list and your name was on it. When I think about people who think deeply about software development, the decision -making process, the architecture, all of the nitty -gritty, and just bike sheds it all the way down, you were at the top of my list, Justin, so. I'm slippery. I refuse to take a stand and stick with it. And I refuse to pick a camp and promote it. I think it's just my religious upbringing that I'm just full of self -doubt. And that's what drives me forward, I guess.

Which

makes you a perfect guest for a show called It Depends, right? That's right. Cause you're never gonna actually pick a side. You're gonna slip around. Jared here in post. Another reason I had this show idea is because of just how often people say It Depends on our podcasts. In fact, we put together a little montage for you, only going back 50 or so episodes. Take a listen. The answer is It Depends. It Depends. It Depends. There's a big It Depends. I feel like It Depends needs its own little theme tune. Problem is it depends on how you view it. I guess it depends, but like, yeah.

Well, it depends. It depends on which country and which language.

Well, some people won't work with you either. It really depends on the moment that you're in and what's just happened.

I suppose it depends on the individual.

It depends. It depends on how sort of automated you want to be about it. Yes, it depends. Trade -offs. It kind of depends, right? It depends on the month, I guess.

It all depends. I mean, again, I hate to say like it depends, but I do, I think.

Well, it depends. It depends what? I guess it depends on which TikTok you're on. So the answers to all the questions are always going to be It Depends, right? I kind of figured that there would be a It Depends, as there always is. What do you think about that? It's like probably kind of a It Depends.

Yeah, it's very much a It Depends.

So... It Depends! It really depends on just like what... It Depends sometimes. But like, it really depends on what I'm coding. And it depends on the drive size. It Depends. I heard that a few times. So it's kind of an It Depends all the way down.

Depends on the graphic.

It Depends looks sexy. Oh, I don't know. It Depends a little bit. This is why a lawyer's favorite phrase is It Depends. But I think it depends if it's a simple... I guess it depends on the... The IBM ask for everything is It Depends, right? Of course. Yeah, I would say It Depends. Honestly, it depends on the... So, it really depends on... I sometimes do. It really depends because...

I think like It Depends, like there could be...

It just kind of depends,

like... It Depends, I mean...

And there it depends, I guess.

The answer is, as almost always in engineering, It Depends. It Depends.

So today I wanted to talk about dependencies. Hey, it's even in the name there, It Dependencies. Yeah, that's good. That is good, right? That was on accident, Justin. This is just how lucky I get sometimes. Yeah, dependencies. This is something that's been on your mind quite a bit. It's something that I think about a lot. You can frame it a few different ways. The first way is like the build versus buy decision, which we talk about a lot, people write about a lot. I'm sure you and I can riff on that concept. But then once you decide to buy, now you have opened up a whole nother can of worms of like, what do I buy? Which is a dependency selection, maintenance, collaboration, like the entire total cost of ownership of a dependency or of a piece of code. So let's start with the buy versus build. And I would just love to hear your thoughts on maybe how you go through that process and maybe how that's changed over time. Cause I've found myself, if there was a continuum, a plane, if you will, and on one far side of the plane was dependency hell and the other far side of the plane was like not invented here, hell. Yeah. Wheel reinvention land. Yeah, like we live somewhere, every one of us lives somewhere along that. And I found myself moving as I get older and more experienced, maybe more crotchety, moving more towards the not invented here and away from the dependency hell. But I'm curious your thoughts and maybe your experience as you've progressed. You know, I have found myself along a similar trajectory and I think part of it is for sure the crotchetiness cause you get burned by, when you get burned by a dependency that you pull in and you know, sets all your servers on fire and you're getting called in the middle of the night and then you realize that to fix it, you've got to change all your code and 800 different places to, you know, call the API just right or so forth. Right. You blame the thing, you blame the third party thing. It's its fault. Absolutely. But I did have my own foolish mistakes in building a thing. It's like, you know, if that goes sideways, if that blows up, it wasn't a bug. It was just a, you know, undiscovered feature request. There you go. We give ourselves excuses. Yeah. This is just what iteration is. This is, yeah, this is agile. This is agile. So there is definitely that. But I also think like, you know, when I started my career and, you know, I was writing Java 1 .3, I think maybe 1 .4, you know, not a very expressive language, relatively immature ecosystem. I think Ant was the way most people were pulling down dependencies. It was before Maven had come out and that was a huge pain. But even though it was painful to discover and pull in dependencies, the thought of how much work it would be to really accomplish anything with custom code on my own. Like I knew I'd just be building this, you know, mind palace of a homegrown framework to do the simplest of tasks. And in that mode, it made a ton of sense to pull in other dependencies to do stuff for me. And I got into that habit. I think a lot of us kind of did, but then nowadays when either the frameworks that we use are so robust and they've already kind of covered 95 % of the cases where it's like, if I use rails, that probably covers almost everything I need. Or languages as they become more expressive. So if you're a JavaScript developer, like modern JavaScript has obviated the need for dozens of little tiny polyfills and one -off, you know, APIs that are now more or less baked into something like a standard lib. Now you can just fly so much further so fast by just rolling your own stuff as you go. And so I think that's probably more than anything eat me further to the left on that graph. I'm with you. I think when I first started, but probably all of us live here for a little while, I pulled in other people's code, not because I wanted to, but because I literally couldn't accomplish it myself. Oh, good. Yes. Yeah. You know, like I literally, well, I don't know how to do this. I literally don't know how. So I'm going to find someone else who does, and I'm going to use theirs. And then over time, theirs lets you down in whatever ways that other people's code always does. And so you find yourself peeling back the covers. You find yourself patching things, you know, submitting issues. If you're like seriously using this over a span and you just slowly learn how that thing works. And then the next time I still can't write it myself, but I'm not going to pull that one in this time. I'm going to try somebody else's, right? Cause the grass is greener. And you see, they had tackled the problem from a different angle and you see that they have these advantages, but now these other drawbacks that you're living with, you know, and now you've learned two ways to tackle that problem. And eventually you get to the point where you're like, you know what? I've seen other people do this. I've seen where those solutions stand up and fall down. And so I'm going to give it a whirl, you know, the old college try. And sometimes that works out nicely. Other times, you know, not so much. And you go back to collaborating on somebody else's piece of code, but it really was out of necessity at first. And then eventually you just don't have the same necessities cause you've learned, you've advanced. I hadn't thought about that either, but that's spot on. I mean, you know, first time you do anything, first time I need to, I don't know, parse a really large XML document that's too big, just to kind of like read as one doc. I got to do a streaming parser or something like that. Right? Right. Well, pulling in something that makes that really easy and provides a DSL for me. So I don't have to think too hard about, you know, streaming a file read, you know, the cost to learn how to do it right, to learn the underlying concepts, to learn like the XML spec is so much higher. And then to do it myself is so much higher than just pulling the thing in. That's the right calculus at the beginning. But then, you know, and we see this writ large over and over again, but I think it's interesting to think about as an individual developer so that we can have some culpability in this. Like if I pull in that dependency and then it slowly burns me five times or a hundred times over the course of years. And then I pull in the second, you know, dependency and the third one to try to like solve the same problem. And if they all fall flat, pretty soon the cumulative cost to my productivity over years of trying to externalize this problem ends up dwarfing the cost it would have cost me just to like read the spec. And I've learned that lesson enough now that I'm a more competent developer and it's part muscle memory of just like, you know, I've learned, you know, sometimes you just got to swallow the bitter pill and learn a thing and. Right. So when it comes time to build or buy, do you have a philosophy or even a process today? I had a show with Ahmad Nasri a couple of years ago. He was at MPM at the time, or maybe he had just left MPM CTO. And he had this very strong take, like literally only build software that only your team could build. And everything else, if you don't have some sort of like unique contribution to the world, you should not be building it. It's a waste of your time and a waste of everybody else's time. I disagree with that, but I thought it was a pretty strong stance on pretty much buy everything, unless you can like literally do something that nobody else has the capability to do. And that's where we should be focusing all of our time. So that was his take. Do you have a strong philosophy today on, you know, when do you buy versus build? That take has a theoretical purity to it that makes me extremely skeptical. You know, because the truth is like, sure, there's probably a thing that I can uniquely do or my team can uniquely do, or that like perfectly encapsulates what our project or our application is designed to specialize in. But the truth is that to know where that line ends and where the sort of just this is commodity, you know, digital pipe fitting between two different, you know, integrations or something begins, that takes time, right? Like, and it's probably a moving target and to know and to be able to discover like what's the best tool for the job, that's real work and to keep all that stuff upgraded is real work. And so I think a lot of the early NPM employees were sort of package, small things, extremists. And I thought that I was one and then they really like lapped me. And it can go so far that you're spending all of your time just trying to curate and keep up with this gargantuan pyramid of transitive dependencies that you're standing on top of. What's up, friends? I'm here with Vijay Raji, CEO and founder of StatSig, where they help thousands of companies from startups to Fortune 500s to ship faster and smarter with a unified platform for feature flags, experimentation and analytics. So Vijay, what's the inception story of StatSig? Why did you build this? Yeah, so StatSig started about two and a half years ago. And before that I was at Facebook for 10 years where I saw firsthand the set of tools that people or engineers inside Facebook had access to. And this breadth and depth of the tools that actually led to the formation of the canonical engineering culture that Facebook is famous for. And that also got me thinking about how do you distill all of that and bring it out to everyone if every company wants to build that kind of an engineering culture of building and shipping things really fast, using data to make data -informed decisions, and then also inform to like, what do you need to go invest in next? And all of that was fascinating, was really, really powerful. So much so that I decided to quit Facebook and start this company. Yeah, so in the last two and a half years, we've been building those tools that are helping engineers today to build and ship new features and then roll them out. And as they're rolling it out, also understand the impact of those features. Does it have bugs? Does it impact your customers in the way that you expected it or are there some side effects, unintended side effects? And knowing those things help you make your product better. It's somewhat common now to hear this train of thought where an engineer or developer was at one of the big companies, Facebook, Google, Airbnb, you name it, and they get used to certain tooling on the inside. They get used to certain workflows, certain developer culture, certain ways of doing things, tooling, of course, and then they leave and they miss everything they had while at that company. And they go and they start their own company, like you did. What are your thoughts on that? What are your thoughts on that kind of tech being on the inside of the big companies and those of us out here, not in those companies without that tooling? In order to get the same level of sophistication of tools that companies like Facebook, Google, Airbnb, and Uber have, you need to invest quite a bit. You need to take some of your best engineers and then go have them go build tools like this. And not every company has the luxury to go do that, right? Because it's a pretty large investment. And so the fact that the sophistication of those tools inside these companies have advanced so much and that's left behind most of the other companies and the tooling that they get access to, that's exactly the opportunity that I was like, okay, well, we need to bring those sophistication outside so everybody can be benefiting from these. Okay, the next step is to go to statsig .com slash changelaw. They're offering our fans free white glove onboarding, including migration support, in addition to 5 million free events per month. That's massive. Test drive statsig today at statsig .com slash changelaw. That's S -T -A -T -S -I -G .com slash changelaw. The link is in the show notes. Kind of a good quintessential example of the decision -making process, I think, is something like authentication. And let's not talk authorization, but like authentication of a web application, like, you know, who are you kind of stuff. And there's businesses built around people buying this, right, like Auth0. That's just the one that comes to mind. I'm sure there's hundreds of them. That one was very successful. I think it got acquired by Okta. It's still out there. People will probably use it. And that's an example where people will say, I think even Ahmad said, you should never roll your own authentication because it's a solved problem. You're solving solved problems and it's a cheap one. And so, you know, just spend and move on. And I also take issue with that for certain reasons, but I'm thinking that probably you roll your own Auth in some of these projects. Yeah. Why? The things that everyone immediately reaches for, a dependency to solve, tend to be the things that people feel like they're too dumb to do, or that are just kind of like enough of a pain, you know, that like, oh, I don't really want to learn that, or I don't want to worry that. Or if you're in maybe an organization where people get blamed when stuff goes wrong, like no one wants to have their name on the get blame next to that one line in that, you know, authentication function that resulted in some sort of exploit or something. And so there's a lot of fear, uncertainty, and doubt driving our decision -making process of like, oh, not it, hot potato. And authentication, I think, is near the top of the list. But when you look at like a Rails application, for example, Devise has been the dominant gem for authentication for Rails for a long time. To this day? Yeah, I think so. But I find it so difficult to use and so difficult to learn, and I find that it gets its tendrils in so many of the different aspects of a system, you know, both in the controller layer and also in how you define your users and so forth, that I've come to just roll my own because like bcrypt and has secure password are good enough. Nowadays, I just do the magic email links like you all do on changelog. Right, why store a password? I wrote a blog post about this once, like how to roll your own kind of like Rails thing that does a magic email link. And there are ways you can go a couple of steps further, like doing an HMAC to make sure that the token isn't usable, that somebody can access your database and so forth. It's not rocket science. It's like, we're talking like 60 lines of code, a little bit of drudgery, maybe call it a code cada when you start up an app. There are a handful of password lists as a gem that like kind of does that. I'm sure there's going to be libraries for, you know, the WebAuthn stuff with the, you know, like... Pass keys. Pass keys, right, that you'll be able to pull in. And it's not like that it's any of these. To use one of those tools isn't bad, but the platforms are getting so good at defining what authentication is that we're talking about a real thin little layer of responsibility. And that if you use the same, you know, it's kind of like the no one ever got fired for hiring an IBM thing. If you use the exact same gem or the same package that everyone else does for auth, and it's got some sort of CVE in it, and you don't update your dependency, and it's like now getting actively exploited, like that seems to be a much wider vector than I did this, you know, callback in the wrong chain and my own custom call of these, you know, three steps I have to follow to get pass keys to work or something. I say that knowing that pass keys are actually a huge pain in the ass. Yes, I think there is actually a lot to the implementation side. And I think a pass key solution might be a situation. So I did all of our own auth on change .com and on other Rails apps over the year. I also learned a lot from Devise. I don't know if Devise is still as actively used as it was, but it was hugely beneficial for me to learn how auth works and then to realize like how many features you could possibly want in an authentication scheme and how I don't want almost any of those. And so it becomes like configuration, turning things off and on, et cetera. And I was like, I've learned how they do it. I'm just going to go do that. And you do find that it's relatively a small amount of code, 50, 100 lines of code, a couple of decisions, not even that many decisions to make it. Like, do I want passwords or not? I think pass keys might be a point where I would personally be like, hmm, I don't know how to do this. This seems new to me. I mean, I'll bolt something on top of what I built here, you know, and learn how pass keys work and rely on a package. I think what happens a lot, and I know that we talked to auth on that conversation. And I think the pushback on me, which you and I are both resonating with a similar stance was, yeah, but someone's going to want single sign -on. Someone's going to want tracking. Someone's going to like, you think all you need is like a simple password base or password list authentication, but there's always more. And now all of a sudden you're building this huge authentication thing with like Google tokens and blah, blah, blahs. And like, that's just a toggle inside your Auth0 account or whatever your password provider is. And so I think scope creep as like a necessary thing inside of business is an argument against rolling your own simple solutions. I'm curious because you work with a lot of businesses. I mean, do you just push back and be like, we're not getting, sorry, CEO, you can't sign in with your Outlook account. No, not at all. In fact, I think that like you raise a really good point that you can't really have this buy versus build conversation without thinking about the context that you're in, right? So far in this conversation, I've been representing Justin Searles, the independent programmer who builds independent things because no one else wants to work with me. Now we get to the, it depends part. But yeah, it depends because like, if you're a consultant who's only going to be there for a little while and you're building that Auth stuff and you're having trouble explaining, you know, for example, maybe the handshake that happens with an OAuth2, a secret and so forth, you wouldn't want to hand that code over to a team or to a more novice developer who wouldn't be able to maintain it. They'd be in safer hands with a, you know, a documented third party library that can do that for them, right? And so I think that if you're in the situation you're describing and you're in a big corporate environment and you know single sign on is probably going to come down the road, I think before you make the decision, you probably ask the product owner or you think for five minutes and you're like, you know what, do I really want to have like a side gig as a guy building a glued together Rube Goldberg machine of an Auth layer? Like, no, probably not. Yeah, just not backing yourself into any particular corners that are obvious. I think we can a lot of times end up in Yagney land where we are talking about non -obvious potential corner cases. I may need SSO someday and you have to actually sit down and think about whether or not that's like a real possibility or just some genericized engineering pipe dream of solving all solutions with one particular silver bullet which we tend to, I mean, I've fallen into that trap before and I know we all have because there's an acronym about it. Anytime there's an acronym, it means we've all pretty much been there which is thinking we're going to need something and finding out much to our chagrin years later, I never ever needed that and it's been slowing me down this entire time, so. Yeah, totally. That's a tough one. I think, gosh, how do you avoid that? Do you just get burned enough times that eventually you're skeptical of all features? I talk about this a lot and I'm sure I've shared with you that one of the reasons that I got into consulting in the first place was because I'd get 10 times as many reps in more organizations and more projects and more code bases in the same amount of time somebody else might only get to work on one product or one startup. True. And that experience has turned me into a pattern recognition machine where sometimes it's hard to explain why my gut is telling me like, you know, buy or build in this case. Sometimes it's hard for me to know like, you know, maybe I'll ask a pointed question to somebody who's saying, hey, we should do this versus that. After the fact, I'll be like, I don't really know why that question's what came to mind but the signals I think start to mount when you have a lot of experience being in the position to make this decision and having been burned by both ends of the spectrum, I like to think that this is one area where experience really does have a major impact on the wisdom of the decisions that we ultimately make. So could you give that wisdom to somebody with less experience or the answer like hang out with experienced folks? Like if you're don't have - Yes, for an hourly rate, I will give you all the wisdom that you desire. Justin's experience is for purchase. At testdouble .com slash contact. There you go. Well, let's get on the buy side now. So we've talked a little bit about that initial decision. Let's say we decided I'm not going to build this myself or my team is not gonna build this. Now we talk about dependency selection, right? Now we talk about, do I get a service? Do I get an open source package? Do I buy off the shelf? Do I buy custom from a development firm? And there's lots of different ways you can buy. Most of what we buy is open source dependencies, I think, pretty much. Cause they're the cheapest thing to buy. We think, but we're not always considering the total cost of ownership. You recently blogged the blog. I'm not sure we came up with this amazing title for it. Must have 10 years experience with Lineman JS. Yeah, that was a case of you egging me into making content. I just gave you, so one thing I do in my life is I write blog posts titles. So you write blog posts, I write blog post titles. And every once in a while, I'll get somebody else to write the blog post. You already had an itch to write this as you were celebrating, or I don't know if it was a celebration, Lineman's 10th anniversary. And we were joking around about that whole meme where somebody's always asking for more experience than is like humanly possible, right? Like as soon as Swift came out, it was like, must have five years experience Swift. So we're joking around about that. And Lineman was turning 10. This is an old JavaScript project that you can talk about a little bit. Actually that one of the reasons you first came on the changelog was probably the reason was Lineman JS. Yeah, yeah, yeah. It was a static site builder, right? So like nowadays we've got stuff like Hugo, you may have used Gatsby. Before it was cool. Yeah, this was before we had a word for static site generators or SSGs, or before anyone had talked about JAMstack, I was just trying to build rich JavaScript web applications that were gonna be backed by arbitrary different backends. And so it did all the kind of stuff you can predict about HTML and JavaScript and CSS and concatenating and compressing and fingerprinting all that stuff. But it also had like a API proxying layer that you could mock out particular requests until they were implemented and so forth. And it was really useful to us, but being a consultancy, we couldn't make it our full -time job to hire a bunch of DevRel people to pitch this free tool that made the job easier. And so it kind of faded out. And yeah, so I was reflecting on it after 10 years. And I think towards the end of that post, I started talking about what advice would I give somebody? What do I think about when I'm shopping for a dependency? So the first one I wanna call out and get your read on, Jared. Sure. First thing I look at when I'm looking at a dependency is I see how many dependencies does it have? And if I'm getting really, you know, ornery, how many dependencies do those things have? Right, right, right, right. Yeah, which is a spiral, can spiral out of control. Right. I definitely look at that. I wouldn't say it's the first thing I look at. I feel like maybe there's a phase of like window shopping first, and maybe you've already just advanced past that. Like when you're serious about a dependency, maybe you look there. It wouldn't be the very first thing I would look at, but definitely would at some point say, the question becomes how big is this thing? And you can't just look at its lines of code. You have to look at what it's building on top of. And yeah, you can find, you know, a node modules folder that goes all the way down into a black hole as the meme goes, or you can find not very much there. And you're like, okay, I'd like, unless it's a framework and I'm building on top of it, if it's a library that I'm actually integrating in, I would like it to have a very small surface area, if possible. Now, maybe it's solving a huge problem. And so it can't, but I want to know kind of how much I'm biting off, but it'd probably be like the third or fourth thing that I would check, personally. Yeah, I look at it because, well, first of all, the obvious, the facial reason is, if you pull something in that brings in a thousand other transitive dependencies underneath it, version resolution in most ecosystems becomes a risk. You know, maybe I can't update some other important thing now because this one library for some Yahoo in Omaha, Nebraska, like it hasn't been updated, right? And so now I'm locked because of this, they both shared the same transitive dependency on some, I don't know, CLI tool or some wrapper around the HTTP APIs or something. That I think is the first reason why people would need to look at that. But the second is having written a lot of open source in my day, and as I've become more competent as a programmer and maybe again, we can't really detangle how much of this is just us being crotchety, almost none of the libraries that I've written in the last five years have, well, okay, some have dependencies, but a lot of, a surprising number that have zero runtime dependencies. And when I see that in another library that does a useful thing, it signals to me that this actually solves the problem. This isn't just some bit of glue that connects me to the other thing that's gonna solve the problem or that the maintainer shares this ethos or this principle of essentialism that I have. And so that to me is a marker I think of quality more often than not. Yeah, there is like an aura of competency by the author because they didn't need anybody else's code to accomplish what at least scratched their own itch. So I think there is like a bit of a quality indicator there, not necessarily a guarantee, but at least an indicator. I've also pretty much eschewed anything with the word a rapper in the library title or read me because I hate hip hop. No, I'm talking about rappers around something else, which most things out there are nowadays. And I've written my fair share. Rappers are so easy to write that if you're just going to have something that wraps something else, we'll just go straight to the source and wrap it yourself. That's just pretty much been my move. So I ignore almost anything that has the word rapper in it. I like that for another reason. So facially, I think, again, yes, like that is a great reason to ignore rappers because all they can really offer is maybe some syntactic sugar that can do a cool demo and like, hey, look at this fluid API where you can chain these five calls and isn't that nicer than, you know, we're having to remember these particular function names or something. But the other reason that I avoid rappers is typically they are designed to be used, for example, like domain specific languages or DSLs to be sprinkled throughout your code base, wherever you might have this need. And it's actually the next thing on this list in this blog post is can I isolate it from the rest of my code via an adapter object that I own? Exactly. Or must it infect the rest of my code and tests and so forth? And what I end up doing with almost every one of these, you know, libraries that I pull in and what I'm looking for is something that just like, give me a function to call that solves the problem. And then I can write my own rapper in my own code that like, you know, basically charts an interface between me and this dependency, creating a little bit of scar tissue between my app and it. And then that way, if you know, down the road, that version resolution problem ever comes up and now I can't update my framework because this thing, they share a dependency, then I can go shopping to replace it and I've got a shopping list right there in the form of that rapper. Cause now I know what's the contract between that and everything else. Whereas if I'm just using this like, you know, fancy little rapper DSL and I'm sprinkling it all over my code, now the thought of switching to something else could be tremendous. Yeah, absolutely. It reduces your switching costs later because you've already isolated it. It also makes it easier to test around. I don't know your stance anymore on test doubles and mocking. I'm sure you have very nuanced takes on these things. We don't need to get into how much time you got. Yeah, exactly. It could be a different, it depends. But you know, if you are going to test in isolation, it's much easier to mock out if you have it, you know, just the number of calls lights down and yeah, you can just hop off whenever you want. Now I was actually thinking while you're talking of a funny, well, not funny, haha, but interesting case where I just recently tried to break the rule that I just laid down. And that is if the API or thing that you're trying to use is so gnarly that I just don't want to bother with its API. I really do want a rapper in that case. And here's an example. Changelog Nightly, which is an old Ruby app that runs through a rake file. I mean, just a Ruby app run through a rake file. Ruby 2 .3, if you're not familiar, it goes out to BigQuery every night and it gets from GitHub archive, all of the most starred repos in the 24 hour period and stuff like that. And it sends an email out. And it's been doing that dutifully on a cron for like eight years to a few thousand people who are interested in like the bleeding edge. Unfortunately, the bleeding edge right now also includes malware and spam. That's one of my problems. And these people are good. They're good, man. It's been cat and mouse, but I was trying to modernize that and just bring it up to like tools I can, cause I can barely hack on it. It's just after feed so much. And in so doing, I upgraded from Ruby 2 .3 to like three point whatever's current, 3 .1 .4. I don't know, something like that. And had to upgrade a bunch of gems. Everything was going swimmingly until the BigQuery gem could not, it was abandoned basically, BigQuery gem was abandoned. And I was like, all right, well, let's go check out the BigQuery gem and see what's going on. Literally no commits since 2019. So not recently abandoned, like long time ago abandoned. And it's got some issue with Ruby 3's TLS stuff and Cypher suites. And it's like, all right, this, you know, I'm losing my interest at this point. Like, why am I doing this? Anyways, I'm like, well, I'll just talk to BigQuery directly. And I did look at the code and I was like, oh, he's basically wrapping some Google calls and stuff. And then I realized that Google Cloud's API has changed since then. And it's like deprecated and stuff. And like the modern way of doing it. I mean, it's so painful to like, I couldn't figure it out. I mean, I didn't give myself that much time, but I was like, man, I wish I just had a new wrapper library that basically did what this guy was doing back in 2019, just for like their modern stuff. I would gladly grab that and use it because that cloud API, whatever Google designed over there, I'm not sure if you've ever looked at it, but holy cow, man, is it a beast? And I just don't have any interest in interface into that thing. Having just written a Ruby gem called feed2gram that takes an atom feed and then posts any photo posts that are configured a particular way to Instagram. This is like a, you know, maybe we'll talk a little bit about Posse later. Yeah, maybe if it's time. That's against the Facebook Open Graph API. That's gotta be painful. It was painful. And of course the documentation isn't stellar. And what I ended up doing was I spent the better part of a day, just me and curl and I would just curl every route and then I figured out the eight step Samba dance to figure, you know, okay, so if I do this and then this and I exchange that kind of token for this kind of token and then I barter with, you know, this fellow over here and then I'll get this other kind of token. It's literally like a three or four part dance. And then finally I can just say, hey, look at this URL and make a post about it. So the gem is basically just encoding these, you know, four or five magical HTTP requests that have to happen. And so I think what we're saying here is it depends. It does depend. I mean, of course it does. The, yeah, it's like the gnarliness of the API makes it depend because most, like if it's a nice restful API or even a GraphQL API, something that is just like, you know what? I can just hit some end points, grab a token, do my thing, chase on these serialized, whatever, whatever. Like you don't need a wrapper for that. But like some of these,

man,

and Google Cloud feels very enterprisey. Like all of this is like enterprise stuff. And it's like, dude, I just want to do the same query I was doing with this other thing. And change as little of my code as possible. And there's just, it's just gonna be painful. So there's a situation where it does depend. Yeah, you know what though? Now that I'm, again, and the reason this conversation I think is so evergreen is that it's so easy for your mind to flip from one end of the spectrum to the other and kind of attack from the other angle. Cause as you were speaking, I realized how many NPM packages and gems have I created? Where like, literally I was on a team, we rolled our own thing. We did the exact same curl thing. And then I was like, well, you know, the last thing I want to do is have this team be saddled with this code forever. It has nothing to do with the application that they're building. It's not, you know, domain specific to the, you know, point that your previous guess has made earlier. Like it's got no special sauce or differentiation for this team to have ownership of. That's when I would, you know, cut and then paste into a new folder and start a new gem that just does that thing. Give it a name, give it a read me, hopefully help somebody else out down the way. But that's where I think most of those zero dependency libraries that I've created come from. And so spinning off the liability of maintaining that wrapper, cause then that way maybe it'll die. And then at least you've got a canary in the coal mine of somebody else who might be using it. And if you're really lucky, they might even contribute a fix. Pick it up or yeah. Which kind of leads into your next point, which is about like people maintaining it or how is this, which I think is a particularly difficult question to answer sometimes. Like even myself, I find myself second guessing cause like a project can look abandoned, but not be. It can also look very active, but what they're doing is not really taking it in a direction that makes any sense. They're just putting fingers in the dike. It springs new leaks every week. Yeah, exactly. So like, is it maintained? Is it active? That's a thing that you can make a judgment call, but then the even harder one is like, and will it be a year from now? I mean, that's darn near just like a crapshoot sometimes. You don't know what's going to go on with that person, you know, or that company. So how do you heuristically decide if a project's healthy in that way? One of the most influential moments in how I think about this was I was speaking at a Node .js conference in Christchurch, New Zealand, and I got to meet Substack, not the email subscription service, but the fellow James who - Who wasn't too happy about the email subscription service, was he? I don't think so, no. I think I made that joke and I got a DM from somebody being like, yo, he doesn't - I didn't make that joke. No, he's probably with that. Anyway, yeah, so James had written so many of the formative original, like two, three year run of NPM packages, and he wrote browserify, which provided browser implementations for a lot of these kind of like standard library stuff in Node .js so that you could ship the same code, this might sound familiar nowadays, right, to a Node application and also to the browser. And I remember he had this one that had been really useful for me when I was probably writing test double JS for figuring out what the resolution algorithm for NPM would say for a given string so that I could figure out how to mock the thing because I'd be able to find the underlying file. And I remember that resolve package that he'd written had been really useful, and so I thanked him for that. And then I said, you've got so many packages, like how do you think about and keep track of and like stay on top of all the issues? And he said, oh, well, to be honest, I forgot I wrote that package. And I just think that if you design like pure functions, right, little tiny things that just do a thing and they're more like math and they're less like glue code behind your Google Cloud Platform API, which is a moving target. Totally. Then they can just be done. And, you know, maybe he even turns off issues or pull requests, right? In that case, right, you might not see any commits for 10 years, but does it work just as well as it did then? Maybe. So that's one reason why understanding the nature or the kind of dependency that you're pulling in, if it is glue code and it is connected to Instagram's API and it's got no commits for seven years, then you can be dead to write certain that it doesn't work anymore. But if it's something that smells more like math or it's working on an established file format, then maybe it just worked and then it's done. Is that an argument for JavaScript ecosystem style, like really small packages and then pulling in thousands of them? I mean, it seems like maybe it is, like small things that do one thing well and maybe are doing math or format changes or... I think there's a lot of value in it, right? Like be single purpose, be focused, be live in like, you know, what you publish and what the like, you know, come up with a good name for it, make sure it does what it says on the tin. But beyond a certain point, cognitively, we can only carry around so many in our heads. Like if I'm talking to James about this and he doesn't even remember writing that thing, like what we've seen in, when you take that to the extreme in NPM is how critical security audits have become because all it takes is like, you know, a domain name expiring or somebody coming along and buying a package from somebody else and then like secretly injecting a cryptocurrency miner, right, or a key logger or

some...

Taken to its extreme, what you're really doing is you're creating a chain of trust with a whole bunch of strangers. And you've got to be mindful of the fact that if you're effectively opening yourself up to everyone, you could never hope to audit at all. Hopefully, you know, GitHub co -pilot will be security scanning everything and it'll catch most of the stuff. I would still never feel comfortable if I didn't feel like I could get my arms around it and look at every single one of my dependencies and have some idea of, you know, who maintained it and what it was and what it did. Yeah, that's the unfortunate situation with NPM, I think, and that style of coding, where I think at a conceptual level, it's completely sound to say like, these are small units of functionality. They're black boxes, they're tested. So they have published tests. So we know they work as according to design and I don't care how they work. I'm gonna pull in as many as I need and that's all well and good, except for the fact that you're also downloading those fresh off the network, you know, in production and dev over spans of time. And we can't actually trust the network over a course of time because of all the reasons. I mean, event stream was a big one, left pad was a big one. There's others as well. Those are just off the top of my head where it's like, I mean, event stream, Dominic Tarr, basically just handing over the project to somebody who he thought was trustworthy. I can't remember how much he vetted that person and they just weren't trustworthy. And I don't really necessarily think that's his fault. He doesn't owe anybody anything. He was done with it. It was kind of like your situation with James where like maybe James would have handed that out. He hasn't thought about it for years. This was a package that Dominic wasn't using. He didn't even suggest you use anymore. He's like, you shouldn't use this. I've written the better thing. And yet so many people did that when that package got compromised, it was a serious problem for lots of people had a bad day. Yeah, there's a theme here that I think, you know, something about dependency shopping that we haven't really dug into that I have identified as being a big motivator for me personally, in terms of like, what is the principle that's driving my decision -making process around dependencies and what I use and whether build versus buy. And I think it's self -reliance. If you go to like the self -hosted subreddit, you know, it's kind of like the digital equivalent of prepper culture of like, you know, people trying to cordon themselves off from the rest of the world. And I don't typically identify with that group or that instinct when people talk about, you know, privacy rights extremists or people who say, you know, like I wanna own my data. Yeah, I think that is a, these are sufficiently confusing flags to plant in the ground and just how kind of, you know, online everything is these days. But when I think of it through the frame of self -reliance, like at the end of the day, how many other people could knock over my sandcastle? And I wanna keep that number as low as possible. And I wanna keep the gross like likelihood that my sandcastle gets knocked over to be as small as possible. And so if you'll take this as a segue, I have been on a mission over the last year to kind of transform my personal website, justin .serles .co to be the place, the single place where I put all of my internet stuff. I post my like tweet -like takes there, my photo posts, of course, blog posts. I started to like link blogging and sort of a Gruber -Daring -Fireball style to the stuff that I was reading. And that replaced for me like four social networks. And, you know, coincidentally, of course, like I started thinking seriously about this when Musk bought Twitter and I realized that the whole Twitter category of like text -based real -time, you know, posting, microblogging, like

there

was no longer gonna be one authoritative website for that. It was gonna get fractured. And in fact, we talked, I think, like a month into that and we were kind of joking about like the post -Twitter era and how that was gonna play out. Instead, what I do now is I post, it's really funny if you go to the website because it's so stupid, but like if you go to my website and you scroll down a bit, you'll see a thing that looks like a tweet with my face on it, the same little Twitter avatar I've been using for 12 years, bigger text and like little share buttons underneath, except instead of like social share, it's like you click the chat button and it just opens an email to me or like, you know, a copy link or a share sheet thing. And then I syndicate it to Mastodon using feed to toot, which is, you know, I named feed to gram because feed to toot was there first, but that's a little Python egg that will, I have running on a Docker container on my Synology and it reads that atom feed however many times a day. And then it posts all of my takes as if they were, you know, Mastodon toots. And if I wanted to, I could do the same thing for Twitter and maybe when threads opens up its API, maybe I'll post to threads too. And I just started doing it for the Instagram stuff last week after I finished that gem. And it's actually, right now it's churning through a backlog of all my photo posts. I have implemented that initially for a Japan trip in when I was at Ruby Kaigi in May and all of my friends, like the guy who does my car detailing and like the lady who cuts my hair, they're all like, oh wow, did you just get back from Japan? And I only then realized that it was like, it posted the entire backlog of all of my photos to Instagram. And that experience having like half a dozen people in my life be confused about what country I'm in right now when I didn't do anything, tells me like, man, like people really use Instagram. Oh yeah. I don't, like I don't have it installed. I don't think about it, but I want to stay in touch. I want people to see my stuff. And it's not like I'm going to go and convince my mom to get an RSS feeder, a feed reader. So that I have one website and I'm syndicating it everywhere else. It has a real appeal to me because yeah, sure. Instagram could go away or that Mastan could go away, but like my site is still sort of the canonical place for all that.

What's

up friends. This episode is brought to you by our friends at Neon. Serverless Postgres is exciting and we're excited. And I'm here with Nikita Shamganov, co -founder and CEO of Neon. So Nikita, one thing I'm a firm believer in is when you make a product, give them what they want. And one thing I know is developers want Postgres, they want it managed and they want it serverless. So you're on the front lines. Tell me what you're hearing from developers. What are you hearing from developers about Postgres managed and being serverless? So what we hear from developers is the first part resonates absolutely. They want Postgres, they want it managed. The serverless bit is 100 % resonating with what people want. They sometimes are skeptical. Like, is my workload going to run well on your serverless offering? Are you going to charge me 10 times as much for serverless that I'm getting for provision? Those are like the skepticism that we're seeing and then people are trying and they're seeing that the bill arriving at the end of the month and like, well, this is strictly better. The other thing that is resonating incredibly well is participating in the software development life cycle. What that means is you use databases in two modes. One mode is you're running your app and the other mode is you're building your app. And then you go and switch between the two all the time because you're deploying all the time. And there is a specific part when you're just like building out your application from zero to one and then you push the application into production and then they keep iterating on the application. What databases on Amazon such as RDS and Aurora and other hyperscalers are pretty good at is running the app. They've been at it for a while. They learned how to be reliable over time and they run massive fleets right now like Aurora and RDS run massive fleets of databases. So they're pretty good at it. Now they're not serverless, at least they're not serverless by default. Aurora has a serverless offering. It doesn't scale to zero, Neon does, but that's really the difference. But they have no say in the software development life cycle. So when you think about what a modern deployed to production looks like, it's typically some sort of tie in into GitHub, right? You creating a branch and then you're developing your feature and then you're setting the PR. And then that goes through a pipeline and then you're on GitHub actions or you're running GitLab for CI CD. And eventually this whole thing drops into a deploy into production. So database are terrible at this today. And Neon is charging full speed into participating in the software development life cycle world. What that looks like is Neon supports branches. So that's the enabling feature. Git supports branches, Neon supports branches. Internally, because we built Neon, we built our own proprietary. And what I mean by proprietary is built in house. The technology is actually open source, but it's built in house to support copy and write branching for the Postgres database. And we run and manage that storage subsystem ourselves in the cloud. Anybody can read it. It's all in GitHub under Neon database repo, and it's quite popular. There are like over 10 ,000 stars on it and stuff like that. This is the enabling technology. It supports branches. The moment it supports branches, it's trivial to take your production environment and clone it and now you have a developer environment. And because it's serverless, you're not cloning something that costs you a lot of money and imagining for a second that every developer cloned something that costs you a lot of money in a large team. That is unthinkable, right? Because you will have 100 copies of a very expensive production database. But because it is copy and write and compute is scalable, so now 100 copies that you're not using, you're only using them for development, they actually don't cost you that much. And so now you can arrive into the world where your database participates in the software development life cycle, and every developer can have a copy of your production environment for their testing, for their feature development. We're getting a lot of feature requests by the way there. People want to merge this data or at least schema backing into production. People want to mask PII data. People wanna reset branches to a particular point in time of the parent branch or the production branch or the current point in time, like against the head of that branch. We're super excited about this. We're super excited, we're super optimistic. All our top customers use branches every day. I think it's what makes Neon modern. It turns a database into a URL and it turns that URL to a similar URL to that of GitHub. You can send this URL to a friend, you can branch it, you can create a preview environment, you can have DevTest staging, and you live in this iterative mode of building applications. Okay, go to neon .tech to learn more and get started. Get on -demand scalability, bottomless storage, and data branching. One more time, that's neon .tech. That speaks to me at a practical level or maybe at a conceptual level. I think maybe not at a practical level. You've gone through a lot of work to get that done. I think we need to make it more easy for folks, but there's something about it as well that just feels antisocial because it's a push -only system. Your mom gets to see your feed to grams, but you're not seeing your mom's grams, so you're not actually there. You're just faking that you're there, and it's a one -way thing. Does it feel like that? Or do you go on Mastodon? I see some of your posts on Mastodon, but now I know your system, and I think Justin's not really here, that he just put that on his website and he's gonna push it out to me. Maybe I replied anyways. I can't recall, but I just know that you're not really there unless you're lurking now and checking your mentions. And I'm not faking it either, and I'm definitely not lurking because the whole reason I built this was - So you didn't have to. Yeah, I had a Twitter addiction where I was just addicted to all these pull -to -refresh timeline feeds. And I tried to cope, and I tried to moderate, and I tried to, well, I don't have it on your phone, and then like, well, why am I on my computer right now just hitting Command -R? Okay. So I had to quit. Fair. But you're right. It is antisocial in the sense that I always think of social media these days as a right -only medium. I put it out into the world so people can see it. If there was a setting where I could turn off replies and comments, I would, because I would hate for somebody to reply for me to not see that reply. And in both Instagram and Mastodon now, my bio says, hey, this is an automated account. Please send me an email. So it's definitely, I am a more antisocial, misanthropic guy than average for sure. Somewhat by necessity though. So I mean, you gotta know where you live. Yeah. I think just that I use it all the opposite of you because we've always published change log stuff to our website. And of course you syndicate at VRSS. That's how podcasts work. That's how change log news has always worked. We used to be way more link bloggy than we are now. Now we just do a newsletter once a week and we publish that out. Best newsletter in tech, by the way. Hey, thank you very much. I appreciate that. It's genuinely really good. It's the only one that I subscribe to. I love that about you. How do you know it's really good if it's the only one you subscribe to? Well, you got me. You got me. I have a special skill of ruining compliments. No, that's awesome. Point being is like, when I go to social networks, then like we're trying to be with the people. Like I want to hear what people are saying, what they're thinking. I want to interact. And so if I didn't want to interact, then I wouldn't even go there. And so whenever time I'm there, I'm wondering like, what's going on? But I do love the fact that you have self -reliance. You have all your content on your website, which is like the way the web is kind of supposed to work. And I think that's a cool thing. So talk about the tech then, because I don't think this is easy for folks to set up and maybe WordPress makes it easy. I don't know what publishing tools look like nowadays, but you're very much manual. This is all your own code driving this stuff. It is, and it's closed source. And I've been debating whether or not to open source it and how much work it would be to make this repeatable. What I wouldn't want to do is put into the world like, hey, just copy paste this repo and get start as a starting point, because then I'd be getting emails for years about, every little customization. What my website is, is a Hugo generated site. Hugo is very fast. It's a great static site generator. The main conceit is if you look at the sidebar, there are like eight or nine different media types. And what those are in Hugo terms is I've created separate sections and each section has like a different set of HTML layouts. Because they're named differently, I can kind of branch with ifs and elses to treat them differently in the RSS feed. And then they each look at different parameters in that front matter at the top of the markdown file that drives them. So when I want to post some images, for example, to my fake Instagram, I wrote like a little JavaScript swipey do carousel thing that I think is really pretty decent. When I want to post something like that, I want to do it from my phone, but all of the Hugo stuff is that's all flat files in Git. So I wrote a series of extremely contrived Apple shortcuts, where I can select the five pictures I want, do the share sheet thing, click on the shortcut, give it a title, hit go, and then in the background is going to use working copy, which is like a Git client for iOS, to pull down the latest from the site, create the markdown file with a timestamp based name, and then compress and size all of those photos appropriately and then list them off as like a list of photos in the front matter in the YAML. And then I just, all I have to do after that is I just hit push. And so that's how I post to the site. I see, and so that's all inside of shortcuts. Yeah, so because static site generators are like naturally, like, you know, they're inert. Once the build happens up in Netlify, it's just some files. I can't get any of that interactivity from the site itself, which makes it really performant from a CDN perspective, but it means for any like action that I want to take on it, it's back to what automation can I build to just get that file that I need in the right place. And shortcuts and, you know, other kind of like, you know, shell scripts and other little things like that work great, but that's not advice that works for non -programmers probably in most cases. Right, so you got posts, links, I assume that's just kind of your link blog, shots, takes, these are your hot takes. The fake tweets. Fake tweets, okay. Tubes, these are videos I assume. Yeah. And mails, you publish all your email this way? Yeah, all my email newsletters. Oh, newsletters. Just all your email. It's like you log in with Telnet and just check out what? I'm an open book, it's radical transparency. That would be pretty radical. That's interesting. Man, all these through shortcuts and stuff. So you just have lots of time. You spend lots of time coding. You code more than I do, that's my takeaway. Despite you being antisocial, despite being totally okay, just sort of blasting out content into the world, I have a larger than average need for the validation of others. And so that win, like for example, Musk bought Twitter and you started to see Twitter deteriorate in various ways. For me, I felt a very visceral loss of, oh no, like even though it's silly, even though it's stupid, even though it's like a manifestation of some sort of digital addiction that I have to timeline -based news, that threatened for me that source of dopamine, right? Like I wasn't getting the same validation that I would. People aren't replying anymore. I am no longer getting the reach that I did. I lost my blue check mark. I had a real blue check mark when those were still cool. And now I don't, because I didn't want to pay however much a month. So just from a purely vanity perspective, it was worth it to me to go through the steps that I needed to in order to finally untether myself from that, let's be honest, just addiction. And so I was like, now I'm finding that instead of writing, you know, pithy and provocative things to elicit some sort of reaction, like people reposting my stuff, I'm finding my voice again as like, you know, an author, like my writing has gotten a lot better. I started a newsletter. And when I say, you know, you can email me and there's a little email button or something, people are starting to email me back long emails, like thoughtful, interesting, actual conversations that I think social media tricks us into thinking are what real, you know, that the comments that happened there are the real conversation of the very suitable replacement for the intimate, you know, actual talking to another human might've been. But I feel like this, you know, owning your blog, syndicating elsewhere, and then inviting people to email you, people show up differently. And like it results in much more, you know, richer and rewarding conversations that matter. So I've really, you know, night and day over the last couple of months since I was able to finally pull the trigger on all this, I just feel so much better about how I relate to the internet. And I can feel sort of like a cloud over my own sense of identity, like lifting. So it's working for you. That's awesome. I would then encourage you to open source this cause it might work for others. Maybe not even open source it, not with the whole like, let's have a community project, but just like, this is my thing. Hopefully it will help you create your own thing. Cause it does very much feel like you've kind of compiled together this system that may only work for Justin, maybe it'll work for like 12 other people. I could be dead wrong and it could work for thousands, but oftentimes I think open source value is just in showing somebody else the way, you know, to do their own thing. It goes back to dependencies. Like I learned so much from just using other people's code for over time and then eventually looking at it, you know, getting the confidence. A lot of us don't ever look at the code in our dependencies, which I would also suggest people look at the code, but maybe somebody else will find their own system that works for them and it helps them with, you know, whatever problems are social, you know, the way they want to interact with the internet by following your path. Well, I'll tell you what, a commitment I'll make here today is if anyone listens to this and what I'm saying resonates and they'd be interested in that too, shoot me an email, which will be in the show notes. There you go. And if I get enough of those, I will, because of my outsized need for human validation, I will probably drop everything and go and figure out how to share this. I will probably drop everything. But at the very least, it would be a good indicator that there's something here and it would probably help shape up whether that should be like a Hugo start point archetype project or what. Yeah, even just publishing how you do it, like even that's just a blog post of how it works. Sometimes that's enough to show people. I think there's probably, I know there's a whole indie web world that I like, I rarely graze upon every once in a while. I'm not like deep into it, but I know people want us to do shows on the indie web. We're very much fans of this style of like, we want people to have a domain, own your content. I think syndication makes sense. Syndicate to all the places. I mean, we kind of do that ourselves. I'm doing most of the things we used to be like buffer users and that I wrote a wrapper on the buffer API and elixir, et cetera. And I've since like just turned all that off and it's like, I'm just gonna go to each place and interact there for a while and see how that works because there's something about the social networks that they all have their own little, like, I don't know, cultures. They have their little persnickety things and just like blasting. I found if you're looking for a region for engagement, which we'd love for more people to listen to our podcasts. So like, that's one of the reasons why we go there, have conversations, reach new people, et cetera, share our clips, having it like just completely automated syndicated for me, it feels for our change log thing that we do, it feels like inauthentic to a certain extent. It is inauthentic. You are just like, I am just blasting stuff. It's just, I had to do the calculus to say, for me in my business where I make $0 off all my content, it was not worth my time to suffer a bunch of fools lighting me up or telling me how dumb I was on Twitter -like platforms. But for you running a newsletter where you actually want to discover this stuff and you want to build that engagement, I think it makes perfect sense to show up. You know, Jared, you're a man of the people. I am. But, you know, at the same time, it's all a matter of like, what do we value? What are we doing this for? And what's the opportunity cost? Like how much time has it taken? And so the amount of time and attention that I would be spending in social media, I realized that it was enough attention residue that maybe I wrote one fewer blog post a week, right? Or I wasn't really able to think through the problems because I was so used to hitting command tab to going to that. And so I think, you know, it all depends on what you're solving for. So what you're saying is it depends. Yeah, there we go. Damn, way to tie it back. You always got that. Oh, I've been BSing for many years now. All right, well, I mean, I think that's a good place to end it. We'll have, the calls to action will be this. If you are interested in Justin's system, look in the show notes for the email for you to send an email to. Do not toot him, do not gram him. I mean, you're welcome to. Follow me on all of these platforms and receive my content if you wish. No, I mean, if they want to contact you, they shouldn't do these things. Email, that's the way to reach. Justin at surles .co. There you go. So easy, so easy. The website is justin .surles .co. Are there other surleses? So you thought you'd put your first name as a sub domain or you could just go on surles .co. Yeah, there are other surleses. So my brother is a surles. He is a senior elixir developer at cars .com. Oh, really? And since I hogged the surles username on every social platform, I figured if I'm going to buy the surles .co domain, I probably shouldn't also make that all about me. So does he have a sub domain of his own then? Well, I've invited him to, but he's more than willing to let me be the internet acrobat of the family. And I think he's a little bit more chill. He's got less that he's got an itch to broadcast. Love it. Well, it takes all kinds, it takes all kinds. Well, Justin, I always appreciate having you on. Fifth appearance, let's make it six, seven, and eight. One of these days, keep coding, keep writing hot takes and warm takes and stuff for us to talk about on the show. I mean, if I could quit it, I would, but I think speaking of addictions, I just compulsively keep putting stuff out and I will keep texting it to you so that you share with your folks. I really do appreciate it. I have so much fun here. And hopefully this conversation has piqued the interest of a few people who might start to think differently about whether their relationship with social media is serving them or not. One more call to action. This one's selfish for me. If you have strong opinions on build versus buy, if you have strong opinions on dependency selection criteria, how you do it, I would love for people to write about that and send them to me so we can aggregate a lot of wisdom. I feel like there's so many different ways to attack this particular problem. Wherever we are on our experience path, we have a different angle into this and there's no one true way of solving this problem. That's why it's the perpetual, it depends. And so I would love to have an aggregation of a lot of folks who are smart and then put thought into this, writing down their thoughts so that we can all learn from each other. So there's my call to action. Cool, thanks Justin. Thanks everybody for hanging out and we'll see you on the next one. See you later, friends. Bye, friends. If you liked this, it depends variant of Changelog and Friends, holla at your boy. I'm Jared Santo on X, Jared at changelog .socialautomastodon and Jared at changelog .com on electronic mail. That's J -E -R -O -D at changelog .com. I love hearing from you. Oh, and if you enjoyed Matt's musical styling from the previous episode, the clips are hitting YouTube as I speak. So you can enjoy them like a little morsel of goodness and you can see the ridiculous faces Matt makes too. Like, subscribe and smash the appropriate buttons at youtube .com slash changelog. Thanks again to our partners, fastly .com, fly .io and typesense .org. And thank you to our beat freaking residents. BMC is working on a new album for you. We're calling it Dance Party. That's all for now. Well, let's talk again real soon.