So I want to start with something non
-controversial and ask you tabs or spaces.

Oh, we use spaces in Laravel, but I think
there's merit to the tabs argument, if I'm

being honest.

Yeah.

You know, I have to give it credit.

Yeah, you could be convinced.

Yeah, so when I originally wrote Laravel,
it actually was tabs.

OK.

And, you know, so of course, I guess the
merit I'm referring to is people can kind

of configure what that looks like.

on their machine.

At some point in the PHP ecosystem, there
was sort of a coding standard that was

adopted across the whole ecosystem.

And it gained a ton of traction across
tons of projects.

And it dictated that you use spaces.

And that's when we moved to spaces, sort
of.

They forced our hand, in a sense.

But we were originally tabs.

Interesting.

OK.

And do you miss that?

Did you take advantage of the fact that
you could change what a tab meant?

I actually didn't on my own machine.

But I know that's just one of the things
that people refer to as an advantage of

tabs.

Gotcha.

Yeah, that's fair.

I wonder if people do that at all, or if
that's just an argument that justifies

after the fact some other preference.

Yeah, I'm not sure.

You come from, I think, a Rails
background.

That's a spaces environment, right?

Yeah, I think Ruby's all spaces.

I don't think there's any traction on the
tabs in Ruby land.

But it's that whole like, I do this, but I
respect the other side's argument is how I

feel a little bit about like Vim and
Emacs, for example.

Like I'm a Vim guy, but I got to admit,
Emacs is a great editor.

It's being able to like code your, like
configure your editor and Lisp is badass.

The fact that it's just like a running
Lisp instance is just super cool.

So I respect both sides.

Yeah, and I've never used Emacs.

I've only used Vim.

Vim's not my primary editor, but I'm...

proficient enough to like make changes in
a program if I need to using Vim, if I'm

in like a production server or something.

But yeah, all of my college professors
were big Vim users.

And that's all we used in all of our
classes actually.

So I got a lot of Vim experience then.

Nice.

I feel like people should try it.

Like I think it's worth knowing to
experience like, hey, modal editing is a

thing.

It's kind of a different paradigm than
everybody else.

basically everybody else uses.

I think that's just like worth exposing
yourself to even if it doesn't really

click for you.

Yeah, I agree.

So what is your daily driver now?

What do you what do you code in?

I am in die hard, die hard, loyal to
sublime text still.

Oh, OK.

Which I don't you know, I don't know what
the current state of sublime text is as

far as user adoption, but.

Before like VS code and I mean before VS
code there was like the atom editor from

github I don't know if you remember that
but sure and they kind of VS code came out

and it feels like VS code grabbed a lot of
Sublime text old market share, but sublime

text is just so dang fast.

It's so light feeling You can just fly
around files.

It's so much faster than VS code which I
think even VS code users admit I think the

The downside to Sublime is its package
ecosystem is not nearly as vast as VS

codes is at this point, probably because
you can write things in JavaScript and VS

code, whereas in Sublime Text, you're
writing Python, which maybe is not as

widely known, I guess.

So yeah.

When you say fast, is that like fast to
start, fast to open files?

Like what is fast?

Yeah, both.

Everything.

Okay.

Yeah, fast to start, fast to open files.

just navigating around files even somehow
feels faster within a single file, you

know.

Interesting.

Okay.

Yeah, it's just a pretty sweet little
editor.

And I think it's cool because it's one of
those projects that's written by kind of

one person.

It reminds me of like a roller coaster
tycoon or like Stardew Valley, you know,

or some of these pretty ambitious
projects.

Those are both games, but they were
written by a single developer all the way

through.

and sort of achieved worldwide fame and
success, which is, I think, pretty cool.

And Sublime Text is like that.

Was there going to be some big Sublime
Text rewrite that never happened?

Or am I remembering that right?

There was a long break kind of between
Sublime Text three and four.

And the Sublime Text author, I think his
name is John Skinner, he'll just disappear

for months, you know, and then he'll pop
back out with a huge update.

And there's not a lot of updates in the
meantime, you know of like hey, yep still

working on it.

Here's what I'm doing It's just radio
silence and then boom sublime text 4 and

then that kind of a year like I kind of
get that You know, it's just like I'll be

in my coding cave.

I'm not gonna talk to you Yeah, I like to
imagine he lives on like sort of a

Caribbean Island and just resurfaces every
now and then to Ship an update.

Yeah, he doesn't have any internet.

He just had like every few months takes a
boat to the mainland like upload something

Yeah, exactly.

I thought what are you using?

I mean, so most of it, I'm still Vim.

Like my VimRC is like almost 20 years old
at this point.

Yeah, but yeah, it's just it works for me.

Yeah, I think once you're that invested in
Vim, you know, it's probably hard to

totally.

Yeah, I mean, it's like super, super
sanded down to like be like the way I want

it.

You know, it's like it's really highly
configured and I have a lot of muscle

memory built up and I still feel like.

at least for most of the editing I'm
doing, it feels like the fastest for me to

get code out and to make changes into
files and things like that.

I think there are times where I'm a little
jealous of certain things, like, oh, are

there better debugging tools or
refactoring tools or slightly higher level

things that maybe I'm interested in?

I want to check out Zedd.

That seems pretty cool as an editor.

I don't know if you play with that.

I haven't.

And I actually don't use a lot of those
kind of higher level tools either.

Are you a shortcuts guy?

Are you kind of like arrow keys, just like
doing an old -fashioned way?

Yeah, I use a lot of shortcuts for sure.

I don't use a lot of like high -level
debugging tools like that, you know, like

kind of IDE style debugging tools.

I don't really get into that.

I think because a lot of what I do is
program for the web, and I've actually

found that like early in my career, I
wrote .NET desktop applications.

where the application starts up and it's
sort of like this long -lived process,

right, that has sort of state that is
maintained over hours potentially and

variables and things.

And I find that when I'm writing web
software, you know, any given web request

exists for an order of milliseconds.

And the path through the application is
generally easy to follow from beginning to

end as far as what is happening.

And I just don't feel like it really
requires like...

a step debugger to step through those
kinds of situations very often.

Whereas when I was writing desktop
applications, I used the step debugger and

all of those tools in Visual Studio every
single day because there was this

complicated state in the desktop
application and you kind of need to step

through it or even reverse and see what's
happening when users click certain

buttons.

But I just haven't had that experience on
the web as I haven't found myself reaching

for that.

Yeah, interesting.

It was a trip going from desktop to web.

Yeah, I mean, super different.

But I like writing for the web.

And when I'm referring to the web, I'm
primarily referring to server -side web.

