The Changelog: Software Development, Open Source - Don't make things worse! (Interview)

Episode Date: June 28, 2023

Taylor Troesh joins Jerod to discuss a bevy of software development topics: yak shaves, dependency selection, -10x engineers, IKEA-oriented development, his new content-addressable programming language & much more along the way.

What's up friends? Welcome back. This week, Jared is joined by Taylor Troche, talking about a bevy of software development topics, yak shaves, dependency selection, negative 10x engineers, Ikea oriented development, his new content, addressable programming language called scrap script and so much more. A massive thank you to our friends and our partners at Fastly and Fly. You know,

Fastly is fast globally, super fast globally. And that's why our podcast gets you fast all over the world. Check them out at fastly.com and our good friends over at Fly. Help us put our app and our database close to our users. And they also get a honorable mention from Taylor in this podcast. Check them out at fly.io. What's up, friends?

This episode is brought to you by DevCycle. You probably heard about testing in production, dark launches, kill switches, or even progressive delivery. All these practices are designed to help your team ship code faster, reduce risk, and to continuously improve your customer's experience. And that's exactly what DevCycle's feature management platform enables. They offer feature flags, feature opt-in, and they seamlessly integrate with popular dev tools, with client-side and server-side SDKs for every major language. And I'm here with Jonathan Norris, co-founder and CTO of DevCycle. So Jonathan, I've heard great things about using feature flags, but I've also heard they can become tech debt. How true is this?

That's a great point. Feature flags can quickly become tech debt is one of my common sayings. And how we deal with that is that we fundamentally believe that feature flags should be as easy to remove from your code as they are to add to your code. And that's kind of one of the core design principles that we're going towards is to try to make it as easy as possible for you to know which flags you should remove from your code and which flags you should keep and making it automatic to actually remove those flags from your code base. And so we've actually already built tools into our CLI and our GitHub integrations to automatically remove flags from your code base for you and make a PR that says, hey, here's a PR. We removed this flag. It's no longer being used from your code base. And you make a PR that says, hey, here's a PR, remove this flag, it's no longer being used from your code base

and you can choose to merge it or not. So that's another thing that I fundamentally believe that like, yes, flags can become tech debt and we've got to work on that full developer workflow

from end to end. It's great that it's super easy to add flags to your code base, but your flag should be visible to you all throughout your development pipeline, everywhere from your IDE to your CLI to your Git repository to your alerting and monitoring system. And then we should tell you when you should remove those flags from your code base and help you clean them up automatically. So it's just as important to clean them up as it is to create flags easily.

Very cool. Thank you, Jonathan. So DevCycle is very developer centric in terms of how it integrates into your workflows. Very team centric in terms of its pricing model. Because this is usage-based pricing means everyone on your team can play a role in feature flags. They also have a free forever tier, $0, so you can try out feature flags for yourself in your environment. Check them out at devcycle.com slash changelog. Again, devcycle.com slash changelog. Again, devcycle.com slash changelog. All right.

Today I am joined by Taylor Taroche. Taylor, thanks for coming on The Change Log. Thanks for having me. I've been really enjoying some of the stuff you've been writing lately, your how to be a negative 10x developer. Actually, it spawned and inspired a funny episode we did on our talk show last week where we had 10 tips to be a 10x and they were all pretty ridiculous tips. Yours, of course, is good advice of things not to do.

And I love that post. I love some of your other writings lately. So excited to have you on. Excited to hear some of the stuff you've been thinking about in the software world. Yeah, thanks. With the negative 10x stuff, I personally have done a lot of those. I think at different points in time, a lot of us are negative 10x, negative 100x. And that's really where it came from. I feel like, I hope nobody misinterpreted that as me thinking these were the teams that

I've worked with. It was mostly me. Right. There you go. Well, it's easier to pick on yourself than it is your past teammates for sure. Well, it's easier to pick on yourself than it is your past teammates for sure. Well, maybe not easier, but maybe just more beneficial for everyone. Why don't you tell us a little bit about yourself, where you're coming from and where you're going? Right. So my name is Taylor. I write at taylor.town. That's my little corner of the internet. Love it. And over there, I write about humor, software, lots of design stuff, and time. I'm a little bit obsessed with time. So you'll see a lot of posts about time.

I am currently doing freelance stuff. You can find more about hiring me on my page. Always doing random projects. Just open sourced a time management utility called Nowify. A lot of people have been interested in that. Working on a programming language called ScrapScript. I'm just all over the place. You're just doing all sorts of stuff.

What about time? I mean, why do you obsess with time? Why do you like this concept? Tell me more. You know, my grandpa growing up, I think it was him. He's like an engine of a human being. And he would always growing up throughout my lifetime, Talk about how many weekends he thought he had left. Yeah. Yeah. And he would just be like, yeah, I got, got a few hundred weekends left. He's still,

he's still living. And he, and the way the number, the counts down real low. Oh man. I was going to say, is he now gone past zero? Cause he's outlived what he thought he might, or is he, is he still on the count? I think he, I think because he's outlived what he thought he might? Or is he still on the countdown? I think he's far outlived what he thought he would. So that's the good news is we don't know how much time we have left, do we? Yeah, he's kind of a reckless man. That reminds me of a site by Scott Hanselman. I can't remember what it's called.

Everybody out there who's heard of it probably knows exactly what I'm talking about now. It's kind of like how many keystrokes you have left in your life. And he does the math. And the whole purpose of that is that Scott Hanselman gets a lot of email and he doesn't want to respond in email because he only has so many keystrokes left in his life. So when he gets a private email, somebody asking him a question or advice or whatever, he would then turn that into a blog post and then reply to the email with the blog post because he only has so many keystrokes left and he doesn't want to waste, I get waste, maybe not the way he would cast it, but he doesn't want to use them on

a private individual. He wants to use them publicly. And so he created a whole website, like how many keystrokes you have left.com or something like this. I don't know what the website is, but similar to weekends, I suppose. Reminds me of a Quentin Tarantino. I believe he's about to make his 10th and final film. film. He kind of put a self-imposed limit there. I kind of do that on a daily basis where you have like 16 hours of waking time per day. And if you chunk that up, 10 minutes is about 1% of your waking day. So every 10 minutes goes by, it goes, oh, there goes half an hour. That's 3% of your day. When you think of like that, it stresses you out.

I was going to say, that sounds anxiety ridden, doesn't it? Just thinking in those ways. Yeah. So sorry for anybody listening who I've gotten in their brain. Right. So here's the question, listener. How much time are you going to waste? I mean, how much time are you going to spend listening to this conversation?

