Aaron Francis

Learn more →

Transcript

Andrew

00:00:00 – 00:00:18

Alright. Here we go. The inaugural episode of Framework Friends. Welcome, everyone. Hey, Aaron.

Andrew

00:00:18 – 00:00:20

What are we doing here?

Aaron

00:00:20 – 00:00:52

So my name's Aaron, and we are talking about Laravel and Rails. So I guess it was, like, a couple weeks ago or maybe a month ago, we were chatting about some of the stuff we were working on and thought we both think kind of similarly, but we're in entirely separate worlds. I'm in the Laravel world and you're in the Rails world. And we thought this would be, like, kind of a good interplay because we've been friends for so long and we're in such different places, but kind of in the same place, but in different worlds. And so, we thought, Oh, let's record something.

Aaron

00:00:52 – 00:00:54

I mean, is that kind of how you remember it?

Andrew

00:00:55 – 00:01:25

Yep. Absolutely. So I should introduce myself. I'm Andrew, and that was more or less the gist of it. I think we have so many conversations about things and have had over the years, but even, like, when we're collaborating on things or, like, bouncing ideas off of each other, And I can't count the number of times we've had in-depth discussion about something, sometimes really technical, and comparing and contrasting the way things get done in the Laravel ecosystem and the Rails ecosystem.

Andrew

00:01:25 – 00:02:00

And at the end of it, I just I'm left with the feeling, like, I wish we had hit record on that because that was kinda cool. There's another side to it as well. I feel like we have a lot of mutual friends, people that we talk to about this kind of stuff. But amongst our mutual friends, I don't know that there's too many people that would wanna hop on a call, hit record, and talk about stuff at the technical depth, the sort of like, yeah, the framework level. And so I think when that kind of emerged as, hey, we're both interested in this.

Andrew

00:02:00 – 00:02:09

None of our friends necessarily wanna do this with us. Why don't we schedule a time and and start doing this? So, yeah, I think it's I think it's gonna be really fun.

Aaron

00:02:09 – 00:02:40

Yeah. That's interesting that I think you have correctly identified that no one else really wants to talk to us about this kind of stuff. And it's not like it's less how do you do this in Rails versus how do you do this in Laravel, but more, I think, what are some of the philosophies about the frameworks that are the same and that are different? I think this will be very interesting as we go on. What are opportunities to pull stuff from the other ecosystem into your own ecosystem?

Aaron

00:02:40 – 00:02:58

Like, where are there gaps in Laravel that there aren't gaps in rails? And how can we pull over some of that knowledge from Rails into the Laravel ecosystem and vice versa? And so it's, like, at a very high, almost meta level, but also at a very technical low level. So I think it'll be a lot of fun.

Andrew

00:02:58 – 00:03:35

Yeah. I think one aspect of that as well, which is way different now than it was maybe, whatever, 5, 10 years ago. I remember this is a bad memory for me, actually, but I'm gonna share it. I went to PHP Tech in 2,008, so I was a PHP developer before I was a Rails developer, and have always had a sort of bent toward framework level thinking, really way before I should have, actually. So even when I was, like, just cutting my teeth on development, I was always, like, leaning into abstractions and trying to make reusable components and things like that.

Andrew

00:03:35 – 00:03:54

It's just sort of how I'm wired. Maybe I'm lazy. I don't know. But I went to PHP Tech and there was this joke happening at that time. Somebody actually went to the effort of printing up stickers that had the Rails logo, but instead of Rails, it said, you wanna guess?

Aaron

00:03:55 – 00:03:58

Oh, gosh. It's cringe already. Is it fails?

Andrew

00:03:58 – 00:04:00

Yeah. Absolutely. I did not know

Aaron

00:04:00 – 00:04:03

that, and I accurately guessed, and it's super cringe.

Andrew

00:04:04 – 00:04:05

It's the worst. Right?

Aaron

00:04:05 – 00:04:06

Like, that

Andrew

00:04:06 – 00:04:21

is I mean, I think that says something about what developer culture was sort of like at that time and some of the stuff that was tolerated. But totally bad vibes. Right? And I think that's really changed. I think I literally work on a product, bullet train.

Andrew

00:04:21 – 00:04:57

We can talk kind of about our projects and our background stories and stuff, but I work on something that is directly inspired by Laravel Spark or, like, what Spark was back 5, 6 years ago or whatever. And I don't think I'm alone in that. I think there's mutual admiration in the ecosystems. Matthias reached out to me and asked to port one of my open source libraries from Rails into a a corresponding Laravel version of it. So I know that it goes both ways, and I think that's what we're here to basically give an outlet for.

Andrew

00:04:57 – 00:05:23

So I think there are times when things come up in the Rails ecosystem and it's genuinely exciting. And there's other times where things come up in the Laravel ecosystem and it's genuinely exciting. And I think we're all excited for each other, for what's working good, and there's an appreciation that everybody has just sort of picked the thing that works the best for them. And there is, like you said, there's inspiration that we can take both ways, so that's what we're here for.

