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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.