Caleb Porzio, Creator of AlpineJS and Laravel Livewire

What's up, Caleb? What's up, Ben? How's it going? It's great. Doing well. Well, it's a pleasure to talk to you, Ben. I just want to lead out and say that I've followed you for a long time. And like one of the first places I worked at, you got on my radar because you worked at Thoughtbot. Like, I don't know what your position was at Thoughtbot. And that was one of my first like pillars of programming people.

at the time was like, oh, and I was scouring the blog posts on Thoughtbot and just every blog post was like, this is the content I'm here for. I just wanted to lead with that, set it up. I appreciate that. That's awesome. Yeah, those were those were good days. I think I built a lot of my audience during that period. So there's a lot of people who basically know me because of or sort of through Thoughtbot. Yeah. I mean, now surely that's not the case. Right. Like Tupel is like on the map.

to pull someone on the map yet, but I think it's hard to say. A lot of people do mention the Thoughtbot days. So I think that was the seas were definitely there. Cool. Yeah. So I'm stoked to talk to you about some code and kind of go deep in some of that stuff. And it seems like this is it seems like you have made yourself a life of mostly focusing on code. Yeah. You're doing you seem to support yourself through.

open source contributions plus like some paid educational products around those open source tools. And, but I'm guessing you spend 80 % of your professional time writing code, maybe more. Yeah. I think it's pretty much all, it's pretty much all writing code. It's, but it's not all open source code. So like the open source stuff. I don't know. Lately I've been spending like the first three hours of my day, like pull request maintenance and stuff.

And then the rest is I'm usually developing something in the background to release it. Lericon. That's usually how it goes. So it's usually like a new version of the open source tools. Maybe it is open source. It's just like a private branch or in this case, it's more of like a product thing that I'm working on. So yeah, but it is all code. And sometimes I do a lot of screencasting to support the work. Like that's where a lot of. the revenue comes from for me.

And that is still like, so there is a lot of screencasting and content production, but the majority of the work there is actually me writing the code for the screencast and like honing it and really kind of figuring it out. The screencasts are very code oriented. You buy the video and the source code. So it's like, you know, so yes, I code a lot Ben and it makes me happy. Yeah. Yeah. Well you it's.

I think this is, it seems like you're maybe living a life that a lot of developers want, which is that you are, it seems like pretty independent and you get to work on your open source things and get paid for that. And you seem pretty happy with this life. I am definitely happy with it. Yeah, I def I'm like reaching, I'm trying to build bigger. I want more. I've decided that like, I'm not just happy to have the like lifestyle independent developer. life, I want more.

I don't know what that looks like, but I just know that I want more. So, yes, but I'm absolutely happy with it in the sense that pretty much every day I do what I want to do, which a lot of times is what I should do, you know, not necessarily things. How do I put this? As you know, it's like when you're independent, you're working on stuff you want to work on, but you're also doing stuff you don't want to do that you know is good for you that you should do. So there's a lot of that, but.

But yeah, I think I've got like a decent life going on here and I'm just really grateful that it works out that way.

Yeah. Gotcha. Yeah. So do you want to maybe start with just like a quick description of it seems like your tube, the two big things are Alpine and Livewire. Those like where I think most of your time is going. Yeah, pretty much all my time. Everything is Livewire and Alpine. Yep. Gotcha. Okay. And do you want to maybe elevator pitch those things for us real quick? Sure. Yeah. So actually now it's easier to pitch Livewire because everybody knows about HTMX.

But HTMX inspired me early on when I was at Titan. I was writing a lot of view SPAs for the past maybe three years at the time and getting kind of bitter about it. I actually almost got fired from a job because it took me a week to do a file upload because I didn't even know what form, I even forget now, uploading a file before SPAs is just input type file. and you know, Code Igniter just knew what to do with that or whatever.

But anyway, so there were moments like that where I just had these awakening moments and then I was reading like DHH's. I mean, you know all this stuff. I just read from the outside because I was never a Rails guy, but the like JS over, I what it used to call it, that pattern. But anyway, like. An obtrusive JavaScript, maybe. No, it's something it's like. it was like JavaScript over the wire, but like sending JavaScript to the browser to execute over Ajax, like things like that.

Server sent JavaScript or something, whatever. But also sending HTML partials was something that I had discovered in the Rails community and PJax and like TurboLinks and whatever, and just sort of realizing that like this pattern, and I found Intercooler, which is now HTML, you just renamed it. And so I started using Intercooler and it's just like fetching HTML.

and really fell in love with the pattern and thought, and then the Phoenix live view came out and I was like, this is that taken to the next level. And I was, I want to do that for Laravel. And that's been LiveWire ever since. So I guess for people who don't know any of the frameworks or patterns I just mentioned, LiveWire is like, it's in the Laravel framework. And when you're using Laravel, it allows you to stay in the backend, but create dynamic interfaces. So like.

you can say wire click on a button and the method that gets called when that wire click happens is a backend method instead of just like a front end click listener that calls a front end JavaScript method. It's literally like a PHP class that you can access state and methods in both the front end and the backend. So interesting. So I can say when you click this button on the front end, make a request to the backend, run this particular method.

Yep. take the results of that and stick it in here or maybe even execute it? Is it coming back as like data or JavaScript? Right, so is the really integrated part. So let's say like if you wanted to build a counter in LiveWare, you wouldn't because why would you send network requests to build a counter? But okay, you want to build a counter in LiveWare.

You have a backend class called counter that has state, so like a public property called count, and then a method called increment on that class. And then you have a view that correlates with that class. So it, for us, it's in a render method in the class, but whatever you have a backend template like ERB or blade and Laravel. And that template is just a normal view, like from a controller that you pass the properties into and you can echo out things in the backend.

So you could say like an H one tag, echo out count that count property as a normal backend variables. This makes sense. So totally. think about almost just like a controller and a view, just sending data and then echoing it into the view. And then you'd have a button that says wire click increment and wire click increment is just an HTML attribute on the button. Okay. Do we have the setup? You got that locked in? I think so.

Yeah. Yep. Is there any hole or any, what's the little tiniest bit of not clarity for you? Let me try to say it back to you and see if I've got it so far. Great. We're wiring up a button. Yep. There exists a back -end class that does the increment and stores the data in RAM somewhere in some sort of instance. Don't even worry about where the data is stored. Just the experience. But it's not on the front end. It's not. It's a back -end class. That's saying. Yeah. That's what we're getting at.

Yeah. And so, yeah. So we have something that's going to fire when I click this button that's going to increment on the back end. And then something is going to flow back to the front end somewhere and show me the new state. Yeah. Yep. Basically. So the experience of it again is just like almost like a controller, except you have state like properties and methods instead of just methods. And there's a view that correlates. You have a button, wire click increment.

When somebody clicks that button on the front end, a network request gets sent to the backend with the last known state. So that's how the state gets transferred. It's like a snapshot. So this little snapshot of state gets sent to the backend. It hydrates that class, calls your method like increment, which bumps count to two, re -renders that HTML view. And then sends back the new snapshot of data, the latest snapshot, along with the latest HTML.

And then in the front end, that new snapshot gets held for the next time. And that new HTML gets morphed onto the page. So it's like kind of like a virtual DOM, but not virtual. It's like DOM diffing, like walking and finding like, okay, this divs the same. Oh, this H1 has a different text content. Let's mutate the current H1 on the page to the last known H1. So the experience on the front end is that. When you're writing code, you feel like you're writing back end code.

When you're using it, you feel like you're using front end code. Yeah. But which is very similar to HTML. It just has, it does a lot more of the glue for you. So you're not creating bespoke endpoints and such, or manually sending the HTML. It's really declarative in that sense. You're sort of declaring a state and a view and a template. And then, yeah. So that's LiveWare. Very similar to Phoenix LiveView, if anybody's familiar with that. But yeah. That's the pitch.

And then Alpine is the JS sprinkles that I wrote for LiveWire, but turns out it's like really useful outside of LiveWire in vanilla Rails apps. It's useful even in Hotwire. It's useful in HTML. So it sort of gained wider adoption because it's for me, it's like, uh, like the modern jQuery. It's like a JS sprinkles framework that just, you can throw in a CDN and all of a sudden have a lot of power to make drop downs and popovers and. Whatever all sorts of stuff. Modals.