Aaron

00:05:23 – 00:05:34

Yeah. And I think that was part of the reason we explicitly named this framework friends. The framework wars, if they're not over, we declare them over right now. They're over. Like, we moved beyond that.

Aaron

00:05:34 – 00:05:50

And I think even a couple days ago, DHH tweeted congratulations to Taylor Otwell on they did a Laravel documentary, and DHH tweeted about it and was like, Laravel's amazing. PHP is my first love. Congratulations, Taylor. And it's like, okay. Hey, this is reasonable.

Aaron

00:05:50 – 00:06:00

Why can't we just be reasonable like this? So I know that the conference you went to was 14 years ago now, but I'm hoping all of that animosity is gone at this point.

Andrew

00:06:01 – 00:06:28

Yeah, I think it is. So before we jump into sort of what we had been planning on talking about in our first episode, I just want to point out you made a huge announcement. This is hilarious to me that 30 minutes before you're scheduled to get on a whatever, a 1 hour call or whatever, You announced an absolutely huge sort of change in the course of your career. Yes. What did you announce?

Aaron

00:06:28 – 00:06:45

So I am taking a new job after almost 5 years working at my current job, and I am going to be the Marketing Engineer at Tuple. So I just announced it literally just announced that today and I couldn't be more excited. I'm thrilled to death about it.

Andrew

00:06:46 – 00:07:00

I think everybody is absolutely pumped for you. I think by the time this episode posts, it'll probably be old news, and that will have kind of, like, disseminated out to everybody. But I am so excited for you. Congratulations. It is an amazing opportunity.

Andrew

00:07:01 – 00:07:20

Ben Orenstein, the CEO at at Tuple, retweeted your announcement and said, hey, Erin's a rare find, really excited about what we're gonna do together. That's paraphrasing it. And I totally agree. I think it's an incredible hire for 2 people. Also, I think 2 people is also a rare find of a company.

Andrew

00:07:20 – 00:07:38

They are a very special business, and everybody I know that uses them loves them. It's awesome now that I can show up in a company that has 40 or 50 engineers, and they're already on Tuple. Yeah. And so you can pair and coach that way. That is an awesome product.

Andrew

00:07:38 – 00:07:40

So I'm pumped for you, man. I think that's gonna be really great.

Aaron

00:07:40 – 00:08:26

Thanks. I think in one of the last tweets, I said, I'm just so excited to go work at a company that is just universally loved in our corner of the Internet, sure, but every single person that we all know in this little section of being online, every single one of them loves Tuple. And it's been cool for me because I've listened along to Ben and Derek on Art of Products for a couple of years, and so I feel like I am very familiar with what they're up to and so when I saw that opportunity, it was kind of a no brainer. I have been at my job for 5 years and haven't applied for anything else. There are, like, 2 companies that if they ever had openings, I would go work for them and 2 Bull was one of them, and so here we are.

Andrew

00:08:27 – 00:08:59

It's amazing. Alright. So getting to the thing that we wanted to talk about today, origin stories. Why don't you start by giving a little bit of background to not necessarily our origin stories in terms of us personally becoming developers or any of that stuff, that's fun too. But I think specifically talking about the frameworks themselves, what were you doing right before you found Laravel?

Andrew

00:08:59 – 00:09:11

And what was it about Laravel that drew you to using it and then really converted you over the long haul to be, like, a a super fan of Laravel?

Aaron

00:09:12 – 00:09:27

Yeah. So I got started with Laravel, I think goodness. I wanna say 20 13, maybe? So a long time ago at this point. And I'd been a PHP developer before that.

Aaron

00:09:27 – 00:09:50

PHP was the second language I picked up, and it's the one I've been with ever since. Asp.net was the first one. So before I got, like, fully into Laravel, I was using a framework called Yi, which is impossible to say out loud. It's y I I. So, like, trying to say Yi on a podcast is really tough, but it was a good framework and it was one of the early ones.

Aaron

00:09:51 – 00:10:18

I specifically remember trying to pick between Yi and Laravel. I think it was 4 at that point, which is a long time ago, and I picked Yi because I couldn't get Laravel running locally. It was something to do with, like, maybe you needed some sort of international string extension and PHP. It was so funny because I couldn't get it running locally, and I got Yi running locally. And I was like, okay, I'll just use this one.

Aaron

00:10:18 – 00:11:00

And so I just picked up Yi, and I used that for probably a year or 2, and it was fine. But then I kinda looked at Laravel again, and at that point, it was just Taylor. So I'll say Taylor put a huge amount of emphasis on documentation, and the ecosystemcommunity had started to grow up around it already, in that I think at that point, Lara Casts was already a thing, and Lara Casts is our big I think you'll have Rail Casts. Lara Casts is our huge education site, video education, and it's all run by a guy named Jeffrey Wei. And early on, he was putting out just tons and tons of super high quality content.

Aaron

00:11:01 – 00:11:52

