Code with Jason
Code with Jason
266 - Hotwire Native with Joe Masilotti
In this episode, I talk with Joe Masilotti about his new book on Hotwire Native, which lets Rails developers build mobile apps using web views with native functionality. We explore the writing process, consulting approaches, client engagement strategies, and how both of us find clients through speaking and writing.
- Hotwire Native for Rails Developers book (use discount code CodeWithJasonHotwire for 35% off)
- Joe Masilotti's website
- Nonsense Monthly
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch.
Speaker 1:Email newsletters are a really nice way to keep on top of what's going on in the programming world, except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed or in someone else's bed, and when they say what are you doing in my bed, you can say I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics, like object-oriented programming, testing, devops, ai. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics and farming.
Speaker 1:The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler, from Los Angeles, says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded, looking forward to more. Drew Bragg, from Philadelphia, says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it and sitting down to read it on paper.
Speaker 1:That is just so awesome, feels like a lost luxury. Chris Sonnier from Dickinson, texas, says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at NonsenseMonthlycom. That's NonsenseMonthlycom. I'll say it one more time NonsenseMonthlycom. And now, without further ado, here is today's episode.
Speaker 2:Hey, today I'm here with Joe Mazzalotti. Joe welcome. Hey, jason, how are you?
Speaker 1:Good, how about you? You just came out with a book, right yeah?
Speaker 2:yeah, what was it? Wednesday, the first release of my book on Hotwire Native finally became publicly available, which is wild. It's been a long time coming. Yeah, tell me about all that. Yeah, so I've been working in Hotwire Native for like I think 10 years now.
Speaker 2:You know Turbolinks back in the day, turbo, then Hotwire Native rebrand last year and just it's been so long that, like, folks have been asking for more content, more courses, and I was like I gotta write a book, I just gotta write a book, I gotta get this all out there. So what was it? 2023 of august? I just like sat down and started writing in motion. I was like I'm just gonna write as much as I can, and I got probably three chapters done in a couple of weeks, just like busted through it.
Speaker 2:And then January rolled around and I was like I have no motivation for this anymore. I'm done, I'm toast. This is like a lot. This is like a 10,000 word blog post and I'm already toast. So I knew I needed to work with a publisher. I just needed to get someone to motivate me, someone to proofread, someone to beta test, like all the good things that come with a publisher. So I ended up signing with Pragmatic Bookshelf in January of last year, officially and worked all of 2024, all of last year, just like working through the book. We're now at, I think, 70% or 65% depending on which way you look at it done with the content and folks can check it out and download it and you know. Let me know what is wrong, what is broken, what's confusing, as I finish up the last few chapters and and get the real hard copy release out nice.
Speaker 2:Nice yeah.
Speaker 1:Yeah, it's interesting because my experience was kind of the inverse.
Speaker 1:I was working with a publisher on a book and I had a really hard time working with the publisher, like yeah, I had to work on their timelines and I had to, to a certain degree, I had to cater to their desires and stuff like that, which weren't always the same as my desires, and I ended up pulling the plug on the whole thing, not because there was anything wrong with the publisher or anything like that. That particular book I realized I didn't have a book's worth of stuff to say on the topic. The topic was AI-assisted programming. Worth of stuff to say on the topic. The topic was AI assisted programming. And then I went back to rewriting my Rails testing book which I just put out in October 2024.
Speaker 1:But, for whatever reason, I have a much easier time working on that alone than with a publisher. I think it's because of kind of my lack well, a few things, uh, my like lack of being a team player, or however you might want to put it. I'm like super particular and like just uh, I don't know, I want things to be a very certain way, totally um. And then the other part of it is like I don't know just all the same reasons why I was terrible at school.
Speaker 1:I like it was like all the memories like came back, like working with a publisher. It's like, uh, this is why I'm terrible at this stuff. Yeah, um, yeah, so I was able to to get it out on my own, um, and that was all great. Regarding the topic of your book, for somebody who's like not familiar with it at all, like, can you tell us what this topic is all about?
Speaker 2:Yeah, so the topic is Hotwire Native for Rails developers. So Hotwire Native itself is a way to take your either existing or new Rails website and kind of shove it in a mobile app. So it works with a web view that you render inside of an iOS or an Android app. That renders the content directly from your server. But because it's running inside of a native shell, you have access to all of the Swift and Kotlin native APIs. So you can do a full screen in native, you know, like in Swift UI or Jetpack Compose, if you wanted to, or just do everything on the web. You can do push notifications, you can access HealthKit or you know the Google version of that. You can access Apple intelligence you have all access to that. But the content, the business logic, is all being driven from your server.
Speaker 2:You're still rendering essentially the mobile website inside of the app and then cleaning up some of the CSS, hiding maybe the navigation bar, doing a native tab bar and stuff like that. So you have all the benefits of once you get the app in the app stores. You can add new features by just adding a new Rails endpoint or adding a new Rails controller, and as long as there's a link to it somewhere in the app, it just shows up. You don't have to worry about building out something three times or two times, once for web and then one for mobile. It's just HTML and CSS at the end of the day. So you get this like the true what I consider write once, deploy everywhere where you deploy your Rails server and all of your apps. On the next pull to refresh, get that content for free, and it's just extremely powerful for, you know, small or even mid-sized teams to get feature parity with the website in a mobile form.
Speaker 1:Okay, and why exactly would somebody want to work this way? I can imagine at least two reasons. Imagine if somebody like me who has basically never touched mobile, um, I can. I can get going with it more easily than if I tried to do it totally natively. Um, and the other reason is maybe, even if I already was like super knowledgeable with mobile development, it would be a more economical way to build and maintain an app. Tell me about that.
Speaker 2:Yeah, no notes. You hit both the big points Because you're rendering web content. You don't have to worry about creating an endpoint like a JSON endpoint and then building the screen natively every time you add a new feature. You don't have to have a huge stack of native components and native caching and native off. You know database stuff. You're just using your single server, your sync, sorry, your single database point of excuse me, a source of truth on your server for all of your content, all of your business logic.
Speaker 2:You do have to write some Swift. You do have to write some Colin. There's no way around that. You're not. You know you do have to write some Kotlin. There's no way around that. You're not. You know you're not using React Native. You're not writing JavaScript on the client.
Speaker 2:So there is a bit of a learning curve there, but it's more of like you get this framework or this baseline implementation of the two frameworks and then that code will rarely change.
Speaker 2:I had I worked with my old company that I used to work at we had our iOS app in the app store for almost six years without any new changes to the native code and we were releasing updates every other week to the Rails server and like that's how little the native code needed to change. It wasn't until we decided to add a different type of like rich push notification with an image in it that we needed to actually update. It wasn't until we decided to add a different type of like rich push notification with an image in it that we needed to actually update the iOS code and the Android code. So you get like this crazy longevity out of your app. You get this amazing low maintenance cost of the mobile versions for that little bit of upfront. You know learning curve of I need to set up an Xcode project and you know run android studio and stuff like that yeah, wow, um, and I'm curious like um, what were you doing for work during this time?
Speaker 1:this is shifting a little bit to the writing process and stuff like that. Um, it can be hard to juggle a big project like writing a book with everything else a person needs to do. For me, I was self-employed throughout pretty much the whole time that I was writing my book, and I had the flexibility to work on my book for like an hour a day, basically at whatever time of day I wanted, which worked out nicely for me. But how did you manage that whole thing?
Speaker 2:Yeah, I've been self-employed for six, seven years I think now. So I'm same as you. I've been writing the book all on my own time, no real boss to answer to or anything. The hardest part is managing it with a growing family. We had our second kid in 2024. So that was a couple months. Yeah, thank you A couple months of leave there. Coming back from that was slow. Managing clients I do Hotwire Native consulting full time so I either get in there and write code for businesses or kind of coach them through their process as they build their own apps. So day in, day out, I'm working in Hotwire Native. I'm building stuff for folks, I'm helping folks work through things and it's this really fun feedback loop of. I write something about it in the book. I teach it to a client. They come back to me and say it's confusing. I get to revise it before anyone even sees the content.
Speaker 2:So, I have this like I've. The content in the book has been almost has been like vetted so many times already, because it's what I teach to people, it's what I, it's my secret sauce of how I build apps. You know, it's been working for 10 years and having that balance was able to kind of motivate me to do both at the same time Because it was even though I wasn't writing maybe the same code base. It was very much like all right, I'm working on push notifications for the next month. I'm going to do it for a client. I'm going to write about a little bit in the book. I'm going to uncover a pitfall for a client. I'm going to write about that in the book. And it created this really fun like being motivated for it once I actually had these deadlines in place from the publisher.
Speaker 1:Yeah, it's interesting. I had very similar experiences with my testing material. Yeah, it's interesting.
Speaker 1:I had very similar experiences with my testing material Not just the book, but also blog posts and podcast material, videos, just anything feedback and I'd be like, oh okay, this way of explaining it is actually kind of not that great, because it turns out the common situation is a little bit different from how I imagined it to be. But now that I've seen like five more code bases and like, yeah, talk deeply with some more teams, I understand that like my mental model of this whole thing was was kind of off and so now I can go back and and revise that and these things that I like. There's a lot of cases where, like there are things that it didn't occur to me to explain. I'm like, oh okay, like not everybody already knows this, I should explain this I'm sure you had that experience too oh my god, so many times.
Speaker 2:Before I did rails, I was an ios developer. So like right out of college I was writing ios and android code and then I shifted into to rails like two or three years later when I started working for pivotal labs like doing consulting, pair programming, that kind of stuff. And the amount of times I've had to just take a step back and realize that a compiled language versus like Ruby and talk about how you might get an error before the app even runs, like things like that that are just like so ingrained in my head that I had to take it to just take four steps above and be like OK, this is the end of a line, like this is a compilation error, this is a runtime error, and and those types of questions and those types of things came up so frequently as I was doing, as I was writing the book, but also when I gave out the first round of feedback to developers and they were like you skipped 13 steps here, like you need to slow down so much, and that feedback is really motivating. But it's also like so much work. It's so much work to think you're done with a chapter and then have to go back and add seven paragraphs about something or like a big aside on.
Speaker 2:By the way, this is how it works in Ruby. It doesn't work with that at all in Swift or Kotlin and like here's your whole new mental model. You have to learn as a reader and it's definitely made my writing way clearer but also way more verbose, and it's a tough balance. Like on my blog, I can gloss over things I could link to articles and be like hey, just you know, if you're not familiar with this, like read this article that I wrote. It's way harder to do that in a book where you kind of have to assume nothing. They might not have internet access, they might not know anything, they might not even have Xcode installed and they're just reading the book and it's like this totally different way of writing. That has been both exciting and very trying.
Speaker 1:Yeah, I know the feeling, although it is gratifying to like finally arrive at like a good explanation or a good um way of wording things, or whatever, where it's like, yes, this, this explanation, works, like I'm sure you've had the experience where you try to come up with an analogy and you're like, ah, this analogy is like weird and it doesn't really fit that well, and then you finally hit the nail on the head and you're like, yes, this is so great delegates.
Speaker 2:I've been trying to explain delegates in swift and ios development for months. I still don't have a really good explanation of it, but there's like it's been it's. I've taken seven different approaches on how to relate delegates and Swift to like what the equivalent in Rails, and the closest I've come up with is kind of like a callback, like an active record callback, like an after create or something. But imagine that that after create block was its own object with its own name and its own instantiation and stuff and and that's delegation in iOS. And even as I explain it now, it's hand-wavy, right. It takes three paragraphs of text to do that and I feel like I'm almost there. But multiply that by the 13 new concepts you have to introduce for native development and it's so easy for this book to just start ballooning in background information.
Speaker 2:That isn't even relevant once you learn it. It just like you have to know, like baseline knowledge type stuff yeah, the book assumes zero mobile experience like you don't have. You've never. If you don't even know what swifter kotlin is like, that's fine. That's what it assumes, and it teaches everything from the ground up. All you have to know is a little bit of rails and a little bit of stimulus to get started. So there's a lot of. There are very few assumptions that I can make about the reader yeah, it's like eventually, eventually.
Speaker 1:It's like where do you draw the line? It's like am I teaching like programming in general at this point you have to draw the line somewhere. Yeah, with with my book, uh, which is called professional rails testing.
Speaker 1:Um, there's definitely some sections where I explain things that have, in a way, nothing at all to do with testing, like I have a whole chapter on duplication, and in order to talk about duplication in tests, I have to talk about duplication in application code, which is a surprisingly like deep and nuanced topic, and so I go way into that just to say that, like, duplication is different in test than it is in application code.
Speaker 1:But I can't just say that without saying right what it means. Um, and then there's another area which I you know, which I already have the second edition of the book in a document on my account. In the second edition I need to go back and update this part, but there's a section on abstraction and applying abstraction to tests, and this is something that I think hardly anybody thinks about. Abstraction to tests, and this is something that I think hardly anybody thinks about. And before I can really talk about how to apply abstraction to tests, I have to talk about what is abstraction in general and that's. You know that's not necessarily a quick and simple thing to explain. I imagine you found cases where you had to explain those fundamental concepts for your book also yeah, um, optional variables, like variables in all ruby.
Speaker 2:All ruby variables are optional technically they can hold a variable like a reference to something, or they can hold nil in swift and kotlin. You have to be explicit about that. You have to say this variable can be nil by default. It can't be nil. So if you try to assign explicit about that, you have to say this variable can be nil by default, it can't be nil. So if you try to assign nil to a variable that's non-nullable, you get a compilation error and that's a whole new process you have to think about as you're writing code.
Speaker 2:In Swift and Kotlin Every variable must be typed. Sometimes you can get dynamic typing but Ruby you can say you know, name equals Joe in quotes and then name equals one. No problem with that. It might not be efficient, but like you can do that In Swift and Kotlin, that's compilation error. Like that variable is a string and will always be a string. And then you have to think about mutability. Like variables by default are not mutable in string and Kotlin, depending on of like very, uh, javascript with like const versus var versus um, whatever the other one is, let I think, or yeah, and you know, just always be thinking about that kind of stuff.
Speaker 2:So I totally hear you there and and it's like you start writing three sentences okay, let's go take an aside and talk about this concept. And here's three more sentences about the book. Okay, we wrote one more line of code for the book. Let's talk about what that meant for three paragraphs. And it's wild how, like chapter one, I think, is only 50 lines of code, total, right, but it's just as long as chapter seven, which is like 300 lines of code, because there's so much text around background explanation, exactly what you're talking about, like building the world from nothing in the first chapter that I can finally assume by the time you get to chapter seven, that I can really just talk about the line of code and not what this explanation point means versus what this type means and stuff like that.
Speaker 1:To get back to the material a little bit, I'm curious what does world um um hotwire native look?
Speaker 2:like in terms of like, how much code is required, or visually. What does it look like?
Speaker 1:um, just at the highest level, conceptually what does it look like? Um, if if I you know, for example, me personally, I'm a good example because I do rails, never done mobile development really like, how do I, how do I go about that?
Speaker 2:yeah, so earlier, not earlier this year late last year we I worked with the team at 37 signals to redo or launch a new hotwire native website. So if you go to nativehotwiredev or hotwiredev and then click the native tab up the top, you can walk through building an iOS app and an Android app from scratch. With no copy-pasting code, sure, but if you work through that, you'll have about 15 lines of code on iOS to get up and running, about 35 lines of code on Android to get up and running, and if you point that to the demo server, you'll have a lot of functionality. But if you point that to just your standard Rails app, like your existing Rails app, as long as you have TurboJS running and haven't done any data turbo equals false attributes you have a pretty decent working app.
Speaker 2:You can click a link, navigate to a new screen with a native animation. You'll get modals sliding up from the bottom instead of sliding up over from the sides. You'll have persistent login. If you set one more variable on the server With that little bit, I always like to think it gets you 80% of the way there for an MVP. But that last 20% usually means you know, 5x effort on it, so you really get this a good understanding of how little native code you need to access your full web code base. It's when you start to add on the native features or native screens that you really start to pack on the code and add a lot more.
Speaker 1:Yeah, and it seems like maybe you could get away with with knowing basically nothing about iOS, for example like you could do a hello world not knowing anything. But then once you actually want to make some tweaks, then you have to like step back and say, okay, now I actually need to learn some stuff.
Speaker 2:Yeah, I would be. I would, you know, challenge myself even to see what the minimum amount of code you could write for iOS and Android and get something in the App Store. And I think that with Android it's pretty low. You know, you get your MVP working, you get some path configuration stuff which would help you route certain screens to modals like sliding up from the bottom. I don't think you need much more to get into the android store 50 lines of code. Maybe ios is a little bit trickier because they always will require one native piece of functionality just to get by the clause in the app store view guidelines. It's like you can't repackage a website and call it an app.
Speaker 2:You have to have one benefit of the app over the website, and that means I usually reach for a native tab bar or push notifications or something simple like that. Uh, so that adds a lot of a lot of code, but it's not a lot compared to writing your entire app in native or even like react native or something like that. There's yeah.
Speaker 1:And I imagine, as always, ai can grease the wheels a lot and make that learning curve easier.
Speaker 2:My recommendation with AI and hotwire native is be very skeptical of what an AI returns Like. If you're saying how do I do a Hotwire native app asking ChatGPT or Copilot or whatever, I still have not had it respond with something that actually works.
Speaker 1:Yeah, I would imagine with Hotwire native specifically, AI is not going to be very strong.
Speaker 2:It's only with the completely native iOS and android stuff that it's gonna be very usable my recommendation is always like get your bare bones hotwire native app working under work through the native um hotwire native tutorial online. Go through my book, get to the end and then it's like okay, I need to add a new feature. Ask the ai how to do that in the native language, how to do it in swift, how to do how to do it in Swift, how to do it in Kotlin, and then apply that to your app in a Hotwire native world. Don't mention Hotwire native to the AI. They just go completely, go off the rails and usually talk about React native and even though you tell them a hundred times, it's not React native. I am very curious to see how much that changes once my book is in the wild and it gets trained on it, but for now, hotwire Native and NAIs is a little useless unfortunately.
Speaker 1:Yeah, even with just general Hotwire and Turbo stuff. I find that at least ChatGPT is not that strong.
Speaker 2:I'd be curious if we as a collective community trained a model on Hotwire native apps. You know, gave it maybe the getting started guide, gave it the demo app that's included with the two repos, gave it some code from my website and stuff. How much better it could be. But I still feel like there's just not a lot of content right now. There's only a handful of folks writing content on this. I think that's changing. Even in the past month there's been a bunch of people starting to write new stuff. So I'm thinking this time next year AIs will finally have started training on the content and will be a little bit better.
Speaker 1:I think we'll get a double benefit there will be more content in the future and also AIs will be better in the future, and those two things together will make it better. I have a sense that, like even all the additional content that might be coming over the next, like two, three, four or five years- will not be a huge amount. You know like compare it to the amount of like PHP examples out there or something like that.
Speaker 1:Like it's just like such a small scale, but I am hopeful if the AIs get better at learning from a smaller set of examples.
Speaker 2:Yeah, that's got to be where it goes first. I mean, you think about how long PHP has been around, even how long Rails has been around, and it's just orders of magnitude, more than like how much content is out there for Hotwire native. And the whole rebrand twice over in the last 10 years doesn't help. Turbolink's native, then it was Turbo native and now it's Hotwire native. Even that the AIs haven't figured out is the same thing, because the APIs have changed too. So it's not the same thing.
Speaker 1:But being able to extrapolate from smaller data sets will be really helpful. Yeah, yeah, and I don't know if that's going to be a difference in degree or a difference in kind, like I don't know enough about how lms work, um to know if that's just like a fundamentally different thing, right, yeah, um, yeah, I don't know either but, now they're not very profitable to even speculate about that.
Speaker 1:We'll just wait and see what happens. Um uh, so you mentioned earlier that you might be interested in talking about consulting and that kind of stuff. You want to get into that? Yeah sure yeah, um, I have some questions for you. Does you have any questions for me?
Speaker 2:let's do your questions first, because I think that they might be some of the same questions, yeah um.
Speaker 1:So first of all, when somebody asks you what you do like, oh, you do consulting. What kind? What's your answer to that?
Speaker 2:yeah, it's such a tough question because it really depends on who I'm talking to. If I'm talking to another rails developer, it's always I help Rails developers make mobile apps with Hotwire native, and that can mean a lot of different things and it's usually like oh well, you know how and we go down that route. I'm talking to more of like a decision maker or a business owner who maybe is less technical. It's more about leveling up their developers to help them build hotwire native apps. Like. That's like the cto kind of slant. But if I'm talking to that solo business owner who's like I need the app yesterday, I'm I talk about how I can just get in there and make it for them. They can, they don't have to worry about it. They throw me some money. I throw back an app. Everyone's happy, it's in the app store. I deal with apple. So it's this mix of like consulting, advisory and development, all in the hotwire native space. So I do, I do coaching. You know, I'll take your team and level them up from like not knowing anything about hotwire native to being able to build their own apps. I'll do the soup to nuts. Give me a requirement, doc, I'll build it for you and then give it back to you.
Speaker 2:But what my kind of my favorite of all of these, and I think is actually the most effective is this advisory retainer that I work with with clients where they have in-house talent. They have a lot of Rails developers. They have no mobile developers. They don't want someone to build the app for them. Rails developers they have no mobile developers. They don't want someone to build the app for them. They want to build it themselves, but they are nervous about building it because there's not a lot of material online.
Speaker 2:And what that, for me, is. I'm on call during working hours. They can email me, they can call me on the phone, they can set up a pairing session. I can work in Basecamp with them. I'm pretty much just like a senior developer who's too busy to write code and only there to, like you know, tap on the shoulder and I'm there for every question, every concern that they have as they build their apps.
Speaker 2:And it's this really cool balance, because I get to see these wild problems, things I've never even like experienced before, that I wouldn't be able to tell them what to do unless I was in their code base with them, pairing with them.
Speaker 2:I get to learn new things, but also teach them the Hotwire native way about how to leave logic on your server and do everything through path configuration, and less native code is better all that stuff and it's really fruitful for both parties, because they learn A from an expert, but B they learn as I'm teaching it, which I think is a big difference than them reading an article. They're learning it in their app, which is totally fine-tuned to their service, to their experience, and it gives business owners a very strong peace of mind. They know they're going to figure it out, no matter what they do like, they'll work with me enough to figure their problems out, and I've seen that be really, really helpful at the end of last year. So one of my big goals for 2025 is to find more folks who want to work with me like that okay, um, and, and the person who hires you?
Speaker 1:yeah, um, you know, sometimes the person who hires you and the person you actually work with is not the same person or people. Um, I've had situations where one person hires me and I work with that single individual um but it's like somebody else who's approving the paychecks or whatever.
Speaker 1:I've had situations where that's the same person and I've had situations where one person hires me but then I work with the team and I don't work with that person who hired me at all. But for the people who hire you and you work with, what roles do those people tend to be in?
Speaker 2:The folks that hire me are almost always the CTO or the small business owner. They have a team of one or two and they're just the founder. Essentially, they're not just the founder, they're the founder, and most of the time when it's the founder on a small team like that, they are also the technical lead. They're the technical founder. They're in there. I'm working with them, maybe working with their developers, but mostly working one-on-one with them.
Speaker 2:When I get hired by a CTO, it's more of what you were saying You're working with the team of developers, I'm working with the team of developers. I'm kind of coaching them through things. I kind of work with smaller businesses in terms of headcount size, so all across the revenue range. You know, I'm working with companies that are some companies that are bringing in like multi-million dollars but they still only have three developers because they have a huge sales team or something. And those are my favorites, like working with two or three developers because they're all helping each other, they're learning from each other and I'm there to kind of push everyone gently around the curve and make sure they get everything working.
Speaker 2:The amount that I can teach a small team is way bigger than the amount that I can teach. A huge team that is trying to like vying for, like vying for my attention, or Big sessions of like 10 people in the audience. No one learns as much as a one-on-one pairing session or a one-on-three mob session Like and those are my favorites If I can hop on and they're like look, this line of code right here keeps throwing an exception, let's figure it out together. And there's like four people around the screen. Oh, it's so much fun, it's so much like high energy, like people are talking about. Oh, there's this. Let me go check on the logs.
Speaker 1:Like this happened last week and you finally figure that out 45 minutes into an hour session and everyone's just like yes, weeks of work, you know, yeah, yeah, it definitely has a different energy when you're pairing with like one to three other people than when there's like 10 people the engagement's way higher. Um, okay, yeah, so usually like the cto or the the owner, um, and then like do the engagements tend to be like for a specific period of time, or open-ended or both?
Speaker 2:yeah, I for the advisory stuff.
Speaker 2:It's always open-ended and I have a minimum, like you have to work with me for a certain number of months to sign the contract, but I always keep it open ended with the option to cancel with two week notice.
Speaker 2:Because I find that everyone, almost every client they work, they work, they work, they work. They feel like there's just never ending work to do. And then they hit the turning point and everything else is easy for them, like they've essentially leveled up to the point where they understand how to fix everything else. They've gone over the hill, you know in terms of like the base camp terms of they've figured everything out that needs to be done. They haven't solved it yet, but they know what needs to be done. And once they get to that point, they're hey, joe, we don't need you anymore, we're good, you know, you've gotten us to the point where we don't need your help anymore. So we're gonna end at the end of the month and I'm like, yes, like that's not churn to me, that's like graduation. These, these developers, this team has leveled up enough and I've taught them enough that they can now figure stuff out on their own.
Speaker 2:And that's where I want to leave every client, every business. I don't want to work with someone for nine months, 12 months. I want to work with them for three to six months, get them to a point where they can fix stuff on their own and then not hear from them until something else happens in two years or whatever, and like that. That's ideal to me. It doesn't always happen, but I try to that's how I structure everything.
Speaker 1:I try to make it happen that way. I'm also really curious if sometimes people bring you in for Hotwire native stuff and then just realize, oh, Joe is like just a generally smart and useful guy and they start asking you questions about adjacent or maybe even unrelated things.
Speaker 2:My last client was working with a was like not subcontracting, but was working with another, an agency to build, to help build their website. They were converting from a JavaScript-based front end to Hotwire. And at one point the CTO brought me in and was like I know this isn't hotwire native related, but can you just like tell me if any of this makes doesn't make sense? And we went through, you know, like the whole plan for converting the front end from javascript to just hotwire and he understood that it wasn't my expertise. He was just like, hey, can you offer your advice on this? As exactly you're saying someone who's been around this stuff for a while, and you know I always go into it like this isn't, this isn't where I what I know best, but I'm more than happy to offer opinion.
Speaker 2:Talking is very fun talking about things that are right and wrong, you know and development is even more fun. So I'm always up for that and I think they got a lot out of it, even if sometimes it's just someone to kind of complain to. You know like I'm kind of just there as their tech therapist to tell them hey, it's okay. Like you know, yes, you're only 70 percent done of the project, but this last 30 percent's pretty small relative. Or telling them that, look you're, they're right, you're not going to make this deadline. You know being being the the, the person who has to break the news to them, and it's not my favorite type of work I'd rather be doing Hotwire Native but it also comes with the territory of an advisory role. I'm acting like a principal-level developer for them and those are part of those decisions and to help out with that kind of stuff.
Speaker 1:Yeah, and the economy is weird, um like, by what I mean when I say the economy is weird is like when you're young you might have a naive, uh, model of the economy where, like um, companies produce useful products and then sell them and people buy them and they use them for their intended purpose and stuff like that, and there are people offering services and it's a similar story. You hire somebody to perform the service and then they do it and value is created. The real economy works a lot differently from that, like those things are happening, but in addition to those things, there is an incredible amount of waste and performativity.
Speaker 2:And.
Speaker 1:I don't necessarily mean those things with any judgment attached to them. I don't want to imply that those are always negative things, um, but it's like you know, most probably, um, most of the money that is spent in the economy is is not going toward the actual creation of value. Um, like, I've worked at so many places and done so many like freelancing engagements and stuff like that, where at the end of it, what we accomplished was either nothing or it was like very marginal. And I've also noticed this is like my cynical observation, but I think it's true is that any organization, there are a minority of employees producing most of the value and everybody else is kind of riding their coattails and their value is either marginal or or nil or even negative, and the thing that's making the company get by is just these handful of exceptionally productive people doing almost all the work. And so I've found out these things, and the truth is often ugly, but if you want to succeed in the economy, you have to understand how it really works and you have to play by the rules of how it really works.
Speaker 1:And that means doing things like letting people hire you supposedly to help them with what they asked for your help with, to help them with what they asked for your help with. But really what that means sometimes is just listening to them complain about their job which again, I'm not assigning any positive or negative judgment to that. That's just. That's something that I didn't really expect going into this, that it would be kind of like the just talking about almost nothing, that kind of thing. And then working with teams. I don't know if you've had this experience, but working with teams who don't really end up being helped, like you work with them for a bit of time and you teach them as best you can, but at the end of it nothing has really changed that much. So I'm wondering if you've had similar experiences.
Speaker 2:I have the latter especially. I worked with a client a few years ago now that did a. I kind of did like a boot camp for them, like a Hotwire native boot camp, where I took five of their developers, three all day session of just they know nothing, they leave, they can build an app and super high, lofty goals. We also had an off-boarding plan and stuff. But the goal was for them to be able to create an app at the end of three days and they felt confident. They felt like they could do it. They were excited. Monday morning they were going to dive in, start building the app.
Speaker 2:Well, over the weekend priorities changed and there was no budget to, or there was no need anymore to build a mobile app at all and no one was to blame. It was just that a mobile app didn't make sense for them anymore. But you know, I spent months preparing for that. Those three days I spent and I got compensated for it. It was. It's fine. Nothing. Nothing changed on my end that they didn't build the app at the end of at the end of the engagement. But it's heartbreaking to hear that they were so excited, like these developers. These were ready to go and they knew they could do it and they just weren't given the freedom to do it because they had to work on other stuff. And I get it like the mobile app was a nice to have at the anyway, but it's hard. It's always so hard to hear where, like I spent so much time, they spent so much time, so much energy went into being excited about it on both ends and then it was just like no, sorry, it's not gonna happen and it's.
Speaker 2:It's funny timing because one of those developers reached out to me when my book came out last week and was like we've, now that your book is out, I'm just doing it on my own. I'm gonna build a mobile app and then present it to my boss and see what they think and it's like that's awesome, like good for you. I hate that you have to do it, but awesome still that you can, and I'm gonna follow up with them and see and see how it goes in a few months, see if they actually got something in the app stores.
Speaker 1:Yeah, I think it takes kind of a hard-nosed approach where you have to recognize that you're going to have those kinds of blows and you have to not get discouraged by it.
Speaker 2:Yeah.
Speaker 1:And you have to take a very mature approach and realize that things like this happen in the world and there are going to be appalling inefficiencies not necessarily always anybody's fault or anything like that. Just priorities change and stuff like that, and you have to say well, okay, uh, you've told me that nothing we're doing is going to have any value whatsoever. I have taken in that information. Thank you for the paycheck.
Speaker 2:And now I'm going to move on to my rest of my day's work.
Speaker 2:I know Another anecdote there this was not 2024, 2023, I think. I worked with a client for 11 months, which like already red flag to me. That's too long to work with a single client, because at the end of that, I'm either just another developer on the team and you should have hired me, or I'm not actually doing anything anymore. You just need to fill budget and I'm not effective. And we worked on building their native, their turbo native at the time iOS and Android app. We I got everything working from an app side, but we just needed someone on their team to rework authentication in a way that worked with mobile. So they had a complex like twoactor auth type flow.
Speaker 2:The last three months of the engagement I didn't do anything except ask them every week for updates on this and finally the engagement ended with lots of notice to them to tell them that we were not going to get into the app store because no one could sign in. And they said no problem and they signed the check in. And they said no problem and they signed the check. And we haven't spoken since and they weren't even unhappy. They were just like that's fine, we're a big enough organization that we were okay to throw away that much money and not have anything come out of it, because it was an experiment to them and I didn't know that at the time. I was trying to push for them. Actually, I thought they were trying to actually get in the app store. It was just like a proof of concept. Could they do it? Could they have a mobile app if they needed it? And it's so demoralizing to be like 11 months later and we still are in you know, test flight or staging or whatever, when all they had to do was make like one change on the server, which you know, I'm sure it wasn't just that, I'm sure it was a lot of other stuff. But for me that's what it felt like and you know, as a consultant, as a advisor, as someone who isn't working full-time for these companies, you kind of just have to grin and bear it. You don't have the control over the business aspect of it. I can build you the app, I can help you build the apps, but that's kind of where my influence ends.
Speaker 2:If you don't let me I always talk about. I will tell a client something two times. The first time is hey, a heads up, we should do it this way. And they push back, that's fine. You're entitled to your own opinion. I'll bring it up again the next time it comes up. If they still push back and say that their way is better or they can't because of these reasons, I don't ever talk about it again. Interesting. I'm in the position to advise, not to force people. And if they think that it's better, for whatever reason they think they're a smarter programmer than me they think that it's better. Maybe there's some politics around it that they can't get into. I don't know the reason, that's fine. But after the second time, that is their responsibility and it is up to them to fix it on their own if they decide to. I'm no longer going to spend mental energy trying to do it, I think that's a fascinating and endlessly deep topic.
Speaker 1:I'd like to go into that a bit more. I do want to bring up one other thing first. We talked about like length of engagements and stuff like that um. My ideal length of engagement is a bit different.
Speaker 2:My ideal engage engagement length is lifetime um okay and I have a couple continuous advising like forever type approach.
Speaker 1:Yeah yeah, till one of us keels over. Um and I have a couple client engagements that have lasted since the beginning of 2023. So I guess like two years at this point or actually I have one of those and then another one that's like a bit shorter than that.
Speaker 1:Um but I think that's great to work with clients for multiple years and, I hope, 10 years from now, I'm working with the same clients Because, the way I look at it is, I become this person's trusted advisor and I work to be somebody who's going to always be helpful in some way. So, like I imagine that your consulting and tell me if this is right or wrong, I imagine that your consulting is a mixture of knowledge sharing and like behavioral advice, and let me even break that down a little bit more.
Speaker 1:Knowledge sharing regarding tools and stuff like that and technology and all that kind of stuff knowledge sharing around principles, stuff like that and technology and all that kind of stuff, knowledge sharing around principles. And then maybe the behavioral stuff is a third category. Maybe that's just more knowledge, but I'm guessing it's at least a mixture of tools and technology agnostic principles.
Speaker 2:Yeah, I think that very much sums it up like concrete examples. This is how you push a new screen onto the stack in hotwire native. Here's the code for it, but also here's like the mindset of where to put your code and how to organize your code versus on rails, versus hotwire like native apps. A big thing that I teach is to leave content or leave decisions on the server, and that's not pointing to a specific line of code and saying this should go somewhere else. It's actually more of a mindset shift.
Speaker 1:Yeah, exactly. And I'm sure that you have cases where you're pairing with a programmer and your intention is to convey some hotwire native knowledge. But when you start you're like, oh hey, hang on, hang on a second. Like let's make sure that you have like a clean git working state before we start and let's like do this honestly like that, like very fundamental programming stuff. I imagine that comes up sometimes too yeah, a big question.
Speaker 2:Um, what is that? How is it always worded? It's just like how do I structure my mobile apps, like at the highest level, do I put my ios code in the same repository as my rails code base or is it in its own repository? And it's not like the answer is a or b. Of course, with everything, it's always it depends, right, and there's trade-offs and stuff. But even that, it's like they haven't even written a single line of code and they're like and folks are like well, where does the code go? You know, and like things like that. You go back to our original conversation at the beginning of this. I gloss over that. I'm not even thinking about that. I'm seven steps ahead. I'm thinking about where they're going to put the code for their authentication stuff, not where the code's literally going to live, and those type of questions are just. They make it really take a step back.
Speaker 1:Yeah.
Speaker 2:And remember.
Speaker 1:Yeah, and hopefully you can provide them with an answer. That's like you know. They're asking where do I put my code? But I've learned to recognize these questions that are actually proxies for other questions.
Speaker 2:Like.
Speaker 1:I think maybe the real question behind that is something like how do I do software design? And they're also signaling that maybe they don't have a super firm grasp yet of proportion and sequence and stuff like that. It's like, yes, you do want to have a feel for which repo you're going to put certain things in and stuff like that. Um, but at this stage that's certainly not the thing to be focusing on. Like, maybe right now you should be focused on getting to hello World as fast as possible and doing some throwaway app and getting familiar with the general principles and stuff like that. And then it's appropriate to zoom out and think about these bigger picture questions and stuff like that. Whatever, the way is that you personally approach it like providing them with that higher level guidance, instead of just saying like, oh well, you put it in a separate app. There you go, it's a separate repo. That's the answer.
Speaker 2:Yeah, yeah, that's. You keep bringing up these like just like flashbacks that I'm having the clients I'm working with right now. Their first question was where should we put the code right? That's why it's so relevant. And I was like, honestly, it doesn't matter, we can change it later. And they're like okay, but where should we put it? You know, they didn't want to know the why or how. They were like I literally need to know if I need to create a new repo or not create a new repo. So I was like create a new repo. It's easier to move things in than it is to pull things out. Done, true? Maybe Is it enough assurance for them to know that they can fix it later.
Speaker 1:Yes.
Speaker 2:Like it's enough for them to know okay, we've made a decision, we can move on, we can not worry about this anymore. And yet we can always fix things. It might be harder or easier to detangle versus retangle Sure, but they want someone who's going to tell them right now. Sure, but they want someone who's going to tell them right now worry about this, Don't worry about that. And the worry is not where to put your code. The worry, for them at least, was like how we're going to do authentication, because they have a complex authentication system. You know, like that's what we want to focus on, so it's exactly what you're saying.
Speaker 1:where they're just're, just like you used a really good phrase the kind of like the actual code versus the mental shift, the theoretical stuff yeah, well, I don't know if this is the same thing or not, but I think I came up with a better way of posing the question that I posed to you earlier. Um, I think in an engagement, you can either help a client gain knowledge or you can help them gain understanding. Um, and obviously, like, every engagement is going to be a mixture of both. Um, like, in, in one way of working, they basically use you as a database that they can query, but in the other way of working, you you help train them on how to think and stuff like that.
Speaker 2:Yeah, yeah, yeah. And I think that every, almost every engagement, with few exceptions, I see the shift go from the former, the ladder, to the former, to go from the high level how, where, why? Into the practical database.
Speaker 2:Query of me where they're like and I would almost expect the opposite, like at the beginning. They're like I have a specific question, I need help with this. But a lot of these clients come to me and they're like we don't get Hotwire native at all. We got questions, question number like is it actually a web view or are you downloading the whole rails app to the, to the ios app and then rendering it? You know, things like that that are so big picture is usually where my conversations start with these folks. And then, by you know, week three, week four, it's like how do we have the tab bar not reload when you click a link?
Speaker 1:Like things like that, yeah, getting down to really specific stuff, and it's like this big inverted pyramid almost of knowledge. My stuff goes the other direction usually, and it's not hard to see why, man, I'm having just a pile up of thoughts. So for me, like, the thing that I'm probably known most for is testing, although definitely other stuff now too.
Speaker 1:But the thing with testing is like a lot of people think they understand how to do it and they don't realize that there are certain things that they don't realize and so they ask me, like very specific, sometimes superficial questions like should we use let or should we not use let, and stuff like that. Um, but then we end up going deeper and more fundamental to questions like what is a a test? What is testing?
Speaker 1:Because you know a lot of people who've even been doing testing for years, like if you ask them what is a test, they couldn't tell you the right answer. I myself couldn't tell you the right answer for the first several years of my testing experience. Sure.
Speaker 2:Yeah.
Speaker 1:Yeah, yeah, and I also have the experience where somebody hires me for help with something specific like TDD or OOP or something like that.
Speaker 1:And then almost immediately we end up going much broader, because we get in there and I discover in literally every single case that almost before we can focus on on anything else, we have to address the design of their system. We have to address the way that they like sliced up the world and created abstractions in their system to deal with the problems they're trying to deal with. And I'm deliberately avoiding using the word code um because I think.
Speaker 1:way too many people think of a software system as code and I think that really like that way of looking at it is the opposite of helpful. Yeah, that's interesting.
Speaker 1:Yeah, again we take the world and we slice it up into abstractions that are useful to us. And you know we have to talk about what's an abstraction because a lot of people aren't really familiar with what an abstraction really is, and I myself, as recently as last week, have like redefined for myself what I think an abstraction is. It's a very um, it's not this, it's, it's not an idea. That's often very well explained and it's not the easiest to understand.
Speaker 2:So anyway, they bring me in for like tdd or oop or something like that, and then we ended up talking about these broader principle based things yeah yeah, it's kind of wild how you I would you, almost from the outside you'd expect the opposite for both of us. You'd expect me to be getting in there answering specific questions right away and you'd expect you to be going in there and I'm going to give a lecture on abstraction, like as your first you know high level thing, and it's interesting how that's what you do talk about first, but it's because of the questions and you're kind of like doing the the 5y exercise with your clients. Yeah, okay, like why are you using, why are you using let? Well, why do you care about using let? You know, and like I'm like extrapolating from there, uh, but it's, it is interesting. One of the things that keeps me so excited and so invested and keeps my energy level high for this type of stuff is that every client goes a different direction than I expected. And it's like exactly what you're saying, where someone asks you about let and you get into abstractions, or you ask about let and you end up talking about what a test is. Maybe you can see that route after a number of years, because you know that when someone asks about this, it actually means this. But my questions are almost always go a different direction than we talked about.
Speaker 2:My couple retainers ago. Someone was like we really need help with tabs. We fixed tabs within the first 15 minutes of the engagement. They had like literally had a false should have been a true. It was like something very, very, very simple that they just kept glossing over.
Speaker 2:We spent the next three months talking about other stuff, you know, and if I were to write on paper like I'm going to work on tabs for the next three months, I would have been totally wrong. And the fact that we were just able to veer and steer and guide the situation to whatever they needed is what keeps it fresh and exciting for me but also like useful for them. And it's not that they came in and said we need to fix tabs and then, once we fix tabs, we're done it's. We need to fix tabs now. Our unknown, unknowns are what's next? And we need you to help find those for us. And being that excavator or whatever, of uncovering those unknowns and even surfacing it to them only comes from years of experience working in rails, working in testing, working in hotwire, native and like. That's where, that's the value that we bring uncovering those. It's not answering the specific question they asked.
Speaker 1:It's uncovering the questions to ask us almost yeah, yeah and hopefully, um, somebody like us can go to a client and we're asking them questions without any prompt at all, because we've we've seen these situations enough times to be able to anticipate what they have going on. No-transcript, which makes it really hard to describe what I do. Yeah, Um partly because I don't know what I do.
Speaker 1:I don't know how to label this thing, Um and it changes over time Like each engagement is different thing, um, and it changes over time, like each engagement is different, and like even like from one point in time to three months later, I'm doing like totally different stuff, totally, and I've gone from like working with individual uh, ctos and stuff on like technical problems, because it's a very small company, to like working with organizations of like 50 or 60 engineers and working with teams and and working with leadership on like non-technical management issues and I don't really know how to explain to people what it is that I that I do.
Speaker 1:lately I've been saying that I that I do like management consulting for, uh, technical, which is like pretty vague, and I don't know if people really know what that means, or anything like that. I think what happens a lot of times is I have to like get to know the person over a long period of time, or they get to know me like through the podcast or something like that.
Speaker 1:And only by gaining an understanding over a long period of time. Can they understand it enough to hire me? Because, like, just an elevator pitch type thing is not going to get it across.
Speaker 2:Yeah, I, I resonate with that on a different vertical, if you will. I work in hotwire native. You know you have a hotwire native problem. I can help. I can help fix it Right. But if someone asks me what type of clients do I work with, I don't know.
Speaker 1:I work with anyone.
Speaker 2:Like they have a Rails app and they want a mobile app. Cool, I can work with you. They could be in the medical space, they could be in the food space, they could have 70 developers, they could have three developers and it's like I have this narrow horizontal of clients and the verticals can be just literally any vertical, you know, and it always hangs me up because I like to do positioning exercises every year or so on my business and um, somewhere over here is like one of my favorite positioning books ever Obviously awesome, april Dunford.
Speaker 2:There's an exercise in it where you build your positioning and it's meant for businesses on on your product, but I like to do it for my own business and it's like who are your direct competitors? You know, what is your distinction between them? How are you distinguishing yourself? How do you? Or like, how do people talk about you? And it works you through this whole worksheet and then at the end it gives you one sentence about who you are as a business and how you're better than everyone else, essentially, and why they should choose you. And I redo the exercise almost every year, sometimes every two years because it changes over time.
Speaker 2:Sure, but it's so helpful in like nailing down how to talk about my business and how to express like, yeah, I do do all these things, but people come to me for a very specific reason and not another hotwire native developer, and like, what is that x factor?
Speaker 2:And this book helps you kind of nail down what that is and for you maybe it's familiarity, maybe you have a trusting voice on the podcast, you know it, it's like, but it uncovers those type of things and makes you lean into it in a way that can help you elevate that. Or like, maybe at the end you realize you want to do more podcasts or just be on more podcasts, or maybe it's actually you need to be on a different medium you know and be more familiar with people, or it's actually that you're positioning yourself entirely wrong and you need to say that you're a principal developer for hire. Who knows? But I find it super helpful in nailing down that sentence or two and then using it just freaking everywhere Twitter bio, website bio, footer or signature my email address because it becomes so tight and punchy that it's hard to ignore yeah, that's really interesting.
Speaker 1:Um, I am not um sure that I want to go that direction, even though it seems crazy like for me to say I don't want to have a sentence that accurately and concisely describes what I do. I'm a pretty avid disciple of Alan Weiss, and the prevailing wisdom in the technical consulting freelancing community is that you should specialize and specialize very narrowly. Yeah, um, specialize and specialize very narrowly yeah, um. And partly because I just have a contrarian streak in me, I question that yeah, um. And alan weiss takes a totally different approach. Uh, he says well in his, in his books. He says, like people say, specialize or die and he says not specialize or die, uh, generalize and thrive right.
Speaker 1:And if somebody you know what kind of consultant is alan weiss? I don't think there's any like he never has mentioned in any of his books like what kind of consulting he does. He just does consulting period. Yeah, yeah, um, and you know, I don't see any particular reason for me personally why, like an insurance company couldn't hire me to do consult consulting about their insurance business, like nothing to do with technology at all and I want to leave that possibility open.
Speaker 1:Um, it could be that that's a really dumb idea, but also it could not be. And it's kind of a race, it's like. Which do I arrive at first, like, do I have enough experiences? Where some commonalities emerge and I find out okay, now that I look back on the last however many years, I can see that I do OOP consulting, and that's the thing. Or management consulting, and that's the thing. Or it might just be that I blindly put one foot in front of the other and I keep getting clients somehow and I never need to do such a thing. So far that's been the case. So far I've never needed to put a label on what I do because I keep getting clients.
Speaker 2:Who knows?
Speaker 1:if that'll continue or not, but it's worked out so far.
Speaker 2:Yeah, I hear that that resonates too, because, in terms of, I feel like I don't even I don't use my punchy one line whatever publicly. It's actually more internal and it's not for me to find new clients Like I've been using I'm the turbo native guy or I'm a hotwire native guy, like that's good enough for people to know that I do stuff in that space, right. But the one that I have internal for me is more about where should I be spending my time and my efforts to further strengthen, like that brand, so to speak?
Speaker 2:It's not about like it's. It helps me make decisions about my business. It's your North Star, exactly exactly, and the most obvious outcome of that was writing the book. Becoming an expert in the space always almost comes with either a course or a book on the topic. Right and the harder one is maybe the book, but maybe you have more prestige with it.
Speaker 2:I chose the book. You know spoiler alert the book's not going to make me a lot of money directly off of sales. It's a tech book. How many Rails developers are in the world? I'm hoping to sell a couple thousand copies of this thing, but if I can close two clients because of the book, it pays for itself in an order of magnitude and that's my goal with it. It's a marketing tool to get more business through the door, and it's a genuine book. I'm laying all my secrets out there. So many people are going to buy this and they're going to build their own apps and never talk to me, and that's great. I want to help as many people as possible with it, but this isn't going to be a New York Times bestseller. I'm not going to get rich from this book If I get just a couple, a handful of clients from it. It did its job as solidifying me as an expert in the space.
Speaker 2:And that's a very different goal than writing a book for general Rails developers and wanting to be on the top programming list on Amazon or whatever. That's not my goal. So I write the book differently, I market the book differently. I market the book differently.
Speaker 2:I decided to write a book versus a course, which would probably make me way more money. I went with a publisher instead of self-publishing. You know like it guided all of these decisions? Just based on that simple thing that this book is not meant to make money. It's an indirect way of bringing in new clients.
Speaker 1:Yeah, that's the exact way that I looked at my book yeah I self-published it on amazon and I could have gone a different route and gotten a bigger share of the revenue, but I decided to do it this way for more reach and credibility and stuff like that, and in general I was going for credibility over um revenue and stuff like that because, just like you said, if it gets me enough good client engagements and stuff like that, because, just like you said, if it gets me enough good client engagements and stuff like that, then like the whole thing is very much worth it um we should probably wrap up soon, so naturally I'm gonna ask a question that we could spend hours and hours discussing. But perfect, yeah, but hopefully we can do a concise version of it. How do you find your clients?
Speaker 2:I find my clients almost 100% through inbound leads, and what I mean by that is people reach out to me and ask to work with me. I don't do really any cold emailing or scraping or messaging people and saying, hey, do you want a native app? Or I heard you talking about like 90% of my clients 95 plus percent of my clients see my blog, listen to me on a podcast, read about me on Twitter, or listen to, you know, watch a YouTube video of mine. And they say, oh, we need help with our app, can you help us? Or we heard that you do this thing, can you help us? And leaning into that, you know, like that's I like that.
Speaker 2:I don't like to do sales outreach. Even my sales cycle is very short. It's like they email me, I write back with a list of questions, they answer them. If that sounds good, we hop on a call to sign a contract. Like it's it's hopefully three messages over email and one video call and we have a contract ready and that's the way I like it. Um, I'm booked through, like you know, q1 right now. So if people reach out to me now, it's like great, here's the earliest we can start. Is that a deal breaker. Yes, okay, sorry, reach out to me later, but I don't like doing really traditional sales.
Speaker 2:I do enjoy doing marketing, which is why I do the blog posts, which is why I do the newsletter, the Twitter, the LinkedIn, even now YouTube. But how clients find me, I think, is actually the more important question, because everything is inbound and I think that that is. I have built up a reputation of just always talking and doing hotwire native stuff. I've whether you want to call it true, you know work myself into a corner here. It's a corner that I'm very happy in. I like this. If hotwire native goes defunct in in three years and I'm totally out of work because of it, it gets whatever. I'll figure it out. Then I'll find something new or whatever. But or I'll revive it and manage it on my own, like right now and for the indefinite future. I'm doing hotwire native and if someone hears my name and they know anything about me, the first thing they think of is probably hotwire native and that's.
Speaker 2:That's on purpose, you know.
Speaker 1:Yeah, that's very valuable um, yeah, and you know credibility I find is very transferable. So if hotwire native goes away, I'm sure you could, you could go a different direction and all this marketing stuff that you've done will be transferable to whatever that may be, and that'll probably never happen anyway, it probably won't go away anytime soon, I would guess I don't think it will.
Speaker 1:Yeah, and I've kind of developed a reputation as the Rails testing guy. I haven't been beating that drum drum quite so hard, but I did just put out a book on rails testing, so that adds to that pretty big yeah yeah um, yeah, and part of why I asked this question is because to me.
Speaker 1:That's like the question of consulting and freelancing, like how do you get clients? And it took me years to find out that the answer is just three words, which is speaking and writing. That's, that's the entire answer there's. There's a ton inside of that, like how do you do your speaking and writing? And stuff like that but. But that's the thing like if you do the right kind of speaking and writing and enough of it, that will bring clients to you.
Speaker 2:Yeah, I think that that very well sums up what I said over many other words. I speak and I write and it brings in clients and people know who I am and then they reach out and say can I give you money to help us with something? And that's my business.
Speaker 1:Where can people go to find your book? And just give us any other links or anything that you want to share.
Speaker 2:Yeah, so best place to reach me is mazzolotticom. There's a link up at the banner right now to buy the book and there's also links to where I am on social on the homepage. There I put out a weekly-ish newsletter on Hotwire Native you can sign up for there as well and monthly-ish blog on Hotwire Native you can sign up for there as well and monthly-ish blog posts on the same the book right now you can buy. You get the full PDF of everything that I've written so far at a discounted rate and you get updates every two weeks as I publish new content for it until the book goes live later this year.
Speaker 1:Awesome. Well, Joe, thanks so much for coming on the show.
Speaker 2:Yeah, thanks for having me. This was a great talk. I especially liked the second half.
Speaker 1:Me too, thank you.