Yeah. Nice. That's so interesting. I I like more or less retired from web development right before all of this stuff like started happening. Okay. It's like I was like just as like JavaScript was like kind of taking off like like do you remember Backbone by any chance? Yeah. Like when Backbone was kind of like ascending was like about when I like stepped out of the early days. That's really that's like pre react era. Yeah, yeah, absolutely.

And so every time I like I'm talking, you know, modern JavaScript, I'm like, I am out of my depth. I have touched this in so long. I'm just so used to like everybody knows everything about, you know, the current landscape. But that's that's funny. Totally. Yeah. Yesterday, I was talking to somebody that works at Duple as a younger guy. And when I told him like my my level of JavaScript knowledge, he was like, oh, wow, you are old.

It like wasn't until he understood where I stopped JavaScripting that he like. appreciated just quite how ancient I was. That's great. If you're ever looking for like a fun time, just like peruse all the stuff that exists now that jQuery used to have to do for us. It's so nice. It's like JavaScript's like decent now. Nice. Yeah. Last you knew it wasn't that decent. It was not that decent. That's sort of still how it is cached in my brain.

Yeah. It's just like this sort of like, I don't know if this is for me. Yeah, it's better. I don't know that I've been sold that it actually is for me. Like it still seems like kind of crazy as I like peek at it from a distance. But I'm glad you're taking it. Yeah. You know, you know more than I do. Maybe about JavaScript, Ben. Yeah. All right. So let's talk about coding a little bit. Yeah.

Cool. If I saw some code and said, oh, man, Caleb definitely wrote this. What would I be talking about? What would I have seen? I think what people would say, like maybe one tiny little ism is like really short or absurdly long method names. Like a method name or a variable name that's like a complete sentence that has like 15 words.

And that's like kind of a philosophy of mine is like the name should either be incredibly short because it's so obvious in its context or it should be incredibly long so that... there's no like question about it at all. You know? Yeah. I like that a lot. I think people are like overly afraid of long names. There's like no harm at all. I guess the only harm is you lose some of that easy like aesthetic, but that that's why you make, try to make things single word.

And if, if they're double word, maybe you can extract, maybe it's, I don't know. I've always been fascinated how naming can kind of give you smells about your code. Like, Totally you have all these contextual names and you're like, oh if I actually put this in a class or a separate file I just remove the prefix on all those things, you know Yeah, so that's the ultimate goal.

But if you can't like just make that big fat method name, you know, yeah, I love that I'm I think this like is a good example of sort of like a philosophy of mine which is as much as you can getting the Implicit knowledge in the code to be explicit. Yeah, so there's a lot of times like people will explain a method to me and be like, oh, well, like this does this as long as this. And I'm like, great, let's tack on as long as this. Yes, right.

Yes. Those are, those are the kinds of prefixes that I, you know, I don't want to say it's all over my code. Cause again, I'm, I'm trying for these, I'm trying for, for really sleek, like minimal stuff, but, but definitely as long as, or doing this until, or ensure this is, you know, things like that. The kind of like describe more about.

I guess like ensure is like a favorite of mine, like for, instead of having like a conditional guard clause at the top that forks the logic in something, just having like a method at the top that's like ensure the file exists or something and then continue the flow as normal. I don't know that that's kind of a sides of point, but ensure is like a name that I like that also like introduces a pattern that I like, I don't know. But yeah, it's like, it kind of feels like the short.

Really short names are like your reward for having done a nice job on your design. Yeah. And like gotten good names into other places so that you can like, so it is unambiguous when you see like, like execute or something like some sort of name like that. Right. Yeah, exactly. Yep. Here's an example of, of something that I did for fun. So I rewrote LiveWire last year, like a full code -based rewrite from scratch. Took way too long, like a year and a half. We gotta talk about that.

Yes, we should. But there was one file or one feature that I felt like I couldn't crack. Like I couldn't, I couldn't like do it well. I couldn't separate things properly enough and whatever. So it was actually, it's basically a Turbolinks feature. I added that to LiveWire. So I mean, you're familiar with Turbolinks and PJax. I can't remember what it does anymore. It's so funny, Ben, to me, you're like the Rails guy that I can, like most people, I can't just drop these Rails references.

They don't know what I'm talking about. But Ben surely knows what I'm talking about. I remember, I think it was like partial page reloading. Was that what that was? Basically, GitHub pretty much still uses it, but TurboLinks hijacks all the a tags on the page. And then instead of doing full page navigations, they Ajax that whole page and they just sub out the body and then splice in any head scripts and links or styles. And then it just basically is a full page change.

and you don't have to do anything on the server to account for this. That's why it's so beautiful, but it speeds up page transitions by light years, because it doesn't have to tear down everything and reboot at all. Whatever. Let me teach you about modern Rails. Let me teach you about legacy Rails, but nobody uses TurboWinks. Let me teach you about old Rails. Pjax was controversial inside Thoughtbot, as I was wrapping up there. So I think we were kind of like, we don't know about this.

This is a maybe for us. And Pjax is more... Uh, like HTML, like P -text can be like partials and things that you're talking about where like turbo links and hot wire, like turbo drive are just kind of full page. You know, it's much less dangerous. Doesn't whatever. So I go to write this feature pen for live wire and I can't like crack the flow in a way that I like, like keeping things separate because everything is so related. It's just whatever.

So I ended up just writing it out like a sentence or like a paragraph. So if you read this code, it's literally like, this is like the first method in JavaScript. It's like when a user presses a button and then a callback that does all those things and then like a parameter in that callback that's like, and then do this that gets called at the end. And like, and in, in that method, it's just, you could literally read it like a paragraph and it would read cohesively. Yeah, I just, I don't know.

I scrapped that, that like file so many times and then decided like, this is something that is so specific. I need to literally write it like a story. Um, and it remains one of the pieces of code that I like maintaining the most for some reason, cause it's so obvious what everything does. And you can just like at a glance, you can look at the entire critical flow and just read it like a book and go, Oh, like that's where I need to go. Or I can add this into that point. I don't know.

Just a random nugget for you. That's interesting. Cause that was my first question. Like that would be my most, my first thought is like, have you made some changes to this since then and found it malleable along with just like declarative? Yeah, it, it really is a joy to maintain. And I, this is like for some reason it's an anomaly. I don't write other code like this. I haven't used it. I don't know. Sounds like it's working in JavaScript.

It feels really natural because in JavaScript, I pretty much don't use classes or anything. It's just functions stored in files, which is honestly, that's another conversation where I like, if you write functional JavaScript, it's pretty much just object orientation, except like each file is your class. All the functions that are in there are your methods.

And then all the, you know, just variables that you say, let, those are your properties and you pretty much have a class, you know, random nugget. But so in, In PHP, I'm doing like object oriented programming and this kind of like callback craziness just doesn't feel as natural for some reason. I don't know. Maybe that's why I haven't written code like that in the backend. Interesting. So is it like the kind of callbacky chaining thing? What makes it feel like you can do this kind of thing?

So I think that's what makes it feel that way. Like that, like when I'm writing JavaScript, it's very free form and, and callbacky in that way. And in PHP for whatever reason, I just don't write code that way. And I think it's because things are up. like object oriented and more rigid. That would sort of make sense to me because like with OO you're sort of, I feel like the flow is not necessarily obvious.

Like it's not clear that like A and then B and then C and then D happen a lot of the time because like any of these methods could be called by some external caller at any time. The state could be kind of anything when those things are called at any time. But if you have like a explicit, like these things are chained together in this way and the data is going to flow between them this way, that sort of... eloquenty kind of interface to me makes sense. Yeah, I think that captures it perfectly.

Yep. I think that's why.

How do you feel about functional versus OO? Any thoughts on that? Yeah, I sort of I'm not a functional programmer. I don't know the like capital F functional programming like fancy lambda stuff. Occasionally in JavaScript. Are you sure? I feel like I think I feel like functional programming has like a little bit of a scary reputation as being like maybe more than it is. Yeah, maybe I'm not sure. It's just like calling functions and passing data between them.

In that sense, I'm a functional programmer. Yeah. Yeah. I guess I don't, you know, there's like a functional programmer that is like never writes or doesn't write a loop. Like there's no loop. It's just recursion. Like that kind of functional programming is like programming. I don't really do. That's like pattern matching all the way down. That's not. my programming. But when I'm writing JavaScript, it's pretty functional and I really like it.