And so I remember switching to Laravel, I think, at 5 0 or maybe 5 1 or 2 or something. And the thing that hooked me at the beginning, and honestly has kind of kept me all this while, is just the insane amount of effort that goes into their documentation and their developer experience and the ecosystems, kind of I feel like that's trickled down from Taylor in that he puts a huge amount of emphasis in developer experience. And so that trickles down to, kind of, the people who write blog posts and the people who make videos, and all of that is very laser focused on pragmatism and developer experience. And so I think that's kind of what hooked me and kind of has kept me around. There are other things since then that have made it so that I'll never leave, but I think that was the initial hook.

Andrew

00:11:53 – 00:12:10

That's really interesting. So I think for me on the Rails side, I think it was a little bit before Laravel because I was in PHP. I don't remember Laravel being a thing. I don't even really remember what the frameworks were, like Symfony or, like, CakePHP, stuff like that. Yeah.

Andrew

00:12:10 – 00:12:20

And there was Zen framework, which was this sort of, if I remember correctly, it was like this very first party, very gate keepery kind of thing to contribute

Aaron

00:12:20 – 00:12:21

to. Mhmm.

Andrew

00:12:21 – 00:13:04

Yeah. And I I remember spending a lot of time thinking, oh, I wanna propose this ORM or whatever I was working on. But they kinda already had an official package, and I kinda thought it stunk. And I thought I could do something really special. And so I had, like, this proprietary ORM that corresponds now to what actually, even back then, it corresponded to, and this was the thing that got me to kinda switch over, was my friend Brian Smith was working at the same company as me, we were both development managers at that point, and he had gotten in one of the, like, smaller divisions of the business where he had a little bit more say, there was a little bit less legacy, and so there wasn't this huge PHP app or any of that stuff.

Andrew

00:13:04 – 00:13:21

Mhmm. And so he started doing stuff on Rails. And he was just absolutely flying. It was because all of these sort of higher level components, the thing that was already there by Rails 3 time was ARL. It was like the whole object relational mapper stuff.

Andrew

00:13:21 – 00:13:48

It was this big rebuild of the ORM and Rails, I think primarily pushed forward by Aaron Patterson, Tenderlo. And that did it for me. Just that alone because I had spent so much time crafting my own in PHP and there was this whole, like, they got the MVC thing down, the m is like overpowered, it's fantastic. That was specifically, I think, in Rails 3 was the perfect time. It was the perfect time for me to be introduced to it.

Andrew

00:13:48 – 00:13:56

And I was like, you know what? It was crazy, dude. I quit my job to switch into Rails. My full time managerial position

Aaron

00:13:57 – 00:13:58

Did you know Ruby at that point?

Andrew

00:13:58 – 00:14:09

No. Wow. So I started messing around with it, started building some stuff on the side, and I was hooked. I knew this is what I wanna do. I wanna play with these Legos.

Andrew

00:14:10 – 00:14:48

These are the toys that I wanna play with. And there was a consultancy locally that was this is a funny story, maybe too much in the details of this particular story, but I knew that they were hiring because some of the people on my team I had I think I had about 10 people that were reporting to me, and I was starting to hear rumbling, people on my team that wanted to go work at this Rails consultancy. And I looked at what the opportunity was, and I basically cut a deal and said, like, look, I don't know Rails, I don't know Ruby, but I'm pretty sure I'm, like, a good developer, and I'm pretty sure I can pick it up. So why don't you hire me at a junior level? This is a legit thing that happened.

Andrew

00:14:48 – 00:14:55

Wow. The yeah. It was Brendan Dunn was the one who ran the consultancy. Yeah. So double your freelancing, all of that.

Andrew

00:14:55 – 00:15:08

So I went to Brendan and said, hire me as a junior. What do you pay your juniors? Oh, you're paying your juniors more than my full salary as a manager in this big corporation? Great. Why don't you hire me as a junior?

Andrew

00:15:08 – 00:15:31

What do you pay your seniors? Oh, tell you what, I know in my heart of hearts, I'm a senior developer. I've been there, done that at that point in my career. Whether that was naive or not, maybe, but, you know, title, whatever. I said to him, hire me as a junior, and the first time I do a project start to finish on my own with no intervention from anybody, then push me up to senior.

Andrew

00:15:31 – 00:15:40

I'll prove it to you. And he's, like, done. It's a deal. And so that happened, and, like, within, like, 3 or 4 months, I was a senior developer in that consultancy. Yeah.

Andrew

00:15:40 – 00:16:00

Yeah. I didn't waste time. I yeah. I mean, to be fair, the other thing that I said to him at that time was, I will not learn on your dime. I will put in full time effort with you of stuff that feels like a real developer contribution in Rails, and any learning that I have to do, that'll be on my own dime on my own time.

Andrew

00:16:00 – 00:16:13

And those were long days. If you ask Carly what that was like, I was working, like, 15 hour days because I was good for what I said. I knew that we couldn't bill myself out to customers learning on their dime or whatever.

Aaron

00:16:13 – 00:16:15

To learn Ruby. Yeah.

Andrew