So I'm sure if you're writing heavy client
-side applications, I think those bear

actually more resemblance to desktop
application development than back -end web

development, where a quest is in and out,
done, over.

So yeah, it was a big change.

But I'm...

I enjoy it, you know?

Yeah, totally.

So switching from editors, do you have
thinking about shell?

Do you have a are you a what shell are you
using?

I use that.

Oh, my.

Is it zish?

Yeah, sure.

Zish.

I think.

Yeah, I use that.

I don't configure it all that heavily
other than how it comes out of the box.

I just have like a pretty simple bash
profile that sets up some aliases and

some.

a couple of functions, but I'm not a, I
don't have a ton of customizations, I

would say to my shell.

Do you make heavy use of the functions and
the aliases you write?

Like what do you use it most frequently?

I have a lot for jumping around different
directories on my system.

I have some for like, Sim linking certain
directories so that I can test Laravel,

the framework against like the application
skeleton without kind of involving a

package manager.

I have some related to like SSH -ing into
different things, but I mean nothing too

crazy, pretty basic stuff, I would say.

And then your Sublime Text, similar deal,
not super configured?

No, I have a few packages.

I mean, I kind of like that.

I feel like it's kind of like even on my
iPhone, I tend to try to use like the

native apps, you know?

I try to use notes, try to use music.

So I think that carries over into like my
dev stack where I try not to actually get

into this sort of crazy customization
because I feel like when I start up a new

machine, I just kind of like not having to
do a bazillion different things to get my

sort of like environment configured.

It's just a lot to wrap my head around.

So I like to keep things as simple as
possible in general.

I bet I only have like seven or eight
extensions installed on Sublime Text.

You know, it's pretty simple.

And on the dot, I do have...

basic dot files, but again, nothing crazy,
you know?

Okay.

Nothing super nuts.

No.

Not even a dot file big enough to put in a
GitHub repo.

It doesn't even feel worth doing that.

Yeah, interesting.

And so it seems like maybe that's kind of
a philosophy of yours in some sense.

Yeah, I think, I mean, I'm a minimalist in
general, you know?

I was definitely even more of a minimalist
before, like I got married and had kids.

But still a minimalist, I would say.

And I think that carries over outside of
my personal life.

It definitely carries over into my code
life, into the way I write code, the way I

set up my environment, everything.

And I think it carries into Laravel as
well.

I think I've tried to maintain a sort of
minimalist philosophy as I write Laravel

as well.

Totally.

I watched that documentary that...

somebody made if about Laravel recently
and Yeah, I heard the word minimal a lot

of times that seemed to be like a really
core thing that you cared about Yeah,

yeah, we tried to avoid obviously
complexity at all costs I mean, I think

every programmer would say they like to
try to avoid complexity But yeah, we

definitely I At least try to make that a
priority for sure.

Yeah, so what was how do you given that
everyone wants it?

But I would say minimalism is actually
probably in sort of short supply.

Like, what are you doing that actually
works there?

I mean, just kind of getting into the
nitty gritty of like how I like to write

code.

But great.

I try to keep the code like to me, good
code is just code that is easy to change

and doesn't have a lot of like sort of
like apparatus around it or like.

You know, it's not like this big ornate
cathedral that feels extremely

meticulously designed to be this perfect
creation that will withstand all business

use cases without, without, you know, it
will be able to absorb any use case we

need because it's so flexible and so well
thought out.

And I actually gave a talk a few years ago
where I sort of parroted a quote by, oh,

it's a lady.

I'll have to look up her name after the
podcast and put in the show notes.

But she said, you want your code to be
like Kenny from South Park and not like T

1000 from Terminator.

Disposable, easy to change, you know,
because as much as you can try to like

plan ahead for so many different business
use cases, it just never pans out.

It seems like and that's actually what
leads to a lot of complexity.

I think in code is trying to anticipate
all of these future scenarios.

Whereas if you just keep the

Write like the minimal amount of code you
need now.

And I think there is some balancing to
this.

Like you can't just be sloppy or, you
know, do something totally, you know,

that's just going to cause you a lot of
problems later, be significant tech debt,

but try to write the minimal amount of
code to get the job done well, let's say,

and go from there.

You know, don't try to anticipate every
single business case you might have in the

future on your product and code around
that.

It seems like it could be that like having
an opinion enables minimalism.

Like if you decide like this is how we're
going to do cues in Laravel and like this

is going to be a small API.

Like this is how we do it.

And we're not going to support a bunch of
other things.

And that lets you have a small surface
area and like keep things minimal.

Does that sound right to you?

I think so.

Yeah.

I mean, yes, agree.

If you have opinions, you can keep things
much simpler for sure.

And I think.

Laravel is an opinionated framework in the
sense that it's born out of the Rails

lineage of sort of inspired frameworks,
which Rails being an opinionated framework

written by a pretty opinionated developer.

We definitely follow in those footsteps,
and it makes our life easier to an extent.

So we try to keep things like, as far as
Laravel goes, keep things extendable and

flexible where people can write sort of
third -party packages to...

hook into maybe some interfaces we've
written or contracts we've written in our

queue system.

Like, hey, as long as your queue system
does like a push, a pop, or whatever, you

know, queues do, you can just write your
own driver and support your own queue.

So we try to do that and it helps us keep
the core pretty minimal.

Yeah.

Do you value backwards compatibility a
lot?

Like, do you try really hard to maintain
that or is that like a thing you're

willing to sacrifice for cleanliness?

So...

As Laravel has gotten older, and I
released Laravel in 2011, I value

backwards compatibility more so, the
longer that Laravel is around.

When Laravel was very young, like in 2011,
we made breaking changes all the time,

because there weren't that many users.

Most of them were early adopters that were
sort of used to living on the cutting

edge, and were perfectly willing to have
breaking changes in the name of like

progress and fixing things that kind of
weren't panning out in the framework.

And we were sort of still feeling our way
through.

what we wanted the framework to be like
and what we wanted its personality to be.

Now though, 12 years later with so many
businesses and so many developers using

Laravel, I do feel a greater obligation to
maintain backwards compatibility, mainly

because I know how much it sucks to update
dependencies that are breaking things all

the time.

So we definitely value that.

We do releases once a year and there are
usually some minor breaking changes and I

sort of...

think about it in time.

So in our documentation, we list like
estimated upgrade time.

And I try to keep that like 15 minutes,
you know?

So there's a few breaking changes, but
it's not hours of work or days of work.

And try to try to do things that we can
automate as well.

Yeah.

So does that do you find?

So that basically requires you to get it
kind of right in the first place or?

to have some sort of like compatibility
layer that you insert for people that lets