And there are, there are a lot of times where like, I'll wrap a callback in another callback and pass that around or decorate a callback with another one, or even occasionally, what do you call that? What's the term for basically taking a function and assigning parameters to it and then passing that as a new function? Kearning? Functional? No, that's right. It's functional. Are you talking about like partial application where you've sentenced some of the arguments?

It's partial application, but whatever. There's some functional term for it. But yes, that's what I mean, like .bind in JavaScript where you can do that. And there's times where I'll do things like that. I'm like, oh, that's pretty functional. Interesting. Yeah, I guess, yeah, that feels functional. I think to me is I could be wrong. I mean, like the functional programming zealots might. Tell me I'm wrong for this.

But I feel like the sort of the big difference to me of like OO and functional is like, do you wrap up your data and the things that operate on that data into this like bag that is a class? And does it have state that changes over time and like the sort of methods are operating on that state? Okay, you're doing OO. And like, are you creating a graph of these objects and having them call things to each other and pass data around? Cool, you probably are doing OO.

Do you, does your function, get all of its data passed in as arguments and then return data that goes somewhere else, you're probably doing functional programming. I feel like that's the main, in my head, that is the main divide. I like that. I think that's a very reasonable definition. Like that's a good handshake definition. Like, can we just like be like reasonable here and say that this is a distinction? Cause I think it is a totally legitimate distinction.

And it is, I tweeted about this the other day that I really feel like two programmers pretty much every day. Because in PHP, I tend towards object orientation. And in JavaScript, I almost never write a class. Like I've refactored out pretty much every class in Alpine. And when I write JavaScript, it's just functions. It's very functional as you describe it. And in PHP, it's very object oriented. And I love both. It's like I have two different hats on for some reason.

No, no. You have to pick a side and hate the other one. Do I? Right. I'm pretty sure that's required. Right, that is the way to do this. We're programmers. We're supposed to have strong opinions about this. I love, I imagine like you'd feel the same. I don't know. I love the rigidity of object orientation at times. And I also love the freeform nature of, you know, JavaScript functional programming. Gotcha.

Yeah. I think I've been kind of radicalized by Rich Hickey and Clojure and just I think I'm on the functional programming is just tends to be simpler to understand, train, and that it's a good idea to have data that's immutable and to pass it between functions and to not build a big graph of constantly mutating objects with internal state. Yeah, I guess like mutability is one thing and the definition that we laid out of JavaScript doesn't always imply a mutability, you know, like there are...

Um, yeah, but I mean, immutability, I definitely agree is, is a value. Um, it, Adam has been like working on this, like Tailwind Re -Reverber and I'm just watching his tweets and, um, and he's like, I don't know if you saw this tweet of his, that was, uh, like the, the noob, the brain, and then the Jedi, you know, and it was like mutable temporary variables, you know, for loops, whatever. And then like the, the big brain is like, immutability and, you know, pure functional, whatever.

And then the Jedi is like mutability for loops. Cause he's talking about performance and how like immutability has like memory costs and you know, all of these function calls are costly. Like in, with like deep performance, mutability is more performant and doing like simple long functions that have like four loops instead of functional transformations and whatever is, I don't know.

I thought it was interesting and it is like, randomly something that I have encountered with Alpine where like I try to use for loops in critical paths instead of functional transformations because they're just like cheaper they're faster and cheaper than like everything else, you know Mm -hmm. Yeah, I don't know but I'm with you Mm -hmm.

Yeah, I can't remember if I told the story on the last pod but I taught briefly at a friend's programming boot camp and So I was exposed to like new developers for the first time in like a while and we gave them a program exercise And the goal is for them to learn proper object -oriented programming, because they're trying to learn Ruby and Rails.

And I was surprised to learn that a huge percentage of people were basically just using class methods and passing data around between them and not instantiating anything and having no be static methods in it. Yeah. Exactly. So they were doing functional programming.

Yeah, like they just had like there's no little no local instance data they were just like taking data and throwing into a function and then taking that and throwing into the next function and It was funny because I was like I get why you're doing this like it is Easier to understand.

Yeah, and I'm here did I have to kind of teach you that like this is a bad habit actually in the pair in this paradigm that you've chosen and like I'm gonna show you how to do it in the OO way, but like It was interesting that the kind of beginner mind to programming reached for that approach. And I was like, yeah, I get it. That's fair. Like, that is that's kind of interesting.

Like that that's there's some sort of you're saying like, this is like evidence that, that not only is like, it's just more intuitive, not only is it better in ways for like, reliability, it actually is more intuitive to understand that our evidence is these newcomers who just into it.

But you're right that that I think that is a common thing is like, I remember early on hearing the advice like, don't use static methods because there's just the temptation so many times to just have to name a function that does something and you pass stuff in and you get something out. Like that's the most, that's like basic.

I've like forgot about some of this stuff, but in, in the O O O O O bootcamp, it's like stop with the statics, you know, like we have the blueprints of the houses with the, you know, it's like, right. You need to make a class and I need to have data locally inside that class they need to call methods that operate on that and don't expose that data because it has to be secret and like right all the stuff is private and There is a lot of ceremony.

Yeah, I just want to like be like value equals X and then I want to pass like this into the first function and up and get a new thing back I want to pass that into the next function and get a new thing back and I'll have the answer and I'm like I get you I see why you want to do this. Yes, that that's really funny. I Because that, I mean, OO is such a, has like a steep learning curve because of all of this extra ceremony that just isn't intuitive.

And you're just like hitting people over the head with these like houses and car manufacturer analogies, like trying to get people to understand or to have an intuition for it. But it, yeah, it just doesn't, it doesn't, doesn't map that easily. I'm trying to think of instances where I like OO. And I do think it's better. I'm trying to think of things and I'm a little hard pressed. Here's one. Here's one for you. So in, uh, in live wires, JavaScript, there's like a request bus, you know?

So if you think about like a component has to make a network request when it's updated to do that whole life cycle thing and that, that request has a whole life cycle of its own. And there might be multiple components on a page. that each need to be able to send requests, but then they potentially get bundled together into the same request if they happen at the same time to save on network resources. But their responses need to come back in the right order and everything.

So there's a bus within a bus. There's an update bus for one component that can have multiple updates per network request, and then a request bus for multiple components. And these buses, These individual requests, I found, this is one of the few times I broke into OO. I created a class called like, one is called commit, like you're committing an update to the server and one is called request. And these have state, they have the updates that are going to the server.

They have like all of OO type stuff. And then they know how to turn themselves into JSON payloads and they know how to handle their response and all this stuff. And I found it to be like, really nice and reliable instead of just free form like data flow to manage all this, you know? So I don't know, do you ever find yourself like with a heart still for objects? I do so much less programming now that I don't have like a great like recent answer to that.

Yeah. So I like I mean, I I do have a love for Rails. So it's like I when I if I need to write a web app, I'm still I'm still going to use Rails. I'm not actually going to use like a closure web framework or something. So I guess it's sort of the case where I tend to write my, even within the OO paradigm, I tend to write my code fairly functionally. I'm trying to avoid mutations or side effects. I'm trying to have things typically be as pure as possible when I can.

But real functional programming has never been tried. In practice, when I need to get stuff done, I'm usually just using OO. So it's the classic hypocrisy, I think. And I think to add onto your hypocrisy here, I think that functional, like you saying like functional programming is easier to intuit. I totally agree. And I love that point about like people just tending towards static methods.

But if they went to a functional bootcamp, they'd be telling them again, they'd, they'd want to reach for a for loop and they'd be like, no, no, you can't use a for loop, you know, or they would want to like create. I wouldn't say that for loops are banned in functional programming. Isn't there languages that don't have a loop? I'm trying to think of, is it like Elm doesn't have a loop? Elm might not, yeah. Maybe Elixir? I don't know. They'd be like, there's no loops.

Maybe it's an Elixir, you would call a class method. And then that method would call itself until the parameters change and it would match a different method.

And that's the exit out of the loop. And then they have to understand recursion and like, and having ensuring there are cases where the, where there's a, an exit for the recursion and that's its own level of, you know, and that whatever the, like all the names, like tuples and tuples and yeah, parameter assignment and. lambdas and whatever those other funny words are that no one understands thunks. Yeah, thunks. I don't know.