00:16:15 – 00:16:20

Yeah. Yeah. Yeah. So I worked long days. I would go into the office.

Andrew

00:16:20 – 00:16:34

This wasn't a remote company. We had a proper office and stuff. And so I'd go into the office in the day, consult, do phone calls, and then I would go home and just until I felt like I had really done a full day. And it was so worth it. It was so good.

Andrew

00:16:34 – 00:16:59

It was so hard, and within a few months, that was over, and the rest is history. So it was just looking over, and there was a vacuum that I think ultimately Taylor filled in the PHP ecosystem. So everybody wins, the folks that stuck with PHP got Laravel, and I myself got Rails, and I've loved it. Ever since, I've been really happy developing in Rails, ever since. I can't think of a time when I've had second thoughts.

Andrew

00:16:59 – 00:17:10

Mostly, it's just looking back at Laravel and gleaning sort of inspiration because you're right. It's on another level. It's a really great everything. Everything about it's great.

Aaron

00:17:10 – 00:17:44

Yep. And I think we should get to where we're at today, but I have a hot take on why Laravel and the ecosystem is so great. And it's not really that hot of a take, but it's because DHH has Basecamp and Taylor has Laravel. Rails benefits, I think, a lot from being extracted from a real world product, in that DHH gets a lot of real world use cases to pull out. I think Laravel benefits from the same thing in that he can pull use cases out of Forge and Envoyeur and Vapor, and those are, like, real products.

Aaron

00:17:44 – 00:18:17

But everything that he builds, everything that Taylor builds is for the Laravel ecosystem. There is no Basecamp for, like, just for normies. Everything that Taylor builds is for other Laravel developers, and so we end up with an ungodly amount of first party stuff because he has no other things vying for his attention. The only thing vying for Taylor's attention is Laravel and Laravel developers. So I think that's one thing that we get a huge benefit from in terms of the ecosystem, not necessarily just the framework itself.

Andrew

00:18:18 – 00:18:37

Yeah. I think you sized that up. And definitely, when you look at Laravel, it is a much more comprehensive brand. I mean, it's gorgeous. You look on the footer, for any Rails developers that haven't looked at the Laravel homepage, man, you'd think you were buying sneakers on that site.

Andrew

00:18:37 – 00:19:07

It is fantastic. And you scroll all the way to the bottom, and there's just this gorgeous, massive banner, Laravel. And there's all these things that are under the Laravel umbrella. Whereas in the Rails ecosystem, it's largely been left to the actual footprint of Rails itself is quite narrow and hasn't really that surface area, that land mass, whatever you wanna call it, hasn't really grown substantially over the years. It's become a better version of itself.

Andrew

00:19:08 – 00:19:31

I think a great example is like the work that Aaron did on Errol, but there's been other things along the way. There's a very clean line of demarcation, for example. There are almost no first party views and controllers that get shipped from Rails itself. It's always things like Devise and other Right. Third party libraries that aren't yeah.

Andrew

00:19:31 – 00:20:01

So I think the umbrella for Rails first party Rails is smaller, and I think that for Laravel, it's absolutely massive, and I think that's fantastic. I think one of the byproducts of that is what you said about developer experience. Having end to end polish is easier when you control as many pieces as possible that you know people will be using inevitably. Yes. And so I think Laravel really benefits from that a lot.

Aaron

00:20:01 – 00:20:02

Yep. I fully agree.

Andrew

00:20:02 – 00:20:31

So that is what sort of the developer experience, the documentation, the ease of getting started, that is what drew you to Laravel in the first place all those years ago as a core principle of the ecosystem or whatever. How has that evolved for you to bring you to what you're working on now in your own contributions to the Laravel ecosystem?

Aaron

00:20:32 – 00:21:13

That's interesting because I think if we zoom out from documentation, which is what kind of pulled me in, and take it as more fully developer experience and I'll say, like, decreasing pain. So early on, it was documentation. I think not totally unrelated to what we just talked about, that has grown, that ethos has grown in Laravel to encompass how can Laravel take away painful parts of development. And so, things have just continually been added over the past 10 years. We have first party queues.

Aaron

00:21:13 – 00:21:34

We have Sidekick, but it's 1st party. Yep. The queues, the jobs, and, like, a full on Redis monitoring and dashboard and all that, we have all of that first party. Weirdly, we have several first party hosting solutions in terms of server full and serverless. And so I think that vision of what would make a Laravel developer's life better?

Aaron

00:21:35 – 00:22:13

What would make a Laravel developer's life easier? And so that has permeated the framework but is also kind of where I'm living right now, too, in terms of what are my contributions to the framework or to the ecosystem in general, I think I have found a good home in how can I solve some really hard problems that a lot of people have? How can I absorb all of the pain and then give someone else an incredibly easy experience to interact with? So two things. 1 is Sidecar.

Aaron

00:22:14 – 00:22:56