We might be taking a large percentage of your day and just throwing it down the drain. Now, the nice thing about podcasts, and I'm not just a creator of podcasts, I'm a junkie. I listen to podcasts all day, every day. That's hyperbole, but you know what I mean, is that they're just, they're parable, right? Like you're not actually wasting, you're actually complimenting something else. So you're mowing, you're exercising, you're walking, you're showering, as we learned. Many of our listeners do listen in the shower. That one's a little strange to me, but there you have it. You're not actually just dedicated, which is why video for me is a much bigger ask. If I might just use that word, the way business guys use it is like, do I have to sit here and stare

at the screen or not? And so a 30 minute video is way more intimidating than a 30 minute podcast. Does that speak to you or do you look at it differently? 100%. I actually just did a 545 mile bike ride from San Francisco to Los Angeles over a seven day period. And the great thing about biking is you can secretly leave one earphone in. You do want to be able to hear the road. You're not supposed to, but everybody does it anyways. I listened to The Grapes of Wrath by Steinbeck. That was an amazing book to listen while going through the California countryside. This ride, by the way, great organization, the AIDS Life Cycle. If you want to donate to them in order to fight AIDS, great, great organization. That's cool. So will that book now always be somehow linked to that bike ride in your memory? Do you think? Oh, 100%. Cause a lot of it is also

about like, like half the book is about California and like deeply about California and all these areas going up and down. So like that was a complete accident on my part, but, uh, uh, it vibed. Right. It's weird how sound and word or music kind of attach like that in our lives. I know when I was a young man, I was even a man, a young boy, probably 10 or 12, one summer I read It by Stephen King.

And I also happened to have, for the first time, acquired Metallica's Black album. And I listened to Nothing Else Matters, that particular track, because that was my favorite one on that album, on repeat while reading the book It. And to this day, when Nothing Else Matters comes on,

I'm for a moment transported into those woods where those kids were in the book of It. And it's a very strange experience where it's like that song triggers for me intense memories of a book that I read when i was 12 or whatever yeah i feel that all right well speaking of time it's time now to talk about some more of your writings i want to talk about this one because uh this is one of those blog posts that i haven't actually linked up yet in changelog news because i know i was going to talk to you about it

but it's kind of one of those posts where i it's's so good to me, like maybe I'm your intended audience that I wish I wrote it. You know, I'm like, I read it, even the conceit, 11 ways to shave a yak. And like, that's something that I would love to write. And I didn't Taylor, you wrote it, darn it. And, uh, the conceit is awesome. And then you also executed quite well. So first of all, as we open this one up for those who are uninitiated about yak shaving, you want to just give the rundown on what it means to shave a yak. And then we'll go through this again, like your negative 10x, a list of anti-patterns, things really you shouldn't do in your opinion, because yak shaving at the end of the day, talk about time, you end up wasting time.

But first of all, define yak shave for folks. Right. So I don't know originally where it comes from, but the saying of shaving a yak is like, Hey, you want to change a light bulb, but Oh, you lent your ladder to your next door neighbor. But so you borrowed a sweater from them and the sweater was, has a hole in it that you made and, and it was made of yak fur. And then, so you, so you wanted to change a light bulb, but you end up find yourself shaving a yak so that you could repair the sweaters

so that you could get the ladder from the neighbor so that you could change the light bulb. So it's a kind of accidental complexity. That's the definition. Yeah, it's kind of a series of unfortunate events or maybe they're not. Sometimes what's interesting about a yak shave is sometimes it ends up productive,

and like, oh, I actually needed to get that done in the first place, and so I'm happy. But oftentimes it're not. Sometimes what's interesting about a yak shave is sometimes it ends up productive, you know, and like, oh, I actually needed to get that done in the first place. And so I'm happy, but oftentimes it's not. Oftentimes it's this complexity that really, if you think about it critically, is procrastination to a certain degree. Cause you find out that the yak shave is enjoyable, right?

Like you'd rather be shaving the yak and you're shaving a yak to do another thing, but you're also kind of just not doing that other thing that you know, she'd be doing. Maybe I'm just projecting, but there's a little bit of that in there as well, where it's like, you really enjoy shaving yaks and not so much this thing that you set out to do. Cause that's hard or boring or whatever it is. And so you, I'm going to do these 11 things and feel productive, but I actually never accomplished my goal. Oh, Oh, 100%. There are the fun parts of every code base that draw you in. And man, sometimes it's like you spawn off a second

project that you're like, oh, this will help the first. You never complete either. Right. Classic. Well, like the Slack team, they were building a video game and they created this chat system in order to build their video game. And this, I believe, is the second game they tried to create. The first one became Flickr. I'm maybe munging the history slightly, but the same people behind Flickr were the people behind Slack. And both of them were efforts to build video games. And Slack became this internal communication tool

they built to build the video game, or alongside it. I don't know. It ended up being the main thing, obviously. And long story short, what's his name? Stuart Butterworth, Stuart Butterfield. He got rich a couple of times, but never got that video game created in the meantime. So I guess, you know. Yeah. I guess you could say that Slack was the golden yak. Yeah, there you go. Sometimes you shave a golden yak. But you have tips here, ways to shave one. These are things not to do. And so these are things that you think are, I guess, not the best ideas or they end you up down a path of complexity. And I'd like to talk about a few of them. The first one you say, not the first one, but the first one I'd like to talk about is create thirsty systems. Can you tell us what you mean by that? Of course, the takeaway is don't create thirsty systems. But what's a thirsty system in the first place? Thirsty systems, they require more and more just to keep going. And when you exhaust the resources necessary to sustain a thirsty system,

you will find yourself out on the road shaving a yak in order to, you know, keep that supply line going. That's how I view it. Okay, so what are some examples of systems that you create that are thirsty? Let's see. I don't remember what I put in the essay, but in my own life, or I guess, let's do a development example. This is the changelog. Credits. Credits would be an example of that, where you forgot to leave the credits going. There there could be let's say that you require a bunch of training data to keep your business going getting that training data if the training data you know stops then then that might require uh you to go do this whole excursion to get more training data yeah that's a good one i know that as a listener and a producer practical

ai a lot of their conversation is around data labeling and how much time and effort and systems are designed, sometimes services, just around labeling data and making data clean and useful for those models to be trained in a way that's productive. So yeah, that's a good one because that train never stops. Once you start it, you just keep going and going. Yeah, Secret i i have been working on a data labeling startup for the past few months so uh oh you have maybe expect some news about that by the end of the year okay cool i guess on the other on the business side maybe you do want to work on thirsty systems right because they need constant feeding and so people will continue to put their credits into your system in order to have that solved for them.