But anyway, I'm sure there's like a whole other ceremony that if they went to the functional boot camp, they'd be like, yeah, is this I just want to write a class, you know? Yeah. And I don't think like, oh, beginners understand this really fast is actually a great argument for programming language design. OK. You know, it's like it's a it's a factor. Interesting. Like ease of adoption is one thing. But really, I think you actually want like.

intermediates to experts to be extremely productive and that's kind of the better like score to grade on. So yes, for sure newbies would trip up on other on new things, different things, most likely. So how do you feel about like C family languages, like all of these, you know,

PHP and JavaScript and things that are like C family that have all the stuff we know, you know, like functions and.

variables and you know things like that where these functional languages are I would consider them not see family languages do you think that like That at a certain level a code base is harmed or a programmer is harmed by some of the offerings of a C family language Guess it I'm not sure so like if if we're talking like malloc level things like we say you know what malloc is Yes, it's memory allocation and see oh, okay. That's one of those words that I've only read the spelling, you know?

Yeah, yeah. Like I used to say, Tutter real, like random stuff like that. Oh, interesting. Yeah. Yeah. Yeah. So like, I think there were design choices made that have caused like innumerable bugs. Like nil being a thing, for example, is like the trillion dollar design mistake. I would people say, and I agree with manual memory management, you know, if you really need it. Sure. But it's pretty, pretty error prone. So yes, there's there's lots of sharp edges.

I'm not here to say that everything should be written in functional functional languages, right? I just think if I My forever language is definitely functional.

I think For me for like the things that I want to do generally They're like sort of like my retirement language like what I will like retire to write my beautiful Yeah, conceptually pure Satisfying to my brain and my soul kind of code is going to be in some sort of functional language, probably a Lisp, because there's wonderful things about those languages. But yeah, I don't need to like have everyone agree with me or do that too for all their work.

I will say that I'm like acutely aware of how often I step on the rake of like calling blank on undefined or something, you know, something like that. How those nulls and undefined leak into my runtime code in both PHP and JavaScript is kind of alarming and And I think some of it is just, you're so used to it that you don't identify it as like a problem that's avoidable. Like there are languages that don't have runtime errors. They definitely don't have runtime errors like that, you know? Right.

Yeah. At least that one. Yeah. And that, that one's like kind of a solved problem in like, in certain languages, which is the thing where it's like, you know, if you, if you have an optional type that you always have to unwrap, you will never accidentally like blow up in that way. Right. And. That's pretty nice. That's a pretty good win right there. And so to just not have that support at the language level is kind of like, that's too bad.

Yeah. Mutability feels similar, like immutable data structures, I think, also prevent a big class of errors. So there are things that I think are nice to have that are too bad that aren't everywhere. Yeah, I think I agree. And I don't consider myself an academic programmer. I very much feel like I'm surfing. Like I'm just kind of taking it as it comes and doing what feels right.

And I think sometimes that probably benefits me and sometimes it harms me by not like really exploring or like being rigorous about some of the like rakes I'm stepping on, you know?

All right. I want to hit you with some some questions. Let's do some some one offs. All right. How do you start something complicated? If you're like built like building something hard, you're not quite sure how it's going to look. Are you a? Do you like start with a prototype? Do you build a small sandbox example? Do you sketch on a whiteboard? Do you have a notebook with words, diagrams? How do you start getting the lay of the land and figuring out like how to make progress?

It's all of the above. I think I, yeah, I'm very like sporadic and inconsistent in my approach to that kind of thing. Cause it's really like what feels like I have the best chance of... of getting to the hard parts, I guess, and like rooting out some clarity in the obscurity. So I always have a notebook on my desk and I found like this, I've gone through a bunch of different techniques. Over the years I've realized pen and paper is crucial to my everyday.

And I used to have just stacks of paper everywhere. And so that was pretty unwieldy. So I bought like a paper roll to put, to like mount on my desk and just pull up like butcher paper. and then my whole desk is a piece of paper. Yeah, because like whiteboards, they're, for a handful of reasons, they just haven't worked for me in making a whole desk a whiteboard. I've done that. Like IKEA has like a whiteboard table that I've used as a desk in the past. So this I really like.

And the coolest part is you keep a ledger of everything you've written. So all these little like notes and to -dos, as you pull more slack, in a perfect world, you have a second roll that you roll up. But I just have like, you know, 50 feet of paper. So, but like last month I decided that this is too messy and there's too much paper in my office. So I've just switched to a notebook. I'll just a spiral like, I'm sad. That was such a cool idea. I love that.

And it was nice because you could get that feeling of like a beautiful clean desk and workspace and thought space every time you pull off like another chunk. but I couldn't get the infrastructure dialed in and I was too lazy to like do it well. This is an indie business waiting to happen.

Honestly, I think it would be, I thought like really hard about like the different, like just for an MVP, I could use like a paint roller thing and like put the roll on the paint roller at the end of my desk as like the axle and just roll up on each end. Yeah. I mean, I like the, I love the sound of like a big, a big swath of it. So it can be like really wide. Yeah. And. I like the idea of like your history is retained because you're just kind of rolling it onto the other the other rollers.

You're like, even if you never go look at it, you're like, you just have that like comfort of like, OK, I know I can go back. It's in there. And when you want a new when you're ready for a new thing, you just like roll, roll, roll, roll big blank wide sheet of beautiful opportunity. Do this. Great. It's awesome. You make this the little tea mug like circle stains and then and then you roll it and then they're all gone. It's like. Yeah, it's beautiful. So I actually did. Yeah. All right.

Let's do it. We'll do it. We'll make it. We'll get a monk to make it. Yeah, exactly. This is not my product. Yeah, they'll do that. And that'll be great. So that, I mean, really gets to the heart of most of work for me is like everything is very free form because that's my personality. So having a free forms. So now it's a notebook. Yeah. And that works pretty much just as well. So a notebook. And, uh, but I guess like, what's an interesting thing that here's a tool that

I don't do often enough when I'm on my best behavior I do, but I've like firmly believe that this is the best way to suss out or to like explore an idea or fix a bug or pretty much anything. Write a blog post, like a publishable blog post to yourself that you would send to somebody whose time you care about immensely. Write that blog post. and you will have solved all your problems properly.

Almost every, if it's a bug, I almost guarantee by the time you're finished with the blog post explaining the bug thoroughly enough, you solved it almost every time. And same goes for new features. Like I personally want to just jump into the code and start hacking. I want to do that, but I have to like, so I do that when I'm not on my best behavior, when I am on my best behavior, I'm rigorously writing out a blog post that I would be proud to publish. That's so good. I love that.

Apparently Amazon does this for new product launches. It's like you have to start with like write the announcement to the customers that this thing is shipped. Oh, cool. Nice. Yeah. Documentation first kind of development. Yeah. The read me driven design. Read me driven design. Yeah. Yeah. All that kind of stuff really. Yeah, it's incredibly valuable. It's such an interesting. It's an interesting brain hack like that. It kind of feels like that shouldn't work so well.

It's like I just like it's kind of like it lets you figure it out by just like if you just think about the end state, your brain is going to work backwards and figure out all these intermediate steps and make your life easier. Yeah, it's like skipping the hard part is the best thing to do. Yeah, really? It's like, why that works? Wow. OK. Skipping the part that should like reveal everything to you is actually it's like that's like more harmful.

Pretending you just have this magic wand and the thing is done. Yeah, you just talk about it and your brain is like, ah, yes We know how to make this no problem. Yep. Yeah that I mean in that like meta concept of starting end first is like Just such a programming truth for me like even down the class you're about to make or the function, you know Just API first, you know, absolutely.

Yeah test driven development did that for me I've just been like let's assume this is here and it works and let's write a test for it. That's another form of that. Yep Totally. I think it worked in the macro and the micro. It's just like a really powerful tool.

Agreed. That's one of those. I'm always, I don't have like a perfect log of this anywhere, but I'm wondering if you're similar. Like I come across something like that in a conversation. I go, that's a fundamental truth to me. Like as close as you can get to truth is like, this is something I want, you know, inscribed on my wall or something. So I'll create these.

