Podcasts about full stack radio

This week Steph's taking a quick break, but while she's off, Chris is joined by a special guest - Jonathan Reinink. Jonathan is the creator of Inertia.js. Inertia.js (https://inertiajs.com/) lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers, and listeners of the show will certainly have heard Chris rave about it on previous episodes. Chris and Jonathan dig into what makes Inertia unique as compared to frameworks like Phoenix LiveView, Laravel Livewire, and Rails' Hotwire & Turbo. They also discuss how Inertia embraces the URL, the unique "protocol" nature of Inertia, and how to consider Inertia alongside native mobile applications. Throughout the conversation, Jonathan's consistent philosophy of wanting to build robust, performant, and delightful applications shines through. Jonathan Reinink on twitter (https://twitter.com/reinink) Inertia.js (https://inertiajs.com/) Eloquent Performance Patterns (https://eloquent-course.reinink.ca/) TailwindCSS (https://tailwindcss.com/) Church Social (https://churchsocial.com/) Jonathan on Full Stack Radio (https://twitter.com/adamwathan/status/1192152495407222784?s=21) Foundational blog post: Server-side apps with client-side rendering (https://reinink.ca/articles/server-side-apps-with-client-side-rendering) Laravel Livewire (https://laravel-livewire.com/) Alpine.js (https://github.com/alpinejs/alpine) Phoenix LiveView (https://github.com/phoenixframework/phoenix_live_view) Hotwire Turbo (https://turbo.hotwire.dev/) The Inertia Protocol (https://inertiajs.com/the-protocol) Transcript: CHRIS TOOMEY: I am seeing what I believe to be the relevant things. JONATHAN REINIK: Let's dance. CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week, Steph is taking a quick break, but while she's away, I'm joined by a special guest, Jonathan Reinik. Jonathan Reinik is the creator of Inertia.js. And listeners of the show will know that that is increasingly one of my favorite frameworks and, frankly, just ways to build applications on the internet. Jonathan is also the creator of the Eloquent Performance Patterns course, which teaches the Eloquent ORM, which is the ORM in Laravel but really digs into deep performance and database things, so really covering that back end as well. Jonathan also collaborated on the development of Tailwind CSS, a utility-first CSS framework which again is something that I have spoken of in very high terms on this podcast. And lastly, Jonathan currently runs his own SaaS business called Church Social. So really, Jonathan is a bit of a quadruple threat covering back end and front end design and entrepreneurship. So pretty much everything you want to see. And frankly, I've been so impressed by the breadth and the depth of Jonathan's work and just the deep way that he is thinking about building applications. So I am absolutely thrilled to have him on the show today. So without further ado, Jonathan, thank you so much for joining me. JONATHAN: Thanks so much, Chris. That was a very kind introduction, and yeah, it's awesome to be on The Bike Shed. I've been a long-time listener, and as I've said to you, I really appreciate the support that you've given to my work over the years. So yeah, it's awesome to be here. CHRIS: That's interesting. We're measuring it in years now, but it's a very sincere thing for me. I think with Inertia, you've built something that is both very unique and a special approach to how we build things, but it's also built from very familiar pieces and allows us to reuse the deep amounts of knowledge that we have in the Rails community or the Laravel community. But actually backing up just a little bit, because we're going to dive deep on Inertia.js today, for folks that are not as familiar or have only heard me mention it in passing, there's a wonderful episode of Full Stack Radio where Jonathan and Adam Wathan talked about Inertia.js, and I think gave a very good foundational summary. So we'll link to that in the show notes in case anyone wants to dig in a little bit more. Likewise, Jonathan has a really fantastic blog post called Server-side Apps With Client-side Rendering, which, as far as I can tell, is the manifesto that began this whole journey for you. And I really love that you have done so much of the work in public, and people can see the history of how this idea has evolved and really crystallized into what now is a very production-ready framework in sort of the way to build things. But I would love to hear right now just for anyone who is not as familiar and also just to hear how you summarize it at this point in time. What does your introductory elevator pitch for Inertia.js sound like in April 2021? JONATHAN: That's a great question. So it's hard to answer this without unpacking a lot of different things. And you mentioned the podcast with Adam; I think that's good because it goes in a lot of the technical detail of how Inertia works and why I created it. But the elevator pitch these days for when I talk to someone about it, it's generally I explain it as a way of building modern web apps. And in particular, when I say modern, I mean web apps that have a lot of JavaScript, so frameworks like Vue or React or Svelte, so applications that are built using those tools. And the key thing that Inertia offers is for you to develop these modern applications without having to first build an API sort of the way historically if you ever wanted to use one of these modern web stacks like Vue or React or Svelte, you could use them within Laravel or Rails by inserting them into your Vue or into your Blade templates or your ERB templates. But it was difficult if you ever wanted to turn it into a legitimate single-page application. And anytime you would ask that question, if you go out on the internet and say, “Hey, how do I build SPA with, say, Vue and Laravel or React and Rails?” The answer was always, “Well, you need to build an API. You need to build an API.” That was always the missing piece because that's the way that everyone in the Jamstack era that we're in that's the way that everyone's building their applications that are like these heavy client-side applications. And I totally get the need for those style apps and the place for those style apps. But I really missed this way that you could build an application with Rails or with Laravel where you could just literally spin up a new app, create some routes within your server-side framework, create some controllers, create some views, and have a working application within minutes really. You could have something being displayed on the screen within minutes with these classic monolith applications. And if you wanted to do the same thing, if you wanted to get an app up and running in minutes with Vue or React as your completely client-side SPA scenario, it just wasn't working because as soon as you say, “Well, in order to do that, you're going to need to have a back end Rails or a Lavarel application, and then a client-side Vue or React application. And then you're going to have to create this API that connects the two together.” There's just a lot more work that goes into that. It's not only the work of actually creating the API; I find a lot of the decisions that come along with building an API; it's like, okay, what does the abstraction look like? Am I going to build it with REST, or am I going to build it as a GraphQL API? And all the decisions that come along with designing and architecting that which again has its place. But there's just something awesome about saying, “Here's a new route. Here's the view that I want to render. And here's the data that I want that view to have,” and just go off and do it, and it's done. And some people ask me, “Well, with Inertia, if you're not building an API, what happens someday if you need an API?” And they frame it like, well, this is a terrible decision. You should be starting with an API. But for me, the reality is that so many of the web applications that I was building and that I've seen other people building is they had already made the decision not to use an API because they had already made the decision that they wanted to use Laravel as a monolith app that had their controllers and the routes and their views all within that and the same thing with Rails. So if you've made that decision to build a monolith app with Laravel or Rails, you've already made the decision to not build it with an API. I was coming in from the other way. It's like, I just want to build an app the way I've always built in Laravel, and I don't want to have to build this API. Of course, there are times where you do need an API, which I think we're going to talk about maybe a little bit later if I don't ramble on too long, where it does make sense to have an API. But yeah, that's kind of the elevator pitch. I think maybe to close off that thought is that I really, really enjoy having a tight coupling between my routes and my data layer and my views, which, again, I appreciate that. That probably sounds like blasphemy in modern web development. But for me, I think it's so empowering when you say, “Hey, I have a controller that's given me some data, and I have a view that's rendering the data, and those two know about each other, and those two depend on each other.” You can work so fast because I'm not thinking, okay, well, I have this API endpoint that returns a user, and that has their first name and their last name and their email. But I also need to think about it in the situation in the future where I might need this attribute or that attribute or some other attribute and make sure I have all that figured out ahead of time or at least have a way to add it in later. And all of that thinking that goes into designing an API, I find that that adds a lot of overhead. And then maybe related to that also is the amount of times that you're rendering a view within your application that needs data from multiple different places. And to me, this is like one of the huge performance benefits that you get with a tool like Inertia is with, say a REST API, GraphQl solves this, but with a REST API, you're often getting too much data for what you actually need for the page, or you're often making more than one HTTP request because you say, “Well, on this particular dashboard, I need some user information. So I have to hit the user endpoint. I need maybe the latest product sales data, so I need to hit that endpoint.” And you're dealing with these performance issues that you get with a REST API that with Inertia, you don't have that problem because it's just going back to classic Laravel Blade views or Rails and ERB templates. Am I saying that right, ERB template? CHRIS: Mm-hmm. JONATHAN: In those situations, you say, “Well, if I need data from three different places, well, I'll just grab data from three different places and send it to the view, and that's fine. And I can do that in the most efficient way and get the data that I need specifically for that view.” So anyway, that's some of the thinking that drove me to build Inertia and some of the things that I was going for. And yeah, it was an evolution. It really came out of me using Turbolinks and really appreciating what Turbolinks gave me but taking it to that next step where it's like Turbolinks, except it's built with the same principles as Turbolinks but built for modern client-side frameworks like Vue and React. CHRIS: Yeah, that all feels very familiar to me. And in my experience, I've now worked with Inertia on a handful of projects, but in particular, I have just a small personal app that I use to manage different aspects of my life. And it's been my playground for different technologies. And I've migrated it through a bunch of different versions where it used to just be a Rails app. And I was like, oh no, the thing that I need to do to be on the cutting edge is to turn this into -- it's a Rails app on the back end with an API, and then it's a React app. It's separately deployed, but those two talk to each other. And what you were talking about of the deep coupling, I think that coupling exists whether we want it to or not. And so embracing that and revisiting when I eventually migrated that application to use Inertia and the client-side stuff folded back into the core codebase. Now deployments all go out in sync. And that turns out to actually be a really nice thing and a non-trivial thing to solve otherwise. As a developer of one on this particular project, the amount of complexity that was removed from the app when I switched it over to Inertia was amazing. I got to remove client-side routing. I got to remove client-side state management, which I think I was using Redux at the time. I got to remove some form helpers that I had. I think I might've been using Formik or React Use Former, any of those. But there are so many different little pieces that you ended up cobbling together to make an application. And it was amazing to me as I moved to Inertia, where I was like; actually, I don't need any of those, and routes suddenly are defined in one place in Rails in a familiar way. But things like redirects all work -- It feels just like a Rails app but with the extra abilities that a front-end client-side framework gives you when you want those when you need those. But otherwise, it really does feel like I'm rendering to an ERB template. It just happens to be that that template is rendering on the client-side and is written in React or Svelte or whatever the front-end framework is. But it almost feels like progressive enhancement. I'm borrowing a term, and it's not actually applicable here, but it really feels like that. It's like, oh, it's a Rails app, but I just want to make it a little bit fancier, and Inertia does that in such a fantastic way. And actually pivoting just a bit, as far as I can tell, there seems to be an explosion of thinking in this space. There are a handful of frameworks, namely Laravel Livewire, which is often paired with Alpine.js. Elixir has Phoenix LiveView, and then Rails has the Hotwire suite, which Turbo and Stimulus are the most pointed considerations. But interestingly, I think all of those frameworks, which I think are trying to provide a very similar experience, tend to keep things on the server-side, so using the Laravel Blade templates or the ERB in Rails. But you've taken the different approach to say, “No, let's embrace this front-end technology where it makes sense.” And again, there are a lot of pieces that can fall in, and I don't need the Redux and the React Router and all of those things but still use that client-side framework to be the rendering engine. And so I'm intrigued if you can talk a little bit more about that and that trade-off because I think it really differentiates Inertia and its approach. I personally found it to be fantastic, but I'd love to hear a little bit more about your thinking on that. JONATHAN: The thing about modern websites and web apps, in particular, is it doesn't matter how you slice it; we need JavaScript. So if you disagree with me there, then everything I say from this point on will not make sense to you. But I think we can all agree that modern web apps need JavaScript. JavaScript is the programming language of the web of the browser that allows us to do whatever magical things that we want to do. And if you look at tools like Phoenix LiveView, Laravel Livewire, and even the new Turbo stuff from the folks over at Basecamp, they all are embracing JavaScript in the same way. It's just they're framing it in a different way. I would say, especially with Livewire and LiveView, they're almost creating like an abstraction between the server and the way you write things on the server and the client-side. And they're almost hiding the JavaScript, which is really, really cool. I think it's such an interesting thing to try to do where somebody who's not familiar with JavaScript and not familiar with Vue, React, and Svelte can go and do things, write server-side code that gets rendered server-side. And then there's some JavaScript that these libraries insert that allow you to do more interesting things, whatever those things might be, show a drop-down, or drag and drop or validate a form or submit a form without actually submitting it fully to the server but submit it over XHR instead, all these kinds of things. But the point is they're embracing JavaScript just in a different way. And same with Turbo, Turbo gives you a way to write JavaScript for an application that mostly has server-side rendered HTML. So I think it's important to just recognize that JavaScript is key in all these frameworks. With Inertia, it's the same idea in that Inertia wants to embrace that classic way of building applications using the classic server-side monolith application framework like Laravel or Rails. But the difference is it acknowledges or embraces these existing client-side frameworks that have really grown in popularity. And the three, again, I keep mentioning them, Vue, React, or Svelte. Svelte being an up-and-coming one that's not nearly as popular yet, but it seems to be gaining a lot of steam. CHRIS: It's on the rise. That's my long [inaudible 14:46] JONATHAN: Yes, and people keep saying that. So anyway, Inertia basically said, “Hey, we want to keep building server-side apps. We want to keep building monolith apps similar to these other tools, except what we're going to do is we're going to embrace the fact that there's this really, really amazing tooling that's been developed for the client-side.” And it just doubles down on that. So for me, the reason that I ended up here was because, in my own SaaS application, it was a Laravel application that started with mostly Blade views initially. And then, over the years of building it, which has been many, many years, I've slowly added more and more Vue components within my app. And initially, the way I did it is those Vue components would just be inserted in as regular HTML tags in my server-side rendered templates. And then, when the page renders, those Vue components would boot up and do whatever they need to do. So for me, when I was building Inertia, I had already fallen in love with Vue, in particular, and having all the power of these client-side frameworks. And there is so much there. It's not just Vue, React, and Svelte; it's all the amazing tooling that's available out there that you can add on top of it. And this is the thing I often tell people that Inertia isn't -- we say right on the homepage, “Inertia isn't a framework.” And the reason why I say that is because I don't want people to think of Inertia as an alternative to Vue, React, and Svelte. Do you know what is a better way to frame it? It's actually more of an alternative to React Router or Vue Router; that's really more what it is, where you can say, “All my routings are handled server-side,” and that has all kinds of interesting implications. But it's more of a router, and it just so happens to pass along that routing control over to the server. Anyway, so that's really for me what differentiates Inertia from those other tools is because it's really doubled down on these client-side frameworks. And I think the reason why Inertia has been relatively popular is because people know Vue and people know React. And when it comes to then working with Inertia, it's not some new thing that they have to learn. It's an existing set of tools that they're already super comfortable with. And in so many ways, when you're building an Inertia app, you're kind of building a classic Vue app or a classic React app or a classic Svelte app. It's just there's a bunch of pieces missing. Like you said, it's like a bunch of the client-side state management stuff, which nobody likes anyway, is gone. The other thing that's gone is client-side routing. You don't have this back-end routing is over here now, and client-side routing is over here, and I have two different routing definitions. It's like, no, that's all just server-side now in one place. The other amazing thing you get is you mentioned redirects and that whole HTTP layer you get just along with Inertia for free because it's just part of your server-side stack. And one key aspect of that is auth. You can just use good old-fashioned nothing is better than session auth. Like, it just works. And, so whatever your typical solution for doing session auth in Laravel or Rails or whatever server-side framework you're using, all this stuff just works. So anyway, coming full circle on your question, the reason why Inertia has gone this way is because I really think that there's a huge amount of value with using these modern frameworks. And we just doubled down on using them. CHRIS: Yeah, that resonates with my experiences using Inertia and in contrast to the other frameworks. Everyone seems to be trying to get to the same place of providing a mechanism to have more almost app-like functionality but still using the traditional server-side technologies. But I think Inertia has chosen an approach to that that is unique in that category and really has provided a fantastic outcome. I've been very frankly surprised by the fidelity of experience and how app-like I can get something to feel when building with Inertia while still using all the same technologies. And the fact that I can use just traditional server-side auth and redirects and things like that is just so nice, and everything feels right. There's an experience that I've had on many applications that are, say, a React client-side bundle that gets sent down and then boots up, and then the layout starts to render. And as its data fetching, it gets like a 402 response or something like that in that data fetching. And then it's like, oh no, I need to hard redirect you over here on the client-side to this other page. And there's this junk of semi-filled-out layout, and then suddenly you're on the login page. And again, with Inertia, it looks like a normal server-side rendered app, but it isn't in the ways that really matter to us. And it is one of those things where the more I played with it, the more there's an experience of interacting with Inertia that it surprises me consistently how nice it is to work with it and yet it's so much easier to maintain an application using it. I know I'm raving here, but I am really a big fan of this for everyone listening in the audience. JONATHAN: [laughs] CHRIS: And actually to continue on one of the things you were saying there, one of the things that stands out to me in Inertia is the way that it embraces URLs and to a certain degree, that seems like a purposeful thing, but it also seems like it just naturally falls out of how Inertia works because we're no longer using a client-side state management technology, the way to manipulate state is through the URL. If you want to see a different version of the to-do list you're looking at when you click on that link, you change the URL and the state changes in response to that. And so everything is fundamentally kept in sync, but URLs are very much at the center of the architecture, and I really love that so much. I think URLs are often forgotten in client-side frameworks or underserved or underused. And it turns out in my experience as a user and both having served many users, people love to command-click on links. They love to right-click open a new tab. They love to be able to reload and see the same thing on the screen when they reload the page. They love to be able to bookmark. These are all really wonderful things that come out of working on the web. And the fact that Inertia has a pit of success around having URLs and have that be the way that we drive state is just so fantastic. So I'm wondering how much of that was very purposeful on your part versus how much of that fell out of the architecture. JONATHAN: That is very much something that fell out of the architecture. I say that not to say that I don't value URLs; I absolutely did. That's the way every single one of my Laravel built apps worked. It always starts in the route file. You hit the route file, you define a new route, and it goes from there. So I absolutely think that the URLs are critical. But the fact that it just ended up working out so nicely was, yeah, I'm going to say it was a bit of luck, a bit of coincidence. I find this is what's so interesting when you start pushing on a new way of things; you initially don't really know where it's going to end. It's like you have some ideas of how the tool can work and where it might go, but I think there's a lot of unknowns that you just figure out after a while. So the thing I said earlier actually about the fact that Inertia in a lot of ways is like a client-side router; it's, it's a routing library, to put it that way. I had been working on Inertia for a year and a half, and then a buddy of mine, Taylor Otwell, the creator of Laravel, he and I were chatting, and he said to me at one point he's like, “Oh, you know what? Inertia is actually super simple. It's really just a routing library.” And it was like, bam. It was kind of that moment; it's like, oh yeah, I hadn't thought of it like that at all. But when he said that, it made a ton of sense to me. So it's just this interesting progression the more you work on something, and the more you push on the edges, you learn what's possible and what it even is. I had this interesting experience, so remembering that Inertia came from Turbolinks. So I had my whole app built with Laravel ton of server-side rendered templates with Blade with view mixed in. And I had the SPA mode by clicking around using Turbolinks. So when I decided to try building Inertia, I removed Turbolinks, and all these requests now happened over XHR but using this preset JSON structure that powers Inertia. I really, in my mind, had this idea that it was only for GET requests, for GET visits; it was just for that. So the initial version of Inertia, there was no Inertia.post or Inertia.put or anything like that. It just wasn't something I even thought was possible. But then I remember, and this is often how it goes; I was out for a hike that day to get away from the computer for a little while and just let your brain drift; I'm sure you can relate to that. I was like, wait a minute; I could totally just support POST, PUT, PATCH, DELETE. And that was such an aha moment for me where I just realized that it was so much more than what I originally thought it was. And then the whole thing from that I remember it was a bit of like a waterfall effect after that where I remember running home out on that hike and hacked it together, and then it was like, okay, well, if I submit a form using POST, well, okay, I'm on the create user page. And I submit this form using Inertia.post to the user's endpoint. I'm like, well, how do I now end up back at the user index page or whatever page, maybe the user edit page. I'm like, wait a minute, I can just return a redirect back to the user index page, and it's literally going to return an Inertia response from the user index page. And then the way Inertia works is it dynamically swaps the page component client-side. And it was just like, oh, this is way too cool. And this really drives my thinking now that it's become a little bit more clear to me is that it really it's all based on HTTP using headers and normal HTTP stuff like redirects are such a critical piece of the story. But to me, that's super neat that, in a way, it's like a throwback to the fundamentals of the web and the browser and the fact that Inertia can just use those things,,, and it doesn't have to be fancy in a lot of the ways. It can just rely on those existing core pieces of the browser. So, yeah. CHRIS: It really is interesting to me how it feels like progressive enhancement in that way where you're building on top of these core fundamentals of HTTP and requests and redirects and status codes and things of that nature. Particularly interesting to me was it took me a while, I'm going to be honest, to figure out forms and particularly validation errors in Inertia. And that is entirely my fault. You have absolutely fantastic documentation. I am so impressed by the quality and the density of the documentation that you have that really covers everything. If we're being honest, I hadn't read the page, but I was doing form posting and then the subsequent errors and how you deal with that. I was doing it in a very traditional Rails way which if we're being honest, that is not a fundamental of how HTTP works. Rails just chose an option of oh, if you POST but we don't create the object because there's a validation error, then we're going to stay on the URL of the POST, so the collection route, but we're going to re-render the form in line. And that's a choice that Rails made that is interesting because at that point, if a user reloads the page, then things are weird, and it's not going to reload. They're not going to see the same thing after that reload, or it's going to try to repost or et cetera, et cetera. There's a bunch of edge cases there that sort of fall out. Whereas with Inertia, you end up redirecting back, and there's this interesting handshake of the errors, but from an end-user experience, it is absolutely fantastic where you stay on the form; the URL does not change. Technically, there's a POST and a redirect back under the hood, but Inertia just handles all of that for you. And you end up with sort of in-line validation errors. But you don't clear out any fields, and there are just wonderful things that fall out of it that again took me a while to get there, but it was another one of those oh, wow, this just naturally falls out of the architecture, but it's so nice and such a nice incremental advance on top of frankly, the stuff that I was doing in Rails historically. JONATHAN: So the way that Laravel works and it's always worked this way is when you make a request using POST or PATCH or DELETE or whatever to an endpoint, and that endpoint does its validation in the event that that validation fails, this is just like built-in standard like Laravel Stock behavior. It automatically redirects you back to the endpoint that you were on. So if you're on the create page or the edit page, it automatically redirects. That's just Laravel behavior. And what it does is it takes those errors that come out of the validator, it flashes them to the session, and then when the forum page reloads, you have those errors available to you in the session. Now, of course, if you're building like a classic server-side rendered application and you redirect now back to your form, you have to repopulate old form inputs, which is not a lot of fun, which you don't have any of that stuff with Inertia because Inertia allows you to preserve your state. But anyway, that's a separate thing. But for me, it's like you build a tool a little bit like in your own silo and the world that you know, and for me, that's Laravel. But there are also ideas that you get that just come from the tooling that you use, and the fact that Taylor Otwell made that decision in Laravel at one point is absolutely what now dictates how is the go-to way to do it in Inertia, just because it works so nicely. CHRIS: I wonder if there's been any consideration in the Rails world to adopt that because I think from an experience perspective, it feels like it's a better thing. It feels like it has the same robustness and guarantees that I would expect. But yeah, that's interesting. It makes sense that that was just naturally there because, again, it didn't feel like the obvious correct thing that Rails was doing. It was always a little bit odd and so interesting that Laravel was already there. But then Inertia can take it that one step further. But taking a slightly higher level view of all of this, one of the things that's really interesting about Inertia to me, especially in contrast to some of the other frameworks that we've been talking about like the Livewires in the LiveViews is Inertia is almost at its core a protocol more than it is…it's a sum of pieces, and with Inertia, you have a server-side adapter, so there's the Rails adapter and the Laravel adapter. And then, on the client-side, you have a separate either Vue or React or Svelte. So those are the officially supported ones on both sides, but there's also been a swell of community support. And so there's a Django one, which I'm not sure if it's currently maintained, but I just saw a Clojure one the other day. There's a Java Spring Boot. So those are all server-side adapters. I haven't seen as much on the client-side, but I imagine there are at least a handful of them out there. And it's so interesting to me that there's this core idea that you define this protocol of communicating back and forth from the server to the client and now this collection of things that are growing around that. And I wonder again, how much was that purposeful versus how much did that just happen? And then further to add a second question to complicate things, how are you thinking about managing that community? Because my sense is that this could allow for Inertia to be so much of a bigger tent and really bring in the best ideas from all of these different communities and end up with something at the core of this Inertia thing that is the best of every community and all of that. So yeah, a lot of questions there, but I'll hand it over to you because I'm super interested. JONATHAN: So I think when I first got going, it was Laravel and Vue; those were the tools that I worked with. And often, the best software and the best open-source software in my mind comes out of trying to solve something for your own needs. So that's really where Inertia came from and specifically for Laravel and Vue. But I quickly realized early on that it didn't have to be just a Vue and Laravel thing. So intentionally early on, I had this idea of trying to build it with multiple adapters, and I had this idea that you could build as many server-side adapters as you want and as many client-side adapters as you want, and maybe we'll officially maintain a certain amount of those, which is what we do right now. We officially maintain the Vue, the React, the Svelte adapters. And then, we also maintain officially the Laravel and the Rails server-side adapters. So that was, I would say, pretty intentional. And it's crazy how many server-side adapters people have been able to put together. Somebody wrote a ColdFusion server-side adapter for Inertia. I had no idea ColdFusion was even a thing anymore; yeah, legit. There are node ones; there are Phoenix ones; if you can believe it, there's a WordPress one, which I'm not even totally sure even how that works. There is ASP.NET. CHRIS: [chuckles] JONATHAN: Like, there's a whole bunch of them. And it's actually despite of me, not because of me, that this has happened because I am yet to write a good here's how to build an Inertia server-side adapter in the language and framework of your choice guide. It's been on my to-do list. I have a bunch of things I want to do. So it's still something I want to write, but people what they're doing is they're just reverse engineering what we're doing in Laravel and Rails and these other adapters, and they're figuring out how to do it in their own server-side language and framework. So that's been really, really cool. On the flip side, on the client side, I'm starting to realize more and more that that's actually where the most important work for us as the maintainers of Inertia that we need to focus our efforts on because it's non-trivial to create these client-side adapters. And for us, we actually have four of them now because we have React and Svelte, but then we have Vue 2 and Vue 3. And they're different enough those frameworks that we actually had to create a separate adapter. So that's really where all our work is. The core of Inertia is actually ridiculously short, like the whole file, like the whole core Inertia adapter is 150 to 200 lines of code. And maybe it's a bit more than that, but it was that for a long time. It might be 300 or 400 now. It's very short. Even honestly, the client-side adapters are pretty short too. It's just that it's more difficult to make these client-side adapters because you get to learn all the intricacies of how each one of these frameworks handles their rendering. The core behavior that Inertia uses is the fact that you can dynamically swap components. So we dynamically swap page components when you visit from one page to the next and the details that come along with that. Anyway, so I've realized that moving forward, my job is going to be to make sure that the client-side adapters are awesome and then letting the community drive the server-side adapters a little bit more and providing some better guides on how to do that. But yeah, for now, it's like if we can get it working in Laravel and Rails, we should be able to get that functionality working in any server-side adapter. And because it's all again just based on HTTP, that's the language, that's the protocol like you say. That's the thing that matters between all these web frameworks, which they all, of course, support since they're web frameworks. CHRIS: I think you're not giving yourself nearly enough credit for the support that you've given to the server-side frameworks because you do actually have a page in the documentation called the protocol that does a great job of at least summarizing it at that HTTP level. But at the end of the day, again, like the job of someone implementing it is to then map that into their given language and framework of choice. But yeah, the documentation is impressive in just how much you put in there and how much care you obviously put into it and lots of nice, subtle details that are covered very well in that. So that again, if you read it, unlike me, then you get to know everything; eventually, I got there. I think I've read the whole thing now. But there's a lot there, and you cover all of the details. But actually looping back to a topic that you hinted at earlier, but this is something that I've been pressing up against lately is I absolutely love building web apps in Inertia, but there's often the need to bring in a mobile app, and we want native mobile for various reasons. I love the idea of progressive web apps, and I want to push that envelope as much as I can. But as an example, right now, iOS does not support push notifications to PWA. So if that's a key feature that we want, then we're dead in the water or if there are certain GPS things. There are a bunch of true platform native things that we just can't get. And so I'm now contemplating building out an app alongside my Inertia web stuff, but I want to build a React Native app, and I'm wondering, to a certain degree, does this invalidate some of my ideas? I know you hinted at this earlier, but I think I'm still convinced of the utility of Inertia on the web. But I think I need a different paradigm to build for a mobile app, and I'm trying to decide where that line falls. I'm also wondering if I can just get away with embedding a bunch of web views and reusing my web logic because, again, if I'm building all of this, I'm going to build it in a mobile responsive way. I don't want to rebuild the core page functionality of my app just to put it on mobile. Maybe mobile folks would tell me I'm wrong there, but I'm interested in maybe wrapping it and getting access to those platform features. But yeah, I'm interested in what your thoughts are there. JONATHAN: Well, embedding a web view within a native app has been proven to work just as DHH, obviously. But yeah, there are definitely people who disagree with that approach and feel like you should build a legitimately native app. Let's say that we're going to legitimately build a real native app. We want to have an Android and iOS app. So I actually ran into this myself for my own SaaS application, and I solved it by building a native app using React Native so React Native obviously being an abstraction on top of iOS and Android and all the tooling there, which is such an amazing platform. It was just a real joy to work with. And I don't even hardly work with React, and I was able to get a nice, high-quality native feeling app built relatively easily. But I had to come to grips with this very question because, like I've been saying all along like, “Inertia is great because you don't need to build an API. Yay, this is amazing. This is what you should do. Oh, crap. I need an API.” And I had those questions like, okay, well, does this invalidate everything that I've been doing? So I was thinking about it, and in the end, what I did is I just built a light API alongside my Inertia application. So what it is is I think I have seven endpoints, and they're just REST endpoints that are designed specifically for my native app. And this works honestly so well. And I think I've explained to you a little bit in a previous conversation, so I'll repeat myself a little bit here for the benefit of the listeners. The reason why I think it's completely legitimate to have Inertia and build your entire web app that way and then have a companion API alongside it in the same monolith app (let's be clear: it's in the same application. It's in my Laravel app, or it would be in your Rails application) is because it just extends a core principle for me of what Inertia is. And that core principle is a tight coupling between my data layer so my controllers, and my views. So if we take that thinking where we say, well, Inertia in an Inertia web app when we have an endpoint, we hit the controller, we load data from the database, we pass that very specific data to the view, which is Vue or React or Svelte and it renders it. And there's a very tight coupling between the two. And I treated my native app in the exact same way. I said, “Okay, I need an API because obviously, the native app on iOS and Android has to make an HTTP request to get this data somehow. But instead of trying to create this super generalized API that could theoretically be used for anything, I use the same principle that said I'm going to allow myself to create an API that has a really tight coupling between the screens in my native apps and the actual data that's coming from those API endpoints. And this worked out really, really, really well. I don't have to deal with a lot of the issues that you run into when trying to create a more generalized API because I could just say, “Hey, I have this calendar page, and I want that calendar page in my particular app. I want it to show people's birthdays, and I want it to show wedding anniversaries, and I want it to show custom events and these things that we have called schedule reminders.” So it's data from four different endpoints. I didn't try to say, “Well, I'm going to go and create now my event's endpoint, and my birthday's endpoint, and my anniversary's endpoint, and my schedule reminder's endpoint,” and now have all that work to do in my native app to okay, we'll hit all these different endpoints and merge it all together; it wasn't like that at all. I created a calendar endpoint that returned all the data that's needed for that screen. And I basically applied that thinking through my whole native app, and it was really a joy to work this way. So I think that approach works really well if you have an app that doesn't have complete feature parity with your web app. And I think if you had a native app that needed absolute feature parity between the native app and the web app, then my thinking might be a little bit different on this. But in my experience, so often, native apps have a vastly reduced subset of the features that the web app has in particular, even if not for the core functionality of the application but just for the administrative side of it. There's a whole bunch of stuff that you tend to have in a web app around administrative stuff that you literally never need. And I mean administrative both in terms of it's a multi-tenant style app, which most apps are so in terms of the user's administrative functionality and in terms of the system level, the software owner administration. If you build your whole web app to be built on top of an API, all that administrative stuff that really doesn't need to exist in both places, you now have to make it exist in your API because you've made that decision to build it that way. Whereas if you just stick with Inertia on the web and just build it using that classic monolith way where you get data from the controls and send it to your Blade views or in this situation, client-side page views, and then you just expose the stuff that you actually need natively, for me personally, it's worked out so well. And if I look at my own web app, the amount of controllers that I have for the whole web app, I have like 100; it's a very big app. And for my native app, I have about 10. So that was like, I'm so glad that I didn't have to create 100 of these in both places. And then some people will be like you might be thinking, well, now I have duplication. I have duplication in some of my API endpoints and my web endpoints, and that's true. I would say first that duplication isn't always a bad thing. I think more duplication in our web apps would actually probably lead -- I feel like we run away from duplication too quickly. I don't think duplication is as bad as software developers often think it is. But even then, if with the duplication you can't live with yourself, there are still ways to solve duplication. So Laravel, for instance, has this concept of they're called API resources, which is basically they're essentially transformers. You give it some models, and it transforms that model into some other states, some other design. So there's nothing stopping you. And I even did this myself within my server-side application within Laravel to have an API resource to have a transformer that's used by both my Inertia controller and my API controller in a couple of situations and for me, only when it makes sense. I'm not going to do it all the time because I found that most often, I wanted the data in a slightly different format in my native apps than I'd want it into my web app. So quite often, that didn't happen. But I'm just saying if you're scared of duplication, there are totally ways to solve it. And we can solve this in our existing frameworks. Laravel or Rails has ways to allow us to abstract some of that stuff and reuse it in multiple places. So, yeah, that's my long-winded answer to how I've approached doing the native apps sort of thing. I think that tight coupling between the data and the screen I think that's a really nice thing, and you just can build faster. And just like you can build faster with Inertia on the website, you can build fast [inaudible 43:19] CHRIS: Frankly, that answer makes a ton of sense one and two, makes me feel better about the path that I'm on because, again, I'm really desperate to cling to Inertia for the web side of things. So I love what you're saying. And again, it really resonates with me and how you're thinking about building. There's also I really appreciate a subtle common theme that I've seen in a bunch of things that you've said where you're like; let me poke at best practices a bit and see what falls out. What if we were to actually embrace the coupling between our data and our view layer? And it's like, actually some really nice things happen there. And actually, going back to an earlier project that you worked on, Tailwind CSS is one of those projects that when you first see it, you're like, well, that's obviously wrong. That's definitely an incorrect way to do things. But then you explore it, and you're like, well, I mean, I know there are trade-offs here, but actually, in my experience and I'm sure in your experience, Tailwind is absolutely fantastic. And the trade-offs you totally win in the long game, and it's maintainable, and it's understandable. And you can continue to develop on top of it in a way that I've never found with any other CSS framework. But again, at first glance, you're like, ooh, that's not right. That can't be right. JONATHAN: 100%, exactly. I think it's fun to push back and just experiment with different things. And for me, I think a lot of my decisions, too, come back to the fact that I'm running a SaaS application as one person, and I need to be able to move fast. I don't want to have two different servers and two different repos. I want to be able to build my applications as fast as I can, as a single developer, a single founder. And so I think the things that I push against and try and experiment with come out of me trying to find the simplest ways to maintain things. So Tailwind, that's really Adam's brainchild. I came along in the first six months or so; me and him built it. I was really just helping him flesh out his idea there, and that was super fun. But yeah, I had the exact same experience as you. Adam was telling me about this, and I'm like, that sounds pretty terrible. Like, I have CSS figured out already. And then it was like, oh man, this is amazing. Fun little fact, my SaaS app, me and him, were both working on web apps at that time. So my SaaS app was one of the first Tailwind applications ever because I and Adam were literally both building our own apps while building Tailwind CSS. But anyway, so yeah, it comes out of not me trying to be like, I know better than other people; it's not that at all. It's more just I'm trying to find a way to survive as a business and trying to build at the same time, not only survive but also I want to build awesome products. I don't want to build software that is just kind of okay. I love striving to make software that's just exceptional that delights people that works the way someone expects it to work. And I just think that there's so much broken software out there. There's a lot of bad software. And don't get me wrong, I've created a lot of bad software, too. But I really try to hold myself to a high standard. And really, for me, that comes down to not necessarily what some purist says that “This is how you need to do it.” It comes more down to like, okay, let me see the results. How fast does the webpage open? What's the performance? You mentioned my course earlier. I'm really, really interested in database performance and how to use databases more intelligently to deliver really fast web applications. And that matters to me because customers hate waiting. They hate it. And that was even part of what drove me to create Inertia because I hated this. I was working for a company, and we had built the right way where we have an API and the client separate And we went down that road. And that was a big team with 20 to 30 developers in the end. And I was just like -- I shouldn't say, “I was,” but we, in general, were not happy with what happened because just the way that the app was built and the way that single views were hitting the API. You could probably argue that this was like we were doing something wrong, but the paradigm didn't lend us to doing it right, in my opinion. So we'd have pages that were hitting the REST API with sometimes 10, 20 HTTP requests just to get the data. And you're dealing with all the loading states of all this stuff. And of course, there were probably better ways to design, but we were trying to ship a product there too. We were trying to get it out the door and make happy customers. And I didn't feel like that way was helping us. I think GraphQL, just as an aside, is a huge step forward where you can say, “Hey, here's all my data in an API, but I'm not going to hit the user's endpoint just to get back whatever you decide to give me.” I can be much more intentional about saying, “Hey, I want this data and then pull in this relationship for that data and this other piece of data.” And I think that's really, really cool. But I think the problem there again is you need to build that GraphQL API, and that's non-trivial, not to mention you probably have to figure out OAuth, which is pretty much always a game-stopper for me because if I never have to work with OAuth in my life [laughs] I'll be totally okay with that. I know it has its place, but yeah. CHRIS: There's a clear passion and a desire that you're describing there to just build good things and the belief that it can be done. And then, as someone who has really benefited from your work, I thank you for carrying that torch and for pushing the envelope. And like you said, having that high standard and holding yourself to it but then hopefully bringing the rest of us along, and I really appreciate that. But I think with that, that's probably a perfect time to wrap up. If folks want to follow more of what you are working on, where can they find what you're up to on the internet? JONATHAN: I'm on Twitter, the classic place to go for following someone in tech, so twitter.com/reinink, my last name. That's R-E-I-N-I-N-K. So that's where even if I have stuff shared elsewhere on the web, that's where it starts. CHRIS: Perfect. We'll include links to your Twitter as well as everything else that we've mentioned in this episode in the show notes. So folks that do want to keep up or investigate further listening to that other podcast episode that I mentioned will have all of that available. But with that, thank you so much for your time, and yeah, again, really appreciate you joining. JONATHAN: Thanks so much, Chris. Pleasure to be here. CHRIS: The show notes for this episode can be found at bikeshed.fm. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. If you have any feedback for this or any of our other episodes, you can reach us at _bikeshed on Twitter. Or you can reach me @christoomey, or you can e-mail hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week. This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

On this week's episode, Steph & Chris take a deep dive into all things technical debt. How do you know when your code has reached "good enough"? When might we purposefully knowingly take on technical debt? How do we tackle existing technical debt without halting new development? How can we tell high-interest, hair on fire debt from "ehh, it's fine" debt that we can let lie? Tune in to find out! This episode is brought to you by: ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy FusionAuth (http://fusionauth.io/podcast) - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code BIKESHED Rack::Timeout Sigterm (https://github.com/sharpstone/rack-timeout/pull/157) The Art of Code Comments - Sarah Drasner | JSConf Hawaii 2020 (https://www.youtube.com/watch?v=yhF7OmuIILc) Technical Debt Panel from thoughtbot (https://thoughtbot.wistia.com/medias/msdwdg790m) Gary Bernhardt on Full Stack Radio (https://www.fullstackradio.com/episodes/144) Sandy Metz - The Halflife of Code (https://sandimetz.com/blog/2017/6/1/the-half-life-of-code) Code Climate Churn vs Complexity Graph (https://docs.codeclimate.com/docs/churn) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

Sam and Ryan talk about how route-based code splitting makes SPAs more like traditional server-rendered apps, potentially negating many of their benefits. They also talk about how the intrinsic width of text affects flexbox-based layouts. Topics include:- 4:20 – Flexbox and intrinsic width- 27:40 – Does route splitting negate the benefits of an SPA? Links:- Daniel Schiffer on YouTube- Sam's YouTube video on building a Twitter clone- Rich Harris on Full Stack Radio

When’s the last time you read a manual or document to know how to use product features and functions? Ben’s new mantra: Write it down! Rather than repeat expertise, reuse content. Currently, Tuple’s most unreliable part is its online users list. Beat the competition by doing what others can’t do Ben and special guest, Adam Wathan (https://adamwathan.me/), address product pricing and licensing questions. Adam hosts Full Stack Radio, created Tailwind CSS, and authored Refactoring UI. He encourages writing simple and succinct stories despite complex information. Also, Adam describes how products on the market look sexy, but may not work well under the hood.

Derrick spent his birthday at the north shore of Lake Superior to disconnect and getaway. Yet, he found some time to brainstorm and problem solve for StaticKit. Ben’s back from Martha’s Vineyard, only to experience less positive updates for Tuple. For the first time, Tuple is shockingly “in the red” financially. So, he feels guilty about going away. Today’s Topics Include: Slow Growth: Substantially fewer Tuple trial signups than previous time periods Marketing and Sales Strategy: From being the new tool on the block to steady state where Ben has to earn new Tuple customers Bullseye Framework: Derrick re-read his go-to startup guide to select StaticKit’s repeatable traction channels Tuple’s Q4 objectives and key results (OKRs): Fill top of funnel to increase new email subscribers and trials to continue to grow Ben’s future plans to gather marketing and sales information/intelligence by advertising and appearing on dev-related podcasts Design Matters: Impacts people’s perception of product and builds trust Links and resources: Art of Product on Twitter (https://twitter.com/artofproductpod) Derrick Reimer (http://www.derrickreimer.com) Website Derrick Reimer on Twitter (https://twitter.com/derrickreimer) Ben Orenstein (http://www.benorenstein.com/) Website Ben Orenstein on Twitter (https://twitter.com/r00k?lang=en) Tuple (https://tuple.app/) Tuple’s Pair Programming Guide (https://tuple.app/pair-programming-guide) StaticKit (https://www.statickit.com/) Using Tailwind CSS with Next.js (https://statickit.com/guides/next-js-tailwind)  Level (https://level.app/) Slack (https://slack.com/) Zoom (https://zoom.us/) Upcase by Thoughtbot (https://thoughtbot.com/upcase) Traction: A Startup Guide to Getting Customers by Gabriel Weinberg and Justin Mares (https://www.amazon.com/Traction-Startup-Guide-Getting-Customers/dp/0976339609)  Ruby on Rails (https://rubyonrails.org) HubSpot (https://www.hubspot.com) Rob Walling (https://robwalling.com/) Drip (https://www.drip.com/) Adam Wathan (https://adamwathan.me/) Full Stack Radio (http://www.fullstackradio.com/) Syntax.fm (https://syntax.fm) Steve Schoger (https://www.steveschoger.com/) Elixir (https://elixir-lang.org) Recurly (https://recurly.com) Chargify (https://www.chargify.com)

Derrick’s short notice about not co-hosting this episode because of being on a plane, and Ben not knowing or planning what to discuss, who and what’s left? Updates and reports on Tuple and Tailwind. Welcome back Adam Wathan! Today’s Topics Include: Today’s Trend: Advisor/investor/founder journals and reports of accomplishments Serves as a way to stay in touch, build relationships, ask questions, and get feedback Three Tuple Reports Later: Things are still going good Programming meets Business: Gary Bernhardt commits to being future podcast guest Successful Tuple Shipments: Significant use of Webcam feature Pricing Options: Ben expresses concern over free trials or pre-paid plans to capture credit cards and emails Invite-only vs. Public Launch: Continue as is, or open Tuple up to all Tuple Update: Revenue is growing quickly, receiving 70-100 support tickets weekly, and room to add customers Tailwind Update: Adam launched first set of videos for Tailwind CSS course Tailwind Subscription/Price Structure: Yet to be determined Adam’s Prediction: Education and documentation determine open source winner Links and resources: Adam Wathan on Twitter (https://twitter.com/adamwathan) Full Stack Radio (http://www.fullstackradio.com/) Tailwind CSS (https://tailwindcss.com/) Refactoring UI by Adam Wathan and Steve Schoger (https://refactoringui.com/) Steve Schoger (https://www.steveschoger.com/) Tyler Tringas on Twitter (https://twitter.com/tylertringas?lang=en) Brian Casel (https://briancasel.com/) Gary Bernhardt on Twitter (https://twitter.com/garybernhardt) ExecuteProgram.com (https://www.executeprogram.com/) David Heinemeier Hansson (DHH) on Twitter (https://twitter.com/dhh) Giant Robots Episode 26: Deep into the psyche of Gary Bernhardt (https://giantrobots.fm/episodes/26) Giant Robots Episode 27: Fabulous new mistakes with Joe Ferris (https://giantrobots.fm/episodes/27) Giant Robots Episode 28: Farther, further, faster with David Heinemeier Hansson (https://giantrobots.fm/episodes/28) Node.js (https://nodejs.org/) React (https://reactjs.org/) Ruby on Rails (https://rubyonrails.org/) Zoom (https://zoom.us/) Superhuman (https://superhuman.com/) Screenhero (https://screenhero.com/) Slack (https://slack.com/) GitHub (https://github.com/) Art of Product on Twitter (https://twitter.com/artofproductpod) Derrick Reimer (http://www.derrickreimer.com) Website Derrick Reimer on Twitter (https://twitter.com/derrickreimer) Ben Orenstein (http://www.benorenstein.com/) Website Ben Orenstein on Twitter (https://twitter.com/r00k?lang=en) Tuple (https://tuple.app/) Tuple’s Pair Programming Guide (https://tuple.app/pair-programming-guide) StaticKit (https://www.statickit.com/) Level (https://level.app/) Level Retrospective (https://www.derrickreimer.com/essays/2019/05/17/im-walking-away-from-the-product-i-spent-a-year-building.html) Level Manifesto (https://level.app/manifesto)

Show Notes Start testing your Laravel applications by JMac The Wrong Abstraction by Sandi Metz Rule of Three by Bob Nadler Shape Up by Ryan Singer Tiny Decisions and Emergent Design on Full Stack Radio

Jake and Michael discuss all the latest Laravel releases, tutorials, and happenings in the community.

Panelist Jerod Santo and first-time panelist Adam Stacoviak talk with Adam Wathan of Full Stack Radio fame about his CSS utility library called Tailwind CSS that’s growing in popularity to rapidly build custom user interfaces.

Panelist Jerod Santo and first-time panelist Adam Stacoviak talk with Adam Wathan of Full Stack Radio fame about his CSS utility library called Tailwind CSS that’s growing in popularity to rapidly build custom user interfaces.

In this episode, Adam Wathan joins Chris and Jason. Adam, a full-stack developer, entrepreneur, Full Stack Radio podcast host, and author of Tailwind CSS spends some time sharing his journey into programming, how he got started with Laravel (PHP framework), how Ruby has influenced his software writing and the story behind Tailwind CSS. It was an honor to have him on the show; we hope you will enjoy it as much as we did.

If you listen regularly to the Art of Product podcast, then you’re probably familiar with the ongoing joke: How long does it take before we mention Steve Schoger and Adam Wathan? Well, today is your lucky day because not only do Derrick and Ben mention them, but Adam is once again their special guest. Adam is a software developer, writer, speaker, and entrepreneur. Also, he is the creator of Nitpick CI, host of the Full Stack Radio podcast, and author of Refactoring UI and Refactoring to Collections. He describes the process of successfully making, promoting, and selling courses on the Internet. Plus, Steve makes a special appearance to share his side of the story! Today’s Topics Include: Concept and Collaboration: How Adam and Steve work together to create courses Be genuinely helpful by offering free, good content for people to know, like, and trust you Build an audience/authority on a topic to make people want to learn from you Understand difference between what you care about vs. what your audience cares about Care about quality and effort put into all aspects; utilize Steve’s design tips on Twitter Signals and validation that your content resonates with and is helpful to your audience What Makes a Successful Partnership: Similar values, but complementary skills Promotion via email, newsletter, social media, case studies, and screencasts to grow number of subscribers/followers Courses: Parts and Pieces (Books, Videos, and More) and Pricing to Make ROI Launching Products and Surpassing Sales Expectations Links and resources: Adam Wathan (https://adamwathan.me/) Nitpick CI (https://nitpick-ci.com/) Refactoring UI (https://refactoringui.com/book/) Refactoring to Collections (https://adamwathan.me/refactoring-to-collections/) Full Stack Radio Podcast (http://www.fullstackradio.com/) Adam Wathan’s MicroConf Presentation (https://microconf.gen.co/adam-wathan/) Adam Wathan on GitHub (https://github.com/adamwathan) Adam Wathan’s Email (mailto:adam.wathan@gmail.com) Adam Wathan on Twitter (https://twitter.com/adamwathan) 7 Practical Tips for Cheating at Design (https://medium.com/refactoring-ui/7-practical-tips-for-cheating-at-design-40c736799886) Steve Schoger (https://www.steveschoger.com/) Steve Schoger on YouTube (https://www.youtube.com/channel/UCxqiDtkXtOCNJdckODHk9YA) Heroicons (http://www.heroicons.com/) Steve Schoger on Twitter (https://twitter.com/steveschoger) Wes Bos (https://wesbos.com/) Bootstrap (https://getbootstrap.com/) Stripe (https://stripe.com/) An eBook pricing model that resulted in $100,000 in sales (https://blog.asmartbear.com/selling-ebook.html) Art of Product on Twitter (https://twitter.com/artofproductpod) Derrick Reimer (http://www.derrickreimer.com) Website Derrick Reimer on Twitter (https://twitter.com/derrickreimer) Ben Orenstein (http://www.benorenstein.com/) Website Ben Orenstein on Twitter (https://twitter.com/r00k?lang=en) Level (https://level.app/) Tuple (https://tuple.app/)

Adam Wathan, a software developer, writer, speaker, and entrepreneur joins Ben and Derrick on this episode. Adam is also the creator of Nitpick CI, author of Refactoring to Collections, and host of the Full Stack Radio podcast. Usually isolated and working alone, Adam enjoys the opportunity to chat with others about what everyone is working on. It’s like a mastermind session that’s fun and rewarding! Today’s Topics Include: Ben launched Tuple’s Pair Programming Guide earlier than expected at learntopair.com Ben continues to focus on marketing for Tuple, while other team members are developing the product Derrick feels a sense of guilt when working, but not sharing; once you get out of the habit of working in public, it might be difficult to return to it Derrick is up against his deadline of having a deliverable by the end of October Pros and cons of working alone or with partners to handle tasks/responsibilities Rails vs. Laravel Battle? No, PHP as a language battles with no one Adam is working on a refactoring UI book/design survival kit; chapters are independent and pricing still needs to be established What are digital vs. physical perks you could offer to those who purchase a product first? Derrick has been getting Level ready for alpha users and spending time, more than he wants, to get file uploads to work on it Links and resources: Adam Wathan (https://adamwathan.me/) Nitpick CI (https://nitpick-ci.com/) Refactoring to Collections (https://adamwathan.me/refactoring-to-collections/) Full Stack Radio Podcast (http://www.fullstackradio.com/) Adam Wathan on GitHub (https://github.com/adamwathan) Adam Wathan’s Email (mailto:adam.wathan@gmail.com) Adam Wathan on Twitter (https://twitter.com/adamwathan) Derrick Reimer (http://www.derrickreimer.com) Website Derrick Reimer on Twitter (https://twitter.com/derrickreimer) Ben Orenstein (http://www.benorenstein.com/) Website Ben Orenstein on Twitter (https://twitter.com/r00k?lang=en) Level (https://level.app/) Tuple (https://tuple.app/) Pair Programming Guide (https://tuple.app/pair-programming-guide) Product Hunt (https://www.producthunt.com/) Extreme Programming Book (https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658) Laravel (https://laravel.com/) Ruby on Rails (https://rubyonrails.org/) Steve Schoger (https://www.steveschoger.com/) Colorbox by Lyft (https://www.producthunt.com/posts/colorbox-by-lyft) Tailwind CSS (https://tailwindcss.com)

Adam Wathan is the host of Full Stack Radio, creator of Nitpick-CI, co-founder of Refactoring UI, and creator of Tailwind CSS. We discuss his path to publishing his books, why he prefers utility-first CSS frameworks, and the many other side-projects Adam has created and works on. Featured Links: Tailwind CSS Refactoring UI Full Stack Radio Nitpick-CI Personal website Test-driven Laravel

Jake and Michael return after a two month (!!) summer hiatus

Show Notes Full Stack Radio Refactoring to Collections Test Driven Laravel Advanced Vue Component Design Refactoring UI Full Stack Radio Episode 5 with Ryan Singer

Derrick continues to code to make progress on things he will need to build at some point for his product, Level. Also, he spent a lot of time in Elm land for refactoring and additions. Will Elm code work for scaling necessary for Level? Derrick is still trying to decide. Ben’s team at Tuple has transitioned from C++ to Swift, a newer and friendlier language. Also, Tuple hired a consultant as a sanity check and to be pointed in the right direction for building a native app on Mac. Initially, the consultant will help step up and build with dependencies needed. Today’s Topics Include: Level App: There’s a lot of work to do and time is flying by; not sure when it’s going to be ready, but every day, make progress More than 800 people have signed up for Ben’s Code Quality Challenge; people engaged in it are getting value, doing useful things, and improving their apps Advantages of building your network up online; they share and inquire about info you post Types of tips that spread fast, including bash, shell, and git Ben plans to reach out to people to make podcast appearances to promote Tuple Ben stepped away from sales, but now plans to make money for the company his #1 priority; difference between self-funding and bootstrapping Being in a constant state of push-and-pull; when to do this/that and change directions If you’re interested in entrepreneurship, read Shoe Dog by Phil Knight; jumping through hoops and funding a company Check out Founder to CEO by Matt Mochary, who coaches tech startup CEOs in Silicon Valley; what do you need to know to grow? Friendly reminder if you’re going camping this summer, remember to take mosquito repellent with you! Links and resources: Derrick Reimer Website (http://www.derrickreimer.com/) Derrick Reimer on Twitter (https://twitter.com/derrickreimer) Ben Orenstein Website (http://www.benorenstein.com/) Ben Orenstein on Twitter (https://twitter.com/r00k) Level (https://level.app/) Tuple (https://tuple.app/) Elm (http://elm-lang.org/) Richard Feldman on YouTube (https://www.youtube.com/results?search_query=richard+feldman+elm) Swift (https://developer.apple.com/swift/) Derrick Reimer on Startups for the Rest of Us (https://www.startupsfortherestofus.com/episodes/episode-399-how-derrick-reimer-is-validating-his-ambitious-third-saas-application) Derrick Reimer on Full Stack Radio (http://www.fullstackradio.com/92) Ben Orenstein’s Code Quality Challenge (https://www.codequalitychallenge.com/) Ben Orenstein’s Shell Tricks Post (https://twitter.com/r00k/status/1013970705229197317) Shoe Dog (https://www.amazon.com/Shoe-Dog-Phil-Knight/dp/1508211809) Founder to CEO (https://docs.google.com/document/d/1ZJZbv4J6FZ8Dnb0JuMhJxTnwl-dwqx5xl0s65DE3wO8/preview)

An interview with Adam Wathan, co-creator of the Tailwind CSS library and author and video producer. Adamwathan.me Test-Driven Laravel Refactoring to Collections Advanced Vue Component Design Tailwind CSS Alberta Oil Sands Reaper Conestoga College Vehikl Desire2Learn Tighten Nitpick CI Adam Wathan's $100k product launch Full-Stack Radio Mark Rippetoe - Starting Strength 5/3/1 Video of Adam lifting tons of weight 5/3/1 calculator Matt's WeightXReps Training Journal Agile Principles, Patterns, and Practices in C# Adam on Twitter Refactoring UI Editing sponsored by Larajobs Transcription sponsored by Tighten Matt Stauffer: Welcome back to the Laravel podcast, season three. Today we're talking to Adam Wathan; author, video maker, teacher of the things, power lifter. Stay tuned. Matt Stauffer: All right, welcome back to the Laravel podcast, season three. This is the version of the Laravel podcast where we get to know less about tech and more about the people behind the tech, and today my guest is none other than Adam Wathan who has taught us all about testing, collections, view, components and many other things. One of things I love about Adam is that he's never satisfied with what's happening around him and he's always taking in stuff from other places, and we'll talk about this more probably later in the podcast, but when I describe Adam to other people, I say he's the guy who basically finds what's good everywhere else and brings it to us in the Laravel world. So if you haven't heard of Adam, my mind is blown. You should go consume everything he's ever made; it's all gold. I will say to some of y'all that his name is pronounced Wa-than, right? That's right? Adam Wathan: Yeah, you got it. Matt Stauffer: Wa-than. Not Way-thin, not Way-than. I'm trying to think about other things I've heard, but Adam Wathan. So Adam, say hi to the people, and the first question I always ask everybody is when you meet somebody in the grocery store how do you introduce yourself? How do you tell them what you do? Adam Wathan: Cool. Yeah, so thanks for having me on. I'm Adam. I usually explain ... It depends on what people ask, because some people ask like what do you do? I say I'm a software developer, although I don't actually get paid to write code, I get paid to teach people about code. So I either describe myself as a software developer who creates courses and e-books and training products for other software developers who are looking to kind of level up. So that's kind of the shortest version that I try and give to people that usually is enough that they kind of either are interested in it and ask me more questions or aren't interested and don't want to hear anymore. Matt Stauffer: Yeah, so I'm already going to cheat a little because I want to ask one little thing about your motivation that I've been curious about for a while and hopefully they'll still come out when we talk about your background but, you know, you're really smart guy, you learn a lot of stuff, but you're also a teacher and you also have like marketing kind of like sensibility, and you just gave an elevator pitch that would make someone who doesn't even understand programming want to go sign up for your product and I don't think that that's really common for a lot of us to know how to talk about it that well, so ... And if this is going to come out later that's cool, but do you have a sense for where your ability to kind of understand how to market something and how to ... And you talk a lot about how to do it in a non-skeezy way, but where did that come from? Is that something you had to work on, or do you feel like you've got some experience that's kind of taught you that? Adam Wathan: That's a good question and I don't think I have a great answer for it. I think I've always just really liked creating things that I was proud of and putting them out into the world with enthusiasm and I think that's been kind of like the simplest version of how I have always tried to share what I've been working on and then I think with the marketing stuff too, I guess I just care just as much about the quality of that as I do about everything I do. I just really like to make everything I do as good as I possibly can and that comes down to even things like, you know, landing pages and how things look on stuff like that. To me, the marketing is a product too and I want it to be good and I want to be proud of it, so it's just something that I just put a lot of effort into I guess the same way I would with something else. Matt Stauffer: Yeah, I mean, I tell this story to people all the time, but when you first joined Tighten, one of the things we were talking about was working on some open source projects together, and we immediately found a conflict in our ways of working where I was like, so what I do with this thing Symposium is I figure out a feature and I spit out the feature as fast as possible and then I move on to the next feature, and you're like what I do is I try to figure out exactly the best way to do this feature and I ponder on it and I make plans and I make diagrams and I get it exactly right so people will really get their needs met and then and only then do I actually build out a feature. Matt Stauffer: And we kind of had this like little head butt moment, and I think that I've kind of ... I would say I've shifted to your way of thinking, but I've been influenced by it a lot. Do you have a sense for where your kind of desire for excellence ... I think you were just talking about like where that comes from, is that just a personality trait? Is that something from your family, and what's that ... Where does that come from? Adam Wathan: I think it's just a personality trait. I've been like that with basically everything that I've ever been interested in my entire life. Like I would sit and play guitar and play the exact same seven notes for four hours straight until I played them perfectly, you know what I mean? So I think I just get a little bit obsessive over the sorts of things that I get interested in. Matt Stauffer: Yeah, I just want to get really good at it. All right, well, I'm sure we'll dip into the stuff a little bit more, but I do want to make sure that I actually have the space for your back story. So the second question I always ask everybody is, where was it that you ... Or what was the context in which you first had interactions with a computer? How old were you and kind of what was your interaction like at that point? Adam Wathan: Yeah, so I have sort of conflicting memories for a lot of some of the stuff. Not necessarily conflicting, but sometimes I have a hard time figuring out like what the timeline was, but some of my earliest memories of working with computers, probably the earliest one that I can think of. is when I was in grade ... It must have been probably grade two, maybe grade three, but I had this librarian at my school who worked with like some of the gifted kids to do little projects and stuff and me and him were working on the super old Mac that we had at the ... It was new at the time I'm sure, right, but like my memory of it's like the old school Mac where everything's black and white and stuff like that. Using hypercard to make this little project we went around and it was actually pretty cool. Adam Wathan: We got to like drive around the neighborhood and I got to like ask questions like different business owners about things and we put together this like little presentation in hypercard, and that's probably like my earliest memory of working with a computer and we got a computer in my family when I was pretty young too, probably grade four or grade five. It was just like kind of your standard ... It was like an Acer or Compaq PC or something with four megs of RAM and, you know, I can't even think, a 500 megabyte hard drive, and we got- Matt Stauffer: Yeah, a 486 or something like that. Adam Wathan: Like our internet a couple years later. Yeah, it was a 486 and I used to dick around on that, you know, looking up game tutorials for my Sega Genesis at GameFacts.com and stuff like that and- Matt Stauffer: What's the best game on the Genesis? What's your favorite, do you remember? Adam Wathan: Favorite Genesis game. I used to play the hockey games a lot. That was probably what I got- Matt Stauffer: You're so Canadian. Adam Wathan: The most fun out of. The funny thing is like I'm not super into hockey, but those were just the most fun like multiplayer games that you could play. That and like Mortal Combat and Street Fighter. Matt Stauffer: Yeah, of course. Adam Wathan: And all the classics. I didn't do much of the single player stuff, just mostly hanging out with friends and playing. Matt Stauffer: No Sonic and Knuckles and things like that? Adam Wathan: I did play Sonic, but I wouldn't say like I have, you know, nostalgic memories about how much I loved that game or whatever. It was a fun game but, yeah. Matt Stauffer: Yeah, I feel like not a lot of people have the same level of memories of Sonic as they did at Mario. I just never quite connected in the same way. Adam Wathan: No, Mario definitely has a more special place in people's hearts, I think. Matt Stauffer: Yeah, you actually got into this a little bit, but my next question is going to be kind of what was your first exposure to the internet? So was that primarily it at least at the start? Adam Wathan: I'm not sure if it would have been at school or at home, but yeah, it would have been most of the time that I spent on the internet would have been at my home desktop computer on our 14.4 connections we used to use. Matt Stauffer: Yeah. So when you were in middle school and high school, what do you think you wanted to do with your life? Did you know? Adam Wathan: I had some conflicting thoughts, so at one point when I was a kid I wanted to be a cartoonist, that was my dream actually. Matt Stauffer: I had no idea. Adam Wathan: I used to draw all the time and I used to like ... You know how you'd have like the book fairs at school, I don't know if you had those in the States. Matt Stauffer: Yeah yeah, Scholastic. We had them here. Adam Wathan: The Scholastic Book Fairs. Matt Stauffer: Yeah. Adam Wathan: I'd always be ordering like the how to draw this or the how to draw that books and I never got really good at it, but it was fun and then eventually I got into like playing guitar and stuff like that and I wanted to be like an audio engineer, but I also wanted to be a programmer and I really liked my programming classes in high school, so I ended up going to university for computer science, but I also considered going to college for music industry arts, which is a program that actually Steve Schoger, who some people might know actually did go to at the college that I used to go to. Matt Stauffer: Oh, he did? Adam Wathan: But I decided against it because it just didn't seem like a profitable career path, so I eventually chose computer science. Matt Stauffer: So you had programming classes in high school. Was this Java or C++ or what kind of stuff were you guys doing there? Adam Wathan: Let me think. So I think we ... I don't think we had computer programming classes 'till like grade 10 and we did a lot of like Pascal and we did C, and we did Java and then we have a web one which was later, which was kind of weird because the Java stuff was ... Even the Java stuff isn't ... When I think back to the fact that we did Java in high school, I don't remember doing any of the stuff that I know about Java now. Like I didn't know what object oriented programming was when I came out of high school, even though Java is an object oriented language. We just would write procedural code in like our main- Matt Stauffer: Good job, yeah. Adam Wathan: Java file or whatever, right? Matt Stauffer: Yeah. Adam Wathan: And stuff like that, but yeah. Matt Stauffer: What made you choose those classes? Adam Wathan: I think I just thought it was really fun to be able to make the computer do stuff. Matt Stauffer: Yeah. Adam Wathan: So I remember like one of my earliest memories of programming actually is when I was a kid I was like super obsessed with pro wrestling, that was like my thing. And I used to download all these like wrestling simulators so you could like ... It's so funny because they weren't ... they're not like games, right? They're like you create characters, you choose their move sets, you give them the statistics and stuff and then you like run simulations and it would spit out like texts, like this guy punched this guy, then this guy powerbombs this guy- Matt Stauffer: Right, and you're not actually controlling what they did, right? Adam Wathan: No, no, no. It's just a computer simulation based on random events- Matt Stauffer: That's fascinating. Adam Wathan: As well as like, you know, the statistics and attributes of the different wrestlers. There's a couple different programs that you could use to do that and I was always looking for different ones to test them out, and then one day I stumbled upon a tutorial online that was like make your own wrestling simulator in QBasic. Matt Stauffer: Oh, nice. QBasic, yes. Adam Wathan: And I was like, okay. And that was my first exposure to QBasic. I followed the tutorial and got everything set up and I didn't know how to like do random stuff or anything like that, so I never got very far with it. It was all just very like ... It was not like conditional logic or anything, you would just do this, this, this. Matt Stauffer: It just takes input- Adam Wathan: I couldn't figure out how to make it do exactly what the other things are doing, but I could make the computer do stuff, and that kind of got me interested in the whole QBasic programming stuff and then I just started looking into more like QBasic tutorials and finding out stuff that you could do, and I remember getting really into ... I don't think I'll ever remember the actual name of it. I found a site that I think might have been it, which is Pete's QBasic tutorials, which I don't know if that was the site for sure, but some of the content looked really familiar, but it had lots of tutorials on like making like tile scrolling RPG engines in QBasic and stuff and- Matt Stauffer: What? Adam Wathan: Where you could create like little sprite characters and you'd make these like 20 pixel by 20 pixel squares and lay them all out and make it scroll as you use the keyboard and stuff like that. So one summer I had this dream of making an RPG, which of course never even remotely happened, but I had a lot of fun just hacking around on the computer getting it to render this stuff and do stuff like that. So I think that's where I really got excited about programming because I don't know if I have a specific passion for programming more than anything else, but it was just like a really perfect kind of platform for just doing creative things, you know what I mean, and making stuff. It's the most like powerful tool for just like making interesting things that I know of so far, right? Matt Stauffer: Yeah. Adam Wathan: So I think that's what kind of got me into that. So I did a bunch of QBasic stuff messing around with that and eventually I started making my own little websites on Geocities an Angelfire and stuff like that and yeah, I've kind of been doing that ever since, so. Matt Stauffer: Yeah, I was thinking about how creation was definitely a trend for you. I mean between music creation, you know, as a guitarist and music production, you know, and the art and everything like this is it's wanting to make things happen and figure out what the tools are, so it's interesting hearing you say, you know, it's the most powerful tool that you can use for that. Adam Wathan: Yeah. Matt Stauffer: Do you ever draw still? Adam Wathan: No, not at all. Matt Stauffer: Do you have any of your old drawings anywhere? Adam Wathan: I might. My parents just sold their house and gave me a big box of like crap lying around that was mine. Matt Stauffer: You got to find something, man. Adam Wathan: I think there's a couple sketchbooks in there so I should maybe- Matt Stauffer: That would be amazing. Adam Wathan: Dig through those. Matt Stauffer: Please. Okay, so you went off to school for computer science and did you have a sense ... Did you have any shifts during school with what kind of aspect of CS that you were interested in or if ... And yes or no, what did you think you were going to do afterwards? Adam Wathan: Yeah, so I actually only went to the university for a single semester, so I did the first semester a bunch of the classes I did find fun like the ones that were direct programming, so we had like a C class where we'd basically get these weekly kind of projects that we have to work on where just have to go through a bunch of problems to get the computer to do that stuff, and that was the stuff that I was really interested in and really excited about, but then we also had classes that weren't as interesting, like digital fundamentals and stuff related to more like computer engineering sides of stuff which is interesting, but it didn't get me excited and want to work on it. Adam Wathan: That stuff was like a chore, and at the time I was also playing in a band and we ... That was all I wanted to do. Like we were playing shows and recording demos and stuff like that, so the computer stuff was not really a big focus for me at the time and I was commuting to school which was about a 45 minute drive away and living at home, so I didn't really get like embedded into the sort of university community that was there. Adam Wathan: So I didn't really like make any friends or meet anyone, I was only there for classes and that was it. So it was really hard for me to sort of, you know, become a university student. That was like this thing on the side I felt like for rest of my life, where my friends were and my hobbies were and stuff like that, so I only stuck with that for a single semester and then dropped out to just basically work full time while I reconsidered what I wanted to do, because it just ... I just wasn't enjoying university and I don't think it was the programming that I wasn't enjoying, it was just the educational side of it and having to get pulled away from the things that I was actually excited about to work on that. So I don't remember what the original question was, but that's kind of that story. Matt Stauffer: Well, no, and that's actually perfect and before I move on from that, I want to ask one question which is, was the distinction between doing versus learning abstract theory, was it about how concrete something was that was the difference between what you did and didn't like, or did I kind of miss that a little bit? Adam Wathan: No, I think that's true. I think the other thing is there's just a lot of classes that you have to take in university that aren't as ... they're not all really like cohesive, you know what I mean? I don't know what the system is like in the U.S., but in Canada we have university and college, which I think is kind of like college and community college in the U.S. Matt Stauffer: I think so, yeah. Adam Wathan: But the way that you pick your classes and stuff a lot of it is you have to go into the school and you have to go and sign up for different classes and you have different requirements, and you have to get credits and different things, but a lot of it is kind of up to you and they don't really put together like a cohesive curriculum. So I had to have X Math credits, X Elective credits, so I took like this history of music class, which is the only class I've ever failed in school in my entire life. Matt Stauffer: Oh, my God. Adam Wathan: And you would think that I ... Just because it's so damn boring, right? Matt Stauffer: Yeah. Adam Wathan: And I just like couldn't get into it at all. But everything was just kind of disconnected. There was like some math over here, some physics over here, and because at the early stages of things it's kind of like when you're in like first year of high school or something, they're just trying to teach you all these fundamental concepts- Matt Stauffer: Basics, yeah. Adam Wathan: Without kind of tying them back to the goal they you're trying to get into and I ended up going back to college years later which we can talk about maybe a little bit later, where the curriculum was much more cohesive and everything is sort of designed to teach you to be a programmer, and I really liked that experience. So yeah, I think it is just the fact that there was only one class that I actually liked, which was the programming class and everything else just felt like high school all over again, you know. Matt Stauffer: Yeah, yeah. No, I totally hear that. I mean there's a lot of conversations happening these days and I'll wait to go into them until we talk more about your later school experience, but around trade school versus university, versus whatever else and what are the pros and cons of each and I think a lot of it ... You know, one of the things I've come down to recently is that I've always been a pro university person with lots of caveats, and one of them is just like the school you're at really makes a big difference, and the classes you take and the professors you have. You know, there's a lot of factors that can give you a very, very, very, varied experience, even in the same type of program in the same type of school. So where did you go from there? You said you kind of were reconsidering your working full time, you were recording with your band and were you doing any touring at that point, too? Adam Wathan: No, we never got successful enough to do anything interesting like that. I was local shows and stuff, but yeah, so I was just working like crappy factory jobs basically. I'm trying to think what was the first job that I got after I left university. I have to try and reconstruct a time line, but the one I remember most specifically was working for a company where I was basically just in a factory building really high-end like antique looking stoves. Adam Wathan: So I did that for like a year while I still played in bands and did stuff like that and then eventually a friend of mine was working up in the Alberta oil sands like way up north and I would have all these construction projects to extract all the oil out of the sand and sell it of all over the world, and his dad actually ran the site up there so he had a lot of pull and one day he just called me and he was like, "Hey, do you want a job up here?" And I was like, "Sure." He's like, "Someone's going to call you tomorrow and offer you a job." And I didn't know- Matt Stauffer: That's awesome. Adam Wathan: What it's going to be. Like I had never seen the job description or anything, but this is just this guy's kind of style and so ... Yeah, I ended up working up there for two years doing like basically data entry stuff for the materials team, so I worked in an office in the frigid cold in Fort McMurray where it's like minus 50 degrees Celsius in the winters. Matt Stauffer: Holy crap! Adam Wathan: Our offices are these little portable trailers on the construction site and I was just there basically in Excel reconciling like purchase orders and invoices and making sure that, you know, we received the materials that we had paid for and that all this ... Just a bunch of really kind of monotonous data entry stuff, but for being like a 20 year old kid it paid really well and I did that for like two years until kind of that whole industry and economy started to suffer a little bit more because gas prices and oil prices dropped and they did a bunch of big layoffs which was ... So I got laid off, which was like a blessing in disguise really because I know a lot of people that basically just stayed up there forever because you can never get paid the same thing to come home. And I would work up there for 14 days straight, 10 hours a day and then they would fly you back to where you lived for seven days off. So I was constantly flying back and forth. which just made it really hard to have like a normal life, right? Matt Stauffer: Yeah. Adam Wathan: So yeah, I got laid off from that, came home, decided I would use that chance to try and get into like the recording stuff, because I was getting into recording a lot when I was up there and doing it when I was coming home just as kind of a hobby, but I thought why don't I try and like find some bands and record and like mix EPs for them and stuff. So I did that for like a year, which is a dumb industry to get into because bands don't have money, especially local bands, so you can't make a lot of money doing that, but what I found is while I was doing that I was using this tool called Reaper, which I still use out of my podcast and stuff like that, and I found that there was a bunch of features that I wished it had that it didn't have, and it was created by the guy who created Winamp originally, and it's like a very hacker friendly tool, so it lets you like extend it with Python or C++ or Lua now as well, so you can write all these sorts of like plugins and extensions for it and the API that they give you to do that stuff is like very powerful, you can access basically everything in the tool and write your own menu options and dialog boxes and all sorts of features and stuff. Adam Wathan: So I started getting into like hacking around with that doing really simple things and then one of the guys in the IRC chat for the software, kind of like this elite group of people who are like hacking on stuff there. I made this thing using Python and he was like, "You should port this to C++ so we can include it in this big extension that they maintain." and I was like, "I'd love to do that, I just don't have any idea how." and he's like "Well, okay, I'll help you." So for the next little while he would kind of like ... He kind of put together like a playground in this extension source code for me to like write my features in and help me figure out how to get XCode compiling it and all this different stuff, and that's when I kind of really like reignited my excitement and passion for programming because I was just having so much fun adding features to this tool and making it easier for me to do my work to the point where I was having way more fun adding features to the tool than I was actually using the tool to record bands. Adam Wathan: And I didn't even get back into web development or anything at that point. I hadn't made a website since like high school. So that's when I decided you know what, I think I'm going to go back to college and do this programming thing again, but I decided to do college and study university specifically because I knew like what I didn't like about university and I wanted to do something that was a lot more practical and focused on making you into a programmer than it was, you know, educating you about computer science. Matt Stauffer: So I had been meaning to ask and that's helpful. Are you familiar with the concept of a trade school? Adam Wathan: Yeah, like where you would go to learn to become like an electrician or something like that? Matt Stauffer: Yeah, that's not the same thing, right? You're more talking about it's a school, but it's more like single focus sort of like our community colleges, but I was wondering whether colleges like a little bit different than communities or if it's just- Adam Wathan: Yeah, I'm not sure. So the college I went to is Conestoga College. I'm going to pull up the website now, but basically here college programs are usually two-year programs and you get a diploma, and university are four years and you get a degree, that's kind of the fundamental difference. So I'm going to try and pull up like the actual program that I did here so I can kind of talk a little bit about the actual curriculum because I think it's kind of interesting. Matt Stauffer: While you do that, this is definitely similar to community college. It literally even in the Google preview says your community ... Ontario Community College and this is definitely not trade school, definitely community college, if that makes sense. Adam Wathan: Yeah, so I did the software engineering program there, and not the computer programmer course, which I got kind of turned on to that by asking around to friends who had gone to the school to kind of figure out like, you know, what are you supposed to do, but if you look at the actual program courses here we can maybe like link to this and then show it to people that are interested, but like in the first year we had classes like software engineering fundamentals, operating system fundamentals, C, C++ programming, computer security, object oriented programming, some of this has changed, but then year two we did like web design and development, relational databases, Windows and mobile programming, microprocessors and embedded systems, software quality, so like in school we learned about automated testing, which is pretty cool. Matt Stauffer: Nice. Adam Wathan: You never learn that in university. Advanced computer security, mobile application and development. Yeah, so it was just like all programming. Every class was programming, but it was just focused around some different kind of element of it using different technologies and stuff like that. So the nice thing about that is that college is really close to my house and unlike university where the schedule it's like really weird, sometimes I'd go to a three-hour lecture and then have seven hours off then have to go back in the night for a one-hour class. Like this is structured so much similar to high school, you know what I mean? Adam Wathan: Like you'd get there in the morning, you'd leave in the afternoon, so you're there for a long period of time, you get to like meet people, you get put on projects with people, and I really got into what I was doing there in terms of like I made a lot of friends, you know, that kind of became like my focus which was I think what made me not stick it out in university. It was just like such a side project, whereas I was able to really sort of like embed myself into what we're doing in this program, so- Matt Stauffer: That's really interesting. Adam Wathan: Yeah, that went really for me. So I did that for two years. It's a three-year program, but the way they do it is kind of weird. They have like three years with co-op, I don't know if people use that term in the U.S. It's kind of an internship- Matt Stauffer: I don't think so. Adam Wathan: Like paid internship. Matt Stauffer: Oh, yeah. Adam Wathan: So if they do like two years of schooling and then for 18 months you go out into the workforce. There was like four work terms across those 18 months I think, something like that. And some people do them all the same company, some people do four different ones, some people split up however, but you get paid to do that, which is pretty cool like 18 bucks an hour or more depending on who the employer is, and then once you're done that kind of co-op internship stuff, you go back and do your third year of schooling and then you get your diploma and then you're done. Matt Stauffer: Oh, cool. Adam Wathan: So I just did the first two years, and then I did my co-op at Vehikl who were called Chrome Media at the time, and I think I was like the only person to apply for that job because everyone else was trying to get a job at Desire2Learn which is a company that makes like education student management software, and it's all C# and Windows stuff and that's what they teach us in school so that's what everyone was excited about and they were kind of like the cool, hip company in the area, but I was like the only kid in my class that used a Mac, so doing the Windows stuff was painful for me. I had to like boot up a VM and do stuff like that, so even with all our projects I would do in school I was always trying to find technologies that I could work with easier on my Mac. Adam Wathan: Because we had a lot of like web based projects, even though we didn't have a lot of web specific courses, but in the later years we'd have like a project that was a two-month project and you could choose the technology, which is cool, so some people did C#, some people did, whatever. I chose PHP because that was the only programming language I knew of that you could do dynamic stuff on the server. Like at the time I didn't know that oh, you can use Ruby to do that or Java or any of these other languages, I just knew from like trying to create PHP scripts I could accept form submissions when I was 16 years old that like PHP was the language that you do ... I used to do stuff on the server, so I started looking into, you know, tools for PHP that could compare with like ASP or C#. Matt Stauffer: Like MVC. Yeah. Adam Wathan: That like framework and I found my code igniter and stuff like that and so we started messing around with those sorts of things, and I was lucky enough to find a handful of people that wanted to work on those technologies with me instead of doing the C# stuff and they were all pretty bright people, so we did a bunch of projects using that stuff and then when it came time to look for co-op opportunities I applied to Desire To Learn and they never got back to me, which is great because if they had and I had gotten a job there I'd probably still be a C# developer now. Adam Wathan: Instead I saw this tiny, little company that was only three people at the time that was doing like Magento sites and some custom app development in PHP, and I was like you know what, I'll apply for that and I ended up being like the only person in my class who applied there and that ended up being like the best way it could have ever possibly worked out because I met some really cool, talented people there that really helped me get my career to where it is now and encouraged me to speak at user groups and get involved in open source and stuff like that. Matt Stauffer: That's awesome. Adam Wathan: So after I went and worked there I did my whole kind of internship co-op stuff there and I just never went back to school because I had a mortgage and stuff like that. I was like 26 at the time or 25, 26, and I couldn't really afford to like not get paid for another year or going back to school and the whole point of going to school was to be able to get a job. and now I had a job and even if I wanted to leave there, well, I had a job doing programming for a living on my resume now so it didn't really matter, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: So I got what I needed out of it and then kind of got into the workforce doing PHP stuff and actually like even when I started there, that's when I really got seriously into Laravel stuff. We actually started using Laravel 4 on a client project before it was officially released when it was still like in a beta, which is cool, so I was getting paid to write Laravel code on my very first programming job. Matt Stauffer: Which is amazing. Adam Wathan: Pretty neat. Matt Stauffer: That's very cool. And who are the three? It was Chris and Grant and who was the third person, do you remember? Adam Wathan: Chris, Grant and Caryn, who is like a ... She's a product designer. Matt Stauffer: Product designer, yeah. Adam Wathan: A UX person there. Matt Stauffer: I didn't know she was employee number one. Adam Wathan: I don't think she was employee number one. They kind of went through a couple different iterations of the company doing different stuff- Matt Stauffer: Got it. Okay. Adam Wathan: Over time, but when I got there it was the three of them and they kind of had their thing figured out. Matt Stauffer: Very cool. All right, so the story from there you did at Vehikl ... So when did you start speaking? Was it the Laracon EU testing talk? Was that your first kind of big conference, or what was your speaking journey like? Adam Wathan: So the first talk that I ever gave was like an intro to Laravel talk at a Meetup that we created so that I could give that talk basically like the vehicle we created like the Kitchener-Waterloo Laravel Meetup which only survived like a few Meetups because we also had this like Guelph PHP user group which half the time we were doing Kitchener anyways and that eventually just became like oh, we'll just do everything there because we'd meet up once a month there. But yeah, so I gave a talk at that user group to about like 30 people or something, which was my first time doing any speaking like that, and I may have done another talk after that to like a local Meetup, but yeah, the first conference talk I think was the community day at Laracon EU 2015 or maybe '14, yeah, and I did the talk- Matt Stauffer: I remember it, but I don't remember the year so, yeah. Adam Wathan: Yeah, I can't remember what the talk was called, TDD the good parts, I think, and then after that I think I gave a talk at True North PHP in Toronto at Chris Hartjes and Peter Meth's conference and from there I just kind of got into it more and more. Once you kind of have one conference under your belt, it's a lot easier to get into the other ones, especially if you make the effort to get them filmed and post them online and be able to use that stuff to help show people hey, I can actually do this and it'll be fun. I'm a grown up I can do a good job. Matt Stauffer: Cool. So at some point you were using Laravel, and you became more aware of some of the world's around there. You were looking into things in Rails, you were talking about Ruby some. What was that journey like from Laravel being the thing that you were spending all your time in, to kind of expanding your exposure to the rest of the web world, I guess. Adam Wathan: I can't say ... I can't think of a specific ... I can't remember exactly how I heard about some of these other things, because like I said, I only remember being in college and being like well, PHP is what I use on a server. I didn't even know Rails existed. Like in some ways, in a lot of ways I wish I had known, because I probably would have never become a Laravel programmer. Not because I don't have ... I have anything against Laravel, but throughout the years it's become pretty clear that philosophically I'm much more aligned with the way people think in kind of the Ruby world, right? Adam Wathan: So I was already kind of like deep into Laravel stuff and feeling like pretty fast and productive with it and I'm sure all I was doing was poking around the internet looking for tutorials, reading things about how to do this and that and somewhere in there someone said similar to how this works in Rails blah, blah, you know what I mean? Like eventually you just kind of like start hearing about these things. Matt Stauffer: Yeah, yeah, yeah. Start hearing it, yeah. Adam Wathan: And the Laravel community was a lot less mature than it is now at that point, so a lot of the really good content that was out there was focused on Rails. Like Rails had a big head start on a lot of what we're doing in the Laravel world. Rails came out in like 2004 I think originally. And there's blog posts written in like 2008, 2009 that are still really useful blog posts for people writing Laravel stuff now, so it was actually really interesting for me to discover that kind of whole world because at the time this was like 2013, 2014 when I was learning Laravel originally. Maybe ... Yeah, probably 2013, there was like eight years worth of high quality Rails content out there. So if I could just figure out- Matt Stauffer: Yeah, sitting out there already. Adam Wathan: How to translate the syntax from Ruby to PHP, you know, there was all this content out there that could make me a better Laravel developer, basically. So I got really, really deep into all that stuff and that's when I discovered companies like Thoughtbot that had done tons of blogging and written books and put together video tutorials or Gary Bernhardt's Destroy All Software, which is all Rails stuff. There was just so much good stuff out there and that's where I basically focused all my learning at that point was taking everything that people had already ... Like I make this joke a lot of the time that any time like someone runs into a problem with Laravel, like a design decision where you're like okay, well, what's the best way to do this in Laravel, take the current year subtract four years, include that in your search query and look for how to do that in Rails and there will be like 100 quality blog posts out there. Adam Wathan: So yeah, I got really into just kind of researching what people were doing in these other ecosystems and finding out what made sense to try to port back and apply to what we were doing in PHP stuff and yeah, that's kind of been like my shtick, I guess. I'm always looking outside my existing community to see if ... I think of myself as like Christopher Columbus like going across the sea to the foreign lands and bringing back treasures for people. Matt Stauffer: Nice. Yeah, so let's see. So you worked at Vehikl for a while and do you know how big Vehikl was when you left? Adam Wathan: So it was still actually just the four of us- Matt Stauffer: Oh, yeah? Okay. Adam Wathan: When I left, which was kind of like my motivation for leaving. I still was really enjoying the work that I was doing there, but I had this like nagging feeling that I was missing out on the ability to grow faster by not being part of a bigger team where there was more ... Not more experienced developers like developers with more experience, but just more developers- Matt Stauffer: More people, yeah, yeah. Adam Wathan: That were experienced- Matt Stauffer: With different experiences, yeah. Adam Wathan: To learn from, right? Matt Stauffer: Yeah. Adam Wathan: And that was kind of stressing me out at the time, so I ended up leaving to go work for a company that did Rails consulting, but when I got there I got dumped onto a project doing C# and Angular, so I only stayed there for like three months because I want to blow my brains out ,and I soon ... Like within the first week of working I was like I can't believe I left my other job, this sucks so bad. And then after being there for a couple months Tighten, this company out of Chicago that does some Laravel stuff, I don't know, people might have heard of them, posted a job posting on the old Laravel job site and I applied for that and ended up going to work there for a while. Matt Stauffer: It's so weird because I've been trying to figure out how to ask you questions about that time, and it's really tough. I don't know how, but maybe I'll just try and throw a broad one at you and see if that goes somewhere. What was the area you grew in the most while you're working at Tighten? I think that may be a question to start with. Adam Wathan: That's a hard one. I can't think exactly what ... I think the biggest changes for me are the things that I had to figure out the most was like the remote working thing. That was like a new thing for me and figuring out how to ask for help with things and get stuff done and get help from people in a way where like I'm just so used to ... I was just so used to working in an office where if you're frustrated with a problem, like the people sitting around you can tell, you know what I mean? Matt Stauffer: Yeah, yeah, yeah. Adam Wathan: And that's not as easy in a remote company, so you have to figure out ways to manage that sort of thing, especially when people are not always like available at the same time because everyone's kind of working ... Like even though you have kind of standard-ish hours, there's still a lot of a synchronicity to it, right? Matt Stauffer: Yeah, yeah. Adam Wathan: Everyone has different calendars with different things going on, which is very different than being in an office. Yeah, people have stuff scheduled and calls and stuff, but you can like see when someone is available. So figuring that out was probably ... That was probably the biggest change and area for me to kind of figure out how to work that way, and yeah, it was good though. I think the remote working set up is the way to do it, as long as you can make sure people are able to communicate when they need to communicate and feel ... You have to be more deliberate about asking for help, which can be hard, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: If you can just be frustrated and people can tell and people offer to help, that's one thing, but sometimes it's like you feel like you have to ask for help every 15 minutes with something, especially when you're starting, right? Matt Stauffer: Yeah. Adam Wathan: And that could be like ... It's like a degree of shame or something like associated with that. That's hard to get over. Matt Stauffer: We've been working ... That's probably been the biggest barrier with bringing on juniors is that the combination of junior, plus remote, it's really an extra level of shame. Adam Wathan: Plus new job, right? Matt Stauffer: Yeah. Adam Wathan: Which is hard for even for like an experienced person, yeah. Matt Stauffer: New job, remote, new tech, I don't know what I'm doing, everybody else here has got it and I'm asking for questions every 15 minutes, I feel like I'm bothering people. Adam Wathan: Yeah. Matt Stauffer: That's definitely tough. Adam Wathan: Yeah. Matt Stauffer: So this is the last question I'll ask about your time at Tighten, but one of the things that was really impactful from our perspective was that you had a lot of thoughts about how a company should be run and a lot of them came from watching Base Camp and and Thoughtbot, and thinking about concepts that you've talked about in the podcasts and some of the times I've talked with you about on podcasts of things like no estimates and stuff like that, where there's a certain way of thinking, and I think that Dan and I say often that your time at Tighten was really impactful in terms of just kind of like sharing those things with us, but it wasn't always just as easy as Adam comes in and teaches something. Matt Stauffer: Often it happened in the context of, you know, there was a ... Not necessarily there was a conflict, but there was sort of like well, why is it not happening this way and we'd be like, "Oh well, I don't know. We'll figure that out." So I was wondering during your time at Tighten, do you feel like you learned anything about what you wanted to kind of do when you grew up kind of vibe in terms of teaching, or were there things that you learned about how you think software should be written or something that happened in the context of those learning moments and those conflicts and everything that we had during those times? Adam Wathan: Yeah, I'm try to think if there's anything specific I can take away as like a learning ... Matt Stauffer: And if not, no worries, I'll just edit out the question. Adam Wathan: Yeah, I think like ... I mean, what I like working on the most at Tighten was being able to create projects for companies, build stuff for other people. I think if anything, what I maybe took away is that ... What's the best way to say this? I like having control I guess of like my own destiny in that sense because working with companies to build new projects for them there's like this of course this whole layer of stuff that comes with that that isn't there when you're just building something for yourself of course, right? Matt Stauffer: Yeah. Adam Wathan: And it can be a real challenge sometimes to get people on board with building something in a way that is in their best interests, even though they might not understand why or agree why, and that's just like a whole thing that you have to figure out how to navigate that can just get in the way of what you want to do which is just like creating the best thing for solving a problem for them, right? Matt Stauffer: Yeah. Adam Wathan: So I think being able to get into what I'm doing now where I get to like create training stuff and stuff like that has been a nice change in that sense, because it lets me focus on just doing ... Creating the thing that I want to create. But yeah, like you said, like I think a lot of the reason that I cared so much at Tighten and everywhere I worked about how to try and run these projects successfully is for that same reason because I just want to make the great project, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: And I think everyone is on the same page there, right? Like you want to figure out a way to navigate the other stuff and minimize it so that you can just focus on doing the work, but because I just care so much about doing the work and that's what I want to do, that it kind of pulls me down this path of figuring out like okay, what is stopping us from being able to just do the work and what ideas are out there in the world that people have that can help us focus on- Matt Stauffer: Help us, yeah. Adam Wathan: Just doing the work for people. So I don't know if that really answers your question in terms of I guess like a specific kind of learnings or take aways, but in terms of, you know, that sort of project management side of things, I think that's sort of like where my motivations at least come from to care about that stuff. Matt Stauffer: Well, it's funny because you say everyone feels that way and of course everyone, you know, hopefully wants to really do a good job for the client, but it also reflects a little bit back on what we were talking about earlier about you love doing things to the best they can possibly be done and it's not just your things, you know, it's also other people's things. Like every project you have a hand in, you want it to be the best possible thing, and if there's stuff getting in the way of that, well, then that's stuff that you need to kind of shave off so that it can just be the optimal it will be. So I totally hear that and that makes a lot of sense. Thanks for answering that kind of convoluted question. Matt Stauffer: So the transition from there was it was during your time there that you wrote your book and you released it and you were able to transition it to be doing your own educational stuff full time. So in terms of that switch, when and what was the process like for you to start thinking you know what, working at somebody else's consultancy may just not end up being the thing for me and I want to try info products or I want to try my own products or something like that? Like what was that journey like for you? Adam Wathan: Yeah, so I think for me what really happened there as I put together this book and released it, I didn't really have crazy expectations for it or anything like that. Again, it was just one of those things where I've always just really liked making polished things that are finished that you can look at and be like this is done and this is tidy and this feels nice. And I used to do that with even like trying to contribute tutorials to Game Facts and stuff back in the day. I never got anything on there, but I would just like agonize over like making some sweet like ASCII art title at the top of these like stupid plain text files- Matt Stauffer: That's perfect. Adam Wathan: And I just wanted it to feel like a polished thing, right? So that was kind of like one of my biggest motivations for making the book was first of all, I've always been interested in like creating something and selling it and seeing like what it's like to make your own money on the internet sort of thing, but I also just like ... It's hard to think back to it now because I have a few products now, but back then I kind of felt like I just had never got to finish anything, if that makes sense? Matt Stauffer: Yeah, definitely. Adam Wathan: And this is a common thing that I think like agencies deal with a lot in general, right? As you get to work with a client, you do a lot of really great work for them, but you're not necessarily like always around 'till the end of the project because maybe eventually they hire their own team which is one of their goals from the beginning, right? They're trying to get like a head start on something so that once they have a little bit of traction they can build their own team around it, because of course that's more economical way to handle that. Adam Wathan: Or the other end of the spectrum is you start working on a project for someone and it turns out that they just aren't able to hold up their end of the bargain really and the project is just not going to work out and you do work for them for six weeks and then they realize like you know what, I'm not ever going to be able to make an app company properly, so you kind of just say okay, thanks for your work, you did a great job, but like that's the end of the project. Like I've worked on so many projects that never even went to production, you know? Matt Stauffer: Yeah. Adam Wathan: Or got any users or anything like that and that's kind of like a ... At the time that was kind of "I just want to finish something. I just want to have something that's done." I did that with my Nitpick too, that little SaaS something- Matt Stauffer: Yeah, I remember. Adam Wathan: That I built, and the whole goal there was just the same thing, like I want to build an app 'till it's done and then put it out on the internet, and that was just like a cool feeling. So I did the same thing with the book and then the book ended up being, you know, pretty successful, and before I worked on that book, I had the idea all along that what I really wanted to do was some sort of testing thing, like some TDD book or course or something, but it was just like ... Sounded like so daunting, it just sounded like a big project. Adam Wathan: So I stumbled on this idea to the collections thing, and that seemed so much more manageable, so once I had finished that and, you know, it was pretty successful, I thought you know what, if I want to do this like testing product, this is the best possible chance that I'm going to have to be able to spend the time on that because the book did well enough that like I can take six months off and focus on this thing. So I thought you know what, I'm not going to get a chance like this again. If I don't do it now then this money is just going to go into an RSP or something and it's just going to ... Yeah, of course that's good, I should have money saved away for a time. Matt Stauffer: Right, right. Adam Wathan: I'm not going to ... Like it's not going to change my life in any way, I'm just going to keep doing the exact same thing that I'm doing. The book's going to be out there, but I'm not like seizing the moment to use it as an opportunity to try something. So I thought you know what, this is like the only chance that I'm going to get to probably do this, so why don't I try it out. So that's when I decided to move on to try and to just do something for myself and see how it panned out and I did the testing course, which was way bigger than I even was worried about it being originally. Adam Wathan: So it's a good thing that I didn't try and put it together when I was still working, but that did really well too, and that's been able to let me focus on continuing to do more stuff like that. I'm always able to stay just like a little bit enough ahead of where I need to be that I have some time to figure out what the next thing is going to be, you know, and I'm just kind of like building the bridge as I try and cross the river. Matt Stauffer: Yeah, that's awesome. I remember one of the things that you said when you let us know that you were going to be going off to do the thing full time and you said, "You know, I don't know how this is going to work out, but I know that if it totally flops in six months I can apply to one of a myriad programming jobs, but if I don't try this, there's no guarantee I'll ever have this chance ever again where there's the traction for my book and I have enough money to kind of try this thing and so I got at least try it." And that really stuck with me, just the idea that like ... And I mean I've had that happen where I've had an influx of cash and it just kind of goes and spreads out across retirement savings and health expenses and whatever else, and your life is exactly the same even though you put all that work into it, and so that idea of those are those moments and it's scary, but like what's the worst thing that's going to happen? I'll use up all the money and then apply for jobs on the other end. Matt Stauffer: You know I'm a little less stable because I'll have to be applying for a job versus having once settled, but there's no guarantee that your job's not going to shut down the next day, you know, and so like the idea that oh well, everything's perfect now, I'll be put ... No, no. You know, I really love that kind of thinking and obviously at least so far it's working out really well for you, so I'm hoping that's an inspiration for other people to kind of consider taking some of those leaps. Matt Stauffer: I would love to ask you a million questions about how you think about product and stuff like that, but we're longer than usual, and thankfully other people have asked you that on their podcasts, so I'm going to try and link some of your stuff with Justin Jackson and some other people, also Full Stack Radio, even though it's you interviewing other people, you do learn a lot about the interviewer by the questions they ask. So all this super interesting stuff that we don't have time for, I hope that we'll be able to ... People will be able to kind of suss that information out anywhere else. Matt Stauffer: But I think one of the things we have not talked about, so every time I'm going to be interviewing somebody in the Laravel podcasts I go into Tighten Slack and I say I'm about to interview this person and I'm actually opening my Slack right now to make sure that new questions ... Yep, a couple of new questions came in, and I say, "Are there any particular questions that y'all want to ask them?" And so I ask that question in Tighten Slack, which is kind of funny because you are still in some of our Slacks and you used to work there, but there's still some questions. Matt Stauffer: So the first question came up for you is, "Do you even lift, bro? Which first of all is fantastic, but second of all in our Slack that actually triggers a gif of you doing a lift, so it's perfect. So we haven't gotten to talk about that at all. Adam Wathan: Yeah. Matt Stauffer: Where did that fit into your whole world? Can you tell everybody a little bit about kind of that part of your life? Adam Wathan: Yeah, so when I was working up in Fort McMurray in Alberta, I've always been kind of like an overweight kid. Matt Stauffer: Same. Adam Wathan: And like most people, like you just want to look better, right? Matt Stauffer: Yeah. Adam Wathan: So when I was working up there, you're just like so bored and you're not using your willpower for basically anything else that it was like an opportunity to finally try and do that seriously, right? It's actually funny because if you follow along with like the bootstrap podcast like Ian and Andre, Andre is kind of doing the same sort of thing. Like he decided to basically take off some time during the year from any really like mentally sort of straining work. Like I think he's just mostly focused on doing some consulting stuff and I'm not even sure if he's working the same amount of hours and stuff that he was doing normally, but he decided like, you know, I want to take this opportunity with this kind of reserve of mental energy that I have and focus on something like really life changing thing, which for him was like getting in shape, right? Matt Stauffer: Yeah. Adam Wathan: And it's funny because I never really thought about it that way, but when I heard him phrase it that way it's like you know what, that's exactly like why I was able to do it originally, because I just didn't have anything else pulling at my brain. So when you're going to make dinner or even going out for dinner with your friends it's easy to order the vegetables instead of the fries because like I just haven't used any of that brainpower, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: So when I was working out there, I just ... It was easier for me to start eating a lot better and get into like home workouts and stuff like that and that led me down this whole path of eventually discovering like strength training. Pro tip; if you're a programmer who wants to like start exercising, the terms that you should be Googling are strength training. That is the term that's going to find you ... At least I think is going to find you the stuff that's going to resonate most with how your brain works in terms of things being really measurable and being able to like science the shit out of everything with lots of percentages and math. Adam Wathan: But eventually I kind of stumbled onto this like form of exercise where you're just focusing on like lots of really high bang for your buck compound exercises like multi joint movements like squats and deadlifts and bench press and overhead press and chin ups and barbell rows and stuff like that, and once I finally found the good stuff online which was like Mark Rippetoe's content and stuff like that, you learn like what you should be doing is progressively trying to increase the weight that you're lifting. Like a lot of people just go to the gym and they just like pick whatever they think is going to be like a good weight to lift that day and just do it or whatever, but they're not actually tracking their progress, so they don't really make progress, but if you can develop a plan where you know like okay, this week this is what I'm lifting, next week I have to try and lift this and it goes up and up and up. Adam Wathan: For me that's what was able to keep me kind of motivated because I was seeing progress on paper because seeing progress in the mirror is a lot harder, it takes a lot longer and it's a lot more subtle and gradual, and if you're not taking the pictures of yourself topless in the mirror every week to compare like okay, do I actually look like I'm getting in better shape, but if you're just like blogging stuff in a notebook it's easy to say okay, I bench pressed 185 for six reps last week and this week I did it for eight reps, that's pretty cool. So I've kind of gone into this whole thing of getting stronger and lifting and eventually started competing in power lifting competitions because like with everything I do I have to take it to the extreme. Adam Wathan: So what started as like 185 pound like skinny fat kid to trying to like look better without his shirt off, turned into like a 260 pound dude deadlifting 600 pounds and winning nationals power lifting gold bells. That was just something ... I would still be doing that, but it's a hard ... Once you get there's like a point of diminishing returns, which I think I definitely hit, where you're just more likely to get injured than you are to make progress, and I've hurt myself a couple times and I have a nagging back injury now that doesn't bother me day to day, but any time I get back into lifting, no matter how light I start, after a couple weeks I do one rep not 100% perfect and my back is messed up for a week, it's really frustrating. Adam Wathan: So it's hard for me to really stay motivated into it these days because the thing that kept me going was like getting stronger. So going to the gym to lift less than I did before is like, whatever. I still need to get back into it more, but yeah, that was a big thing for me for a while. Matt Stauffer: It's funny because as you were saying that, a light was going off in my head. I switched to a new trainer about four months ago and it was the first time the trainer has been trying to teach me the skills to be able to stop working with him versus just kind of like giving himself job security by just kind of telling me what to do. And he's a Mark Rippetoe guy and he just moved to Chicago, or he's moving to Chicago this weekend and so he's like here's everything I know and he set me up with this thing called ... Have you ever heard of the 5-3-1? Adam Wathan: Yep, that's what I always used to do. Jim Wendler. Matt Stauffer: That's literally what I started it this week at the new gym on my own and I've got a 5-3-1 calculator. Adam Wathan: That's awesome. Matt Stauffer: I plug all my information in. Adam Wathan: It's amazing. Jim Wendler is like he's the DHH of weight lifting. Like he's just got that same like everyone over complicates things attitude and there's this quote that I ... So this is so funny because like so many people who get into power lifting are like super nerds about this stuff, right? Like the amount of like just nerds that get into this stuff is outrageous just because of the fact that you get to make spreadsheets, you get to calculate like your estimated one rep max based on how many reps you lift this way or whatever. Adam Wathan: And I'll never forget there's like a F.A.Q. section in one of Jim Wendler's books where someone asks a question and it's like, what is the best ... I can't remember exactly how it was phrased, but basically the question is like what incline should I be using on like

Jake and Michael make their return to discuss event sourcing, auditing and reporting, and finite state machines after a busy real life schedule kept them away from recording for a month!

Jake and Michael return in an irregular time slot to discuss ANZACs, scaling Laravel, queues, handling file uploads, and more!

Jake and Michael talk about the latest open source contribution from Basecamp, Stimulus, keeping up to date with new technology, and smart speakers.

Ben is entering the last week of The 30-Day Code Quality Challenge. He has enjoyed getting the challenges out each day and seeing participants engage with the content. In the future he is deciding whether to personalize the programming languages or to remain language agnostic. The next cohort of the Challenge will start January 3, 2018, and Ben’s looking forward to iterating and improving each cohort of the Challenge. He also discussed a connection he made with Discourse, and explores options for forum management in the future. Drip is working on their visual email builder with the help of their new Elm developer. The team has just completed several product structure tests using a prototype, which was a greatly helpful experience to the developers. Ben and Derrick discuss their experiences with product usability testing. Today’s Topics Include: Approaching the end of The 30-Day Code Quality Challenge Challenge results and stats on participation The next Challenge cohort begins January 3, 2018 Positive customer experience with Discourse Drip’s visual email builder project Product usability testing If you’re enjoying the show please give us your ratings and reviews in iTunes. Links and resources: The 30-Day Code Quality Challenge (https://www.codequalitychallenge.com/) Discourse (https://www.discourse.org/) Steve Schoger @steveschoger (https://twitter.com/steveschoger) Full Stack Radio podcast 78: Ben Orenstein - Our All-Time Favorite Refactorings (https://www.acast.com/fullstackradio/78-ben-orenstein-our-all-time-favorite-refactorings) RefactoringRails.io (http://refactoringrails.io/) Drip

Ben and Derrick are joined by guest Adam Wathan, an esteemed software developer, writer, speaker and entrepreneur from Ontario, Canada. He is the creator of Tailwind CSS, author of Refactoring to Collections and host of the Full Stack Radio podcast. Listen in as he shares how he built his own products over time and became an independent entrepreneur, and talks about his new project Tailwind CSS. Today’s Topics Include: Starting his first side projects and products Adam’s successful marketing channels and strategies Lessons learned from past product launches Experience with pricing plans and tiers Adam’s current projects and products, including Tailwind CSS CSS programming, utility and presentation If you’re enjoying the show please give us your ratings and reviews in iTunes. Links and resources: Tailwind CSS (https://tailwindcss.com/) Test-Driven Laravel (https://course.testdrivenlaravel.com/early-access) Refactoring to Collections (https://adamwathan.me/refactoring-to-collections/) Full Stack Radio (http://www.fullstackradio.com/) Adam on Twitter @adamwathan (https://twitter.com/adamwathan) The 30-Day Code Quality Challenge (https://www.codequalitychallenge.com/) RefactoringRails.io (http://refactoringrails.io/) Drip

Jake and Michael return after a few weeks' hiatus and discuss Michael's new role as a lead developer and the slightly softer focus for the podcast moving forward.

In this episode, Jake and Michael welcome Paul Redmond and the returning TJ Miller to have the HTTP client discussion you were promised last time.

Adam welcomes David Hemphill back to the show, but this time as a co-host! David introduces Crondog, the new product he's working on to help developers manage dynamic recurring tasks in their applications. Adam introduces KiteTail, an app that let's you create webhook-driven hosted checkout pages; something he wishes he'd had when he launched his course. From here on out, Full Stack Radio will follow David and Adam's journey building these new products; discussing interesting technical, design, and business challenges they face along the way. Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio to try their Bootstrap Plan free for 90 days Hired, sign up at https://www.hired.com/fullstackradio to double your signing bonus to $2000 if you get a job through Hired Links: Crondog, David's new recurring task app KiteTail, Adam's new checkout app PushSilver, David's existing invoicing app DonorGive, an app David worked on that motivated him to build CronDog Laravel Spark, the boilerplate Laravel skeleton David's using "What's KiteTail?", Adam's blog post introducing KiteTail Test-Driven Laravel, Adam's course app that inspired him to build KiteTail MicroConf Start Edition

We discuss Pokémon Go and what it's success might mean for software developers before Sean lays out his case for replacing the pg gem and libpq. Derek on Full Stack Radio The Laila and Brenda Show Google's Project Tango devices Pokemon Go gets full access Google auth token Why your email address isn't your identity The pg gem libpq SQL Server data types

On this weeks episode we are lucky to be joined by Matt Davis. We start off the show with discussion surrounding how Matt got into programming, the Symfony certification system and his experiences working with both Symfony and Laravel. With Edd’s recent guest appearance on Full Stack Radio just being released, we then touch upon this experience and the PostgreSQL topics covered. Following this we chat about working with external API’s, testing logic dependent on these services and how Matt has been using RabbitMQ and the Laravel Queue abstraction. This leads us on to discuss the concept of queued work in more depth, along with how to design computation in such a manner. Finally, we chat about the pros n’ cons of moving away from jQuery and back to vanilla JavaScript.

Een show gevuld met vanalles en nog wat deze week. Naast de app van deze week, Unroll.me, hebben we vanaf deze week ook een podcast van de week. De allereerste is aflevering 32 van Full Stack Radio met David Heinemeier Hansson over waarom ze een nieuwe Basecamp hebben gebouwd en hoe de grootte van je team impact heeft op de technische oplossingen die je kiest. Verder hebben we het over Scrum in het onderwijs, hoe blijf je gemotiveerd en Apps die toegang hebben tot Gmail en social media.Shownotes Unroll.me voor iPhone Link naar Google Security Link naar alle Apps die toegang hebben tot je Twitter Link naar alle Apps die toegang hebben tot je Facebook Aflevering 32 van Full Stack Radio: DHH - Building Basecamp 3 like a Porsche 911 David Heinemeier Hansson op Twitter De done lijst motiveert Natuurlijk zijn vragen, input of ideeën zijn altijd welkom op hallo@uitgeklokt.nl of volg ons op Twitter via @uitgeklokt!

In product design, the "planners" need to figure out the plan before you start, and the "cowboys" just want to get coding. Wee need them both, and we need them to work together. Karani Confomo Gistlog Symposium Markedstyle Ryan Singer on Full-Stack Radio

Hey folks! Sod’s law but just as we were getting into our stride recording this week the technology failed us! Thankfully we managed to ramble a sufficient amount before this happened. Finally the 4 of us all were online to together so lot’s to catch up on i.e. Mike’s fascinating computer animation module, Fraser’s React.JS workshop among other usual ramblings. It also looks like we may have Adam from the popular web podcast ‘Full Stack Radio’ joining us soon which we all look forward to. So without further ado, enjoy the rest and thanks for listening as well as your feedback.

This is an interview from Full Stack Radio. In this episode, Adam talks with Sean Devine, host of the Ruby on Rails podcast. Sean gives Adam an introduction to building applications with Ember, and how it's different than the way you might sprinkle AngularJS into a mostly server-side app. They talk about why your Ember apps shouldn't be mixed in with your server-side code, and the advantages that come along with building a server-side API with no front end of it's own.

This is an interview from Full Stack Radio. In this episode, Adam talks with Sean Devine, host of the Ruby on Rails podcast. Sean gives Adam an introduction to building applications with Ember, and how it's different than the way you might sprinkle AngularJS into a mostly server-side app. They talk about why your Ember apps shouldn't be mixed in with your server-side code, and the advantages that come along with building a server-side API with no front end of it's own.