I mean, yeah, if you're okay with it, like I do view this, the business model for me, you know, it's like if I'm in the training business, then every single time I get a customer, it's like, okay, well now I got to go find people to like, there's, there's a lot of yak shaving in that. So it's not something I necessarily recommend, but I do see an opportunity there. So I'm going to go shave some yaks. Yeah, well, I mean, let's face it. If we're going to extend the metaphor, I mean, yaks need to be shaved. And if you're being paid to shave a yak and you don't mind shaving a yak and getting paid for it, then like this is no problem at all, is it? This is just a business. It's a yak shaving business.

Yeah, exactly. Right. The other one you talk about is clever architecture and you say clever systems produce clever problems is there more to say about that or does it speak for itself that's i love that saying no no that that's a great one so there's this uh there's this building out in france i cannot remember the name of it but um it was made by this like famous architect you know and one of its cool ideas was it made all of the plumbing and the wiring and stuff color coded on the outside of the building so that they could theoretically

maintain it easier. Well, the problem was it actually, for some reason, was a very hard to maintain building and they had to kind of do major repairs every few years. uh it has cost a lot of money to maintain this building because it's clever right like right it doesn't follow the normal building design so they have to get architects and stuff to to kind of like help with any small change so yeah clever designs require clever solutions yeah totally it reminds me also of like certain cars now i'm not a car guy so i'm gonna quickly get outside my depth, but I know you're not going to have any hard times finding parts for a Honda Civic, right? But you know, these small limited quantity cars where it's like, it's rare, the car is rare, all the parts are rare. And so anytime you have

a problem with that car, you've got a bigger problem than you'd have with any other car. And it's kind of the same situation where their design is really clever and they're worth more because they're rare or unique or whatever. They drive faster, et cetera. But all the problems are like equally bigger than they would be if you go down that happy path. So just this idea of like straying from the normal, you know, in order to have something that's not necessarily worth it,

you're going to end up with bigger problems than if you would have just taken the straight or the broad way. Yeah, I think Kubernetes was in that zone for a while where there weren't enough people using it. And so whenever you had a problem with it, you needed to get an expert out. I think it has become mainstream enough where maybe it's not a clever system.

I'm not actually sure. I haven't used it in a while. But there are definitely architectures that are so unique that you need to get the experts in. I wouldn't do that. I've heard Marco Arment talk about this. He really yells or screams about boring systems and choosing boring systems. Specifically, he's been on MySQL forever. And the reason is, and I guess I he's been on MySQL forever.

And the reason is, and I guess I've probably been on Postgres an equally long time, and you see a lot of databases come and go and they have various allures to them and they're very interesting for this reason or they embarrass your current database in this particular vertical. And you have that desire, that wanderlust to be like, what would it be like if I was running Cockroach, if I was running Mongo, if I was running Fauna, whatever it is, insert your newer database here.

And he says, I never want to be the first person using a new database, or even the first 10,000 people. He's like, I'll be the last person using the oldest, most worn down, beaten paths ever, because I just don't want to have database problems that are bespoke. I don't want to be the first one to find this, any bug. I think there's some real wisdom in that.

That being said, new databases are fun to play with, so it's kind of hard to decide. Yeah, I've been thinking a lot about boring technology. I just wrote a piece called IKEA-Oriented Development. I think IKEA has boring furniture to an extent where like yeah they don't use any fancy tools like you have everything you need right and i like making software like that like minimal dependencies and if the dependencies are there they're either bundled or they are in everybody's toolkit like right for me i think python is one that uh people mistake for a tool that's in everybody's toolkit.

But it's like it's more like a hex wrench, you know, like there's so many different varieties and sizes and you reach for it takes a little bit to kind of get the exact right thing. It's not a screwdriver. Python's not a screwdriver. Right. So it's more like a hex wrench. I like that analogy. I'm not sure how I guess I don't know that it applies to Python. I'll take your word for it.

I'm not a Python user, but I do like that analogy because immediately I think of all the different sized hex wrenches that come with whatever furniture you're buying. And they're all like just, and I have a collection of these over the years having installed tons of furniture in my life. And I'm always like, I'll hold onto this one

because I'm going to use it later to install something else. And like, they never fit. They never fit the next thing that you're putting together. They're always just like a sixteenth of an inch smaller or bigger. It's maddening. Yeah. Find this in the JavaScript ecosystem too.

But my like platonic ideal for software that I make is I want everything to feel like Mario Kart 64 where like it's been how long since that's produced. There's like zero chance that you plug that thing in and it's going to ask you for to like like download python 3.9 right like it's going to work i i wish all software was like that we're like it just works after time i don't know yeah i mean

bit rot's a real thing sorry i got stuck on mario kart 64 i just went back to a happy place in my mind and i was just playing the game as you talked there so that one's almost too uh too good of of an analogy. But yeah, I mean, you pop in an old NES cartridge. Okay. You might have to blow on it first, even though I think that's a wives tale, but we still blow on it, pop it in and play it. And the sucker is just going to, just going to work. Yeah. I wish software just worked sometimes. I'm with you. So do you have any practical tips? I mean, you mentioned like dependencies, like how do we write software that works most of the times? How do you do it? How do we do it as an industry?

Me as an individual. Do you have any advice on that? Dependencies is a big part of it, but I'm sure there's other things. Yeah, so actually dependencies is the one that I think is usually the worst offender. So I tend to pick stuff that's been around for a while, like Postgres. Postgres is going to be around for a while in terms of like web technology. But yeah, seriously, if you can get away with not even using Postgres and maybe using like, I don't know, file system stuff, that's going to last way longer. Just like not even including Postgres as a dependency.

Right now you have to do the trade-off of course of your business. And if you're, you know, handling any sensitive data or anything important, then you're going to want the power of Postgres. But in general, yeah, I just like, I use, it's like in the JavaScript ecosystem, if I'm like, oh, I need to make a call to GitHub. I just use HTTP, like just use the fetch API. I don't go and use their, their official package because that's prone to break. But in the first place, if you're, if you're going to be connecting to somebody else's API, that's going to break anyways. Right? Like, so it's hard in the web world to create things that last. I'm the same way. So just that, that spoke to me. If we,

if we look inside of, so our website is built on Elixir and I do have an HTTP library. That's like, it's called htt poison so it's a third-party library but i speak to pretty much every web service there is just using that one hdp library so if you look in our code base there's little clients for buffer for github for hacker news for mastodon for twitter for typesense for TypeSense, for Campaign Monitor, Shopify. And they're all pretty much the same thing. It's just like, here's the details for this API, and here's the details for that API.

And each of these different services has a client library that you could go at. I could go out and get the GitHub client library, or especially in the JavaScript world, there's a billion packages that you can install instead. But if you could just have one dependency, like a good HTTP library, in the case of the web,

fetches all you need, basically. Well, let's say you need one library. Sometimes you need more, OAuth or something. And you can use that to build 17 integrations. You're gonna be way better off than having 17 libraries, just on plain surface area alone right right and a pro tip you can actually do payments without stripe you can go directly to the bank apis and use notcha files and all that stuff it's annoying but if you want things that last