At one point it was a field notes of like core beliefs and like practical beliefs, not like a, ethereal beliefs, like things like this, but it never stuck. And just today I made a new Trello column called Core Values and put in it every day is day one, like sort of the Jeff Bezos, like Amazon, like, uh, whatever. I have a whole, a whole other reason for believing in that as a core truth, but, um, I don't know.

I just feel like we, we struck one of those chords and you go like, Oh, that's, that's a big one. Don't forget that. You know, totally. Yeah, Nat Friedman has a website, it's like one of the best personal websites I've ever seen. Really? And on it is something like 30 things that he believes. And it's just like bullet points in Times New Roman. And it's just like a collection of those kind of core values that he's sort of distilled from his experience. And sounds like that one would be on yours.

Yep. Yeah, that would be on there. I mean, you didn't ask and we didn't... go there with beliefs and we could go on a giant tangent, but another one that comes to mind that's like an age old, make the change easy than, or make the change easy than make the easy change is like, put that on my tombstone like that. This is one that is an undisputable truth, you know? Is that that way for you as well? Oh yeah, that's a great one.

Yeah. And I love Kent Beck's, I don't know if he originally formulated this, but like his tweet where he says, you know, first make the change easy. note, maybe hard, then make the easy change. I really appreciate that kind of like it's a good note. By the way, by the way, the hard part actually might is likely in this first part here. Right. But if you can do the hard part, then the next thing is easy.

I like that a lot because so I the nice thing about making the change easy is that it looks like a really clean refactoring pull request. It's just like I can start with just one piece of it and just say like, all right, the first thing I'm going to do is make this change easy. And so to do that, I'm going to pull these three, three separate things that would need to change into one place.

And then that's its own PR and the code base is now likely better, regardless of whether I now make the easy change or not. Yeah. Yeah. It, it, it is a beautiful thing. And I've like, I try to remind myself that at times that like I should, you know, when I make the change easy, I should ship. making the change easy before I make the easy change. Cause actually just straight up tagging a release in between those two makes you feel more confident about it.

And it gives you an opportunity to, to really like vet out any bugs that might, it, yeah, it takes something that was like really kind of daring and turns it into two reasonable steps, a refactor that maintains, you know, like parody and then a new addition that. isn't dangerous because the infrastructure is already in place. And it's easier for a reviewer to look at and be like, OK, there should be zero behavior changes here. No test should fail. Nothing should be new.

Nothing should be different. I'm just looking at this code and making sure it used to work like this. It still works just like this. And that's a pretty easy PR to review. And then now you make the easy change. It's like, well, this is an easy change. This is easy to think about, too. I can just see you're just changing this one place where you pulled all the stuff into one place. And now you're changing in that one place. Looks good to me. And they're both individually easy to review changes.

If you jam them together, it gets more tricky. You're more likely to do stuff, I think. Yes. It's funny because it takes one really tricky thing, like a pull request that changes everything and does something big, and turns it in. It takes one dangerous thing and turns it into two safe things instead of two less dangerous things, in a sense. It just feels like that, which is asymmetric in some way that I think is cool. Totally. And rings of truth. More values, yeah.

Nice. On that just randomly to just totally blow that one up. These truths to me like almost always have applications outside of programming. If they're like big truths like that and like cigarette smoking, like if you just try to quit, but you still hang out with smokers, like it's just really hard. But like if you make the change easy and fire all your smoker friends, I don't know what it's bad example. Like now it's really easy to quit smoking or something, you know, things like that.

That's like, this really is a core truth to apply to life in so many ways. Change your environment, you know. Totally. Yeah, that makes a lot of sense. I like the idea of like when faced with a complicated, like a tough thing, asking first, like what would make this easy? Yes. If something were like, what would be, what could be true that would make this thing easy? Absolutely. And maybe just do that. And then it's not so scary. You're not like, well, I'm not quitting smoking. I'm just.

I'm setting myself up. I'm changing my environment. Yeah. I'm just going to throw this pack away and I'm going to not make, I'm going to make different plans on this time when I normally would do it or whatever it is. Right. Or ridiculous things like what. what could be true that would make me stop smoking? Like, let's say I, uh, didn't have access to cigarettes or something like, cause I'm on a camping trip. I don't know. It's like, I could take that camping trip or traveling.

Like let's say, or, or let's say you're like, you hide cigarettes from your dad or something. Go on a trip with your dad. You know, I don't know. Like if you need to not smoke for two weeks, like book that trip that that will make that an impossibility, you know, I don't know. That's a very specific example, but it applies to, I think you put it perfectly is like, what's the thing that's hard that you're trying to do?

Like if what could be true that would make it easy, what does it take to make that thing true? You know?

Yeah. Nice. Yeah. All right. So what's so on your desk, you're getting, you're getting work done. You're flowing, you have a notebook these days. Do you have a notebook brand or type that you're like really into? I forget where I read this. Oh, This YouTuber guy, I'm not going to remember his name. He's like a entrepreneurship YouTuber guy and he's like pucca pads. And so I was like, I just needed a brand to latch onto for a notebook.

So I just chose this guy's brand and there he believes in them and thinks they're spiritually amazing. And so I was like, somebody thinks this is like a holy book. So I'll just buy the pucca pad. Okay, great. Are you a pen person? Have you, have you swiped the pen details? Oh, I mean, I've like, I've gotten into that a little bit. But I always go back to just who cares.

But yeah, there's that that one pen that like You probably know it I don't maybe it's zebra or it's some kind of pen people who cares about pens If you're not passionate about it, stop. I'm not passionate about it. Okay, don't care then In general, how are you getting yourself into the zone?

When you want to like when you like, you know, you've got a block of time You got a big meaty thing to work on. What is your like on ramp into productivity look like? Tea, like some sort of caffeine, but tea for me. Morning or night. Really? You're fine? Yeah, morning, night or weekend. Just when everybody else is not working, for some reason I'm like more... Oh, like early morning, late night, weekend. Gotcha. Not like midday. No, no, no, no. Gotcha, gotcha. I mean, that's that.

But I guess the only... If I'm excited about it... then it's really easy to focus. If I'm not, I need accountability. So I'll like live stream and that like I'll have like three hours of focused deep work against my will. That's really good for the thing. You know, like pair programming does that. Totally. That was my thought. Yeah. It's like live streaming is kind of like parent, like pairing with a bunch of people at once. It captures the value of pairing for me.

Like the value is less in the ideas I cook up with the other person, which is valuable. It's the accountability. And I'm a one -man band, so I can't just hang out with coworkers. So streaming kind of accomplishes that. Nice. That makes a lot of sense. Yeah. So I've streamed programming a couple times. And I was pleasantly surprised at how it made it feel less lonely. Oh, yeah. Yeah, it's great.

My only complaint with it is it does force, it takes such intense focus that it's sometimes similar to pairing. I'm like, ha. I'd rather just like sit back in my chair and lazily work on something, you know? But yeah, it is a communal experience. Yeah, it's good.

How do you feel about testing? What's your stance on tests? Yeah, I'm not sure. Sometimes I write code bases with no tests and I just have a bug tracker and it's like the LiveWire docs are sort of an app. They have like payments and logins and stuff. I don't have any tests and I'm fine with that because if it's simple enough and I ship a bug, I chose up in the bug tracker. I fix it in a minute.

Um, but for like live wire itself, I honestly think the test suite, I know that the test suite is more valuable to me than the code itself. Um, and I believe that wholeheartedly. So sometimes I'm like a testing TDD. Yeah, I'm not sure, you know, but man, like a solid test suite for me, that's acceptance tests cause they're full stack framework.

So. I've like Selenium type tests and one Cypress and the other, but yeah, like literally browser tests for a lot of it that are slow and suck, but every failing or every bug that gets submitted, like it's always starts with a failing test. Like that's probably the most valuable like workflow improvement I've made along the line. Yeah. Why do you value the tests more than the code itself? Yeah, because like the code, maybe this is why, like for re.

Like I rewrote LiveWire and the only way I was able to do that is because I had the test suite. And when I, it gives me the freedom to do what I want with the code because I resent the code a lot of times, you know? And it's like the only thing that gives me salvation from this resentment is these tests that allow me to change the code, you know? And I don't care if the tests suck.

Like it doesn't really matter what matters is do they give me assurance that that if I ship this thing, it's not going to break everybody's apps, you know? Yeah. And they do that. Yeah. Yeah. So if you deleted all the code, you could reconstitute it. I could reconstitute the code. You can make the tests pass again. If you delete all the tests, tougher to get those back. Way harder.