Sidecar is an open source library that allows you to run functions on a serverless platform from your Laravel application. And so the pain there is you're hosting your application and you want to run headless Chrome, or you want to run a node process, or you want to run, for whatever reason, Python or Ruby or dotnet, all from your Laravel application. And so the pain is, good lord, am I going to have to switch to Docker containers so that I can now ensure Like, this is really painful. And I had to do it personally and thought, like, this is really painful. And I had to do it personally and thought, wow, this is awful and I hate it.

Aaron

00:22:56 – 00:23:11

And so immediately I was thinking, okay, well, there are other people that have to do this and feel the pain, but maybe other people have a higher pain tolerance. I think Adam Waddens talked about this before, like, you need to

Andrew

00:23:11 – 00:23:12

hear the point.

Aaron

00:23:12 – 00:23:44

If you're, like, in the business of developing tools for other people, you need to lower your pain tolerance. So, where you hit something painful, you don't just grit your teeth and move through it, you fix it so that everyone else gets up. So you need to make yourself sensitive to painful parts of whatever it is you're developing and make them not painful. That's what I did with Sidecar. It's like, this sucks and I hate it, so I'm gonna spend an unreasonable amount of time making it so it doesn't suck and I don't hate it.

Andrew

00:23:45 – 00:24:37

Man, I had that feeling last night so hard. I've got, like, a lot of stuff cooking right now, and I was working on one thing in particular, and I absolutely hated it. And I actually had the thought, like, there are days I I love what I do. I'm so grateful that I get to work even just as a developer generally, Even when the thing that I'm working on, I hate it, the silver lining of that is I just absorbed the most painful part is exactly what you just said. I got to absorb the most painful part of that for a 100, for a 1000 other people that no longer need to feel that pain or whatever.

Andrew

00:24:37 – 00:24:58

So with the sidecar presentation that you did at Laracon, that was next level. From a demo perspective, it was a sort of mother of all demos kind of thing. It had, like, that great demo ability. But the reaction, that would have been evident to anybody that was watching it. But also the reaction, I actually took a screenshot.

Andrew

00:24:58 – 00:25:51

I never posted it or anything. I didn't have an opportunity to put it into something, but I took a screenshot of the reactions that were happening, and people were just losing their freaking minds. And so I feel like it's gotta be like a law of the universe or something. The more aggravating and frustrating and anger inducing, if that's the type of reaction that a person has to something, the more irritating something was to do or to accomplish, the more mind blown emojis are gonna stream when you record a video of it and share with the Internet. I've seen that over and over again, not just with the demo that you did, but other things, videos that I've been able to record and publish and stuff like that, that it's almost like the harder it was to make it easy, the more people look at it and they're just like, didn't see that coming.

Andrew

00:25:52 – 00:25:58

I thought that was a really cool part of the Sidekick stuff. Stuff. Because if you just explained it, if you just, like, say,

Aaron

00:25:59 – 00:26:05

and I did just explain it and nobody cared, I mean Yeah. It had been released for a couple months, and nobody cared.

Andrew

00:26:06 – 00:26:13

Yep. But when you see it in action, I think something clicks for people. Yeah. That was a really cool one. So what else are you working on?

Aaron

00:26:14 – 00:26:46

So the other thing that I'm working on is this visual filter builder, and we call that one Refine. That is another example of something that everyone in their development career has to do. So at some point in your development career, you have been tasked with, Hey, I want a report builder, basically. I want to be able to say, show me users named Andrew in California that have done this 2 times in the past month. Go.

Aaron

00:26:47 – 00:27:45

And so, everyone in their development career has had to build this thing out and it is awful because the management, or whoever wants it, is like, I can't tell you all the reports I need to run. I just want to be able to run any kind of report that I may ever dream of. And you're like, well, that's actually kinda hard to do. And so what we've done there is we have given the developer the control to say, here are the 5, 10, a 100 different attributes that the user could choose, and then we'll just let the user put them together any way that they want. And we, as Hammerstone so Hammerstone is the name of company side project company that is developing this we, as Hammerstone, will say, here are all the things that the user can filter on, We will handle the front end, we'll handle the validation, we'll handle the back end, we'll handle the querying of the database, the saving of the filter so the user can directly address it later.

Aaron

00:27:46 – 00:28:34

We handle it all, and we do it in such a way, I think, that the developer gets to be in control of the developer knows what the data is, but they also know what the user wants to see. And so, they get to sit in the middle and control the user experience without sacrificing correctness in terms of the reports and the data and without leaking implementation details to the user. So, like, if you have a field that's nullable, you as the developer get to decide whether you expose that implementation detail or you coalesce it into a true or a false. So I think the easy thing would have been, hey, we just sit on top of your MySQL database and we just let your users figure out how to do it. That would have been easier.

Aaron

00:28:34 – 00:29:00

I think the hard thing, and where we ended up going, is we're going to sit in the middle and let the users have a great experience and the developers have a great experience and the SQL be performin'. And turns out that's pretty hard, but if we can pull it off once, which I think we have, then other developers get to just pull it in and say, here are my a 100 attributes, you guys figure out the rest. And that's kind of where we've landed.