that bank the banking api is not going anywhere in 50 years okay have you done that before because man i don't know if i don't know if i yeah go. Yeah, I've done it for a few companies. A lot of these, yeah, I think you can get really deep into a lot of these systems and build them out yourself. I don't think it's usually worth it. Yeah, that's the hard part, right? I mean, the hard part is deciding where that trade-off is. Like, where do you draw those boundaries?

And I think that these are things that every developer struggles with. Because like, when do I pull the dependency in? And when do I say, no, you know what I'm going to do? I'm going to code against the bank API because it's worth it. I think that's a hard decision to make, isn't it? Oh, 100%. I encourage everyone to go watch some Greg Young videos.

He does a lot of stuff. Engineers need to think more from the business perspective. One such example that I've been thinking about recently is like meetings, right? Where I think that engineers forget to look at things from the business point of view sometimes. And, you know, we're, we're talking about like the platonic ideal of software that lasts. That's a, that's an engineering thing. Like the business views your code as a disposable thing. Right. And it's not this like elegant statue that's going to be lasting a long time. So this is more for like the love of software, the making something that lasts.

But yeah, from the business perspective, they don't care. No. That's fine. Like that's completely fine. And sometimes it's smarter not to care. I mean, in the case of a startup, when you don't have an established business that you know is going to generate revenue, if you're building software that lasts, you're building the wrong thing because the business might not even last, right? So at a certain point, it's foolish to build a statue when you're trying to change the thing constantly. But at a certain point, this starts to now formalize and coagulate.

And then you're like, okay, this thing that I built not to last, turns out the business is working and it's going to last. And now, when do I know that's the case? How do I built not to last, turns out the business is working and it's going to last. And now, when do I know that's the case? How do I know when to start taking it more seriously? These are hard problems. And oftentimes we err on the side of moving fast and breaking things and end up with systems that are very, very difficult to maintain, difficult to change, and end up having some sort of consultant come in and say, we need to rewrite this from first principles, right? Yeah. Yeah. I think this actually brings me back to the negative 10 X post kind of what I've been thinking about recently is not making things worse. Right. So, so you go into a business and just don't make things worse. That, that like, I think fits the business needs most of the time.

Like, right. Make sure that the database doesn't go down. Like they don't care if it's faster. They just don't want things to get worse. Right. And I think like a lot of the reasons I end up using these, like how to shave a yak and negative 10 X, the, the inversion principle is because for messy systems, I have a 10 month old and I want to be

a really good father, but there's no, there's no guide on how to be a good father. However, there's a lot of advice on there on how to be a bad father, right? Like I know to an extent how to not be a bad father. So like, I'm just trying not to make things worse. I'm just trying not to mess her up. Same thing kind of goes for, I think doctors, right? Like you, you have the exceptional surgeon, uh, what his name, Robert Liston, who did amputations in 30 seconds. He would, he would start his surgeries by saying, time me gentlemen. And you compare that to somebody like a Semmelweis, uh, who essentially invented hand-washing in hospitals. And he And he was of the mind just like,

yeah, let's not make things worse. Let's not kill people versus like, you know, trying to optimize and make things as fast as possible. I tend to be more on the hand washing side of things. Yeah, that's the kind of doctor you want to be put under before he does any surgery, right?

Because when you hear the doctor, imagine you're like slowly drifting off and you hear him say, time me, gentlemen. Like that's not comforting. I think this was pre-anesthesia, which is why he went so fast, which was. Oh, well, okay. It's making more sense. I could be wrong on that one.

It's been a while since I've looked into him. This episode is brought to you by our friends at Drada. Automate and accelerate your SOC 2 compliance, your ISO 27001 compliance, and many, many more compliance frameworks. With a suite of more than 75 integrations, Drada easily integrates with your tech stack through applications such as AWS, Azure, GitHub, Okta, and Cloudflare, and countless security professionals from companies including Lemonade, Notion, and Fivetran have shared how crucial it has been to have Drada as a trusted partner in the compliance process.

They have deep native integrations that provide instant visibility into a security program and continuous monitoring to ensure compliance is always met. Drada allows companies to see all their controls, easily map them to SOC 2, ISO 27001, and many other frameworks to gain immediate insight into framework overlap. They are the only player in the industry to build on a private database architecture from day one, meaning your data can never be accessed by anyone outside your organization. It is time to say goodbye to manual evidence collection and hello to automated compliance by visiting drada.com slash partner slash changelog.

That's drada.com slash partner slash changelog. They are bringing automation to compliance at Drada speed. I do like this idea and you know we make fun of the 10x thing around here quite a bit because you know it can be quite silly but software is interesting in that to be quite a bit more productive than other people sometimes all you have to do is not make things worse, like you're saying, because it's so easy and maybe uniquely easy in software, maybe not uniquely. I don't know. I always compare software to like construction because people try to, you can't really compare the two, but it's kind of a close analog is like physical engineering and construction, right? Like building buildings, bridges, et cetera. And the thing about that is you can hide mistakes for a little while,

you can cover things up, but it's really hard to unbeknownst to you and the team be going in the wrong direction for a long time. You know, whereas in software, one developer doing something wrong or short-sighted or whatever it is, can do so much harm so quickly and so secretly, even maybe they don't know how much they screwed up, that to be 10x, sometimes all you have to be is 1x, meaning like I'm actually pushing things forward because so many of us make mistakes that are just headed in the wrong direction and make things worse that maybe the negative 10x thing is possible, right? To actually go backwards at such a clip.

Which is unfortunate, but I think it is true that you can screw up a lot of things fast. And we do from time to time because it's hard and it's complicated and there's so many pressures, right? You're not just writing software. You're trying to please your teammates. You're trying to please your boss. Maybe you have a deadline that's like ridiculous. Maybe you have a 10-month-old at home and you're not getting please your boss. Maybe you have a deadline that's like ridiculous. Maybe you have a 10 month old at home and you're not getting very much sleep.

Maybe you got put into a position that you're not actually good at yet and you don't really know Lisp all that well, but now you're writing Lisp and you didn't realize that when you miss a parenthesis, this thing happens. You know, there's like so many factors that make this job so hard in many ways.

And we can like secretly, unbeknownst to anybody, be causing harm. That's kind of scary. Yeah, totally agree. Yeah, now that I've been thinking a lot about not making things worse, my coding has changed a little bit. I think I'm a little bit more interested in testing,

a little bit more interested in really, really simple deployments that aren't going to break on me later on. I really like fly.io, by the way. We'll plug for them. They're a sponsor of ours, so plug away. Oh, they are? They are. But we did not pay Taylor to say that. Yeah, we're fans as well. No, you didn't. I love fly.