Those get built up over years of people finding edge cases that aren't me, that aren't in the happy path, that, you know, that's what it is. Yeah. That's the real value. Yeah. Yep. That makes sense. Yeah. If you had to lose one, I would, I'd go the same way. Yeah. That's so funny. I haven't thought about that, but like if you have to pick one, I would pick the tests.

Yeah. Yeah. And like, I feel like most, I think a lot of programmers would be fairly delighted to learn that they, all the code has been deleted and now all they need to do is make all these tests pass. Right. Yes. Like these high level acceptance tests in particular. unit tests, kind of annoying. Your cramping style can be annoying. Yes. But if you give me a high level test, I just need to make these go green. Oh, man. Absolutely. One by one, baby. Let's go. Yeah, that's the dream.

Yeah. Yeah, a lot. Yeah. It's interesting. So I've talked about this, that phenomenon before about how it's like, oh, yeah, given the test, you can make the code, but given the code, you can't make the tests. And then I caught myself. now in 2024, like wondering like how true is that still? Because I think I could feed some code to various AI tools and be like, give me some tests. And are they going to catch the edge cases? Maybe.

Probably not like the gnarlier ones, like the oh man, on Windows with this setting, this thing fails. So yeah, you're not going to get all that detail back. But I think there's more of the ability now to like, I could create the tests from the code in a way I couldn't before. You're probably right to a degree, but I would imagine like Livewire, like tuple is something that is so like integrated in the experience of use.

It's not just like a package that you're calling methods on that has like very clear ins and outs. It's like, Oh yeah. These are, there's a 10 zillion scenarios that no LLM is going to suss out at least right now, you know? Um, but yeah, I don't know, but. It's an interesting point that it probably is getting less and less true, but I think it's still pretty freaking true. Yeah. I mean, I would still rather delete the code than the tests. Yeah. Yes. I have a question for you, Ben.

Hit me. And this question goes better if you were like a day -to -day programmer. So I am actually curious to hear like to what level you still code, if any. But in my career, I made a change from being like a systems.

like information systems developer in Laravel apps, like very typical stuff, like maybe you at Thoughtbot, like just Rails apps kind of thing, to being like a systems programmer, like with bespoke systems, like with these frameworks, you know, like how do you write a tree walker and, you know, all of these things that are not just databases and controllers and whatever.

And I found it to like breathe new life into my career and expose all these new loves for programming and... I just wonder if you found a similar transition into working on a non -typical app. Like the only typical part of Tupil is like the app, your user account, you know, everything else is like a bespoke system. So is that just, is that amazing for you? Yeah. So you're right. The Tupil is not like a, not like the apps that we'd worked on before.

So I have two co -founders, all three of us were Rails developers. And then we realized we had to build. We tried a few prototypes and realized, OK, the thing that gives us the control and performance we want is a C++ desktop app that's doing all these real -time things, real -time audio, video, data channels, that sort of thing. And fortunately or not for me, it was kind of clear that we shouldn't have three people coding on this thing and no one doing sales and marketing.

So because I had the audience, I was like, all right, I'm going to do sales and marketing. And so I wrote the first version of the Rails backend that the app talks to. But then I didn't sling any of the C++. So I didn't get to make that transition. Do you regret that? Is there a part of you that, or is it just like, no, that's what had to be done and I'm glad?

Or is there a part of you that's like, man, I was an equal programmer, but now I'm the business guy that I used to work with that doesn't understand that it has to trust these devs and such? I wouldn't say I regret it. No, I think it was very much the right call for the business. Yeah. Personally, I miss programming a bit.

Like I feel rusty with some of these concepts we're talking about or like I haven't touched the new things and I'm like, you know, JavaScript is a big mystery to me and like sort of newer paradigms I haven't played around with. So there's part of me that feels a little bit of like personal sadness around that fact. Yeah. But I think if you have three co -founders, having all three do programming is probably not the right answer. Yeah. And like I like the other stuff too.

Like I really enjoyed like figuring out how to do sales, figuring out how to do marketing, doing product, talking to customers, making choices about how it should work. And it felt like I was in like my kind of zone of genius there. Cool. And I, before Tupel, I had kind of gotten to the point where I was like, I've been programming for like, 12 years or something at that point. And I had gotten pretty good.

And it felt like I was at like, know, diminishing returns in terms of like continuing to get better. It was like I could get better, but it was like I was already a eight out of 10 programmer or something. And I was like a three out of 10 at like other aspects of running a software company.

And I was like, I'd rather lift those skills up and like figure out how to get good at that rather than get like a bit better at programming, which is going to take actually quite a bit of effort now, given where I'm at. Right. Yeah, that's a great answer. And I can identify with that somewhat myself. And I think that's, yeah, yeah, that's really cool and makes a lot of sense.

Do you find that the business problems and sales problems and such are like just as intellectually satisfying, like solving these puzzles and cracking them open and whatnot? Generally, no. Generally, no. Okay. You can't beat programming for brain stimulation and like flow state. like when you know you got a big chunk of time and like an interesting programming problem and you've kind of like figured out some of it in your head and like you're like ready to go after it.

Nothing for me like makes the hours fly by like getting like really into the code. And I don't I get some of that from writing if I'm doing like longer form writing. I think that will get me in the inflow state eventually. But most of the other stuff not quite. Yeah. So I think so. So programmers got it good in that way I would say. True. Yeah. I definitely, I could see that.

And any of the business salesy stuff in my life, it's engaging and rewarding, but it's like when you're working on a system or something with a really slow feedback loop where every deploy takes two hours and you have to get it through Q &A three times. There's so much cruft that it disrupts that flow. And to me, it's like... that process is so like that. It's so nebulous. The feedback loops are slow.

It's not conducive to that constant stimulation flow state problem solving loop that is programming or can be programming so often. Totally, especially with tests, because I was pretty into TDD. I wrote most of my code with test -driven development. So it's like, you're getting that constant, here's what's wrong. OK, it works now. Here's what's wrong. OK, it works now. And it's just like all these little. dopamine hits like a hundred times an hour as opposed to occasionally.

Yeah. Yeah. Funny that you describe like passing tests as dopamine hits and there is like, there is some dopamine drip when you physically see that green. Like, that's funny. There's like something really beautiful about the color green when you're programming, you know? And like the slot machine has like lit up for you. It's like you tried and didn't work. You tried, didn't work. Oh wait. Oh, I see. Hold on. Okay, there it is. Great. Got it. Right. I want to, I've always found it interesting.

Like the thought process before you hit that test run, especially if you're doing it like very quickly, like I think you have like a sense for like, I think developers get pretty good at predicting if like what percentage chance this test is going to pass or fail, you know, like you just have this sense. You can almost not even describe.

That's like, how much I think this time it's going to, or like, like I'm going to make this fix, but I don't believe it's gonna fix it, but you still have to try it. I don't know. Even when I'm pairing with people, I find myself doing that where I'm like, before we run this test, is it gonna pass? I don't know. Yeah, I feel like I actually, my guess would be that I have a pretty high accuracy on predicting tests pass or fail, because I'm usually not very far from it passing, I think.

Gotcha, because you're close. you're following the development closely with the tests. I would say so, yeah. I don't write 10 tests and then go write some code and see what happens and be like, I wonder if three of these will pass. It's more like, OK, we need to now handle the situation where there are no orders in the list and we should show this message. And I know we don't handle this yet, so I read the test. I know it's going to fail. It does. It fails the right way.

It gives me the error I expect. I'm like, OK, cool. I need to handle this. And I'm like, I think we've handled it. And then sometimes I'm wrong. I'm like, oh, actually. something was a little bit off, but I would say most of the time I can sort of, I know if I'm about to go red or green.

Yeah. Yeah. Um, let me ask you this unrelated question on, on your own interview podcast, Ben, are there, are there any radical things that you Institute at two bowl on the development side? Are there any places where you guys say like, like it, that you guys are different in some sense or, or really radical in your adherence to some practice? I would say, Nothing is immediately coming to mind.

