Taylor Otwell, Creator of Laravel

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.