them not have to change if they don't want
to.

So do you feel like you're...

That sounds right.

So are you investing a ton of effort in
trying to get the initial API correct?

Does that sound like you?

Yeah, I would say so.

I mean, we're definitely very hesitant to
take on new APIs because once we do, you

know, we're committed to that API.

So I definitely think those through a lot
before we adopt them.

And yes, we do try to, like say an API
doesn't pan out or it just kind of like

doesn't feel right.

We do try to develop a new API while
keeping the old one.

So like this, say, I mean, let's just keep
it really simple and say like, I hate this

method name that we named this method.

Like we could obviously just leave the old
method in there.

We'll make a new method.

We'll have the old method just call the
new method and everything sort of works.

We do that actually fairly often if we
want to.

Fix things but not break things.

Nice.

Yeah, we should turn off your automated
reaction things.

I don't if you just saw that.

Yeah, what was that?

This is a new Mac OS feature they turned
on by default.

I think if you click the green camera in
the menu bar, there'll be a little video

thing somewhere.

I see that, reactions.

Oh, I turned it off.

Okay.

You do it per app, by the way, so get used
to doing that.

Wow.

Which is a wild decision.

Yeah, so then...

Yeah, I feel like the I heard interesting
things about like how stripe maintains

their their API or there's all of these
transformations They've written going

basically back to the beginning of time
where it's like you can just be on any

version and they will translate it for you
to get to you where you need to go and

that's just like that that commitment to
To not making programmers go back and

change stuff.

I feel like it's kind of an
underappreciated Bit of work that keeps

your thing popular and appreciated and
loved

Yeah, and one thing I've talked about
actually with with Adam Wathen on this

topic is I don't like people to go
shopping on the framework.

Like if I make a bunch of breaking changes
And I think you can kind of see this Maybe

with like view 2 to view 3 I don't want to
put like view and to negative of spotlight

But when you make a lot of breaking
changes and people sort of have to almost

rewrite it feels like if I'm rewriting

Now there's sort of like a question in my
mind of what should I rewrite it in?

And it's not necessarily going to be the
same thing.

And programmers love a new thing.

They're excited to try the new whatever.

So they'll take that They would love
nothing more than to rewrite the whole app

in an entirely new stack.

Not just rewrite, but rewrite in a new
place.

Yeah, with a new thing.

Absolutely.

So I try not to sort of instigate that
mentality in developers.

Because if we have to rewrite,

Why not rewrite in React or Zvelt or in
Laravel's case, why not rewrite in, you

know, I don't know, Rails or Django or
Next .js or whatever it is.

Yeah.

So is there anything besides trying to get
the initial API right and trying to like

not just like be conscious of breaking
changes that helps you keep avoid that

fate?

A lot of the stuff we do, I would prefer
it to be born out of real world needs.

So like surprisingly, when people
contribute to a framework, they will

contribute things that they actually have
never needed in the real world.

And I think when you do that, that's when
you run kind of the biggest risk of not

getting the API right, right?

Cause it's not really born out of any
application need or any business need that

you actually had in the real world.

And I think that's one thing that benefits
Rails and benefits Laravel quite a bit is

that both of the frameworks,

are sort of extracted out of real world
stuff, whether it be Laravel's queue

system or authorization system.

And like, you know, I saw Rails just came
out with a new solid queue that's sort of

born out of their queue experiments and
sort of database backed queues and also

their new solid cache package.

I think that helps you get the API right,
you know, because you know that the use

case is valid, that the methods make
sense.

So I'm always very hesitant and I've
actually closed PRs on the Laravel

framework that I could tell were sort of
built in a vacuum and they weren't

connected with any sort of real
development need.

They're just sort of cool to have.

I think that's risky.

Is there a smell that you noticed that
those have?

Yes.

So I see them come in, like we'll get,
let's say we get one PR that adds a

feature and it gets merged.

someone will see that it gets merged and
then open a very related PR to add maybe

like a complimentary method or something
that I know for sure they have not had the

need for yet.

They only saw the first PR get merged.

And so they're like, oh, well, it would be
cool actually if we had this too.

And I almost always close those.

Interesting.

I can tell.

I can tell where they're coming from.

I assume there's probably a little bit of
a sense of cache from getting a PR merged

into the framework.

Like do you?

I picture myself as a young developer
seeing that, like, ooh, we added first,

second, and third.

Maybe if I make a PR for fourth, that'll
get in there.

Exactly.

And then I get my name on the contributors
list.

Yeah.

And I get it.

People do get excited about contributing
to big open source projects.

But yeah, that's exactly the kind of PR
I'm referring to.

Gotcha.

Yeah, nice.

I've heard that your comments are a little
bit infamous.

You have a very specific comment style.

I would love for you to opine about
comments.

Yeah, so all of the comments in Laravel
are three lines long and each line is

three characters less than the line before
it and I don't know I honestly don't

remember how or when that started but
eventually it became Kind of a thing and

it felt like I was so invested in it.

I might as well keep going And make every
comment that way from now on

There's actually a pretty funny like stack
exchange post from me.

This is pre Laravel actually I was still a
dotnet developer asking like is it dumb to

care about these sort of aesthetic things
in a code base And most of the answers

were like yeah There actually is better
better things that you could be spending

your time on probably But I don't know it
is sort of like is a small thing that

makes me happy when I go through the code
base and like all the comments are the

Same even though it has no real value but
yeah, it's kind of become just like a

a shtick at this point and we just keep it
up in the code base.

Yeah.

It seems like you have a strong, like,
aesthetic sense or like a sense of craft

and like you care about small details and
things.

Do you feel like that was like, was that a
learned thing?

Like, are people born with that?

Did you pick it up by seeing other people
do it or something?

Like, where did that come from?

Probably a little bit of both.

I definitely picked it up some from seeing
other people do it and not seeing it just

necessarily in programming alone.

Like for example, I used to mow grass when
I was in college and back then my grandpa

would help me actually sometimes.

And after every time we mowed, he would
make me lift the mower up on this like

lift and spray off the whole underside of
the mower before we put it back in the

garage.

So it didn't get any, a single blade of
grass in the garage basically.

And he just sort of had this personality
in general of like, you know, like,

finish the backside of the piece of
furniture, you know, make everything look

good, even if no one's going to see it.

That kind of personality, I guess.

And I did pick up on that and sort of
carry it over into programming in some

sense where if I knew, for example, that
like there was some nasty file took deep

into Laravel that was just gross.

I just like couldn't sleep well at night.

Like I wouldn't want to even use Laravel
at all, you know, because I would know

that deep down in there, it's sort of
like.