Yeah, our site's deployed on fly as well. Yeah, I mean, good tools is one thing you can do, right? Rely on reliable systems. Dependency selection, because you're not going to write the entire system yourself. I think, I can't remember the stats. Amel Hussein over on our JS Party podcast always cites in the JavaScript world. I think it's like, I'll just use big and little.

For every one line of code you write in a typical JavaScript web app, Express backend, whatever front end you want, React, it's like one to a thousand, I don't know. It's a little amount of code that you write compared to how much code somebody else has written in any typical application, like astoundingly so. There's so much code that somebody else has written.

And if you're building your app on top of giants' shoulders, as they say, it's really important to pick the right giants because so much of that code you rely upon. And so dependency selection, not just do I pull an independency, but what kind of dependencies do I trust or not trust? It's a little easier in some languages to find good dependencies. So Elixir is something we mentioned

earlier elixir i would say all of their packages were pretty nice before it became popular and that makes a huge difference npm was the opposite it was already popular and then everyone just kind of came in and there was a lot of competition right and that ends up you get a lot of competition, right? And that ends up, you get a lot of fragmented design decisions across the ecosystem because things aren't baked and made a little bit slowly in the beginning. So I do actually think your language matters in that regard. How your language started out kind of does matter. That's interesting. And it can change as well over time.

You know, as an ecosystem changes, the package ecosystem around that ecosystem also changes with time. Completely. Yeah. Like Deno, I know is trying to rethink a lot of the JavaScript ecosystem. And I have found that their community packages are consistently pretty good. Like I use it for some hobby stuff. It's obviously like, if you want something to last, don't use something that new. It's what 0.19 right now, but, um, it's delightful. And the, the community I think is taking it seriously. And I'm just finding the packages out there to be a lot higher quality than the average thing on NPM, uh, thus far.

Side note, hook me up with that link to Greg Young's videos. I'll put in the show notes. Cause I can't find them because there's a local car dealer here called Greg Young Chevrolet. His discoverability is so bad. I'll send you some of his stuff. We're talking about dependencies. Let's also talk about tooling. You mentioned Fly as a service you like. You mentioned Stripe as something that you'd rather go against the bank.

Have you really coded against the bank API? I have. I've done it for multiple companies. I worked in cryptocurrency before the second wave. Okay, like 2018 timeframe. Yeah, so I had to do some banking stuff there. But yeah, currently out of that ecosystem. Sure. I can't leave this topic. So when you're coding directly against the bank APIs,

the decision to do that, was it because we're a cryptocurrency thing and it makes more sense for us? Or was it like we want to cut out that 3% or whatever Stripe takes as more important? Or was it really about just long-term resiliency? So the first company I worked for was a real estate company. I think we had to do it because our money transfers were too large. We were working with really large deposits and withdrawals. In the cryptocurrency space,

I think Stripe doesn't support or allow cryptocurrency companies. So I think that's why we had to integrate directly. And I think we had to, it's like an SFTP type. You have to like put things and get picked up. Yeah, yeah. You're like just FTP and stuff to a thing. Yeah. Yeah, it's been a while. But yeah, I think there was only like a few banks that you could use.

So we had to go directly to the bank and the bank has a crappy API. So another thing you had mentioned here on the Yakshave post is something that I hadn't heard of, which is Lindy's Law. Oh, yeah. And this is about,

and in the post you're saying like, well, you can build on other people's property. Of course, we have all seen and heard about somebody on the App Store who's built their business on Apple's app store and has to deal with, you know, Apple problems. There's similar problems, Facebook marketplace. I mean, you name the platform you're going to have to deal with the platform provider. And so that was no surprise to me, but this Lindy effect,

I hadn't heard of. Oh yeah. It's super cool. I can't remember where I found out about it, but it says that like the lifetime of a thing is proportional to its existing lifetime. So in other words, if you want to like try to predict how long a thing will be around for, just look at how long it's already been around. Right. Books will be around for a very long time. Deno at this point, it's very new. I'm like, based on Lindy's law, I'm not going to expect it to be around in another 20 years. Look for old technology for things that are going to be around in a long time. I love that. So it's just like the longer it's been here, the longer it will be here.

Exactly. And the shorter it's been here, the shorter it will be here. That's so easy to hold onto and use in decision-making. Not always true though. It's kind of a distribution, isn longer it will be here. Exactly. And the shorter it's been here, the shorter it will be here. That's so easy to hold onto and use in decision-making. Not always true though. Like it's kind of a distribution, isn't it? Because I mean, things that have lasted this long by de facto at one point hadn't lasted as long as they do now. 100%. I think it's a, it's a rule of thumb and there might be a little bit of mathematics. I actually don't remember how it was just, or, you know, I don't remember how Lindy came up with it. But I would say that if you were to make bets

and try to get like expected value, Lindy's law applies. But yeah, sometimes if you want to forge the future, you want to invent the future as Alan Kay says, then you got to ignore it. You got to just follow your passion, you know? Right. So when it comes to tooling, platforms, Deno,

I think they call it Deno now, by the way. Oh, was it Deno? Not to correct you on air here. Yeah, well, even Ryan couldn't figure it out at first. It was Deno, then it was Deno, then it was Deno. I think they landed on Deno because that dinosaur is just so stinking cute that they just are going to roll with it.

But it definitely started off Deno. That project, fly.io, which hasn't been around very long, by the way. It's relatively new. The app store now is getting years. But do you have any insights on like when to break from that general rule of thumb? Or like, what do you see in a technology

or a platform that says, I'm going to give it a go on this? Because even when I was talking about boring databases, sometimes you come along and you find something new, and that new thing actually allows you to build something you couldn't build previously. I mean, even the App Store, I mean, even if we look at just commercial apps like Instagram.

Instagram couldn't have existed before the iPhone. The iPhone made Instagram possible. And had the Instagram founders said, well, this iPhone's not going to be around, or I don't like Objective-C, it's not going to be around, whatever, if they had not done that, then obviously that would not have existed. So there are times where, like you said,

you have to break from that. And do you have any insights on when, how? When can you tell? So I'm kind of working on a bunch of different projects right now. There are a few that I want to last last and those I am very careful to make sure that I am thinking about not breaking links from the beginning. I don't know. I think if you go into something from the beginning thinking like, okay, I want this

to last a little bit longer. You kind of have that in mind. Then it does inform some of your decisions. I think for like, I used to have a seat, I used to have a work for a company whose CEO always talked about type one and type two decisions were like, is this a permanent decision or is this something that could be changed later? Oh, yeah. And when it comes to a lot of these longevity things like choosing fly.io, I can move somewhere