Andrew

00:29:01 – 00:29:22

There's a couple of things that I love about that product and your approach at Hammerstone generally. The first is you make this product available in Laravel and in Rails. It's in the DNA of Hammerstone as a business. You've got basically the same thing that we're doing on this podcast. Mhmm.

Andrew

00:29:22 – 00:29:29

Yeah. Which is is serving 2 communities. So that's awesome. I love that. I think it's an incredible product.

Andrew

00:29:30 – 00:30:39

The other thing that I love about what you're doing and your approach to it is the size of the problems. I'm almost jealous of the size of problems because I think from a if there's anybody out there that's listening that maybe they don't have a product yet, they might be listening because they're interested in that kind of thing, like, developing framework components or whatever, but they haven't done something yet. I feel like there's something very smart about carving out a limited piece of the overall developer experience to try and, like, solve for and improve, it is a lot easier, I think, to get traction with something where you have had the opportunity to focus to have a strong focus on one particular problem and just do the absolute best version of it. I think a great example in the Rails ecosystem is Sidekick. This is a very specific problem that is solved, and it's like Refine solves a very specific problem.

Andrew

00:30:39 – 00:30:51

And it's not an easy problem to solve. The surface area doesn't mean that it's easy. It just means that you're gonna go really deep and solve this problem better than anybody has with an off the shelf sort of solution.

Aaron

00:30:52 – 00:31:18

Exactly. So, kind of, our thesis at Hammerstone is we build the things that everybody needs to have, but nobody wants to build. The issue that you end up with in most of these use cases is somebody comes, says you need to build this, you build it 60%, 70%. And then your business requirements necessitate that you move on to the rest of your business. Our business requirements are that we build it a 100%.

Aaron

00:31:18 – 00:31:56

Our entire business is this one thing that in your business would be an afterthought, but it's our entire focus. And to quote Adam Weven again, he had a thread a couple years ago that was, like, forget 80 20, go the whole way. Go the whole way, do the full thing, write the docs, cover the edge cases, and there's always a tension between go the whole way and ship early, ship off and whatever. That's a bigger topic. But going the whole way and, like, fully solving the problem that you set out to solve is very underrated, in my opinion, because you'll see open source repos that are 70% of the way there.

Aaron

00:31:57 – 00:32:04

And as you look at it, you're like, oh, it's not all the way there. I guess I should build it on my own. It's like, oh, god. Exactly. They were so close.

Aaron

00:32:04 – 00:32:10

You can't justify it from a business perspective if it's not your main thing. And for us, it is the main thing.

Andrew

00:32:11 – 00:32:18

Yeah. Yeah. I love that. And the reality is if it's 70% done, that is the definition of last mile issues. Yep.

Andrew

00:32:18 – 00:32:52

It's not gonna work for your use case, and they could have got it there or whatever. I think both of those things that you said go a 100% and release early, release often, those things aren't mutually exclusive. But if you pick a surface area, for example, of a product that is supposed to handle your authentication, your authorization, your all of your scaffolding, your invitations, teams, outgoing webhooks, incoming webhooks, OAuth integrations, like, whatever sort of crazy person decides to do that. I think it's ill advised because

Aaron

00:32:52 – 00:32:53

Tell us about Bullet Train.

Andrew

00:32:54 – 00:33:03

This is a legitimate lesson learned. I've worked on Bullet Train for, like, 4 or 5 years, whatever it is now. Right? Got a false start on it 5 years ago. I've been working on it for 4 years.

Andrew

00:33:03 – 00:33:15

And I love the thing. I've had incredible life experiences as a result. Deep satisfaction for the work that I do on it. I get to work with an incredible group of people who work on it. No regrets there whatsoever.

Andrew

00:33:16 – 00:34:02

People used to reach out to me when they saw the initial sort of traction that bullet train was getting and that there was clearly an appetite for it. People would reach out and be like, hey, I'm thinking of doing the same thing, like, do you recommend doing that? And at the time, I didn't really know what to tell people. I didn't want competitors, that was for sure, but that was inevitable. I think looking back on it now, the result it's been great for me personally, but if you're just looking to, like, do a software component business, do smaller components, I have so many friends that have done things so much simpler than what I've had to do on bullet train and are arguably or, like, measurably, depending on whether I know the the financials or not, had greater success with a more limited scope.

Andrew

00:34:02 – 00:34:24

And it's possible they're even more satisfied with the quality of what they've been able to do because they've been able to focus on something very narrow, and there was a market just for that thing. So I think it's worth saying because it is a big difference between the two types of products that we work on that if I had to do one or the other knowing what I know now, I think I would encourage people to do the smaller ones.

Aaron

00:34:24 – 00:35:09

I would fully agree. I think there's something satisfying about being able to encompass a 100% of the problem. You still need to explain what bullet train is, but I'm going to guess that there's something unsatisfying about knowing the full surface area of the problem and not being able to address it all because the area is so huge. When I know that there's something in Refine that can be done, like putting filters inside a filter so you can filter on relationships, I can both get my head around that and I can do it because the surface area is fractional compared to bullet train. So what is bullet train, and am I correct on that question about dissatisfaction?