Farce and there's this ugly code and I
can't well, how can I build my business on

this piece of trash, you know?

So I think it is a little bit OCD to an
extent in a legitimate sense, but that's

just sort of like It's been a it's been a
good thing for Laravel I guess in the

sense that it's made me really thorough in
terms of the quality of the tool I feel

like this I feel like I I can empathize
with some of this where I think I think

people that create stuff

to create things tend to have this like,
it has to be amazing and like it's trash

otherwise.

And like you just want it to be so perfect
and so good.

And I feel like all of us are just kind of
like, man, it sucks today, but eventually

I'm gonna make it like so good.

Once I get these last few things, it's
just this constant sense of not quite good

enough.

And it can be hard to live with, I think,
because it's not, it doesn't feel, yeah.

Yeah, it can be hard to live that life
sometimes.

when you're focused on the negatives and
like needle things to want all the things

to be perfect.

But I do think it leads to really great
software.

Yeah, I agree.

All right.

Do you do you have a coding hill that you
would die on?

Oh, gosh.

What's an example of a hill?

Like, do you have a hill?

Like all instance methods should be like
one line, Max, maybe three lines if you

are an emergency kind of thing.

Um.

Wouldn't say I have a hill that specific
No, I can't even honestly think of like a

certain hill I would necessarily die on in
that sense I Mean I I think in general We

have a few guidelines that I try to follow
I like to keep methods fairly short I

would say but not necessarily a specific
number of lines of code one thing We also

try to avoid really small thing, but I
think it helps

in terms of code readability is we never
make callers of like a function pass

Boolean flags to change the behavior of
the function.

So basically you don't want to end up with
a function that's like some method name,

open parentheses, false, true, false,
true, true, false, you know?

And it's just like imperceptible from the
outside what any of that means.

So in all of Laravel, you never would have
to pass a Boolean flag to any method.

So the way we work around that, you know,
is usually having another method.

Like, let's say we have a method that
generates a URL.

We have a function called URL.

And maybe sometimes people might be
tempted to put like a Boolean flag if they

want the URL to start with HTTPS instead
of just HTTP, like a secure flag, let's

say.

We would just make like a secure URL
function that requires you not to pass the

Boolean flag.

So we do that throughout Laravel.

But I don't know.

None of them are like...

That's actually probably one of the
strictest rules we have.

I would definitely die on that hill.

Before I would put a Boolean flag in the
Laravel docks, I would rather delete the

project, I feel like.

Nice.

By the way, I think that's a really good
anti -pattern to know about.

The term to Google is control couple.

I remember reading about this...

quite a bit.

It's it's sort of like you're effectively
leaking into all the colors of this

method, the conditional that's in the
method.

You know, it's like, everybody knows I got
a conditional and it looks like this.

And it's like, that's not, you're not
supposed to know that.

That's a secret.

Yeah.

That's true.

Yeah.

Call, call the other.

Yeah.

So, so split them into different methods
and call, call what you actually want is I

think a better approach.

By the way, I just like Google control
couple just to remind myself.

And the first result is the anti pattern
that I was speaking about.

The second one is, are you in a
relationship with a controlling partner?

Nine signs.

It's bad.

And it's bad in a lot of contexts.

Yeah.

So no.

So no control couples allowed in there at
all.

No.

And you know, one thing, if I can bring up
something, I think one thing I find

interesting about clean code.

is how clean code is seen across different
ecosystems.

And you may have some insight into this
because we kind of come from different

ecosystems in a sense.

Yeah.

But like when you say clean code, do you
mean the book or the concept?

I mean, a little bit of both, actually.

So like in the PHP and dot net ecosystems,
clean code as in the book and clean code

as in like the Uncle Bob sense of clean
code, if people have heard of this person

is like super popular.

So.

tons of like tons of directories and
architecture and interfaces around

separating concerns really, you know, a
lot of ceremony around getting all of the

application architecture just right with
all of these boundary layers and how they

interact and things like this.

And it's just like a super popular thing
and in .NET.

And I think that's leaked over into PHP
and maybe Java as well, let's say.

Whereas like in JavaScript and

Even in Ruby, to an extent, I feel like
it's not the same emphasis.

And it's like not the same influence of
the same people has bled into those

ecosystems.

And it creates sort of different
definitions of what clean code means.

Whereas like in PHP and .NET and Java, I
feel like clean code means your code is

separated into different files in the
right way.

And they have the right interfaces.

And...

You know, they're typed the right way.

Whereas like in Ruby, or at least in
Rails, it feels like clean code is sort of

code that reads like prose or is, you
know, like more English, plain English or

something.

And it's not the focus is not so much on
like architectural purity as it is in like

ease, how easy it is to read and, you
know, kind of the syntactic sugar of the

code.

Yes.

Which I find interesting.

Yeah, that is interesting.

The word that popped into my head, it was
like idiomatic.

Yeah.

It feels like languages will have
different idiomatic ways of writing code

that is kind of distilled from the culture
of the people who are writing it in a way.

Like you could certainly write, like the
thing when I think of clean code, I think

of the solid principles, like the capital,
all caps.

And like, I would say...

I bet DHH would be like, yeah, that's not
that interesting.

I'm interested in how the file looks.

I'm a software writer, and I want to write
it like an essay a little bit, and it

should look a certain way and feel a
certain way.

And this thing you're telling me about the
Liskov substitution principle about how

this class should be able to stand up for
that class, I don't really give a shit

about that.

That's not that interesting to me in this
hypothetical world where I'm refactoring

in this certain way and using a class
hierarchy.

And so I think it's.

But I think that resonates that sort of
approach resonates more and maybe like

other o languages that are just just with
different people in them Yeah, and I think

one one place I was going with that is the
salt like take for example the solid

principles of clean code Yeah, which I
think in general are kind of helpful Some

of them are more helpful than others.

I think But I think it can lead to this
sort of

idea that clean code can be boiled down
into like a checklist.

And if I do these things in my code, the
code is going to be good and easy to

maintain.

And it's sort of, I feel like it's almost
a little bit of ironically, a lazy way to

code in the sense that you're, you can
not, you can sort of check out your real

critical thinking and just say like, as
long as I'm doing solid, the code is good

in this very robotic, you know, fashion.

Yeah.

And I think it's sort of chasing a silver
bullet to clean code that maybe isn't as

clear cut as you would like it to be.

And I've seen this a lot when working with
especially younger developers who are just

getting into code and they're kind of
taking code serious, which is good, but

they sort of latch on to sort of these
checklists that they can follow to achieve

clean code.

And I think it lacks a little bit of the
intuition that is needed.

when writing clean code, a little bit of
just like the experience of coding for