I would say sort of two things that I wouldn't say radical, but are a bit different than what I'm used to. One is that we actually have manual QA testing. So we have a test suite for the app, but there's enough pieces and weirdness and sort of like impossible to create state programmatically or challenging to create that we have found value from having someone manually run through a checklist of the app. And the other is that I've never actually seen so many little prototypes get created.

Um, interesting. I think this might be because the app itself is fairly large and fairly complex. And so often to try a new interaction out or a new little bit of functionality, it seems more approachable or it's we get a faster, uh, time to feedback by doing a little play version of it that is in its own repo with like no constraints. Yeah. I mean, that, that is, seems like another one of those just.

really good buttons to hit in development, like really good practices to have is like code that you intend to throw away where you're just, you know, exploring. Um, yeah, proof of concept prototypes is definitely one of the, it's like, seems so obvious, but it's something that I don't often reach for. And then when I do, I go, why don't I do this for everything?

Like, why don't you can get so far in a single day with no constraints and, you know, just playing around and really like, you know, expose a lot of the complexity that this thing will have or the, I don't know. So did you guys have to like, do you systematize that in some way that like, do you just all remember that, oh, this should be a prototype or, you know? Yeah, I think it's, I know, I think it feels like it's part of the culture now where it happens fairly automatically.

I don't think there's any dick, like no dick dates that say like, you must do this. Right. Yeah. Yep. Is that, is that the way a lot of it is, is just like things get embedded in the culture because they're good ideas and then that's how good ideas continue. Or do you have to like set? good ideas, bake good ideas in somehow, or is that like a challenge? I've never thought about it systematically like that.

So I don't think we have like a thing that's like, here's how we write code here, like here are the good ideas you must not forget. I think it's a little bit more like, probably because we pair so much, I think these things like get spread around or someone will remember, or it's kind of like, is the part of the oral history of how we work. Yep. Yep, that's cool.

So you review it. I have to imagine a ton of pull requests as an open source maintainer. I think what I'm finding is the more active I am, the more pull requests I get. And then the less active I am, the fewer I get. Cause I think people, I think people don't want to submit pull requests if they don't think that it's going to get paid attention to.

So lately I've been like pretty on fire with, with like getting the inbox zero every day and like, It's doing horrible things to my productivity because like yesterday 11 PRS got opened in one day. Like I woke up and it was like, I have 11 new pull requests to review this morning. So anyway, yeah, sometimes I do a lot of code review, but sometimes I go, I can't do this right now. I have to work on other stuff.

But yeah. Well, okay. So I actually want to come back to my original question because that's, that's interesting. So I noticed you tweeted the other day, like you have these like list of, you have like a bunch of shortcuts in your Chrome new tab in order. of how you start your day. And like, I want to clear all the decks here. And the first one was email, which I feel like is probably actually a terrible way to start your day.

Actually, that was my take on your tweet is that like, this is actually not probably not a good way to start your day. No, email is nothing. It's there because it's the easiest. I used to use it's easy and it almost takes me no time ever. But I need to look at it in case Aunt Millie like wants to like have a family party or something, you know. Gotcha. Yeah. Well, so. I saw some of myself in this tweet. Okay. I often think, all right, I need to get going.

But first I'm going to clear all my inboxes and then I'm going to clear my to do inbox. And then I'm going to like hit all the things that are due today. And then I'm going to get to like the media project that is important for me for this this month. And I often stop the day after step three. It's like, all right, I like like I spend all my energy on the tending of the inboxes. And I almost got to the big thing that I want to work on.

But I didn't. Yeah. And. Do you experience that? Like, do you, how do you stay productive when you've got all this like incoming issues and PRs and all that, and you feel like to be a good maintainer, you've got to do those, but they're not really what you want to do long -term?

I just want to clarify that like, this is somebody preaching about something he doesn't have a lot of experience with because the majority of my career is just working on the meaty stuff and letting all the stuff decay like a messy room until it's so messy that you just. crush all the PRs and then do it all over again. But I'm trying to do better and differently. So one thing that I've been trying to stick to is 11 a .m.

being so I was listening to Matt and Taylor on their the Laravel podcast and and Matt was like, how are you so productive? And there's like, I don't even feel like I'm productive. And we're all like, dude, shut up. You're such a liar. But whatever. And he's like, I. he still, you know, he said this on your podcast that he goes through every, he still merges every pull request in the organization.

And I've been trying to get out of that for so long, but that it was like a, you know what, if Taylor can do it with 10 times as much code as more than way more than 10 times as much code as me, like I can do it with my small repo. And so he said that he does it basically, he, he works on all that stuff until 11 am and then he starts his day for other stuff. So I thought if Taylor can, can dedicate up to 11 a .m. I can dedicate up to 11 a .m.

And so that is one prevention from this bleeding out into the red. The two things I think the first prevention is having that hard stop where it's like, no, it's 11. I'm done. I'm not. You can't sidetrack me. You know, I'm going on to this other thing. And because all those things aren't in like pins, tabs and whatever, I closed the browser window. So it's like there's not the pull request things hanging out there. So I'm only giving you till 11 a .m. I think that's one important thing.

like breaking up the sessions of your day. And then the other thing is being excited about the meaty stuff. So I'm like really amped about the meaty stuff to the point that I'm like rushing to try to get through the other stuff so I can get to the meaty stuff. And as you know, when you're like amped about something, you're gonna do it, but

you're never gonna be amped about the maintenance. So that's why I think it just is only gonna work for me to do that stuff first, because I'm never gonna be amped about it. So I have to. I have to make sure that the reward is after that, you know? Yep. That makes sense. Yeah. So you're eating the vegetables first. I'm trying. I'm trying to eat the vegetables first. Yeah. You're going to have the steak later automatically because you want it.

Yes. I'm not a vegetable eater, but I was in Disney recently and this is another thing contributing to this. Like Disney keeps up on all their old stuff so well. I'm just like so inspired by that. And I'm so not good at that. I suck at that. So I'm like, This is my Hail Mary or this is my starting fresh or my everyday is day one. It's like, I'm going to reinvent myself. I'm determined to reinvent myself as somebody who cares for small details that aren't exciting to me at all.

You know, interesting.

Huh? I've gone the other way with that. Really? Yeah. Don't tell me about it. Sorry. Tell me. Well, I think I've decided that I can't make myself want something. Okay. And. Also that I'm at my best when I'm embracing the things that I'm good at and have passion for. Yeah. And should just kind of accept this other stuff. And maybe this is honestly this is kind of a luxury because you can you can build a business to augment your weaknesses.

True. So I can hire people to do those things that don't give me joy and I'm not good at. Yeah. And often they're really good at it and enjoy it. So there's like as a one man band, you might not, you may just have to like suck it up and do that for a while. But like, I feel more motivated when I'm just like, look, I love this and this and this. And I want to like spend as much time doing those things. Yeah, I generally agree with you.

And most of my life is spent with this belief that like, man, like swimming upstream, like just to, you know, find your unfair advantage and double down on it. Like that's and for me, it's it's. programming and innovating and new ideas and talking and communicating and easy communication like this.

Like these are all my strong suits, but you know, long form written stuff and keeping up maintenance support tickets, like pull requests, all that crappy context, which he stuff that I hate, I suck at. And I've, yeah, I guess right now I'm okay. My counterpoint to what you're saying, because I have to like, I have to double down on what I'm saying so that it sticks. Cause I like, I'm trying. I guess building a company and being able to delegate some of these things is a big solution to it.

But I'm even like, I'm wondering, this is what I'm wondering is if working on my week suits enhances the strong ones and fills in these gaps. And like, like now, because I have that discipline injected into my day, the last chunk of it is even more productive than if it was the whole chunk and I wasn't, you know, deferring that gratification or something. I don't know.

It could be a weak argument, but yeah, maybe I'm just a solopreneur and right now I'm in a position where to have the company I want, I have to be good at the things I'm not good at. Or at least be like willing to do them. Like hit a tolerable level of performance there. And I think it's like such a rare attribute for people to be able to do what I'm trying to do like this week and I have no proof that I'll be able to. that like I see it in the, the, the really successful people around me.

Like I'm always, you know, picking on like Taylor and Adam and Jeffrey and these people in our community who've managed to do this, they appear to be very strong in all of these suits. And it's like, I'm, I'm either, maybe they naturally are or aren't, but I can at least try really hard for this set of things. And maybe, you know, maybe that's a key here, you know, I don't know. Maybe that's why they make it to that extra level is because.

