Caleb Porzio, Creator of AlpineJS and Laravel Livewire

In this conversation, Ben interviews Caleb Porzio, the creator of AlpineJS and Laravel Livewire. The discussion ranges from discussions about life in general to specific testing practices and which notebook Caleb uses.

Links
Tuple.app - The best app for pair programming
AlpineJS
Laravel Livewire
Caleb's VSCode Course

Takeaways

• Apply core truths to life outside of programming.
• Find ways to make difficult tasks easier.
• Change your environment to support your goals.
• Value tests as much as, if not more than, the code itself.
• Keep methods and functions short for better code quality.
• Embrace your strengths and delegate tasks that don't bring you joy.
• Focus on the meaty tasks that excite you.
• Consider rewrites carefully and prioritize other solutions first.
• Pull down unfamiliar code and interact with it to understand it better.
• Start the day with tasks that align with your goals and priorities.

Chapters

• (00:00) - Introduction and Background
• (03:51) - Overview of LiveWire and Alpine
• (12:09) - Caleb’s Programming Style
• (20:09) - Functional vs Object-Oriented Programming
• (25:39) - The Appeal of Functional Programming
• (32:01) - The Challenges of Learning Object-Oriented Programming
• (33:06) - Memory Allocation and Functional Languages
• (36:30) - Starting Complicated Projects
• (40:10) - Writing Blog Posts as Problem-Solving
• (42:30) - Core Beliefs
• (48:21) - Materials
• (49:20) - Getting into the Zone
• (51:14) - The Value of Tests Over Code
• (55:27) - Transitioning to Non-Typical Apps
• (01:03:00) - Radical Practices at Tuple
• (01:05:50) - Managing Pull Requests and Code Reviews
• (01:06:33) - Starting the Day and Prioritizing Tasks
• (01:07:41) - Balancing Maintenance and Long-Term Goals
• (01:09:52) - Finding Motivation for Maintenance Tasks
• (01:10:50) - Embracing Strengths and Delegating Weaknesses
• (01:11:46) - Continuous Improvement and Learning
• (01:14:19) - Favorite Tools and Productivity Hacks
• (01:19:07) - Core Beliefs and Values in Coding
• (01:21:19) - Benefits of Short Methods and Single File Principle
• (01:21:57) - Approaching Unfamiliar Code
• (01:22:51) - The Pros and Cons of Rewrites
• (01:23:46) - Final Thoughts and Passion for Coding

Creators & Guests

Host

Ben Orenstein

Co-founder @tuple.

Guest

Caleb Porzio

Creator of AlpineJS & Laravel Livewire

What is The Tuple Podcast?

Ben Orenstein interviews great programmers about their craft.

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.