years and kind of knowing, hey, typically
when I've written code in this way, it's

gone poorly.

You know, like when I've written code in
this way, it's gone well.

And that's just born out of years of
programming, I think.

It can't be summarized into a checklist.

Yeah, I feel like that's also kind of what
makes coding so hard is like, hey, did I

pick a good architecture for this?

You can't even know that today or this
year.

Yeah, you know, you'll you'll know that
maybe like three years from now when like

you're trying to make these complicated
changes or like new people are coming up

onto the system and trying to understand
how it works and reason about it or it's

it like takes a long time to even get good
feedback from your decisions.

Yeah, it really does.

Yeah, unfortunately, you're making a piece
of a pottery.

You can be like, all right, this is a good
bowl of water.

It's you know, it's watertight.

It didn't fall apart.

And like, yeah, it looks nice.

I did it, you know.

Yeah, but like does did the queue system
turn out well?

Do we pick the right API for this or like
are we gonna regret parts of this later

that we couldn't anticipate?

That's that all comes much further down
the road.

Yeah.

Yep.

How do you feel about testing?

I like testing.

We write.

I write a lot of tests.

Laravel has thousands and thousands of
tests.

I don't do a lot of tests first.

I would say I do a lot of tests during
kind of tests after.

But yeah, huge fan of testing in general
would not be able to ship software

confidently without tests.

I don't think Definitely think it's you
know something that every developer should

learn But yeah have no strong opinion in
terms of like test first or test driven

development, I would say Gotcha went so if
you're what does it look like when you

are?

Tackling a kind of law a large new Project
of some kind you like are you a

prototyper?

Like, do you...

What does this look like?

When do the tests show up?

Okay, well, like, let's take, for example,
like a new package or a new feature in

Laravel.

A lot of what I do first is just go into a
blank text file and start writing kind of

my dream API for what this is going to
look like from the outside in.

So basically, kind of like what the
documentation is going to look like.

What are the examples that are going to be
in the documentation?

And sometimes I even call this, you know,
like documentation -driven development.

I think that helps iron out a lot of the
the warts and like problems in your idea

if you have to write out sort of how
people will use it and I also kind of

carry that over into Say I'm building like
a full app.

I have a whole new product idea I'll build
a UI first And it doesn't have to be like

pretty, you know, I'll just use basic
Let's say tailwind classes to sort of get

some basic shape in place, but I'm
definitely not like, you know

tweaking every drop shadow and every
gradient.

But just to make sure that the user
perspective is correct first.

And I didn't used to be this way.

When I first started programming, I would
do like back and I'm going to build this

whole API first that has no front end.

It's front end agnostic.

And that sounded like really appealing for
some reason to my developer brain.

But I was bitten by that sort of several
times where I would build this big API

that was front end agnostic.

And when I went to write the front end,

there was all these awkward things I
needed to do that the API didn't

accommodate for.

So now I start from the outside and work
my way in both if I'm doing an application

or I'm writing something that's just
purely a Laravel feature, like a package

for Laravel that doesn't have a UI at all.

In that case, I would start with a
documentation level, basically.

Gotcha.

And do you like to have like...

Will you spin up a new Laravel app to try
to use this thing?

Like you make it like a toy example kind
of?

Yes.

Exactly.

I do that every day almost.

I actually just have a blank Laravel app,
you know, ready to go to kind of like a

sketch pad that I can just write, drop an
idea into.

Got it.

And then from that app, you're like
writing calls you wish you had and then

updating the framework to try to support
that.

Yep, exactly.

Nice.

And then once you have it the way you like
it, some of those calls probably become

unit tests on the new functionality.

Yep, then I'll just go back in and fill in
the test and you know ship it out there

pretty much.

Yeah, are you are you?

What was your balance?

Would you say between like kind of lower
level unit tests versus higher level

integration type things?

This is another thing that's changed.

I think over the years Earlier in my
career.

I wrote a lot of low level tests.

They ended up feeling really brittle I
think I think there are certain classes

that like lend themselves well to low
level testing things that are sort of

really like say like you pass in a string,
you get out a string, you pass in an

array, you get out an array.

And they're like these very unit testable
types of classes, like a classic like

calculator class or something like that.

Where I feel like those kinds of things
actually lend themselves well to like low

level testing or even just like test
driven development.

But when I'm building web applications, I
test from like the feature level or like,

I guess you would say the controller level
of like, let's make an actual simulated

HTTP request into this endpoint.

we're actually going to assert that
certain records exist in the database

afterwards.

We're going to assert that a mail was
maybe dispatched to some user or a mail

notification or text message or whatever.

And some of those things might be sort of
like faked.

Like, of course, we might fake like the
actual mail sending.

But in general, the test is very high
level.

I just feel like I get so much more
confidence out of those tests.

And I guess the downside is if something
goes wrong, maybe it's not as granular

what exactly went wrong during the
request.

But in my experience, it's still been very
quick to sort of diagnose what was

happening.

And I just get so much more confidence out
of those tests versus like these very low

level tests that almost start to feel
coupled to the implementation of the code

that they're testing in a way.

And in general, I find that also,

the higher level test helped me achieve
what I consider to be the goal of testing,

which is one, shipping software
confidently that you know works, but then

also two, being able to change the code
without significantly changing the tests.

And I think a lot of people actually get
their tests so coupled to the code because

they are so low level that they're almost
one -to -one in terms of when they change.

And to me, that's like losing one of the
main benefits of even having tests is,

the ability to refactor the code or
improve the code without changing the

tests.

So that's why I kind of prefer, honestly,
high level end -to -end tests.

Gotcha.

Yeah.

I would say my style has moved that way as
well recently.

I was a pretty hardcore TDD practitioner.

So I was like, well, I need a lot of unit
tests to drive the next step in this

process of me writing another method and
changing how that method behaves.

But I had of come to the same conclusion
you did, which is that,

The maintenance burden of tests that are a
bit too low level is really pretty high.

And it just doesn't feel...

I feel like I get way more leverage on the
higher level ones.

Yeah.

And you know, like, I keep bringing up
Adam, but I think Adam Wevin actually has

one of the best testing video courses out
there.

It is a Laravel -based course.

It's a video course with like, I don't
even know how many hours of video.

It's gotta be like 100 hours.

But he does a high -level test, but tests
first.

And I think even if you don't use Laravel
or PHP, it's such an awesome course to

check out because it demonstrates, I
think, how to write tests that aren't

brittle but still write tests first if
that's kind of like what people are

interested in.

I don't know.

I found it super cool.

It actually was very influential, I think,
in my own testing journey in a sense.

