The Changelog: Software Development, Open Source - It dependencies (Friends)

Episode Date: November 17, 2023

Jerod goes one-on-one with our old friend Justin Searls! We talk build vs buy decisions, dependency selection & how Justin has implemented POSSE (Post On Site Syndicate Elsewhere) in response to the stratification of social networks.

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. 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 want to say the craft of software development, but really the practice and the nitty gritty decision making.

And it was going to 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. It is. Decided not to do that. We decided to do Change Logging Friends instead. And one of the reasons is because a talk show format,

this is a superset 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 Mike sheds it all the way down, you were at the nitty gritty, and just Mike sheds it all the way down. You were at the top of my list, Justin. 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? Because you're never going to actually pick a side. You're going to 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. 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. Tradeoffs. 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 my questions are always going to be it depends right i kind of figured that there would be a uh it depends as there always is what do you think about that that's probably kind of a depend it depends yeah it's very much an 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 on the text. It depends a little bit. This is why lawyers' favorite phrase graphic it depends looks sexy well i don't know it depends a little bit this is why lawyers favorite phrase is it depends but i think it depends if it's a simple and 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 um i sometimes do it really depends because i think like it depends like there could be 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. Yeah. So today I wanted to talk about dependencies. 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 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 yeah 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. Because 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 some 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 because 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 pull in and it, 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 by din of 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'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, 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. I knew I'd just be building this 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 it 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 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 eked me further to the left on that graph. Yeah. I'm with you. I think when I first started, probably all of us live here for a little while. whatever ways that other people's code always does. And so you find yourself peeling back the covers. You find yourself patching things, submitting issues, if you're 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 because 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 and 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 because you've learned, you've advanced. Yeah. 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 that 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 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 uh muscle memory of just like you know i've learned you know sometimes you just got to swallow the bitter pill and 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 I had a show with Ahmad Nasri a couple years ago. He was at NPM at the time, or maybe he had just left NPM, 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 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 on 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 is 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 keep all that stuff upgraded as real work. And so I think the, uh, a lot of the early NPM employees were sort of package small things, extremists. Uh, 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 StatSync? Why did you build this? Yeah, so StatSync 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 like, you know, how do you distill all of that and bring it out to everyone? If every company wants to like 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 what do you need to go invest in next. And all of that was fascinating, was really, really powerful. So, 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 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 like 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. from these. Okay, the next step is to go to statsig.com slash changelog. 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 changelog. That's S-T-A-T-S-I-i-g.com slash change law the link is in the show notes so kind of a good quintessential example of like the decision making process i think is something like authentication 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 zero that's just the one that comes to mind i'm sure there's businesses built around people buying this, right? Like zero, that's just the one that comes to mind. I'm sure there's hundreds of them. That one was very successful, I think acquired by Okta, it's still out there, people 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 solve problem. You're solving solve 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 off 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 a maybe a an organization where where people get blamed when stuff goes wrong like no one wants to have their name on the get blamed next to that one line in that you know authentication function uh 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 lot 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, 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 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 steps further, like doing an HMAC to make sure that the token isn't usable. If 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 coda when you start up an app. There are a handful of password lists as a gem that kind of does that. I'm sure there's going to be libraries for the web auth and stuff with the- Passkeys. Passkeys, 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 hire 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 call back in the wrong chain in my own custom call of these you know three steps i have to follow to get passkeys to work or something right i say that knowing that passkeys are actually a huge pain

in the ass. Yes. I think there is actually a lot to the implementation side. And I think a Passkey solution might be a situation. So I did all of our own auth on changelog.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 configuration, turning things off and on, etc. 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 be, I may 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 off on that conversation. And I think the pushback on me, which you and I are both resonating with a similar stance was, package um i think what happens a lot and i know that we talked off 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 gonna want single sign-on someone's gonna want tracking someone's gonna like you think all you need is like a simple password based or passwordless 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 auth zero 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, a 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, uh, 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 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,

for example, maybe the handshake that happens with an OAuth 2 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 documented third-party library that can do that for them. 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 off 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. You know, 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, you know, 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. 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. 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 is what came to mind. But the signals, I think, start to mount when you have 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 for an hourly rate, I will give you all the wisdom you can purchase. 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 going to build this. Sure. 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, because they're the cheapest thing to buy. We think, but we're not always considering