later. Like that's not that big of a deal. Right. But like the architecture does matter. Those broken links, that's hard to change. So I think that's more important. And when you're trying to decide whether or not you want to make something that lasts, I think making something that lasts is it takes longer, right? Like making one of those KitchenAid mixers that, that lasts, you know, 50 years and still, still works is it's more work work it is right so you as an organization or project

planner open source maintainer just need to decide your shelf life where i see this a lot is people's choice of time stamps right some time stamps like you can at least for like certain ids i was at a company and it's like okay do we want to use 32 bits and give this app uh 10 years or do we want to use 32 bits and give this app 10 years? Or do we want to do 64 bits, double that? And like, okay, then we get unlimited. But like I asked the CEO, I was like, should we do 10 years? Like, are we going to be around in 10 years? Do you want to save that money on AWS costs? Right.

Yeah. These are business decisions. Yeah. What'd they say? Said 50 years. Okay. So he said, he said like, let's, let's pretend like this is going to go on 50 years yeah yeah yeah but then you gotta decide like is it a type one or type two like you said because if it's a small decision it's like well let's go for the gusto no no that

was not a small decision that wasn't that was no no no that was a very important id for hundreds of terabytes of of uh data in a very large postgres database oh wow that that was not yeah that was that was an important one that one was. Oh, wow. That was an important one. That one was not going to be changed. That was an important one. Was it the right decision? Yes, I think so. I think taking up a little bit more space

to go longer term was the right decision. Are they still around and going at it? Yes. Okay. Because if they were gone by now, then the answer was no, it wasn't actually worth it. But since they're still going, I mean, 50 years, that's a long time in life, let alone in software, right? I mean, gosh, software changes so fast that a 50 year company, I mean, are there 50 year companies? How old's IBM? I don't know. In software, it's like 10 year old is old. I mean, Stripe is old at this point. I think like it's weird because software moves so fast and yet doesn't.

Like if you go search on YouTube, you can watch the mother of all demos where Douglas Engelbart in a one hour presentation shows the first GUI, the first mouse, the first, uh, he has like a video display, uh, for like a Google docs type thing. This was, this was in 58, 60. Uh, like this was like everything kind of was, was designed and things have not really changed a whole lot since then. Um, so like things change so fast and yet don't change at all i don't know it's it's bonkers isn't there an old cliche it's like the more things change the more they stay the same yeah um it's hard to pick out like in the 60s i think it would have been really hard to pick out which parts were going to be around in another 50 years like because they were all they you can you

can ask them none of them knew what they were doing. Right. Like the people in Xerox park, they're like, yeah, this sounds cool. Like, how about, how about, uh, and you have Metcalf. He's like, oh yeah, ethernet. We just need to plug these things together. You didn't know ethernet was going to be around in, you know, the, the defining thing that like connects the world together. Yeah, that's totally true. I was thinking about that a little bit with TCP and UDP. You know, the new version of like H3 and QUIC and all that stuff, they're building it over UDP. It took us a long time to get, there were a lot of problems with the TCP and HTTP stack. I am glad that we're kind of moving over to this UDP thing. Yeah. That's an example of like a design decision. I don't think the person that, uh, that invented T or the group that invented TCP really intended like this much information being sent over it.

Right. Right. Like if they knew how serious it was going to be, they would have thought of something different. What's funny about that is like when I was in university, one of the things they taught us in our networking classes is like TCP is for important information and UDP is for like not important. Like you don't care if it really gets there, whatever. And it's like, so that's the, that's the serious one. Like UDP is fine for whatever DNS. I don't know what else you guys are gonna use it for. It's just over here. It's, it's simple, but we don't use it very much. TCP, we're going to spend half of a semester learning about it. And now it's like, well, it turns out UDP is pretty important

because we're going to reimplement a whole bunch of stuff on top of it. It gives us way more flexibility. The simplicity actually pays off in droves. Now that we realize how we're using these things, which, like you said, they didn't know back when it was designed. It's amazing sometimes that it works at all, isn't it? Oh, I describe it to my wife every once in a while, asks me what I do for work.

It's like, oh, I create bugs and mess with duct tape. I think software barely works sometimes. Absolutely. All right, well, we've plumbed the depths of yak shaving. We talked a little bit about IKEA-driven development. Is there anything else you want to say on there to bring out beyond the simplicity and the modularity about IKEA-oriented development?

I don't know, we just touched on it. Yeah, I do. On the IKEA one, I have a phrase, composable and disposable. If you look at the IKEA tables, you could see the shelves behind me, if you're watching on video. The shelves have these pluggable tables.

And so you could like have a desk shelf hybrid. And so things are composable within the IKEA ecosystem. And yet, like if I wanted to kind of edit it and maybe chop something off, you know, like it's it's disposable. I don't have a ton invested in this like work of art. And so I feel free to, uh, experiment with it. I think back to Greg Young, I love this guy. He coined this phrase, um, expendable over extendable, right? Like you make throwaway code or a code that can be easily thrown away. It's not necessarily throwaway code, but it's code that can be thrown

away right and that makes you create the system a little bit differently his rule of thumb is that no area of your code base should take more than 10 days to rewrite from scratch i like that rule i think it's a little lofty but it's something to shoot for right like if you needed to if like there was some intractable bug, like to an extent it should, it should take less time to just rewrite that module rather than like go, go hunt down this like weird distributed system type thing going on. What are some attributes of code that it's easy to delete or expendable code? I'm trying to think of what it would look like. Would it have clear boundaries? I guess is the only one I can think of. What makes a code easy to delete?

So two things. Number one is the internal state of it. If it's connecting to a database or something and it has its own persistence inside of its boundaries, then way harder to do anything with it, really. That's code that is a lot more sensitive than everything else in the system. Um, even, even just storing things in memory can, can have the same effect. The other thing is not so much. So it is the, the connections between it and other parts of the code, but it's, it's the pieces of code that connect to it rather than vice versa. So

it's the number of places where code is referencing it. The actual API for it, I don't know, would you rather have a good API referenced a thousand times or a bad API referenced once? Like, I think the API is just less important than the sheer number of times it's being called sometimes. Isn't number of calls somehow indicative of usefulness, though? If code is useful, it's going to be called more. And so if you have a lot of call sites, then what you're dealing with is useful code. I guess useful code, by definition, is hard to delete

because it's being useful. Yeah, exactly. But I'm just wondering if that's like a bad attribute of code. Like if I can write a function that gets called in a thousand places, I feel pretty good. Like that was a good function. Look how many places we're using it. If it's not scary, like if it's easy to understand. Oh yeah, that's great.

That's like a severe win. I see. But if there'd be dragons in that function, then that's when. Oh yeah. Like I think that back to do not make things worse. If there's any part of your code base that is starting to scare you, it needs, it needs like immediate attention. Like things, things will just get worse. If you know, you have that one part of your code base that all the