Cool.

Nice.

That's test -driven Laravel, I think it's
called.

Yeah.

I remember that that was a beast.

I think I remember talking to him as he
was trying to get like the 80th through

100th video released.

Yeah, yeah, that was a quite a labor.

How often are you looking at like a big
chunk of code that you're trying to

understand?

Does this happen frequently with like
contributions or like picking up a

different library or something?

Is this at least weekly?

I would say I don't know I would go so far
as I daily, but weekly for sure, mainly in

the form of pull request, but also in the
form of code that.

employees here at Laravel have written and
we kind of have a peer review process

where probably other people have looked at
it first and we're kind of getting to the

point as well where I don't scan every
single line of code in our commercial

products.

I'm just gonna be such a bottleneck.

But at the framework level, I actually do
read through every pull request to this

day.

I'm the only one that merges pull requests
into the Laravel framework still.

So I review every single pull request and
of course some of them are pretty

complicated.

And so I would say about once a week I'm
looking at a pretty beefy pull request

that let's say is 20 files changed.

I would consider that kind of like in my
context a pretty big pull request for the

framework and sometimes even more than
that.

How do you do that?

Well, I don't know.

I try to tackle like the hard things
first.

So just in general, not just on this
topic, but if I have something that I'm

trying to tackle, I'll just do the hardest
task first and just get through it.

So I kind of do that with pull requests.

I don't really have any secret other than
just like gritting your teeth and pulling

down the pull request and going through it
kind of file by file.

So first, I'll take like a high level
cursory overview, just like in the GitHub

web interface and kind of get my head
wrapped around.

in general what they're trying to do and
then I'll pull down the pull request

locally go file by file checking them off
on GitHub as I go, you know, making sure

everything looks good renaming variables
refactoring methods if I need to, you

know, things like that.

Interesting.

Okay, so you'll so you'll you're editing
you're making edits here as you go.

Yeah, like maybe pushing to a branch that
is like their changes plus yours kind of

thing and merging that later.

Yep, exactly.

And I will say that like the bigger your
poor request is to Laravel, it has to be

really valuable.

So I'm all about like bang for your buck
poor requests.

So my favorite poor requests are obviously
poor requests that are like two lines

changed, but immense developer value like
added.

Because obviously almost no maintenance
burden, tons of value added for the

hundreds of thousands of people using
Laravel.

Like that's ideal.

The bigger your poor request is,

it has to be really freaking good in terms
of value added because I have to take over

all of the maintenance burden for that
feature going forward.

And it doesn't matter honestly how hard
the person promises that they'll stick

around and maintain the feature.

Just like you have to understand that life
happens, they change careers, maybe

they're in a different language, they're
at a different company and they're not

even using PHP anymore and it's like, hey,
sorry.

I don't remember exactly why we did this,
or I don't even use PHP anymore.

So I just assume that we're maintaining
this forever without any help.

And in that case, the feature has to be
freaking awesome if it's going to be like

20 or 30 files changed in the framework.

Yeah, that makes sense.

Yeah.

Do you care about good commit messages?

Yeah, when we squash things down, yes.

Especially if it's pretty complicated,
what's being added.

I try to add something meaningful in my
own pull requests at least Just to kind of

you know make it easier for people if
they're browsing through and seeing what

changed Mm -hmm And so do you is this
mostly like a description of like a high

-level description of what's what's going
on?

What's part of this this change?

Yeah, pretty much So like we recently
refactored some stuff in Laravel to make

it a little bit slimmer a little bit
easier to onboard

sort of new developers into a little bit
less overwhelming out of the box.

And when I made that change, I actually
wrote a pretty detailed description in the

get commit message of like everything that
changed and why it changed and the

implications of that, because it was a
sort of beefy PR that fundamentally

changed some things in Laravel.

So if the poor request is more, you
there's a lot of kind of moving parts and

a lot of things happening, you know, I'll
write a more detailed message.

If it's a pretty simple change, that's
pretty self -explanatory.

I might not write much of anything.

Right.

Do you draw diagrams or anything as you
work?

Do you keep notes or sketches or anything?

Rarely.

I mean, I can only think of like a handful
of times I might have done that.

There are times I wish I had a whiteboard
next to my desk.

I feel like when I used to have that when
I was like in a cubicle, I used that

actually a lot to sketch out things.

So maybe the fact that I don't sketch out
things is just lack of access to a quick

whiteboard, but...

No, it's not something I really reach for
very often.

I'll more like write, I would say, like a
manifesto of a new feature more than I

would like draw something.

So I might open up Notion, go to a new
document, let's say, you know, new

database feature in Laravel and type up
like a pitch for that feature just to kind

of wrap my head around it and the benefits
and the drawbacks.

I do that more than like drawing diagrams,
I would say.

Gotcha.

Do you feel like there are habits?

that you follow that help you make good
code.

Kent Beck has this great quote, which is,
I think he says something like, I'm an

average programmer with above average
habits.

That's interesting.

Yeah.

I mean, asking a lot of questions as far
as like, why does it have to be this way?

Why does it have to be that way?

You know, challenging assumptions in terms
of what we're building.

Do we actually need this code at all?

I think is a good question to ask.

Totally.

Which is, you know, not probably asked
often enough.

I sort of agree that like I see myself as
a very average developer with, I think my

power in a sense is I have a very low
threshold for like pain, developer pain.

And there are just like certain APIs.

I'm just not willing to stomach.

And I think my threshold is pretty low
compared to other programmers around me

that I see where it's like they're willing
to put up with a little bit more

complexity, a little bit more like
cumbersome APIs and just sort of live with

it and move on with their life.

Whereas in Laravel, I'm just have such a
low threshold for what I'm willing to

tolerate in terms of like cumbersome,
awkward, gross.

unrefined API's are.

And I think that helps a lot keep Laravel
nice and clean and feeling fresh and

enjoyable.

Yeah, I thought that's kind of the secret
of quality is just like caring a little

bit more.

Yeah, I think that just works in almost
everything is like it's not that like I'm

so brilliant programmer or a product
person.

I think it's a little bit more just like
I.

I have low pain tolerance.

Like it's I get more annoyed maybe than
the average person.

Yeah, when things are not awesome.

And so I'm just like, well, can't we just
make it better?

And often the answer is yes.

But you only get to that.

Yes.

If you're like, I find this too annoying.

Like I want you to make it better.

Yeah.

So I've long thought that was sort of one
key to, you know, Laravel success in a

sense.

It's just you.

Yeah.

You not being annoyed.

Yeah.

Being okay with pain.

Yeah.

And I think needing things, you know, I'm
not I don't feel like an exceptionally