the total cost of ownership. You recently blogged a blog. I'm not sure where you came up with this amazing title for it. Must have 10 years experience with LinemanJS. 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 post 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 humanly possible, right? 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, 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 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 So 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 going to 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, compressing and fingerprinting all that stuff. But it also had like a API, you know, proxying layer that you could mock out particular requests until they were implemented and so forth. And it was really useful to us, but, you know, 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 want to 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 at that. I wouldn't say it's the first thing I look at. I feel like maybe there's a phase of window shopping first, and maybe you've already just advanced past that. 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 just look at its lines of code. You have to look at what it's building on top of. And yeah, you can find 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 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 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, 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. Maybe I can't update some other important thing now because this one library for some Yahoo in Omaha, Nebraska hasn't been updated. And so now I'm locked because of this. They both share 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 to tangle 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 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 going to 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 rapper in the library title or readme because I hate hip hop. No, I'm talking about rappers around something else, which most things out there are nowadays. I mean, 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 wrappers 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 wrappers 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 wrapper 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 wrapper because now I know what's the contract between that and everything else. Whereas if I'm just using this like, you know, fancy little wrapper 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 that. Yeah, how much time you got. Yeah, exactly. It could be a different, it depends. But if you are going to test in isolation, it's much easier to mock out if you have it, just the number of call sites 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 wrapper 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 running 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 at and mouse. But I was trying to modernize that and just bring it up to tools I can... Because I can barely hack on it.

It just atrophied so much. And in so doing, I upgraded from Ruby 2.3 to 3.1.4. I don't know. Something like that. And I 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 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 deprecated and stuff. And the modern way of doing it, I mean, it's so painful. 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 ever looked at it, but holy cow, man, is it a beast? And I just don't have any interest in interfacing with that thing. Having just written a Ruby gem called feed to gram 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 painful and of course the documentation isn't stellar uh 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 like 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 bar barter with, you know, this fellow over here, 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. Yeah. And so I think what we're saying here is it depends. It does depend. I mean, of course it does. Yeah, it's like the gnarliness of the API makes it depend. Because 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 endpoints, grab a token, do my thing,

JSON, deserialize, whatever, whatever. You don't need a wrapper for that. But some of these, man. And Google Cloud feels very enterprise-y 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 going to 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. Right. 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 guests 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, because 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 because 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 but what they're doing is not really taking it in a direction that makes any sense they're just putting fingers in the in the dike yeah it

springs new leaks every every week yeah exactly so like is it maintained is it active that's a thing to you can 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 fella 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 want to hear that joke. No, he's probably like that. Anyway, yeah. So James had written so many of the formative original two, three-year run of NPM packages, and he wrote Browserify, which provided browser implementations for a lot of these standard library stuff in Node.js, so you could ship the same code, this might sound familiar nowadays, to a Node application and also to the browser and i remember uh he had this one that

had been really useful for me when i was probably writing test double js for um 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 i remember uh 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 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 right certain that it doesn't work anymore. Yeah. 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 yeah 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 something 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. Um, hopefully, you know, GitHub copilot 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 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 going to 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 handed 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. He didn't, it was kind of like your situation with James where like maybe James would have handed that off. He thought 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, 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 want to 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 want to keep that number as low as possible. And I want to keep the gross likelihood that my sandcastle gets knocked over to be as small as possible. Yeah. 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.cerulls.co, to be the place, the single place where I put all of my internet stuff. I post my tweet-like takes there, my photo posts, of course, blog posts. I

started to link blogging in sort of a Gruber, Daring Fireball style to the stuff that I was reading. And that replaced for me four social networks. And coincidentally, of course, 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, micro-blogging, like there was no longer going to be one authoritative website for that. It was going to 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 going to play out. Instead, what I do now is I post, it's really funny if you go to the website, cause it's so stupid, but like 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 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 uh which is a you know i named feed to gram because feed to toot was their first but that's a little python egg that will i have running on a docker uh container on my synology and it reads that atom feed however many times day. And then it posts all of my takes as if they were, you know, Mastodon toots. Right. 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 when I was at Ruby Kagi in May. And all of my friends, like the guy who does my car detailing and 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 posted the entire backlog of all of my photos to Instagram. And that experience of 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 has a real appeal to me because yeah, sure, Instagram could go away or that Mastodon could go away, but 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 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 that people are trying and that they've seen 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 lifecycle. 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 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 lifecycle.