engineers are afraid to touch because then it just kind of, you pile around it and it kind of grows in, in a disgustingness. Everyone just kind of wants to get in there and get out and it just kind of accumulates. Yeah, I think when you start getting to that point, even if you have a thousand references to it, you want to start thinking about how you can throw that thing away and not break everything.

That's well said. I have an idea in my code base that no longer serves our business. And it served our business very well for six years. So I made the decision. This is in the system, that everything was going to be a news item. I kind of like this idea, like when you design a system, like there has to be a core idea, a core tenant, you know, and the core tenant for, you know, like Unix, like everything's a file, right? I was like, everything's a news item. So what do we do? Well, we point people to news. Like that's kind of the core of what we do here. And it's like, well, so we have a news item. That's like a piece of data and it's going to point, so we have a news item. That's like a piece of data. And it's going to point somewhere. Everything's a news item. And every news item points to somewhere. It could

point to taylor.town, right? It could point to an episode of the changelog. It could point to anywhere. Everything's going to be a news item. And we have different kinds of news items. Some point to our blog posts, some point to our podcasts, some point to other people's websites, but everything's a news item. That's just how it's going to work. And that system had a lot of implications as we built out the system that were really nice and worked really well, especially because we publish a news feed on the homepage for years. And it's like, here's news, news, news, news, news, news. And we would decorate them based on their internal attributes.

And then we decided we got sick of posting news items to the home feed every day. And instead, we're going to write and mark down and publish a newsletter once a week, ChangeLog News. And we're only going to publish podcasts and episodes and posts to the website. And now all of a sudden, this core decision I made all these years ago that has served us very well

kind of feels useless. It's just there. It's just there in the system. And I'm having to work around it a little bit, but mostly it's fine. But there's always a layer of indirection between me and what I'm actually trying to get at, which is the episode or the blog post or the whatever. And it no longer serves a useful purpose. And like, those are the kinds of changes where like business change, it wasn't a 50 year decision, but it was a nice six year decision.

But here I am year seven, year eight. And I'm sitting here thinking like, do I rip out this, the cardiovascular system in my code base and simplify everything? Because my life would be simpler now that we're done with this idea if I ripped it out. But also, you know, it's my cardiovascular system on my gut base. So I'm just, you know, I'm sharing a little bit of my thoughts around this as we talk about usefulness too, because it's like, it was very

useful for a long time. And I don't think it was a bad decision. It's just a decision that no longer applies to the way that we run things. And so that's now it's now it's a liability. Yeah. So I like to call this architecture archaeology where you you go back in time to think when they designed this, what were they thinking? Like, it's just so it's so fun because you can go back to old Postgres code and be like, oh, I understand why they made certain decisions. So for you, like, I think don't beat yourself up too bad.

Like, I'm not being I'm just I'm just sharing because up too bad. Like, I'm not being, I'm just, I'm just sharing. Cause it's interesting. Yeah. I'm not mad at myself. I just know that I got myself here for reasons and here I am. So in terms of trying to redo that, that mental model that you have, because it sounds like the code, the code itself, I think is sometimes incidental. It's the mental model itself.

That's itself that's hard to change. Have you played around with different database designs? Because when I have things like this, I tend to just think about the database. And maybe it's like, okay, well, if I move these tables like this and migrate it, right? If I just did this, what effect would it have from the back end all the way to the front end, just everywhere. So that's how I tend to do it. Sometimes it's like, you can find a compromise that isn't so bad. Sometimes it's just like a single column. In your case, it sounds like it's like RSS where RSS, you can have the content or

the link or, and I'm not, I'm not sure yeah but maybe just adding you know a content column would fix the problem somewhat easily I don't know yeah yeah I'll start with the database though I like that I do think in databases I do think that data structures and the form of the data and the actual data itself is the most important part of most systems and I don't really feel bad about the way it works now, even though it doesn't really map to the way we're doing things exactly. It's not causing any problems. It's mostly just like, I know it no longer maps to the way I'm doing things. And so now every time I have to step over that architecture in the code, I'm like, oh,

there it is again. This is useless. I'm just doing it because that's the way we do it. And so that that over time, just begins to nag. And you start wondering, you know, because I'm just kind of the, I take the gardening approach to software development, like any area of the code base that I'm in, I'm going to pull the weeds, you know, like, I'm not going to spend the whole day just pulling weeds. But when I'm over here fixing this, or adding something, changing something, I'm going to leave that code better than I found it. So now I always have this one thing that could be better anytime in a certain section where I'm like, this doesn't make sense anymore. Why am I doing it this way? And I know why, but I wish I wasn't. And then I'm like, what would the refactor look like? Right? How big of an effort is it?

Could I replace this subsystem in 10 days? It's not really a subsystem. It's like I said, it's more like a cardiovascular system where it's running through the entire code base. So I don't know exactly my point here. I'm just kind of sharing a little bit of architectural archeology that I like to think about. My advice to you is just don't make things worse. I like that. Don't make things worse. Like, like in this situation, it sounds like it's really hard to make things better, but it's really easy to make things worse. So yeah, proceed with caution.

Which is why, and I'm with you and why my tactic thus far has been just leave it alone. It's not causing harm. You know, like it's not a problem. It's not even really slowing me down. There'll be a point where it starts to slow me down more. It's not currently slowing me down because I understand it. You know, if I hired an outside developer to come work on this, it would be slowing

us down quite a bit because I would have to give them the mental model that I have in such a way that they would be like, why is this working like this? You know, and we come across that a lot, but yeah, I'm not, i'm trying not to make things worse and so i'm just leaving it in there and i probably will leave it in there but part of me is the perfectionist purist architect guy who's like dude your your software doesn't map to your business anymore you know what's what's wrong with you so i had that little niggle of like you should fix it jared but you're right i just should not make things worse so like i have a i have a static i made my own static page generator for taylortown

okay and like at first i think i had like some postgres database to store like okay i want this released on this date and uh the created out you know and then i like yeah the the mental model wasn't even right from the beginning so like i ended up redoing it so i just used a yaml front matter so it's like i have a little yaml thing on top of all my markdown files but now it's like my entire site is just a bunch of markdown files and a i don't know 30 line elixir script that parses the markdown that what else creates the rss feed and generates a few dynamic pages based on everything but like yeah like if you can get rid of a big dependency like that and just move things down into simpler subsystems it's like it is really nice it's it's so. Cause now I like, if I want to make

changes to the website, it's like, oh yeah, the whole website is dictated by like 30 lines. I'm just like, okay, throw that away. That's nice. That's beautiful. I think every engineer should build their own personal static site generator at some point. Right. And it's kind of like becoming an adult, you know, kind of thing. Like your rite of passage is like, I built my own website generator and so now I can be a big boy or girl. Yeah, I think HTML CSS is like so much easier now than it was a while back, like especially with like the CSS grid and flex stuff.