gifted computer scientist, you know, I
kind of prefer things to be easy and

digestible.

And, you know, so I tend to try to write
code that way.

I mean, it's probably it's probably better
that you aren't because if you were a

super brilliant programmer, it might be
hard for you to know that you have written

something that is hard to understand or
follow.

Yeah, I agree.

I think I'm an average developer that hits
average developer problems and writes

solutions for the average developer, and
that is a big market.

There's a lot of people there.

Yeah.

Yeah, nice.

So if you think about your...

So maybe you're an average developer, but
let's...

If you think about your programming skill
over time, when was that curve the

steepest?

In terms of when did I improve the most?

Yeah, when were you improving the most and
what were you doing that led to that?

I feel like I made the biggest leap during
my dotnet days when I was working with

some really talented dotnet programmers
that were much smarter than me and had

much more experience than me in building
software.

And I just leveled up like extremely
quickly in that environment, which kind of

sucks because I feel like I'm not in that
environment anymore necessarily.

Yeah.

And I it's just awesome.

If.

early in your career, you can be around a
great team of people that really know what

they're doing.

And not in the sense that like they're,
you know, ivory tower people, but just

they've got a lot of experience building
and maintaining software, and they know

what works, they know what doesn't.

And I just think you can level up so
quickly in that environment.

Yeah, I think if you're a newer programmer
optimizing for the quality of your

teammates is probably the number one thing
like over

product or salary like, oh, I'm super
excited about the app or like I would make

a lot of money.

Okay, fine.

But like, how good are the people on your
team and are they willing to teach you?

That's that's the thing I'll be thinking
about early in my career in particular.

Right?

Yeah.

Did you?

So when these when you were getting better
by working with these more experienced

programmers, what what was the knowledge
transfer like?

Was it happening mostly in code reviews?

Was were you sitting at lunch talking
about this stuff?

Were you pair programming?

It actually was more like in the code in
the code reviews like and I was not a very

good programmer.

I had only been programming for you know,
maybe a year professionally at this time

and obviously making like just you know,
new programmer mistakes or writing things

in a way that maybe I wouldn't write today
and they'd be like, hey, what if we wrote

it like this way?

Or have you thought about like taking this
approach and it would just like click and

be like, oh yeah, that actually is a much
better way to do things.

So it was a lot of that, a lot of just
friendly review and pointers in the code.

And then also looking at how they wrote
code.

Because say I just had a down afternoon
where I didn't really have much to do

because I had wrapped up a project or
whatever.

Then I could just go browse some code and
just see how things worked and see what

people were doing.

Do you ever do that now?

Not really, no.

I don't do that a lot now.

But I did.

definitely do that early in my career just
to kind of like get insight into how

people were tackling different problems.

Yeah, totally.

It's kind of shocking to me how I was
watching in that Laird Mill documentary,

what a big role Ian Lansman played.

I didn't recognize him as kind of like the
daddy that like kind of incubated this

thing and made it happen.

That was really fascinating.

Yeah.

I mean, I think Ian took a pretty big risk
on Laravel, I guess, early days.

I had released Laravel maybe six months
before I got an email from Ian, like, hey,

we build customer support software and we
kind of want to modernize some of our, you

know, PHP code base onto Laravel.

It looks like kind of a cool tool.

Would you want to come work for us and
help us do that?

And Laravel was like not a...

It was not a big thing at all.

Definitely not outside of PHP, but even
within PHP, it was not even in the top,

let's say four or five frameworks that you
might choose to write a new application

in.

So in that sense, it definitely feel like
he was placing a bet on a pretty young

tool.

But what was cool is when I got there, he
actually gave me probably six months to

just work only on Laravel, building out
features that we knew we would need.

Like we knew...

we would need a queue system.

We were handling lots of incoming email,
building a customer support tool.

We needed to really queue a lot of
incoming email for processing later.

We wrote the whole database migration
system.

We improved the ORM a lot.

Tons of stuff that we knew we would need,
I built during those months.

So yeah, I mean, it was a pretty pivotal
moment for the framework.

He's also the one that sort of first
encouraged me to have like a Laricon in

general.

He was like, hey, I think we could do a
conference about this.

about Laravel.

And I was like, man, I don't know.

Like, I don't know if anyone's going to
come to that.

And he was like, you know, even if it's
only like 100 people, we should do it.

It'd be fun.

And that's just kind of how it got
started.

Yeah, that's so cool.

I feel like my takeaway from that was that
it can be so powerful to believe in a

person and a thing and like encourage them
to raise their ambitions a bit.

Yes.

Yeah, agree.

I've done that in the Larval ecosystem
sometimes where I'll see like someone

write something really cool and I'll just
like email them and be like, I just want

to let you know, like this is a pretty
cool thing.

You know, if I can ever be in any
assistance to you, you know, like, let me

know.

Like not any kind of like I'm not looking
for any business deal or anything like

that, but just like if I can like put you
on in any way that helps you, you know,

like, let me know.

Yeah, I think that's really good.

Like, like kind of like watering the seed
a little bit, but it also seems like Ian

watered the seed and also like

told you like this could be bigger.

This can be like a real thing.

This conference can happen.

People could like really love this
framework.

Like it was like raise the ambitions, not
just like support.

I think this is good, but like this can be
more than you think it could.

Yeah, yeah, totally agree.

Because at the time, like when when I was
writing Laravel, the most popular

framework in PHP was a framework called
Symphony and like and also code igniter.

And I was like Laravel will like.

obviously never be his biggest symphony.

Like that's what I was thinking in my
head.

And that was fine.

Like I was just building Laravel for
really for myself, honestly, to build my

own ideas.

But if anyone else used it, that was just
added bonus.

And then once it was his biggest symphony,
it was like, it'll never be as big as

rails, you know, like it'll never reach
that level of like market permeation.

And then eventually sort of basically got
to that point.

So I don't know, just crazy.

But yeah, he did.

kind of seemed to always believe that it
could be much bigger than I did.

Yeah.

So, yeah, I hope people sort of take that
lesson.

I don't think it...

In this case, he gave you a job, so it
literally cost him something.

But I think the raising someone's
ambitions and helping them believe

something could be bigger doesn't usually
directly cost anything, but can have huge

impacts.

Yeah.

So you're one of two people that I talk to
pretty regularly, the one being Adam, who

have...

taken an open source thing and then built
a pretty huge business around it, which is

kind of wild.

And it feels a little bit like the dream.

It's almost like the best sort of freemium
business there is, whereas like the open

source thing is free and then there's paid
things around it.

Yeah.

Any thoughts on like how you pulled that
off?