So when you think about what a modern deploy to production looks like, it's typically some sort of tie-in into GitHub, right? You're creating a branch, and then you're developing your feature, and then you're sending a PR. And then that goes through a pipeline. And then you run GitHub Actions or you're running GitLab for CICD. And eventually, this whole thing drops into a deploy into production. So databases are terrible at this today. And Nian is charging full speed into participating in the software development lifecycle world. What that looks like is Nian supports branches. So that's the enabling feature. Git supports branches is Nian supports branches. So that's the enabling feature. Git supports branches, Nian supports branches. Internally, because we built Nian, 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. You know, 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 lifecycle. 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 back into production. People want to mask PII data. People want to 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. And 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 dev test 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. So like, you're not actually there. Like you're just like faking that you're there. And that's, it's a one way thing. Does it feel

like that? Or do you go on Mastodon? I mean, 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 going to 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 like lurking now and checking your mentions. And I'm not faking it either. And I'm definitely not lurking because like the whole reason I built this was, you know. So you didn't have to. I got a, yeah, I had a Twitter addiction, right? Where I was just addicted to all these pull to refresh timeline feeds.

And, you know, 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, why am I on my computer right now? Just hitting command R. Okay. So I had to quit. Fair fair, but you know, you're right. It is antisocial in the sense that I always think of social media these days is like a right only medium. Like 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 in Instagram and Macedon 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 got to know where you live. I think just that I use it all the opposite of you because we've always published ChangeLog stuff to our website. And of course, you syndicate it via RSS. That's how podcasts work. That's how ChangeLog 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. 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. 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're 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 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's 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 they each each section has like a different set of HTML layouts and they each because they're named differently. I can kind of branch with ifs and elses to like treat them differently in the RSS feed. Sure. And then, you know, they each look at different parameters in that front matter at the top of the markdown file that drives them. So like 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 and 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's going to use a working copy, which is like a get 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 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 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 emails 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 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 when, 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, even though it's silly, even though it's stupid, even though it's 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 checkmark. I had a real blue checkmark 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. So I was like, now I'm finding that instead of writing pithy and provocative things to elicit

some sort of reaction, like people reposting my stuff, I'm finding my voice again as an author. My writing's 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 happen there are the real conversation of the very suitable replacement for the intimate you know actual talking to another human might have 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 because it might work for others. Maybe not even open source it, not with the whole let's have a community project, but just like, this is my thing. Hopefully it will help you create your own thing. Because 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 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. 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. But at the very least it would, 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 or what yeah even just publishing how you do it like even that that's just a blog post of how it works sometimes that's enough to show people i 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, you know, I wrote a rap around the buffer API and Elixir etc and I've since like just turned all that off and it's like I'm just going to 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 reach and for engagement which we love for more people to listen to our podcast

like that's one of the reasons why we go there have conversations reach new people etc share our clips having it like just completely automated syndicated for me it feels for our changelog 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,

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, on, on Twitter likelike 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. Jared, you're a man of

the people. I am. But at the same time, it's all a matter of what do we value? What are we doing this for? And what's the opportunity cost? 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 I, 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. Um, and so I think it, 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

I've been BSing for many years now alright well I think that's a good place to end it 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 these platforms and receive my content if you wish. No, but I mean if they want to contact you, they shouldn't do these things. Yeah. Email. That's the way to reach. Justin at Searles.co. There you go. So easy. The website is Justin at Searles.co. There you go. So easy. So easy.

The website is Justin.Searles.co. Are there other Searleses? So you thought you'd put your first name as a subdomain or you could just go on Searles.co. Yeah, there are other Searleses. So my brother is a Searles. He is a senior Elixir developer at Cars.com. Oh, really? And since I hogged the Searles username on every social platform, I figured if I'm going to buy the Searles.co domain, I probably shouldn't also make that all about me.

So does he have a subdomain 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 how 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.social on Mastodon, 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 to like subscribe and smash the appropriate buttons at youtube.com slash changelog. Thanks again to our partners, fassy.com, fly.io and typesense.org. And thank you to our Beat Freakin' residents.

BMC is working on a new album for you. We're calling it Dance Party. That's all for now, but let's talk again real soon.