Andrew

00:35:11 – 00:35:51

So before we jump into that, the last thing I was gonna say just to complete the thought was because I I don't think I tidied this thread up. But the thing that you said about go a 100% and release early and often, the point that I meant to make there was just that when you choose the surface area of the problem that you're gonna solve, you set yourself up for being able to go a 100%. So you can release early and often and maybe it's not there yet, but you know you're gonna be able to get there. Whereas the implication of, like, what you just said is it takes a lot of people to work on Bullet Train. Bullet Train is bigger than I would be able to do slash maintain on my own.

Andrew

00:35:51 – 00:36:03

And that's fine. I've been in in a position to do that. Like, it's been great to be able to bring people on and have help from a fair number of people, but that's resource intensive. Oh, yeah. Getting in yeah.

Andrew

00:36:03 – 00:36:30

Exactly. So there would be something, I think, appealing, especially for people that are just getting started or trying to bootstrap or whatever, to being able to pick out a problem that they can solve by themselves with little help and go all the way on it and feel satisfied with the level to which they're able to solve that problem. So okay. Background on bullet train. This will be sort of my answer to the follow-up on the framework origin story.

Andrew

00:36:31 – 00:37:11

I always thought when I went to Rails that they were just getting started on things like scaffolding and that was one of the things about Rails that was, like, really part of the killer demo which was the 15 minute blog demo. The big thing there was the app just appeared right before you from a series of commands because of scaffolding. Practically speaking, that wasn't really true in the Rails ecosystem. And so once I started building on Rails, basically nobody used scaffolding. So everybody would just say, there's so much other stuff that I've gotta do.

Andrew

00:37:11 – 00:37:25

Once you do the scaffolding, It's not worth it. I just do it by hand. And so it was interesting because I thought in 2010, 2011, when I got started on Rails, we're just getting started. These people get it. This is an ecosystem that gets it.

Andrew

00:37:25 – 00:37:45

We're going to higher levels. And that's really the the key phrase for me, is higher level. Raising the level at which we're doing development. And going from PHP, like, 2008, 2009 PHP to 2,010, 2011 Rails, like Rails 3, that was a huge level up. It was a huge level up.

Andrew

00:37:45 – 00:38:09

But I thought we were just getting started in the Rails ecosystem, going to higher and higher levels of abstraction in software development. And I think that is what has driven me to work on things that I ended up working on. So it was fine. I loved Rails, built a couple of startups in Rails. There was Borrowed and Blue.

Andrew

00:38:09 – 00:38:42

There was Churn Buster, which I owned, but both had success in their own ways, ended up being acquired, and Churn Buster ended up selling. And that kind of led me to the conclusion of, like, my first phase of being a Rails developer. Hey, I'm good with this thing. We can build businesses out of thin air with just me and Rails. So when I got back to work, there was this desire, I think, on my part to see Rails go to another level.

Andrew

00:38:42 – 00:39:02

And lo and behold, what is in the Laravel ecosystem but Laravel Spark? And it's interesting, like, I don't even really remember what the surface area of Spark was at that time. I think it was quite limited, but it did subscriptions, it did authentication, Teams. Oh, well, if it did Teams, then it's not so limited. That's a biggie.

Andrew

00:39:02 – 00:39:33

But it had this SaaS in a box sort of pitch, and that to me was, like, that is the right idea. That is going to another level. And coming full circle with Brennan, Brennan started a new application, new business called RightMessage, which he still works on to this day, with Shy, and they built RightMessage in Laravel because

Aaron

00:39:34 – 00:39:35

I don't think I knew that.

Andrew

00:39:35 – 00:39:40

You didn't know that? No. And, specifically, they built it in Laravel

Aaron

00:39:40 – 00:39:43

because of Spark. Really?

Andrew

00:39:44 – 00:40:05

Yeah. The guy that more or less I mean, it was basically Brennan Dunn and Ken Collins and Brian Smith. Those were the 3 Norfolkians that got me into Rails. And Brennan peaces out from the Rails ecosystem because of Spark. And, yeah, people can't see it, but Aaron's pumping his fist on the webcam right now as it does.

Aaron

00:40:05 – 00:40:06

We got him.

Andrew

00:40:07 – 00:40:17

Yeah. And I know you love that, but for me, I was like, no way. I'm too old. I don't wanna learn new tricks. I love rails.

Andrew

00:40:17 – 00:40:41

I gotta do something about this. And that was the genesis of bullet train. So when I got back to work late 2016, I got a false start on it, tried to get something started, didn't really work, talked about it with some folks. And then in 2017, toward the end of that year, actually got, like, a real start on it. And that's a longer story than we have time to tell today.

Andrew

00:40:42 – 00:41:41