They're not only doing all that innovating, they're also answering support tickets and making sure they're at inbox zero for pull requests and caring for those small details, you know? I don't know. Who knows? But normally I'm with you. Don't fight your nature. Just like double down on it. Use it to your advantage. Pull those big levers, you know? It's pretty nice. But I don't know. Yeah.

Okay. Let's do a little lightning round. Yeah. So I want to hit you with a bunch of questions and give me like, a minute max on each of them. Okay. And don't ask me any questions. Okay. All right. What is your dream pull request on one of your open source libraries look like? A documentation update that I can instantly merge. That's my dream. But definitely failing tests, small, you know, well, Yeah, I don't even care so much about the description.

The code should say a lot of it, but I'll just pull it down. And if the test makes sense and I don't know, the smaller, the better. That's the best thing I can say. Yeah. Tiny, tiny PRs, tiny PRs. Yep. Focused, tiny, small, high value. That's, that's my dream. Yep. Do you care about good commit messages? Not at all. Ooh, why not? I from other people. I don't care. Uh, for me, I, I used to do whip. I don't do whip commit messages. I write like a few words.

Like I'll say, tweak this or fix test or try to just like keep it as simple as possible but provide some sort of flag. But they all get squashed in the PR and the PR description is usually, or at least the title is like well written and the release notes. So I'm pretty rarely like actually looking at individual commit messages for any information, you know? Gotcha. Do you have any favorite coding books?

Yeah, I mean, refactoring Martin Fowler's book is like kind of was a Bible for me at one point. And I guess another there's like making your users badass or whatever. That book was pretty impactful for me. Yeah, from a maintenance perspective, I read that book in that I still think about that a lot of like making my users awesome by making them really good at the tool that I'm giving to them, not just giving them the tool.

Making them feel like they're wizards so that they go and they go like this thing is the best I'm awesome at it. Like you should learn it. So Yeah, that's really good and Sandy Metz 99 bottles was really impactful for me at one point a clean code was impacted You know, there were things all along the journey that were really impactful, but I don't know I don't reference a lot of books anymore. I've given away most of them except for refactoring and like That's it.

Yeah. What are you doing now to keep improving? a lot of it is like a What's that, uh, can't Albert Hubbard and like Thoreau and the transcendentalists that were like very extreme, like, like in, in that the truth is within you and like, find your own way and, and whatever they're like, things like that have been kind of my journey as of late is like writing my own story and finding my own best ways to do things within myself.

It's a weird way of thinking about it, but it's, I've been sort of drawing in to create. in original ways on my own. So I'm not referencing a ton of stuff these days, but improving my craft, I guess. I don't know. I probably should do more of it, but a lot of it's just internal progress, I guess. Yeah. Do you have any scripts or shell aliases that you use a lot that you find valuable? Yeah. Nah, I got from Jeffrey. It's like, get hard reset, you know, I use that all the time.

Okay. To just scratch everything that's not committed. That's a big one. I use a lot. Um, nah, I have one called PR that just like checks out a pull request locally so that I can run the tests and work on it. Um, yeah, that's really valuable. And I'm trying to think there's probably a bunch. I mean, I have, Oh, like SIM linking a local repo in our package manager.

So whatever, I mean, this is pretty esoteric stuff, but like doing like if I maintain a project, so I want to be able to use it inside of other apps, like locally, but not get the one from like NPM kind of. So having commands to just easily like sim link those dependencies to my local versions that I can develop on them and then test them in apps locally. Like that's an annoying thing that I put into a bash alias, but yeah, I probably have like 15 bash, bash aliases.

I keep it pretty simple, but that's, that's the short answer. Yeah. Are those, are your files public? Uh, Old ones are, yeah. Like I did this at one point. I don't know how much I've changed since then, but I think I put up like a bash profile at one point. And now it's like a ZSHRC file, but yeah, there's not a ton going on in there. There's just a few helpful things, yeah.

Gotcha. Anything else in the core beliefs or values about coding? Something that I've kind of come to is, I say this is like the only two things I care about in programming is, is like keeping methods small, keeping functions and methods short, small is probably the most valuable thing I think for any programmer to improve code quality. And then the other one is I call it the single file principle.

It's basically like, if you can keep everything, I don't really care about like, uh, like co -location of like concerns and all, you know, all these like kind of big things, separation of concerns, separation, you know, optimizing for this and that. For me, it's pretty much all about like, can I put everything related to this one thing in one file? And if I can't, can I put it in one folder? And so like LiveWare is code -based, every feature has a folder and there's patterns in those folders.

So it's like the tests are right in those folders too. So it's very, it's like as co -located as you can make your code make it, which is often hard because things that are co -located are separate and sometimes they need to interact with each other. And that. So I use like an event system in LiveWire and that introduced a little bit of indirection. But anyway, two big programming philosophies are the single file principle or just like single folder, whatever, keep it in one file.

So when you need to go change that thing, you just go, oh, I go to that file and the change lives in here somewhere, you know, or if I want to rewrite it, just rewrite that one file and then keeping methods short. It's like the two big things. Yeah. Yeah. So if you, if you're using the single file or single folder thing, let's say you like, you like, you decide you want to delete a feature. You're like, actually, this was a bad idea. Yeah. Delete that folder. almost nothing else changes, gone.

That's everything. So LiveWire and Alpine, every single directive and pretty much every feature, you can comment out the one line that includes it, like that references that flake in JavaScript. It's like import this file. You can pretty much just comment out any of the APIs and everything else still works. So I separate the code bases into the core machinery that can't be changed and then all the features. And I try to really make, yeah, so that. make it as removable as possible.

But that is a goal and I can do that. I've achieved that with both of the rewrites. Those were the big motivations. Yeah. Why are short methods good?

Short methods are good. I mean, they're good for readability, but I think they ultimately they're really great for readability, but I think they just result in better architectures because you identify points of reusability and, and like extraction so much better than when everything is is like in a pile. Yeah, I don't know. It's just one of those things that to me feels like you can turn your bad code into good code simply by making a bunch of small methods.

Like it almost is universally true for me. I don't know.

How do you start trying to understand a piece of code you haven't seen before? First, I pull it down and like I have to touch it. I can't just like read it on GitHub. I could do that a little bit, but it's. annoying for me to pull stuff down, but I know it's the secret to success. Like I have to pull the thing down because then I'm in the context and then I can touch it. So if I can open the file and look at it and especially interact with it, that's really good. Running the tests is good.

I use step debugger in the front end. I use like Chrome step debugger a lot, but, but yeah, I, I guess it's just like, it's really bouncing around to different modes of, of, um, of interaction until one of them gives me the understanding I'm looking for. It's like, I start with just scanning out. I didn't do it. Pull it down, run the test, start with that. You know, I didn't do it. You know, it's like sort of dig into the different depths until one of them sticks.

Yeah. Got it. You recently rewrote a large project and it seems like it went well. It seems like you achieved your goals and you're happy with that. What is your, what is your take on rewrites now and your advice for other people considering them? If you're your own boss and you can afford it. and it'll make you happy and happiness is important to your business. That's all the things that were true for me. I need to love the code base I'm working in. So I just decided, well, screw it.

I'm just going to do it. Um, but for most applications and businesses and whatnot, it doesn't make a ton of sense. Um, pretty often. And so I'd like, would probably caution people, tell people to like do everything, but, or rewrite. And then like, that's like the very last thing. you should do. And if you do do it, like do a base camp style new version of your product that you can market so that business is amped about the rewrite too. And it's not just like a giant waste of resources to them.

Yeah. That's good. Awesome.

Anything we didn't talk about that you want to cover? You feel passionate about things. So, I mean, I'm pretty passionate about everything so we could be here all day. I think we covered, we covered some ground and, and had some good chats. Yeah, we did. I'm really glad you came on. This is, this is great. Nice. Yeah, thanks for having me, Ben. I agree. It a pleasure. Is there anywhere you want to send people? How do we support you as a developer and human?

Twitter is where I hang out, so follow me on Twitter. Most important thing. I sell screencasts for stuff I make, and if you use the stuff I make, buying the screencasts is the best thing you could do for me, and I appreciate that. Cool. Awesome. Well, thanks for coming on. Thanks for having me, Ben. See you. See you.