Because I know you left Ian and you were
like, you're like, all right, I'm going

full time on Laravel.

Did you have a path in front of you when
you did that and knew how you were going

to do it?

When I first wrote Laravel, no, I had no
idea.

And that wasn't even the intention,
honestly.

The goal was to write my own SaaS using
Laravel and start my own business that

way.

And Laravel kind of turned into this meta
business.

But when I first wrote my first commercial
product, which was Laravel Forge, which

was kind of this deployment tool that you
could use to deploy your Laravel apps, I

wrote that and launched it in 2014.

And even in the weeks before it launched,
I was talking to my wife and I was like,

if it just pays our mortgage and our
bills, that'd be awesome.

And we can just have that money for fun
money and whatever.

But within a few weeks, I was actually
making more than I was making at

Userscape.

And soon I was making double what I was
making at Userscape within a couple of

months.

And then it was like, oh boy, this is a
real business at this point.

And that's basically when Ian was like,
look, you can't work here and run your own

full business at this scale.

OK, so we sort of transitioned me out of
userscape at the end of 2014.

But I mean, it was all of it was like a
surprise to me, honestly.

I guess I just underestimated how many
people were going to be interested in that

kind of thing.

And then once that was out, we just kind
of kept building more commercial products

around Laravel and went on to launch, you
know, four or five more things.

Do you ever talk publicly about the
revenue of those things?

I think I have a few times so like a
couple years ago.

I think I had I did a podcast series on my
own podcast of like Building Laravel to

like ten million dollars in sales as like
a solo founder and that was a few years

ago And I mean I think all time Laravel's
an ecosystem has passed like 30 million in

revenue or something like that That's the
commercial products built around open

source.

Yeah, the commercial products.

Yeah and Across all of them.

So we have five forage vapor on voyeur
Nova spark

And all together, I think they've passed
like 30 million lifetime revenue since

2014.

So pretty crazy, honestly, for like an old
source tool.

And we've also done conferences, but
conferences have always been a very

breakeven thing for us.

We've never made any significant money
running events like that.

Yeah.

But it fills the excitement bucket,
though.

Yeah.

That's the only reason it exists is to
just sort of build excitement and goodwill

like in the community.

Yeah.

So I went to the last Lericon, it was
great.

And like the excitement is real.

And like I was talking to some tuple users
there and that like filled me up with just

like that's the in -person interaction
with people that you normally like only

talk to through the internet is like, it's
amazing.

Yeah, I always come away from those events
like super energized, honestly.

And I didn't realize how big, how much I
was missing that during the COVID years.

But when we did our first Lericon since
COVID, which was actually like July of

this year,

I was like, wow, I actually really miss
this a lot.

So I'm glad we got back on that train.

And I'm actually I just signed the
contract for 2024 LaraCon today.

So we'll be we'll be back next year as
well.

Cool.

And so it seems like it sounds like you're
spending a lot of your time focused on

Laravel itself and less on the commercial
products now.

So have you have you freed yourself up
mostly from that?

From a coding perspective, yes.

So what I do is like at the beginning of
each month, I'll write up like a pitch of

all the things I think we should do on the
commercial products and kind of who I

think should work on them.

But honestly, like that, even that is sort
of flexible based on what the employees

are feeling like and what they have an
appetite for.

So I'll write up the high level product
pitches and maybe a few technical details

of like how I think maybe it could work.

But then they're sort of like free to go
implement those things as they see see fit

I mean they know the code base is better
than I do at this point like I actually

wrote every commercial product at Laravel
from start to finish in terms of the 1 .0

version that was initially launched to
customers So I did know the code base is

like top to bottom at one point but over
the years I've of course forgotten them

and now they know more than I do so they
do that and I mainly focus on the open

source stuff and

I mean, on a day -to -day basis, I'm
almost exclusively in our open source code

because I think the framework is sort of
the foundation and centerpiece of the

whole ecosystem.

So I'm really focused on making sure that
stays really well maintained.

And then are the other Laravel core team
members paid as well?

Are they employees of you?

Yeah, so we have 10 employees and they're
all full -time paid employees.

And we actually have two of them that are
really

It's pretty exclusively open source, full
time, salaried, open source people that

help me triage things, help me with the
release process, because we have a lot of

packages these days, and we do weekly
releases, help me with that whole process.

Just make sure things are like running
smoothly.

If there's a really gnarly bug that I
don't have bandwidth to really chase down,

like we have a guy that's just really good
at chasing down hard to find bugs that are

deep into the framework.

So they help with that.

And then the other programmers are
primarily on the commercial products seems

like such a huge advantage if you can make
it so that your Open source project can

have some sort of revenue stream attached
to it That then lets you hire people to

work on the open source project that feeds
the paid thing.

Just like a beautiful flywheel Yeah, I
mean it is a huge huge advantage and I

think there's like

only a few categories of open source
project that actually lend themselves to

this sort of model.

Unfortunately, I think there's so many
important libraries out there that just

never seem to lend themselves to
significant revenue.

But frameworks are definitely one of them
where it feels like you can kind of

leverage this model.

But there are some open source packages
like you have a Excel spreadsheet

manipulator.

package on GitHub.

And it just never seems those kinds of
packages just never seem important as they

are and widely used as they may be.

Never seem to make any significant
revenue, you know, unfortunately through

like donations or whatever.

And people ask me all the time, like, how
did you make open source sustainable?

And I don't feel like I actually made open
source sustainable.

You know, I just built commercial products
around an open source platform.

And to me, that's sort of a little bit of
a different thing than actually making

open source sustainable.

Right.

Right.

It's like open source.

Open source became sort of lead gen for
these paid products that plugged in

nicely.

Yeah.

I don't know very many people at all that
just like maintain open source and make a

couple hundred K a year on GitHub
sponsorships.

That seems like incredibly rare.

Right.

Yeah.

Totally.

Yeah.

Well, if I ever started open source tool,
that will be my goal.

It's something that could get that
flywheel going.

Because man, what?

What a huge advantage to like have all the
incentives aligned.

Like you just like, yeah, I want to hire
more people and pay them to work on this

thing that we happily give away for free
because that generates new customers who

can new potential customers for these paid
products over here that lets us hire more

programmers.

It's just, it's, that's great.

Yeah.

Yeah.

Yeah.

It's been nice.

Cool, man.

Awesome.

Well, thanks for sharing all this
programming wisdom.

That was a great chat.

Yeah, that was a, yeah, it was a fun
conversation.

Covered a lot of ground.

Yeah, we did.

I enjoyed it.

Cool.

Well, thanks.

Thanks.

Thanks for having me.

Yeah, take care.