Like it just makes, I don't know, like I'm very efficient with just plain CSS now. I think if you haven't given HTML CSS a try without like React or whatever go for it like JS is also really nice like a lot of these new query selectors they have vanilla JS pretty dang good right now and if you're making websites also if you haven't ever made your own programming language, Rust makes it super easy. Like that's another project, like a, like a static site generator where I think everyone needs to give that a try. And especially cause we have this book, Crafting Interpreters,

excellent book. It's a long read, but it's a good one. Walks you through making your own programming language, something I think everyone should try. So you you through making your own programming language, something I think everyone should try. So you've been making your own scrapped script coming in 2024, according to the website. So still in development. Tell us about it. What is this thing? I hope it comes out in 2024. I just put that there because it's not coming out this year. Because it's a different year. Yeah, I see. You can just put an incrementer on that and every year increments by one you'll be good yeah so let's see scrap script i have made a bunch of different versions of this over the years i think uh i said earlier in the podcast i used to work cryptocurrency i was i was um less interest in the currency and more interest in the crypto and so

i was like oh what if you made a programming language where everything was content addressable and making that nice to use is really difficult that's why i think you'll see unison which i think they started working on it around the same time i did but they actually worked on it right i just kind of fiddled twiddle my thumbs for a while sure but getting content addressable where every little section of the language is hashed getting that nice to use is a large paradigm shift you need a lot of additional tooling so for instance unison uses a lot of git type stuff it's like okay we're going to store these these files and kind of like this this kind of thing in Git. Whereas if I understand correctly, I might be wrong about that. Whereas ScrapScript where I'm using it,

it's like it has its own Git type thing that you use. That's kind of like a distributed key store of all of the little snippets in the language, which are called scraps. Yeah, so it's just a whole weird space that I think is fun to explore. Not sure how useful it's going to be, though. So with everything being content addressable, like what are what's the implications of that?

What is what falls out from that? So the design goals of scrap script were to essentially make JSON plus plus plus like well, that's a lot of pluses. Yeah. Like think of like a nice to use JSON that has types. Right. pluses yeah like think of like a nice to use json that has types right you can you can essentially define a schema right there in the json and it's so so it's so it's typed so you can describe other types and it also has functions right so you can actually it's a full programming language but it's

really small now where it gets even better is you add that one little thing in the language where you can take any expression and replace it with a hash of that expression and store it in this global namespace so you can you know name it and other people can name it so you get this really shareable language you can send the scraps to each other via socket or whatever right like you can send it as a message but you also can upload it and have people reference it by hash kind of like it's a web page right so you have like a bunch of different options and scrap script also comes with its own compact byte format so it's like i could think of like message pack where you can like compress it really small j JSON's not very compressible. Whereas if you give it a little bit of forethought,

you can make things a lot nicer on the bandwidth. And that seems to be the problem right now, is bandwidth and having these systems that degrade connection over time. The APIs don't match after a while. So I'm kind of working in that space, is making software shareable. What's the status? Where are you at how far how far along let's see i have made like four working compilers

for this thing each time i find something i don't like i've been i've been working on it since like 2017 2018 wow so right now i i think I'm working on the final compiler. Like I'm really happy with the design and ergonomics. Like I've used a few different versions of this. I have a ton of really talented people that have like reached out and are on the mailing list at news.scrapscript.org. I am trying to get that spec out. Hopefully in the next few months. I was supposed to get out last month. And I think this is one of those 50 year problems. We were talking a lot

about like trying to make software that lasts. I want to make a spec more like JSON or JSON doesn't need to change the tooling surrounding it. Right. Like there's always new tools that use JSON and I want an evolving ecosystem around scrap script, I don't want the spec to change. I don't want new language features. It's, it's more of like a data change format, but you can also code in it. So I am working on getting a spec out. That's coherent. The language itself, you can, you can write a crappy interpreter in a, in a weekend. Like it's not that complicated. So I'm trying to get the important things done right so that it lasts 50 years, 50 years is the hope.

Okay. Well, you do have a website out there. So people who are inspired by the idea, scrapscript.org, like you said, there's a news feed people can hook into. That's cool. Is it going to be community? Is it going to be open source? Is it going to be community is it going to be open source is it going to be what oh yeah totally open source like the only reason it's private right now is i'm trying to get i've already been getting some some feedback and trying to tune a few more things in private so that when i put it out i think everyone could have like a little bit more fruitful discussion, but Oh yeah, definitely. This, this thing's going to be out in the open. Like I, I, I don't know. It's hard as a open source person, like trying to, trying to make something. I think if you go back to what I said earlier about like Elixir, right. Elixir started out very small and it had a chance to

make everything right before it got popular. I am somewhat trying to copy that success. I want this thing to be really small until it works really well and all the packages and stuff are nice, and then we can throw everybody on. It's like, hey, everything already works. Don't make a bunch of crappy packages. Everything is already made for you. So I don't know.

Maybe I'm just moving too slow and I'm a little bit neurotic. We'll see. Time will tell. Well, if you got a 50 year timeline, I mean, come on. I do have time. I do have time. And time is something that you love. Well, the website is taylor.town. Of course, as I said, scrap script.org. If you're picking up what Taylor's putting down, definitely check out his website. Definitely subscribe to the feed or to the newsletter or however you get Taylor's content. I've been enjoying, as I said at the top, a lot of the stuff you've been writing.

So I just encourage you to keep writing, keep coming up with blog posts that are just envious or enviable, that I envy them. I wish that I wrote them myself. So the rest of us can learn from the things that you know, Taylor. Thanks for coming on the show today. This has been a blast. Any final words or anything you want to say before we call it a show?

Yeah. I have one thing to say. Don't make things worse. Don't make things worse. Wise words to end on. All right. We'll, uh,

call that a show and we'll talk to you all next time. Don't make things worse. Wise words from Taylor. Totally agree. So now's the time to head to the comments or into Slack. If you want to do that, you can go to changelog.com slash community. It's free to join. Hit us up on Twitter, whatever works. We want to hear from you. What do you think about all the topics discussed in today's show? The link is in the show notes. And there's also a bonus. Yes, a bonus for our Plus Plus subscribers. We love you. It's too easy to join. Changelog.com slash plus plus. 10 bucks a month or 100 bucks a year. Directly support us, drop the ads, get bonuses, all the good stuff. Once again, changelog.com slash plus plus. Of course, a big thank you to our friends and partners at Fastly, Fly, and also TypeSense.

And those beats from Breakmaster, they're banging. Hey, this show's over. We'll see you on Friday. Thank you. Game on.