But just in terms of how did that initial attraction to rails, what did that evolve into, and how does it kind of inform or how did it inspire the things that I try to contribute to the Rails ecosystem now? I was satisfied with Rails' evolution, how it got to be a better version of itself, but it didn't go far enough. It wasn't comprehensive or first party enough. And so what bullet train effectively became was like another framework on top of as a commercial product that I sell to people, it was like a commercial framework in the image of what I wished existed on top of the Rails core, but it brought in a lot of third party things like Devise and CanCanCan and API libraries and things like that, and OmniAuth, all of that stuff. And it made them effectively first party things.

Andrew

00:41:41 – 00:41:59

So that if you're using bullet train, you don't choose device, you don't choose can can can. You get them automatically. They're part of the framework. And that really is it comes back, I think, to the same thing that you were talking about. The gold standard for me isn't can you build a little blog in 15 minutes?

Andrew

00:41:59 – 00:42:21

The gold standard for me is, you wanna build a new SaaS app, can you get it into production in an hour? Can you get started, spin up your new project, have it launched to Heroku, and have the same thing that it got you sort of started in Laravel or in Yi. Is that what it was called?

Aaron

00:42:21 – 00:42:22

No. Yeah. That's right.

Andrew

00:42:22 – 00:42:43

The thing that got you started there was it was zero friction to get started. And my end goal with bullet train really is how complete an application, how good looking an application, how functionally comprehensive an application can I help somebody build with zilch friction?

Aaron

00:42:44 – 00:42:51

Just to wrap that up, your surface area is ginormous because hit me with 20 of the features, just rapid fire.

Andrew

00:42:52 – 00:43:16

It's more than it should be. And authentication authorization, so that's like, can somebody do something? We've got payments, we've got REST API, serializers. You've got all your integration, like, we generate integrations from code. The scaffolding engine is actually the most special thing of all, really, in bullet train because it's 2 things.

Andrew

00:43:16 – 00:43:51

It has a unique take on templates for So the templates are living pieces that you can actually run-in the application and then also generate code from them. That's unlike traditional rails scaffolding. But the other thing that's beautiful about the scaffolding is when you know what all the dependencies of the application are, man, you can scaffold some pretty crazy stuff. So we've got, like, all the reactivity stuff, like cable ready, stimulus, reflex, and we use Hotwire and turbo for the things that it's really good for. So I think I maybe mentioned it.

Andrew

00:43:51 – 00:44:29

Incoming, outgoing, webhooks, real time conversation threads. You can scaffold them into your app, and there's a little conversations inbox. We've got audit trail, all of this stuff. So we do a crazy number of features, and the reality is my plight is similar in some ways to the DNA of Rails, which is the entire time I've been building Bullet Train, I've been working with people to build applications with Bullet Train. It's been a big source of revenue for the business, but it's also been an incredible validation that our abstractions are good, that the tooling is good, and the size of some of these applications that we've built.

Andrew

00:44:29 – 00:44:58

Multiple applications that have over a 150 models in the domain models. And we're able to do that with really efficient development teams because of the tooling. So that's deeply satisfying. On a professional level, like, I feel like there are things in Bullet Train that are have the opportunity to be a real contribution to just the philosophy of software development generally, the stuff about code generation, having a ton of fixed dependencies. It's like omikaze to the max.

Andrew

00:44:58 – 00:45:26

Last thing I'll say about it, I basically describe it to people. Rails historically has this phrase, rails is omakaze, which refers to, like, chef's choice at a sushi restaurant, and they are going to set the course. While if rails is omakaze, bullet train is like 7 day package vacation, and all your meals and hotels and destinations are all planned for you. For better or for worse, that doesn't appeal to everybody. But there is a certain class of developer.

Andrew

00:45:26 – 00:45:45

As a business, we have super fans amongst our customers. And so that's where it is. There's so much more that we can kinda unpack on that one over time, and inevitably, I think we'll get to pieces of it. But that's where my desire for higher level development has led me to in the Rails ecosystem.

Aaron

00:45:46 – 00:46:23

Yeah. I think there's a lot more to impact there in future episodes. And I think the philosophy of bullet train and I think some things that are coming on the bullet train side will be very interesting to dig into. And I think the meta framework aspect of bullet train is something that I would like to talk about as a teaser. I think perhaps bullet train is very similar to Laravel in the same way that Rails is similar to some of the stuff that underlies Laravel because you have made decisions about bringing together packages in the ecosystem and combining them into a cohesive narrative.

Aaron

00:46:24 – 00:46:27

I think there's something there that would be interesting to talk about.

Andrew

00:46:27 – 00:46:29

So you like talking about frameworks? Is that what I'm hearing?

Aaron

00:46:29 – 00:46:31

Yeah. Yeah. That's what that's what you're hearing me say.

Andrew

00:46:31 – 00:46:35

Maybe we should do a podcast and call it to Framework friends.

Aaron

00:46:35 – 00:46:36

I love it.

Andrew

00:46:36 – 00:46:42

I love it. Let's do it. Looking forward to continuing the conversation. Chat with you soon, Aaron. Congratulations.

Origin Stories

Transcript

Not enough emails?