Podcasts about rails

Stephanie recommends "Blue Eye Samurai" and a new ceramic pot (donabe) for cooking. Joël talks about the joy of holding a warm beverage in a unique mug. Stephanie discusses her shift to a part-time support and maintenance role at thoughtbot, contrasting it with her full-time development work. She highlights the importance of communication, documentation, and workplace flexibility in this role. Stephanie appreciates the professional growth opportunities and aligns this flexible work style with her long-term career goals. Blue Eye Samurai (https://www.netflix.com/title/81144203) Donabe pots (https://jinenstore.com/collections/nagatani-en) thoughtbot's Support & Maintenance services (https://thoughtbot.com/services/rails-maintenance) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I have a TV show recommendation this week. I think this is my first time having TV or movies to recommend, so this will be fun. My partner and I just finished watching Blue Eye Samurai on Netflix, which is an animated historical Samurai drama. But the really cool thing about it is that the protagonist she's a woman who is disguising herself as a man, and she is half Japanese and half White, which the show takes place during Edo, Japan. And so that was a time when Japan was locked down, and there were no outsiders allowed in the country. And so, to be mixed race like that was to be, like, kind of, like, demonized and to be really excluded and shamed. And so, the main character is on, like, a revenge mission. And it was such a cool show. I was kind of, like, on the edge of my seat the whole time. And it's very beautifully animated. There were just a lot of really awesome things about it. And I think it's very different from what I've been seeing on TV these days. JOËL: Is this a single-season show? STEPHANIE: So far, there's just one season. I think it's pretty new, yeah. It's very watchable in a couple of weekends. [laughter] JOËL: Dangerously so. STEPHANIE: Yeah, exactly [laughs]. JOËL: How do you feel about the way they end the arc in season one? Do they kind of leave you on a cliffhanger, or does it feel like a pretty satisfying place? STEPHANIE: Ooh, I think both, which is the sweet spot, in my opinion, where it's not, like, cliffhanger for the sake of, like, ugh, now I feel like I have to just watch the next part to see what happens because I was left unsatisfied. I like when seasons are kind of like chapters of the story, right? And the characters are also well written, too, and really fleshed out even, you know, some of the side characters. They all have their arcs that are really satisfying. And, again, I just was left very impressed. JOËL: I guess that's the power of good storytelling. STEPHANIE: Yeah. I was reading a review of the show. And that was kind of the theme of–it was just that, like, this is really good storytelling, and I would have to agree. Yeah, I highly recommend checking it out. It was very fun. It was very bloody, but [chuckles], for me, it being animated actually made it a little more palatable for me [laughs]. The fight scenes, the action scenes were really cool. I think the way that it's been described is kind of, like, you know, if you like historical dramas, or if you like things like Game of Thrones, there's kind of something for everyone. I recommend checking it out. Joël, what's new in your world? JOËL: Listeners of the show don't know this, but you and I are on a video call while we're recording this. And you'd commented earlier that I was holding a cool mug. It's got a rock climbing hold as a handle, which is pretty fun. I enjoy a lot of bouldering. That makes it a fun mug. But I was recently thinking about just how much pleasure I get from holding a mug with a warm beverage. It's such a small thing, but it makes me so happy. And that got me thinking more broadly about what are things in life that are kind of like that. They're small things that have, like, an outsized impact on your happiness. Do you have anything like that? STEPHANIE: Oh yes, absolutely. You were talking about the warmth of a hot beverage in your hands. And I was thinking about something similar, too, because I'm pretty sure this time of year last year, I talked about something that was new in my world that was just, like, a thing that I got to make winter more tolerable for me here in Chicago, and I think it was, like, a heated blanket [laughs]. And I am similarly in that space this year of like, what can I do or get to make this winter better than last winter? So, this year, what I got that I'm really excited to use— it actually just came in the mail—is this ceramic pot called the donabe that's kind of mainly used for Japanese cooking, especially, like, hot pot. And so, it will be a huge improvement to my soup game this year [laughs]. Similarly, it's kind of, like, one of those small things where you can take it from the stovetop where you're cooking straight to the table, and I'm so looking forward to that. It's kind of like your hot beverage in your hand but, like, three times the size [laughs]. JOËL: Right. The family-style version of it. STEPHANIE: Yeah, exactly. So, that's what I'm really looking forward to this year as something that is just, like, I don't know, a little small upgrade to my regular soup routine. But I think I will get a lot of pleasure [laughs] out of it. JOËL: What do you normally cook in that style of pot? Is it typically you do a hot pot in there, or is it meant for soups? STEPHANIE: Yeah, it holds heat really well, so I think that's why it's used for soup a lot. And the one that I got specifically has a little ceramic steamer plate as well. And so, I'm looking forward to having, like, this setup that's made for steaming, where you don't have to have any, like, too many extra bits. And, again, it can go from stove to table, and that's one less thing I [chuckles] need to wash. JOËL: I love it. So, something else that is kind of new in your world is you'd mentioned on a recent episode you'd wrapped up with your current client. And you've rotated on to not exactly a new client but a new almost line of business. You're doing a rotation with our support and maintenance team. Can you tell us a little bit about what that is like? STEPHANIE: Yeah. I'm excited to share more about it because this is my first time on this team doing this work. And it's pretty new for thoughtbot, too. I think it's only, like, a year old that we have had this sub-team of the one that you and I are on, Boost. In the sub-team, support and maintenance is focused on providing flexible part-time work for clients who are just needing some dedicated hours, not necessarily for, you know, a lot of, like, intense new feature work, but making sure that things are running smoothly. A lot of the clients, you know, have had Rails apps that are several years old, that are chugging along [chuckles], just need that, like, attention every now and then to make sure that upgrades are happening, fix any bugs, kind of as the app just continues to work and provide value. And then, occasionally, there is a little bit of feature work. But the interesting thing about being on this team is that instead of being on one client full-time, you are working on a lot of different clients at the same time, and a lot of them are on retainers. So, they maybe have, like, 20 hours a month of work that gets filled with kind of whatever tasks need to be done during that time. So yeah, I recently joined a few days ago and have been very surprised by kind of this style of work. It's different from what I'm used to. JOËL: That seems pretty different than the sort of traditional thoughtbot client engagement. Typically, if I'm a client and I'm hiring a team from thoughtbot, as a client, I get sort of a dedicated team. And they're probably either building some things for me or maybe working with my team and sort of full-time building features. Whereas if I hire the support and maintenance team, it sounds like it's a bit more ad hoc. And it's things I assume it's like, oh, we probably need to upgrade our Rails version since a new release came out last month. Can you do that? Here's a small bug that was reported. Can somebody fix that? Things along those lines. Is that pretty approximate of what the experience is for a client? STEPHANIE: Yeah, I would say so. I think the other surprising thing has been there have been a little bit of more DevOps type of tasks as well mixed in there. Because oftentimes, these are smaller clients who maybe have, like, a few developers actively working on new features and that type of stuff. But there is, like, so much of the connecting work that needs to happen when you have an application. And if you don't have a full in-house team for that, that often gets put on developers' plates. But it's kind of nice to have this flexible support and maintenance team, again, to, like, do the work as it comes up. A lot of it is not necessarily, like, stuff that can be planned in advance. It's kind of like, oh, we're hitting, like, our usage limit for this Heroku add-on. Let's evaluate if this is still working for us, if this is a good tier to be on. Like, should we upgrade? Are there other levers we could pull or adjustments we can make? So, that's actually been some of the stuff that I've been working on, too, which is, again, a little bit different from normal development work but also still very much related. And it's all kind of part of the job. And, you know, a lot of the skills are transferable. And to know how to do development in a framework then sets you up, I think, really well to, like, be able to make those kinds of evaluations. JOËL: So, it sounds like you almost, in a sense, provide a bit of a velocity cushion for clients so that if something does come up where they would maybe normally need to pull a dev off of feature work to do some side thing for a couple of days, you can come in and handle that so that their dev team stays focused on shipping features. STEPHANIE: Yeah, I like that phrase you used: velocity cushion. That's cool. I like it. The other surprising thing that I have kind of quite enjoyed, at least for now, is because we bill a little bit differently on this work; we have to track our hours more explicitly. And that has actually helped me focus a lot more on what I'm doing and if I should continue to be doing what I'm doing. I'm timeboxing things a lot more because I know that if there is a ceiling on the number of hours, I want to make sure that that time is spent in the most valuable way. And I also really enjoy, like, the boundaries of timeboxing, yes, but also, like, the tasks are usually scoped pretty narrowly so that they are things that you can accomplish, definitely in the week, because you don't know if you'll kind of still be working for this client next week but even more so, like, within a few days. And that is nice because I can kind of, like, you know, track my hours, finish the task, and then feel a little bit more free to go do something else without being, like, okay, like, what's the next thing that I need to be doing? There's a little bit more freedom, I think, when you're kind of, like, optimizing towards, like, finishing each item. JOËL: Do the stories of the work that you have to do does it typically come kind of pre-scoped? Are you involved in making sure that it has, like, very aggressive scoping? STEPHANIE: Yeah. So far, I've not been involved in doing the scoping work, and it has come pre-scoped, which has been nice. This was also, again, just different. Because I was on a client team previously, a lot of the work to be done was the disambiguating, the, like, figuring out what to be doing. Whereas here, because, again, we're kind of optimized for people coming in and out, if there is uncertainty or lack of clarity, it's pointed out early, and someone is like, "Okay, I will take care of this. Like, I'll take the lead on this so that it can be handed off." One client that I'm working on is using Basecamp's Shape Up methodology, which I actually hadn't worked with in a very explicit way before. And that has been interesting to learn about a little bit, too. One thing that I have enjoyed about it is instead of sprints, they're called cycles. And I like that a lot because, you know, sprints kind of have the connotation of, like, you're running as fast as you can but also, like, you can't run that way forever [laughs]. And so, even that, like, little bit of rewording change is really nice. The variable part is scope, right? It's we're focused on delivering something completely and very intentionally cutting scope as kind of the main lever. JOËL: How do you maintain sort of focus and flow if you're jumping across multiple clients? Because you said, you work with multiple clients as part of this team. And I feel like I can get a little bit frustrated sometimes, even just jumping between, like, tickets within one project. And so, I could imagine that jumping between different clients during the week or even the day might be really disruptive. Have you found techniques to help you stay in the flow? STEPHANIE: Yeah, that is a tough one because, also, every client has their different application; you then have to start up on [laughs] your local machine, and that is kind of annoying. You know, I do still tend to kind of, like, bundle similar work together. If, like, there's a few things I can do for a client on one day, I'll make sure to focus on that. But what I mentioned earlier about, like, seeing something to completion has been really, I want to say, fun even. Because it then kind of, like, frees up that mental space of, like, okay, I don't have to, like, have this thing that I'm working on lingering in my head about, like, oh, did I forget to do something? Or, you know, have, like, shower thoughts of like, oh, I just thought of a new way to implement this [laughs] feature because it doesn't spill over as much as maybe larger initiatives anyway. And so, I am context-switching, but it's only kind of after I've gotten something to a good place where I've left all of the notes. And that's another thing that I'm now kind of compelled to do a little more actively. It's like, every single day, I'm kind of making sure that the work that I've done has been reported on, one, because I have to track my hours, so, you know, and I sometimes leave notes about what that time was spent on doing. And also, when the expectation is that someone else will be picking up, then there's no, like, oh, like, let me hold on to this, and only when I know that I have to hand off something that's when I'll do the, like, dedicated knowledge dumping. It's kind of just built into the process a little more frequently. JOËL: So, you're setting up for, like, an imminent vacation factor. STEPHANIE: Yeah. Which I kind of like because then I can take a vacation [laughs] whenever I want and not have to worry too much about, oh, did I do everything I needed to do before I leave? JOËL: So, you know, these practices that you're doing are specifically adapted for the style of work that you have. Are there any that you think you would bring to your own practice if you ever rotated back on to a dedicated client project, anything that you would do there that you would want to include from your practice here? STEPHANIE: Yeah. It does sound kind of weird because part of what's nice about being on a full-time team is that there is less, oh, if I don't get something done today, I have tomorrow to do it [laughs]. And it seems like that would be like, oh, like, kind of take the pressure off a little bit. But I would be really curious to continue having, like, such an intense awareness about how I'm spending my time. Because I've certainly gotten a little bit lax on, like, full-time development work when you just go down a rabbit hole [laughs] and you come out, like, three hours later, and you're like, "What did I just do?" [laughs] And, you know, maybe that's what needed to be done, and that's fine. But if you have the information that it took you three hours, you can at least make a better-informed decision about, like, oh, maybe I should have stopped a little earlier or, like, yeah, it took about three hours, and that's okay. I think that would be an interesting area to incorporate and to be able to report more frequently. And I also like to know how other people spend their time, too. So, just, like, that sharing of information would also be really beneficial even to, like, a team. JOËL: What about the more aggressive documentation? Is that something that...because that can be really time-consuming, I imagine, as well. Is that something that you would value in a kind of, more focused full-time project context? STEPHANIE: Yeah. One part I've enjoyed about it is that I'm documenting, like, decision-making a lot more actively where, you know, I'm kind of, like, surfacing to be like, hey, here's the outcomes of, like, my research. We're not as, you know, embedded in the business, and we don't have as much of that, like, context and knowledge about what the best solutions are all the time. I'm documenting all of that, you know, usually, for the client stakeholder to be like, "Hey, here's my recommendations, like, how do you want to...what do you think is the best way to go? On one hand, it's kind of nice not to have to, like, be solely responsible for making that decision, right? And I'm kind of, like, leaning on, like, hey, like, you're the expert of your application and your product, you know, here's what I've learned. And now I've, like, put this all, like, for you and presented it to you. And I think that, for me, has gotten lost sometimes when I end up being the same person of, like, doing the research and then deciding, and it just kind of ends up being held in my head. And that, I think, is something really important to document, even if it's just for other people to, like, see how that process might work or, like, what things I already considered or didn't try. That exercise, I think, can be really important. So, so far, the documentation has not necessarily been, like, code level, but more, like, for each task, it's, like, showing your work, right? And not in a, like, you're being monitored [laughs] sort of way but in a way that supports it getting done with a lot of that turnover. JOËL: It's almost like a mini report that you're doing. So, you'd mentioned, for example, an application running into memory problems on Heroku. It sounds like you would then go maybe investigate that and then make some recommendations on whether they need to increase some dynos or maybe make some internal changes. It sounds like you may or may not be the one to execute those changes. But you would write up some, like, a mini report and submit that to the client, and then they can make their own execution choices. STEPHANIE: Yeah, exactly. And they can execute it themselves or then create a new ticket for the next person rotating on to support and maintenance to tackle it in a different cycle. JOËL: So, support and maintenance doesn't just do the investigation. Your team might do the execution as well. It's just that the sort of more research-y stuff and the execution stuff gets split out into different tickets because it's so tightly scoped. STEPHANIE: Yeah, that sounds right. JOËL: I like that. STEPHANIE: One area that I wasn't sure that I was going to like so much about this kind of work is, you know, when you're not kind of embedded on a team, I was thinking that I might not feel as connected, or I would miss a bit of that getting to know people and just, like, seeing people face to face on a daily basis. I'm still evaluating how that would go so far because it has definitely been, like, mostly asynchronous communication, you know, which is what works well for this type of the style of team or project. But I think what has been helpful is realizing that, like, oh yeah, like, I can also get that elsewhere, you know, with thoughtbot folks like with you doing this podcast every week. And right now, there are, like, two Boost members who are doing support and maintenance full time, and folks who are unbooked kind of come in and out. And I can see that there's still a team. So, it's not nearly as kind of, like, isolating as what I had thought it would be. JOËL: There's something that's really curious to me, I think, sitting at the intersection of the idea of fostering more team interactions and the sort of, like, mini reports that you write. And that's that I would love to see more sharing among all of us at thoughtbot about different interesting problems that we've had to solve or that we're tackling on different client work. Because I think in that case, it's a situation where we all just learn something, you know, maybe I've never had to deal with a memory leak or might not even have an idea of, like, how to approach memory issues on Heroku. So, seeing your little mini report, if you'd maybe share that, and, you know, maybe it can be anonymized in some way if needs to, I think would be really nice, at the very least, something that could be done, like, internally. So, I almost wonder if, like, building that practice of, you know, maybe not for every ticket that I do because, you know, I don't want to just be dumping my tickets in the thoughtbot Slack. But I run into something interesting and be like, oh, let me tell a little story about this and do a little write-up. That might be something that's good for the whole team and not just for folks who are on support and maintenance. STEPHANIE: Yeah, absolutely. As you were saying that, I was thinking about how it does kind of encourage me to find support outside of my, like, immediate team, right? Because I don't necessarily have one with the client and to, I don't know, I'm imagining, like, these roots growing in terms of different communities I'm a part of and bringing those problems just outside of my internal world, and kind of getting that outside feedback because by necessity a little bit, right? But also, with the added benefit of, you know, I think that's also how a lot of people end up writing content that gets shared with the world. So, I had the misconception that I would be kind of just, like, on my own off doing things like just tickets and being a little coding robot, but I've been surprised by it feels very fresh and new. So, I think, I guess, I was needing a little bit of that [laughs]. JOËL: I was having a conversation with another thoughtboter recently about how valuable sometimes change can be for its own sake and how that can sort of refresh. You want it just at the rate where you have a chance to build some stability. You don't want chaos. But sometimes change can sort of take you out of a rut, give you energy, maybe sort of restart some good habits that you had sort of let atrophy. And that finding, like, just that right level of shaking things up can really help a team, you know, get their effectiveness to the next level. STEPHANIE: Yeah. I like what you said about good habits, for sure. A couple of other random, little things that I just thought of about what I've liked is, I don't know, maybe this is a little silly. But we, you know, use shared credentials for logging into different services and applications or third parties that clients are using. And that has actually been something that has been so easy [laughs] and very low friction compared to, you know, joining a new project and manually be added as, like, your individual account to all of the different things. And things inevitably get forgotten, and then you have to rely on someone else to do it. And sometimes they don't get back to you [laughs] for a while. The self-serviceness of this work has been cool, too. And I just, yeah, wanted to say that I really appreciated the thought that went into making it as easy as possible to be like, yeah, I can find the credentials here. It is, you know, a bit more anonymized because I'm just using, like, a shared account. JOËL: Like a generic thoughtbot account on a client system rather than stephanie@thoughtbot. STEPHANIE: Yeah, exactly. But I think I saved so much time [laughs] this week just being able to do all of that myself and, you know, knowing where to look first before having to ask. JOËL: I guess you'd need something like that, right? If you're only jumping in on a project for the first time, for a couple of hours or something like that, you don't want to go through a whole onboarding process because that might then, like, easily double. You know, instead of doing two hours on this project, you're now doing four. STEPHANIE: Yeah, exactly. I guess the other takeaway, for me, was like, oh, definitely, if I were to have to set up accounts [laughs] for an application, you know, I've obviously seen where it was like, very clearly, like, the founder having created all these personal accounts for this services, and people are still using their credentials many years later [laughs], even though they probably, like, maybe may not even work for the company anymore. But yeah, the shared credentials and using that generic account that anyone can kind of get into when needed has really lowered the barrier to jump into doing that work, right? And especially because, like you said, it reduces that time. And we're, you know, billing by the hour anyway. So, it's kind of a win-win situation. JOËL: And I totally understand why you would not want something like that for a longer engagement. But for something like support and maintenance, it sounds like it was the right choice. STEPHANIE: Yeah, yeah. Again, I just mentioned it because it's just different. And so, maybe if this sparks any ideas for our listeners about how processes could be different or, like, the styles or ways of working can be different, I think that would be cool. JOËL: And just to be clear here, it sounds like what you're doing is for sort of each client; you create a separate set of credentials that are for that client but that are about thoughtbot generically. You don't have, like, one thoughtbot email and password that we reuse for every client. STEPHANIE: [laughs] Oh yes. That would be not so good [laughs] if we got hacked and suddenly, now they have access to everything. JOËL: So, every client gets its own unique email password combo. We're using security best practices here. And then, since you do have to share them through a team, are you doing some sort of, like, shared 1Password vault or something along those lines? STEPHANIE: Yeah, we are using a shared 1Password vault. That is definitely what I meant [laughs] the first time when I was mentioning the shared credentials, where that was basically the only thing I had to get onboarded to, the vault, for support and maintenance to be able to hit the ground running. JOËL: So, this sounds like a pretty exciting new style of project for you. Is this something that you would see yourself preferring to do longer term, to sort of focus on this style of project? Or do you think that you'd like to come back to more classic project work in the near future? STEPHANIE: I'm not sure yet, but I'm also hoping to have an answer to that question. And it definitely does feel like an experiment for me personally. I can see liking it, and that also fitting well with some of my longer-term goals of being able to, like, step back from work. Maybe working fewer days a week is something that I've, like, thought about in terms of, like, a long-term goal of mine because I'm not as needed [laughs] on a team. Which I think, in the past, I also had a bit of a misconception that, like, in order to be a good developer, I had to have all the domain knowledge, and be indispensable, and, like, be the go-to person to answer all the questions. But now I'm at a point where I don't want to [laughs] necessarily have to answer, like, every question because that creates, like, a dependency on me. And if I need to step away from work, then that could be tough, right? The vacation factor that you mentioned. So, this style of work is very interesting in terms of if it might provide me a little bit more of that, not exactly work-life balance, but just kind of be closer to my goals in terms of what I want out of work and my time. And, hopefully, I'm going to be doing this next week, but I don't know because that's the nature of it [laughs]. But if I am, then I'll definitely have more to say about it. Probably. JOËL: Well, it definitely sounds like we'll have to check in again on what's, I guess, not so new in your world on a future episode. On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Brass locomotives are dead. There's no point in buying them. They're a bad investment. In fact, we couldn't understand why anybody would even want to buy and sell them until we met Matt Dowd at Resourced Rail's. Not only is Matt an avid Model Railroader but he's been an avid collector and trader of brass locomotives in all scales for decades, and now he's turned it into a full-time business. We decided to have a return visit to find out how this fledgling company turned into a full-time job for Matt who now employs seven people to help him keep up with demand. Plus he tells us all about his exciting trip to the “Land of the Rising Sun” and what model railroading is like in Japan as he introduces us to some of the great brass locomotive builders of our time. It's a great episode and one we're all sure you'll enjoy!!

Rails are thin, and so are rakes and pencils and many other things.

The engines have trouble with Travis the new tram, Class 40 returns to help and Duncan visits Australia in five train-tastic stories! Hosted on Acast. See acast.com/privacy for more information.

In this supper club episode of Syntax, Wes and Scott talk with James Mikrut about Payload, how Payload isn't just a CMS, where Payload fits in a tech stack, why they picked Drizzle for an ORM, what Payload Cloud is, and where's the Rails for JavaScript? Show Notes 00:31 Welcome 02:00 Who is James Mikrut and what's the idea behind Payload? 05:22 Payload isn't just a CMS Payload Payload on GitHub Payload on Twitter Payload on YouTube 09:08 Where does Payload fit in the tech stack? KeystoneJS Supabase Retool 11:22 Is Payload using TypeScript? 13:44 Why did you pick Drizzle? Drizzle ORM 18:08 Do you have to maintain MongoDB and Drizzle? SvelteKit 26:31 Does Payload have visual editing elements? 30:34 Do you build a custom UI for users? 35:10 What is Payload Cloud? 38:12 Where is the Rails for JavaScript? Next.js by Vercel Laravel Spark Deploy your Laravel PHP application painlessly RedwoodJS: The App Framework for Startups | RedwoodJS.com 41:39 How do you manage contributions from open source? 43:46 GitHub + AI 48:18 Syntax Brought to you by Sentry Error Management Magic: Introducing the Sentry Plugin for Payload 50:26 Supper Club questions Shameless Plugs Payload on GitHub Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads

It's holiday season and we're ready as ever (even though this year has gone by insanely fast). If you recall, we had on one half of the OMG You Need That duo last year—the wonderful Hally Seminara. Now, we're lucky to have both Hally and her stylish partner in crime, Lauren Vreeland. We wanted to get some expert guidance on all things holiday dressing, gift giving, and winter style. We learn what textures to embrace for the joyous times ahead (hello, velvet and sequins). We also learn how to wear the same dress three ways for any and all upcoming gatherings. If you have a festivity on the horizon, this episode is for you.Mentioned in this episode:Jennifer Fisher Hoop EarringsAlaia Crystal Embellished Ballet FlatsMonika Blunder Lip LinerYSE Beauty Exfoliating PadsBiologique Recherche Lotion P50Isabel Marant Long CoatPrada Platform HeelsMango EarringsAgolde Cooper Cargo PantsSteve Madden Chanel Ballet Flat DupeJennifer Fisher Heart EarringsPerfect White TeeBottega Veneta Skinny BeltToteme High Neck Sleeveless TopZara Satin Skirt With Elastic WaistbandPlease note that this episode and description may contain paid endorsements, advertisements, and affiliate links for products and services.Head on over to macys.com/giftfinder or macys.com to find that perfect present.Rails provides free worldwide shipping and free returns. Enjoy 10% off your first order on rails.com when you sign up for emails. Go to tryarmra.com/LIPSTICK or enter LIPSTICK to get 15% off your first order. Produced by Dear Media.See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

In this episode, we're unwrapping the highlights from Laracon AU, with a special focus on Laravel Pulse leading our discussion. Taylor takes the reins to guide us through the origins and functionality of Laravel Pulse, a health monitoring tool for your Laravel applications.We then shift our discussion to Laravel first party packages.  Taylor openly shares insights into his decision-making process—revealing how he selects packages to join the Laravel family and when it's time to bid them farewell.Our conversation doesn't end there though.  We also look at the future of Laravel and examine the strategies used for continually injecting innovation and fresh ideas into the Laravel ecosystem. Taylor Otwell's Twitter - https://twitter.com/taylorotwell Matt Stauffer's Twitter - https://twitter.com/stauffermatt Laravel Twitter - https://twitter.com/laravelphp Laravel Website - https://laravel.com/ Tighten.co - https://tighten.com/ Laravel Pulse: https://pulse.laravel.com/ Laracon AU - https://laracon.au/ Bugsnag: https://www.bugsnag.com/ Cashier: https://laravel.com/docs/10.x/billing Docker: https://www.docker.com Forge - https://forge.laravel.com/ Herd: https://herd.laravel.com/ Horizon: https://laravel.com/docs/10.x/horizon Inertia - https://inertiajs.com/ Livewire: https://laravel-livewire.com/ Lumen: https://lumen.laravel.com/docs/10.x Mix: https://laravel-mix.com/ Next.js: https://nextjs.org/ Passport: https://laravel.com/docs/10.x/passport Pennant: https://laravel.com/docs/10.x/pennant Sentry: https://sentry.io/for/php/ Tailwind: https://tailwindcss.com/ Telescope: https://laravel.com/docs/10.x/telescope Tony Messias Twitter: https://twitter.com/tonysmdev Valet: https://laravel.com/docs/10.x/valet Vapor - https://vapor.laravel.com/  -----Editing and transcription sponsored by Tighten.

It's probable that the same person committed a series of axe murders between 1898 and 1912 across the United States, including the infamous 1912 Villisca axe murders in Iowa.  And, this serial killer appears to have traveled by train to perform these heinous acts.  If it were the same person, he was responsible for at least 59 deaths, with the potential to have committed up to nearly 100.  The theory of a single killer hinges on a pattern of behaviors and circumstances: the murders were typically carried out with an axe belonging to the victim, the majority of the murders took place near a train track, the killings were done at night, and the victims were often asleep in their beds.  The Villisca axe murders are the most notorious of these cases; however, with the passage of over a century, definitive answers are likely out of reach, and the true identity of "The Man from the Train" remains a subject of speculation.Visit us at www.mydarkpath.comwww.youtube.com/@mydarkpathwww.patreon.com/mydarkpath

Welcome to the Nothing Shocking Podcast 2.0 reboot episode 210 with our guest Rudy Sarzo of Quiet Riot (Ozzy Osbourne Whitesnake, Dio, Blue Oyster Cult, Guess Who). In this episode we discuss Quiet Riot's 40th Anniversary of Metal Health tour, 2024 plans for Monsters of Rock Cruise, and more!  Rudy is also the author of the book, Off the Rails.   For more information visit: https://www.quietriot.band/ https://guitarnuttees.myshopify.com/collections/rudy-sarzo-iconic-bass-design-collection https://www.chromacast.com/rudy-sarzo-gig-bags   Please like our Facebook page: https://www.facebook.com/nothingshockingpodcast/  Follow us on twitter at  https://twitter.com/hashtag/noshockpod.   Libsyn website: https://nothingshocking.libsyn.com For more info on the Hong Kong Sleepover: https://thehongkongsleepover.bandcamp.com Help support the podcast and record stores by shopping at Ragged Records. http://www.raggedrecords.org 

NTD News Today—11/23/20231. Macy's Parade: Float Displays2. Macy's Parade: Inflatable Balloons3. Macy's Parade: Holiday Spirit4. Macy's Parade: Marching Joy5. Macy's Parade: Iconic Characters6. Macy's Parade: Live Performances7. Macy's Parade: Crowds Cheer8. Macy's Parade: Seasonal Magic9. Macy's Parade: Family Tradition10. Iconic Macy's Balloons11. Macy's Holiday Cheer12. Macy's Musical Performances13. Macy's 2023 Thanksgiving Day Parade14. Macy's Thanksgiving Day Parade Excitement15. Macy's Workers to Strike on Black Friday16. Thanksgiving Travelers Hit Roads, Rails and Skies17. U.S. Troops in South Korea Celebrate Thanksgiving18. Ukraine Launches ‘Food Train' to Help Residents19. AZ: Accidental Thanksgiving Invite Sparks Unusual Tradition20. Hy-Vee Turkey Gravy Recalled Over Labeling Issue

On this episode of Ruby for All, Andrew and Julie welcome Joe Masilotti, known as the ‘Turbo Native Guy,' to discuss Turbo Native. They cover what Turbo Native is, its advantages when building apps, and how it can be an effective tool for Rails developers.  Joe also gives us an update on his library, Turbo Navigator, and provides some insightful advice for those wanting to dive into Turbo Native.  He shares his experience of Rails World Conf, discusses the future of Turbo Native, and Joe shares advice for junior Rails developers interested in Turbo Native. Press download now to hear much more! [00:00:47] Joe introduces himself and discusses Turbo iOS and its benefits for Rails developers. He outlines the difficulties of building Native iOS and Android apps and explains how Turbo Native simplifies this.[00:03:12] Julie expresses interest in potentially using Turbo Native for her projects. Joe elaborates on the advantages of Turbo Native, such as avoiding the need to build and maintain separate screens for each platform. [00:04:50] Joe discusses the process of app release and approval on iOS and Android, highlighting the efficiency of Turbo Native in rolling out updates.[00:06:49] Julie asks how Turbo Native achieves its functionality and Joe describes the use of a web view that renders the mobile web content within the app. [00:08:19] Andrew talks about his expectations for app quality on his iPhone and Joe explains how Turbo iOS and Strata avoid poor native web implementations. [00:10:32] Andrew inquires about Strata, its necessity, and its impact now that it has been released. Joe clarifies that while Strata is not essential for building Turbo Native apps, it does facilitate easier communication between web content and native code, reducing boilerplate code. [00:12:28] Andrew comments on the marketing of Strata by 37signals and its positioning as a game-changer. Joe agrees it was a marketing issues and notes that Strata was branded as a third pillar of Hotwire, and he discusses a conversation he had with DHH about the positioning of Turbo, Stimulus, and Strata.  [00:14:49] Julie asks for an explanation of what Stimulus is. Andrew describes it as a lightweight JavaScript framework that integrates with HTML, providing a structured way to write JavaScript in Rails, and Joe adds that Stimulus allows for reusable JavaScript behaviors across multiple pages. [00:18:06] Andrew asks Joe about his library, Turbo Navigator. Joe explains that Turbo Navigator aims to bring Turbo iOS up to feature parity with Turbo Android, simplifying the use of Turbo Native on iOS by reducing boilerplate. Andrew mentions Joe's upcoming Turbo Native crash course. [00:20:58] Julie inquires about getting started with Turbo Native and Joe suggests watching his Rails World talks and checking out resources on his website and mentions a book he wrote coming out soon.  [00:24:21] Joe shares his positive experience at Rails World,  and he mentions the podcast booth at the conference and Andrew reminisces about RubyConf and looking forward to future events. [00:29:12] Andrew asks what Joe predicts happening in the new few months around iOS and what he's excited for. Joe anticipates a surge in interest for Turbo Native following the conference, and he's energized by increasing developer interest in Turbo Native and contemplates expanding his educational content as a result. [00:32:12] Andrew brings up a past RailsConf in Portland where he sought advice from Joe getting into iOS development and he credits Joe's suggestion to use Swift Playgrounds. Joe affirms that Swift Playgrounds is an excellent tool for leaning Swift, but for Turbo Native specifically, developers need to engage with Xcode and write Swift more directly related to app development.[00:35:03] Joe talks about Kotlin, noting its fast evolution and his plan to pick up more of the language due to demand for Android content. [00:35:35] Joe emphasizes that Turbo Native is a wrapper around a Rails website and suggests building a mobile website first before enhancing it with Turbo Native. [00:36:56] We end with Joe advising junior Rails developers that while Turbo Native is not necessary to know, it could provide a competitive advantage in the job market. Panelists:Andrew MasonJulie J.Guest:Joe MasilottiSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteJoe Masilotti X/TwitterJoe Masilotti WebsiteJoe Masilotti NewsletterThe reverse job board for Rails developersRails World 2023-Mobile Apps for Rails Developers with Joe Masilotti (YouTube)Turbo Native crash course-Joe MasilottiTurbo Native for iOSHotwireStradaReact NativeRemote Ruby Podcast-Episode 151: Turbo Native & Hotwire-How Polywork Supercharges DevelopmentTurbo Native DirectoryJoseph Masilotti Apps for iPhoneStimulusTurbo NavigatorSwift Playgrounds AppSwift Playgrounds KotlinXcode-SwiftUI

Kevin and Scott describe a dozen historic practices that have, to one degree or another, been forgotten in much of the Catholic world. Join them in rediscovering the holy uses of chalk, salt, and tying knots.

Looking for the Summary version of this build? Click here! Join the Guild during our Black Friday sale! Get 40% OFF a single course using the code TURKEY40 Stuff I Used: Taper Maker Hardware Kit RevMark White Marker Festool Domino Festool OF1400 Router 1/4″ Upspiral Bit Titebond Extend Dovetail Bit Milwaukee Die Grinder Cove Bit […]

Mike Perham is the creator of Sidekiq, a background job processor for Ruby. He's also the creator of Faktory a similar product for multiple language environments. We talk about the RubyConf keynote and Ruby's limitations, supporting products as a solo developer, and some ideas for funding open source like a public utility. Recorded at RubyConf 2023 in San Diego. -- A few topics covered: Sidekiq (Ruby) vs Faktory (Polyglot) Why background job solutions are so common in Ruby Global Interpreter Lock (GIL) Ractors (Actor concurrency) Downsides of Multiprocess applications When to use other languages Getting people to pay for Sidekiq Keeping a solo business Being selective about customers Ways to keep support needs low Open source as a public utility Mike Mike's blog mastodon Sidekiq faktory From Employment to Independence Ruby Ractor The Practical Effects of the GVL on Scaling in Ruby Transcript You can help correct transcripts on GitHub. Introduction [00:00:00] Jeremy: I'm here at RubyConf San Diego with Mike Perham. He's the creator of Sidekiq and Faktory. [00:00:07] Mike: Thank you, Jeremy, for having me here. It's a pleasure. Sidekiq [00:00:11] Jeremy: So for people who aren't familiar with, I guess we'll start with Sidekiq because I think that's what you're most known for. If people don't know what it is, maybe you can give like a small little explanation. [00:00:22] Mike: Ruby apps generally have two major pieces of infrastructure powering them. You've got your app server, which serves your webpages and the browser. And then you generally have something off on the side that... It processes, you know, data for a million different reasons, and that's generally called a background job framework, and that's what Sidekiq is. [00:00:41] It, Rails is usually the thing that, that handles your web stuff, and then Sidekiq is the Sidekiq to Rails, so to speak. [00:00:50] Jeremy: And so this would fit the same role as, I think in Python, there's celery. and then in the Ruby world, I guess there is, uh, Resque is another kind of job. [00:01:02] Mike: Yeah, background job frameworks are quite prolific in Ruby. the Ruby community's kind of settled on that as the, the standard pattern for application development. So yeah, we've got, a half a dozen to a dozen different, different examples throughout history, but the major ones today are, Sidekiq, Resque, DelayedJob, GoodJob, and, and, and others down the line, yeah. Why background jobs are so common in Ruby [00:01:25] Jeremy: I think working in other languages, you mentioned how in Ruby, there's this very clear, preference to use these job scheduling systems, these job queuing systems, and I'm not. I'm not sure if that's as true in, say, if somebody's working in Java, or C sharp, or whatnot. And I wonder if there's something specific about Ruby that makes people kind of gravitate towards this as the default thing they would use. [00:01:52] Mike: That's a good question. What makes Ruby... The one that so needs a background job system. I think Ruby, has historically been very single threaded. And so, every Ruby process can only do so much work. And so Ruby oftentimes does, uh, spin up a lot of different processes, and so having processes that are more focused on one thing is, is, is more standard. [00:02:24] So you'll have your application server processes, which focus on just serving HTTP responses. And then you have some other sort of focused process and that just became background job processes. but yeah, I haven't really thought of it all that much. But, uh, you know, something like Java, for instance, heavily multi threaded. [00:02:45] And so, and extremely heavyweight in terms of memory and startup time. So it's much more frequent in Java that you just start up one process and that's it. Right, you just do everything in that one process. And so you may have dozens and dozens of threads, both serving HTTP and doing work on the side too. Um, whereas in Ruby that just kind of naturally, there was a natural split there. Global Interpreter Lock [00:03:10] Jeremy: So that's actually a really good insight, because... in the keynote at RubyConf, Mats, the creator of Ruby, you know, he mentioned the, how the fact that there is this global, interpreter lock, [00:03:23] or, or global VM lock in Ruby, and so you can't, really do multiple things in parallel and make use of all the different cores. And so it makes a lot of sense why you would say like, okay, I need to spin up separate processes so that I can actually take advantage of, of my, system. [00:03:43] Mike: Right. Yeah. And the, um, the GVL. is the acronym we use in the Ruby community, or GIL. Uh, that global lock really kind of is a forcing function for much of the application architecture in Ruby. Ruby, uh, applications because it does limit how much processing a single Ruby process can do. So, uh, even though Sidekiq is heavily multi threaded, you can only have so many threads executing. [00:04:14] Because they all have to share one core because of that global lock. So unfortunately, that's, that's been, um, one of the limiter, limiting factors to Sidekiq scalability is that, that lock and boy, I would pay a lot of money to just have that lock go away, but. You know, Python is going through a very long term experiment about trying to remove that lock and I'm very curious to see how well that goes because I would love to see Ruby do the same and we'll see what happens in the future, but, it's always frustrating when I come to another RubyConf and I hear another Matt's keynote where he's asked about the GIL and he continues to say, well, the GIL is going to be around, as long as I can tell. [00:04:57] so it's a little bit frustrating, but. It's, it's just what you have to deal with. Ractors [00:05:02] Jeremy: I'm not too familiar with them, but they, they did mention during the keynote I think there Ractors or something like that. There, there, there's some way of being able to get around the GIL but there are these constraints on them. And in the context of Sidekiq and, and maybe Ruby in general, how do you feel about those options or those solutions? [00:05:22] Mike: Yeah, so, I think it was Ruby 3. 2 that introduced this concept of what they call a Ractor, which is like a thread, except it does not have the global lock. It can run independent to the global lock. The problem is, is because it doesn't use the global lock, it has pretty severe constraints on what it can do. [00:05:47] And the, and more specifically, the data it can access. So, Ruby apps and Rails apps throughout history have traditionally accessed a lot of global data, a lot of class level data, and accessed all this data in a, in a read only fashion. so there's no race conditions because no one's changing any of it, but it's still, lots of threads all accessing the same variables. [00:06:19] Well, Ractors can't do that at all. The only data Ractors can access is data that they own. And so that is completely foreign to Ruby application, traditional Ruby applications. So essentially, Ractors aren't compatible with the vast majority of existing Ruby code. So I, I, I toyed with the idea of prototyping Sidekiq and Ractors, and within about a minute or two, I just ran into these, these, uh... [00:06:51] These very severe constraints, and so that's why you don't see a lot of people using Ractors, even still, even though they've been out for a year or two now, you just don't see a lot of people using them, because they're, they're really limited, limited in what they can do. But, on the other hand, they're unlimited in how well they can scale. [00:07:12] So, we'll see, we'll see. Hopefully in the future, they'll make a lot of improvements and, uh, maybe they'll become more usable over time. Downsides of multiprocess (Memory usage) [00:07:19] Jeremy: And with the existence of a job queue or job scheduler like Sidekiq, you're able to create additional processes to get around that global lock, I suppose. What are the... downsides of doing so versus another language like we mentioned Java earlier, which is capable of having true parallelism in the same process. [00:07:47] Mike: Yeah, so you can start up multiple Ruby processes to process things truly in parallel. The issue is that you do get some duplication in terms of memory. So your Ruby app maybe take a gigabyte per process. And, you can do copy on write forking. You can fork and get some memory sharing with copy on write semantics on Unix operating systems. [00:08:21] But you may only get, let's say, 30 percent memory savings. So, there's still a significant memory overhead to forking, you know, let's say, eight processes versus having eight threads. You know, you, you, you may have, uh, eight threads can operate in a gigabyte process, but if you want to have eight processes, that may take, let's say, four gigabytes of RAM. [00:08:48] So you, you still, it's not going to cost you eight gigabytes of RAM, you know, it's not like just one times eight, but, there's still a overhead of having those separate processes. [00:08:58] Jeremy: would you say it's more of a cost restriction, like it costs you more to run these applications, or are there actual problems that you can't solve because of this restriction. [00:09:13] Mike: Help me understand, what do you mean by restriction? Do you mean just the GVL in general, or the fact that forking processes still costs memory? [00:09:22] Jeremy: I think, well, it would be both, right? So you're, you have two restrictions right now. You have the, the GVL, which means you can't have parallelism within the same process. And then your other option is to spin up a bunch of processes, which you have said is the downside there is that you're using a lot more RAM. [00:09:43] I suppose my question is that Does that actually stop you from doing anything? Like, if you throw more money at the problem, you go like, we're going to have more instances, I'll pay for the RAM, it's fine, can that basically get you out of these situations or are these limitations actually stopping you from, from doing things you could do in other languages? [00:10:04] Mike: Well, you certainly have to manage the multiple processes, right? So you've gotta, you know, if one child process crashes, you've gotta have a parent or supervisor process watching all that and monitoring and restarting the process. I don't think it restricts you. Necessarily, it just, it adds complexity to your deployment. [00:10:24] and, and it's just a question of efficiency, right? Instead of being able to deploy on a, on a one gigabyte droplet, I've got to deploy to a four gigabyte droplet, right? Because I just, I need the RAM to run the eight processes. So it, it, it's more of just a purely a function of how much money am I going to have to throw at this problem. [00:10:45] And what's it going to cost me in operational costs to operate this application in production? When to use other languages? [00:10:53] Jeremy: So during the. Keynote, uh, Matz had mentioned that Rails, is really suitable as this one person framework, like you can have a very small team or maybe even yourself and, and build this product. And so I guess from... Your perspective, once you cross a certain threshold, is like, what Ruby and what Sidekiq provides not enough, and that's why you need to start looking into other languages? [00:11:24] Or like, where's the, turning point, or the, if you [00:11:29] Mike: Right, right. The, it's all about the problem you're trying to solve, right? At the end of the day, uh, the, the question is just what are we trying to solve and how are we trying to solve it? So at a higher level, you got to think about the architecture. if the problem you're trying to solve, if the service you're trying to build, if the app you're trying to operate. [00:11:51] If that doesn't really fall into the traditional Ruby application architecture, then you, you might look at it in another language or another ecosystem. something like Go, for instance, can compile down to a single binary, which makes deployment really easy. It makes shipping up a product. on to a user's machine, much simpler than deploying a Ruby application onto a user's desktop machine, for instance, right? [00:12:22] Um, Ruby does have this, this problem of how do you package everything together and deploy it somewhere? Whereas Go, when you can just compile to a single binary, now you've just got a single thing. And it's just... Drop it on the file system and execute it. It's easy. So, um, different, different ecosystems have different application architectures, which empower different ways of solving the same problems. [00:12:48] But, you know, Rails as a, as a one man framework, or sorry, one person framework, It, it, I don't, I don't necessarily, that's a, that's sort of a catchy marketing slogan, but I just think of Rails as the most productive framework you can use. So you, as a single person, you can maximize what you ship and the, the, the value that you can create because Rails is so productive. [00:13:13] Jeremy: So it, seems like it's maybe the, the domain or the type of application you're making. Like you mentioned the command line application, because you want to be able to deliver it to your user easily. Just give them a binary, something like Go or perhaps Rust makes a lot more sense. and then I could see people saying that if you're doing something with machine learning, like the community behind Python, it's, they're just, they're all there. [00:13:41] So Room for more domains in Ruby [00:13:41] Mike: That was exactly the example I was going to use also. Yeah, if you're doing something with data or AI, Python is going to be a more, a more traditional, natural choice. that doesn't mean Ruby can't do it. That doesn't mean, you wouldn't be able to solve the problem with Ruby. And, and there's, that just also means that there's more space for someone who wants to come in and make an impact in the Ruby community. [00:14:03] Find a problem that Ruby's not really well suited to solving right now and build the tooling out there to, to try and solve it. You know, I, I saw a talk, from the fellow who makes the Glimmer gem, which is a native UI toolkit. Uh, a gem for building native UIs in Ruby, which Ruby traditionally can't do, but he's, he's done an amazing job at sort of surfacing APIs to build these, um, these native, uh, native applications, which I think is great. [00:14:32] It's awesome. It's, it's so invigorating to see Ruby in a new space like that. Um, I talked to someone else who's doing the Polars gem, which is focused on data processing. So it kind of takes, um, Python and Pandas and brings that to Ruby, which is, is awesome because if you're a Ruby developer, now you've got all these additional tools which can allow you to solve new sets of problems out there. [00:14:57] So that's, that's kind of what's exciting in the Ruby community right now is just bring it into new spaces. Faktory [00:15:03] Jeremy: In addition to Sidekiq, you have, uh, another product called Faktory, I believe. And so does that serve a, a similar purpose? Is that another job scheduling, job queueing system? [00:15:16] Mike: It is, yes. And it's, it's, it's similar in a way to Sidekiq. It looks similar. It's got similar concepts at the core of it. At the end of the day, Sidekiq is limited to Ruby. Because Sidekiq executes in a Ruby VM, it executes the jobs, and the jobs are, have to be written in Ruby because you're running in the Ruby VM. [00:15:38] Faktory was my attempt to bring, Sidekiq functionality to every other language. I wanted, I wanted Sidekiq for JavaScript. I wanted Sidekiq for Go. I wanted Sidekiq for Python because A, a lot of these other languages also could use a system, a background job system. And the problem though is that. [00:16:04] As a single man, I can't port Sidekiq to every other language. I don't know all the languages, right? So, Faktory kind of changes the architecture and, um, allows you to execute jobs in any language. it, it replaces Redis and provides a server where you just fetch jobs, and you can use it from it. [00:16:26] You can use that protocol from any language to, to build your own worker processes that execute jobs in whatever language you want. [00:16:35] Jeremy: When you say it replaces Redis, so it doesn't use Redis, um, internally, it has its own. [00:16:41] Mike: It does use Redis under the covers. Yeah, it starts Redis as a child process and, connects to it over a Unix socket. And so it's really stable. It's really fast. from the outside, the, the worker processes, they just talk to Faktory. They don't know anything about Redis at all. [00:16:59] Jeremy: I see. And for someone who, like we mentioned earlier in the Python community, for example, there is, um, Celery. For someone who is using a task scheduler like that, what's the incentive to switch or use something different? [00:17:17] Mike: Well, I, I always say if you're using something right now, I'm not going to try and convince you to switch necessarily. It's when you have pain that you want to switch and move away. Maybe you have Maybe there's capabilities in the newer system that you really need that the old system doesn't provide, but Celery is such a widely known system that I'm not necessarily going to try and convince people to move away from it, but if people are looking for a new system, one of the things that Celery does that Faktory does not do is Celery provides like data adapters for using store, lots of different storage systems, right? [00:17:55] Faktory doesn't do that. Faktory is more, has more of the Rails mantra of, you know, Omakase where we choose, I choose to use Redis and that's it. You don't, you don't have a choice for what to use because who cares, you know, at the end of the day, let Faktory deal with it. it's, it's not something that, You should even necessarily be concerned about it. [00:18:17] Just, just try Faktory out and see how it works for you. Um, so I, I try to take those operational concerns off the table and just have the user focus on, you know, usability, performance, and that sort of thing. but it is, it's, it's another background job system out there for people to try out and see if they like that. [00:18:36] And, and if they want to, um, if they know Celery and they want to use Celery, more power to Faktory them. Sidekiq (Ruby) or Faktory (Polyglot) [00:18:43] Jeremy: And Sidekiq and Faktory, they serve a very similar purpose. For someone who they have a new project, they haven't chosen a job. scheduling system, if they were using Ruby, would it ever make sense for them to use Faktory versus use Sidekiq? [00:19:05] Mike: Uh Faktory is excellent in a polyglot situation. So if you're using multiple languages, if you're creating jobs in Ruby, but you're executing them in Python, for instance, um, you know, if you've, I have people who are, Creating jobs in PHP and executing them in Python, for instance. That kind of polyglot scenario, Sidekiq can't do that at all. [00:19:31] So, Faktory is useful there. In terms of Ruby, Ruby is just another language to Faktory. So, there is a Ruby API for using Faktory, and you can create and execute Ruby jobs with Faktory. But, you'll find that in the Ruby community, Sidekiq is much widely... much more widely used and understood and known. So if you're just using Ruby, I think, I think Sidekiq is the right choice. [00:19:59] I wouldn't look at Faktory. But if you do need, find yourself needing that polyglot tool, then Faktory is there. Temporal [00:20:07] Jeremy: And this is maybe one, maybe one layer of abstraction higher, but there's a product called Temporal that has some of this job scheduling, but also this workflow component. I wonder if you've tried that out and how you think about that product? [00:20:25] Mike: I've heard of them. I don't know a lot about the product. I do have a workflow API, the Sidekiq batches, which allow you to fan out jobs and then, and then execute callbacks when all the jobs in that, in that batch are done. But I don't, provide sort of a, a high level. Graphical Workflow Editor or anything like that. [00:20:50] Those to me are more marketing tools that you use to sell the tool for six figures. And I don't think they're usable. And I don't think they're actually used day to day. I provide an API for developers to use. And developers don't like moving blocks of code around in a GUI. They want to write code. And, um, so yeah, temporal, I, like I said, I don't know much about them. [00:21:19] I also, are they a venture capital backed startup? [00:21:22] Jeremy: They are, is my understanding, [00:21:24] Mike: Yeah, that, uh, any, any sort of venture capital backed startup, um, who's building technical infrastructure. I, I would look long and hard at, I'm, I think open source is the right core to build on. Of course I sell commercial software, but. I'm bootstrapped. I'm profitable. [00:21:46] I'm going to be around forever. A VC backed startup, they tend to go bankrupt, because they either get big or they go out of business. So that would be my only comment is, is, be a little bit leery about relying on commercial venture capital based infrastructure for, for companies, uh, long term. Getting people to pay for Sidekiq [00:22:05] Jeremy: So I think that's a really interesting part about your business is that I think a lot of open source maintainers have a really big challenge figuring out how to make it as a living. The, there are so many projects that they all have a very permissive license and you can use them freely one example I can think of is, I, I talked with, uh, David Kramer, who's the CTO at Sentry, and he, I don't think they use it anymore, but they, they were using Nginx, right? [00:22:39] And he's like, well, Nginx, they have a paid product, like Nginx. Plus that or something. I don't know what the name is, but he was like, but I'm not going to pay for it. Right. I'm just going to use the free one. Why would I, you know, pay for the, um, the paid thing? So I, I, I'm kind of curious from your perspective when you were coming up with Sidekiq both as an open source product, but also as a commercial one, how did you make that determination of like to make a product where it's going to be useful in its open source form? [00:23:15] I can still convince people to pay money for it. [00:23:19] Mike: Yeah, the, I was terrified, to be blunt, when I first started out. when I started the Sidekiq project, I knew it was going to take a lot of time. I knew if it was successful, I was going to be doing it for the next decade. Right? So I started in 2012, and here I am in 2023, over a decade, and I'm still doing it. [00:23:38] So my expectation was met in that regard. And I knew I was not going to be able to last that long. If I was making zero dollars, right? You just, you burn out. Nobody can last that long. Well, I guess there are a few exceptions to that rule, but yeah, money, I tend to think makes things a little more sustainable for sure. [00:23:58] Especially if you can turn it into a full time job solving and supporting a project that you, you love and, and is, is, you know, your, your, your baby, your child, so to speak, your software, uh, uh, creation that you've given to the world. but I was terrified. but one thing I did was at the time I was blogging a lot. [00:24:22] And so I was telling people about Sidekiq. I was telling people what was to come. I was talking about ideas and. The one thing that I blogged about was financial experiments. I said bluntly to the, to, to the Ruby community, I'm going to be experimenting with financial stability and sustainability with this project. [00:24:42] So not only did I create this open source project, but I was also publicly saying I I need to figure out how to make this work for the next decade. And so eventually that led to Sidekiq Pro. And I had to figure out how to build a closed source Ruby gem, which, uh, There's not a lot of, so I was kind of in the wild there. [00:25:11] But, you know, thankfully all the pieces came together and it was actually possible. I couldn't have done it if it wasn't possible. Like, we would not be talking if I couldn't make a private gem. So, um, but it happened to work out. Uh, and it allowed me to, to gate features behind a paywall effectively. And, and yeah, you're right. [00:25:33] It can be tough to make people pay for software. but I'm a developer who's selling to other developers, not, not just developers, open source developers, and they know that they have this financial problem, right? They know that there's this sustainability problem. And I was blunt in saying, this is my solution to my sustainability. [00:25:56] So, I charge what I think is a very fair price. It's only a thousand dollars a year to a hobbyist. That may seem like a lot of money to a business. It's a drop in the bucket. So it was easy for developers to say, Hey, listen, we want to buy this tool for a thousand bucks. It'll ensure our infrastructure is maintained for the next decade. [00:26:18] And it's, and it's. And it's relatively cheap. It's way less than, uh, you know, a salary or even a laptop. So, so that's, that's what I did. And, um, it's, it worked out great. People, people really understood. Even today, I talk to people and they say, we, we signed up for Sidekiq Pro to support you. So it's, it's, it's really, um, invigorating to hear people, uh, thank me and, and they're, they're actively happy that they're paying me and our customers. [00:26:49] Jeremy: it's sort of, uh, maybe a not super common story, right, in terms of what you went through. Because when I think of open core businesses, I think of companies like, uh, GitLab, which are venture funded, uh, very different scenario there. I wonder, like, in your case, so you started in 2012, and there were probably no venture backed competitors, right? [00:27:19] People saying that we're going to make this job scheduling system and some VC is going to give me five million dollars and build a team to work on this. It was probably at the time, maybe it was Rescue, which was... [00:27:35] Mike: There was a venture backed system called IronMQ, [00:27:40] Jeremy: Hmm. [00:27:41] Mike: And I'm not sure if they're still around or not, but they... They took, uh, one or more funding rounds. I'm not sure exactly, but they were VC backed. They were doing, background jobs, scheduled jobs, uh, you know, running container, running container jobs. They, they eventually, I think, wound up sort of settling on Docker containers. [00:28:06] They'll basically spin up a Docker container. And that container can do whatever it wants. It can execute for a second and then shut down, or it can run for, for however long, but they would, um, yeah, I, yeah, I'll, I'll stop there because I don't know the actual details of exactly their system, but I'm not sure if they're still around, but that's the only one that I remember offhand that was around, you know, years ago. [00:28:32] Yeah, it's, it's mostly, you know, low level open source infrastructure. And so, anytime you have funded startups, they're generally using that open source infrastructure to build their own SaaS. And so SaaS's are the vast majority of where you see sort of, uh, commercial software. [00:28:51] Jeremy: so I guess in that way it, it, it gave you this, this window or this area where you could come in and there wasn't, other than that iron, product, there wasn't this big money that you were fighting against. It was sort of, it was you telling people openly, I'm, I'm working on this thing. [00:29:11] I need to make money so that I can sustain it. And, if you, yeah. like the work I do, then, you know, basically support me. Right. And, and so I think that, I'm wondering how we can reproduce that more often because when you see new products, a lot of times it is VC backed, right? [00:29:35] Because people say, I need to work on this. I need to be paid. and I can't ask a team to do this. For nothing, right? So [00:29:44] Mike: Yeah. It's. It's a wicked problem. Uh, it's a really, really hard problem to solve if you take vc you there, that that really kind of means that you need to be making tens if not hundreds of millions of dollars in sales. If you are building a small or relatively small. You know, put small in quotes there because I don't really know what that means, but if you have a small open source project, you can't charge huge amounts for it, right? [00:30:18] I mean, Sidekiq is a, I would call a medium sized open source project, and I'm charging a thousand bucks for it. So if you're building, you know, I don't know, I don't even want to necessarily give example, but if you're building some open source project, and It's one of 300 libraries that people's applications will depend on. [00:30:40] You can't necessarily charge a thousand dollars for that library. depending on the size and the capabilities, maybe you can, maybe you can't. But there's going to be a long tail of open source projects that just, they can't, they can't charge much, if anything, for them. So, unfortunately, we have, you know, these You kind of have two pathways. [00:31:07] Venture capital, where you've got to sell a ton, or free. And I've kind of walked that fine line where I'm a small business, I can charge a small amount because I'm bootstrapped. And, and I don't need huge amounts of money, and I, and I have a project that is of the right size to where I can charge a decent amount of money. [00:31:32] That means that I can survive with 500 or a thousand customers. I don't need to have a hundred million dollars worth of customers. Because I, you know, when I started the business, one of the constraints I said is I don't want to hire anybody. I'm just going to be solo. And part of the, part of my ability to keep a low price and, and keep running sustainably, even with just You know, only a few hundred customers is because I'm solo. [00:32:03] I don't have the overhead of investors. I don't have the overhead of other employees. I don't have an office space. You know, my overhead is very small. So that is, um, you know, I just kind of have a unique business in that way, I guess you might say. Keeping the business solo [00:32:21] Jeremy: I think that's that's interesting about your business as well But the fact that you've kept it you've kept it solo which I would imagine in most businesses, they need support people. they need, developers outside of maybe just one. Um, there's all sorts of other, I don't think overhead is the right word, but you just need more people, right? [00:32:45] And, and what do you think it is about Sidekiq that's made it possible for it to just be a one person operation? [00:32:52] Mike: There's so much administrative overhead in a business. I explicitly create business policies so that I can run solo. you know, my support policy is officially you get one email ticket or issue per quarter. And, and anything more than that, I can bounce back and say, well, you're, you're requiring too much support. [00:33:23] In reality, I don't enforce that at all. And people email me all the time, but, but things like. Things like dealing with accounting and bookkeeping and taxes and legal stuff, licensing, all that is, yeah, a little bit of overhead, but I've kept it as minimal as I can. And part of that is I don't want to hire another employee because then that increases the administrative overhead that I have. [00:33:53] And Sidekiq is so tied to me and my knowledge that if I hire somebody, they're probably not going to know Ruby and threading and all the intricate technical detail necessary to build and maintain and support the system. And so really you'll kind of regress a little bit. We won't be able to give as good support because I'm busy helping that other employee. Being selective about customers [00:34:23] Mike: So, yeah, it's, it's a tightrope act where you've got to really figure out how can I scale myself as far as possible without overwhelming myself. The, the overwhelming thing that I have that I've never been able to solve. It's just dealing with billing inquiries, customers, companies, emailing me saying, how do we buy this thing? [00:34:46] Can I get an invoice? Every company out there, it seems wants an invoice. And the problem with invoicing is it takes a lot more. manual labor and administrative overhead to issue that invoice to collect payment on the invoice. So that's one of the reasons why I have a very strict policy about credit card only for, for the vast majority of my customers. [00:35:11] And I demand that companies pay a lot more. You have to have a pretty big enterprise license if you want an invoice. And if the company, if the company comes back and complains and says, well, you know, that's ridiculous. We don't, we don't want to pay that much. We don't need it that much. Uh, you know, I, I say, okay, well then you have two, two things, two, uh, two things. [00:35:36] You can either pay with a credit card or you can not use Sidekiq. Like, that's, that's it. I'm, I don't need your money. I don't want the administrative overhead of dealing with your accounting department. I just want to support my, my customers and build my software. And, and so, yeah, I don't want to turn into a billing clerk. [00:35:55] So sometimes, sometimes the, the, the best thing in business that you can do is just say no. [00:36:01] Jeremy: That's very interesting because I think being a solo... Person is what probably makes that possible, right? Because if you had the additional staff, then you might say like, Well, I need to pay my staff, so we should be getting, you know, as much business as [00:36:19] Mike: Yeah. Chasing every customer you can, right. But yeah. [00:36:22] Every customer is different. I mean, I have some customers that just, they never contact me. They pay their bill really fast or right on time. And they're paying me, you know, five figures, 20, a year. And they just, it's a, God bless them because those are, are the. [00:36:40] Best customers to have and the worst customers are the ones who are paying 99 bucks a month and everything that they don't understand or whatever is a complaint. So sometimes, sometimes you, you want to, vet your customers from that perspective and say, which one of these customers are going to be good? [00:36:58] Which ones are going to be problematic? [00:37:01] Jeremy: And you're only only person... And I'm not sure how many customers you have, but [00:37:08] Mike: I have 2000 [00:37:09] Jeremy: 2000 customers. [00:37:10] Okay. [00:37:11] Mike: Yeah. [00:37:11] Jeremy: And has that been relatively stable or has there been growth [00:37:16] Mike: It's been relatively stable the last couple of years. Ruby has, has sort of plateaued. Um, it's, you don't see a lot of growth. I'm getting probably, um, 15, 20 percent growth maybe. Uh, so I'm not growing like a weed, like, you know, venture capital would want to see, but steady incremental growth is, is, uh, wonderful, especially since I do very little. [00:37:42] Sales and marketing. you know, I come to RubyConf I, I I tweet out, you know, or I, I toot out funny Mastodon Toots occasionally and, and, um, and, and put out new releases of the software. And, and that's, that's essentially my, my marketing. My marketing is just staying in front of developers and, and, and being a presence in the Ruby community. [00:38:06] But yeah, it, it's, uh. I, I, I see not a, not a huge amount of churn, but I see enough sales to, to, to stay up and keep my head above water and to keep growing, um, slowly but surely. Support needs haven't grown [00:38:20] Jeremy: And as you've had that steady growth, has the support burden not grown with it? [00:38:27] Mike: Not as much because once customers are on Sidekiq and they've got it working, then by and large, you don't hear from them all that much. There's always GitHub issues, you know, customers open GitHub issues. I love that. but yeah, by and large, the community finds bugs. and opens up issues. And so things remain relatively stable. [00:38:51] I don't get a lot of the complete newbie who has no idea what they're doing and wants me to, to tell them how to use Sidekiq that I just don't see much of that at all. Um, I have seen it before, but in that case, generally, I, I, I politely tell that person that, listen, I'm not here to educate you on the product. [00:39:14] It's there's documentation in the wiki. Uh, and there's tons of, of more Ruby, generic Ruby, uh, educational material out there. That's just not, not what I do. So, so yeah, by and large, the support burden is, is not too bad because once people are, are up and running, it's stable and, and they don't, they don't need to contact me. [00:39:36] Jeremy: I wonder too, if that's perhaps a function of the price, because if you're a. new developer or someone who's not too familiar with how to do job processing or what they want to do when you, there is the open source product, of course. but then the next step up, I believe is about a hundred dollars a month. [00:39:58] And if you're somebody who is kind of just getting started and learning how things work, you're probably not going to pay that, is my guess. And so you'll never hear from them. [00:40:11] Mike: Right, yeah, that's a good point too, is the open source version, which is what people inevitably are going to use and integrate into their app at first. Because it's open source, you're not going to email me directly, um, and when people do email me directly, Sidekiq support questions, I do, I reply literally, I'm sorry I don't respond to private email, unless you're a customer. [00:40:35] Please open a GitHub issue and, um, that I try to educate both my open source users and my commercial customers to try and stay in GitHub issues because private email is a silo, right? Private email doesn't help anybody else but them. If I can get people to go into GitHub issues, then that's a public record. [00:40:58] that people can search. Because if one person has that problem, there's probably a dozen other people that have that same problem. And then that other, those other 11 people can search and find the solution to their problem at four in the morning when I'm asleep. Right? So that's, that's what I'm trying to do is, is keep, uh, keep everything out in the open so that people can self service as much as possible. Sidekiq open source [00:41:24] Jeremy: And on the open source side, are you still primarily the main contributor? Or do you have other people that are [00:41:35] Mike: I mean, I'd say I do 90 percent of the work, which is why I don't feel guilty about keeping 100 percent of the money. A lot of open source projects, when they look for financial sustainability, they also look for how can we split this money amongst the team. And that's, that's a completely different topic that I've. [00:41:55] is another reason why I've stayed solo is if I hire an employee and I pay them 200, 000 a year as a developer, I'm meanwhile keeping all the rest of the profits of the company. And so that almost seems a little bit unfair. because we're both still working 40 hours a week, right? Why am I the one making the vast majority of the, of the profit and the money? [00:42:19] Um, so, uh, I've always, uh, that's another reason why I've stayed solo, but, but yeah, having a team of people working on something, I do get, regular commits, regular pull requests from people, fixing a bug that they found or just making a tweak that. that they saw, that they thought they could improve. [00:42:42] A little more rarely I get a significant improvement or feature, as a pull request. but Sidekiq is so stable these days that it really doesn't need a team of people maintaining it. The volume of changes necessary, I can easily keep up with that. So, I'm still doing 90 95 percent of the work. Are there other Sidekiq-like opportunities out there? [00:43:07] Jeremy: Yeah, so I think Sidekiq has sort of a unique positioning where it's the code base itself is small enough where you can maintain it yourself and you have some help, but primarily you're the main maintainer. And then you have enough customers who are willing to, to pay for the benefit it gives them on top of what the open source product provides. [00:43:36] cause it's, it's, you were talking about how. Every project people work on, they have, they could have hundreds of dependencies, right? And to ask somebody to, to pay for each of them is, is probably not ever going to happen. And so it's interesting to think about how you have things like, say, you know, OpenSSL, you know, it's a library that a whole bunch of people rely on, but nobody is going to pay a monthly fee to use it. [00:44:06] You have things like, uh, recently there was HashiCorp with Terraform, right? They, they decided to change their license because they, they wanted to get, you know, some of that value back, some of the money back, and the community basically revolted. Right? And did a fork. And so I'm kind of curious, like, yeah, where people can find these sweet spots like, like Sidekiq, where they can find this space where it's just small enough where you can work on it on your own and still get people to pay for it. [00:44:43] It's, I'm trying to picture, like, where are the spaces? Open source as a public utility [00:44:48] Mike: We need to look at other forms of financing beyond pure capitalism. If this is truly public infrastructure that needs to be maintained for the long term, then why are we, why is it that we depend on capitalism to do that? Our roads, our water, our sewer, those are not Capitalist, right? Those are utilities, that's public infrastructure that we maintain, that the government helps us maintain. [00:45:27] And in a sense, tech infrastructure is similar or could be thought of in a similar fashion. So things like Open Collective, things like, uh, there's a, there's a organization in Europe called NLNet, I think, out of the Netherlands. And they do a lot of grants to various open source projects to help them improve the state of digital infrastructure. [00:45:57] They support, for instance, Mastodon as a open source project that doesn't have any sort of corporate backing. They see that as necessary social media infrastructure, uh, for the long term. And, and I, and I think that's wonderful. I like to see those new directions being explored where you don't have to turn everything into a product, right? [00:46:27] And, and try and market and sale, um, and, and run ads and, and do all this stuff. If you can just make the case that, hey, this is, this is useful public infrastructure that so many different, um, Technical, uh, you know, applications and businesses could rely on, much like FedEx and DHL use our roads to the benefit of their own, their own corporate profits. [00:46:53] Um, why, why, why shouldn't we think of tech infrastructure sort of in a similar way? So, yeah, I would like to see us explore more. in that direction. I understand that in America that may not happen for quite a while because we are very, capitalist focused, but it's encouraging to see, um, places like Europe, uh, a little more open to, to trialing things like, cooperatives and, and grants and large long term grants to, to projects to see if they can, uh, provide sustainability in, in, you know, in a new way. [00:47:29] Jeremy: Yeah, that's a good point because I think right now, a lot of the open source infrastructure that we all rely on, either it's being paid for by large companies and at the whim of those large companies, if Google decides we don't want to pay for you to work on this project anymore, where does the money come from? [00:47:53] Right? And on the other hand, there's the thousands, tens of thousands of people who are doing it. just for free out of the, you know, the goodness of their, their heart. And that's where a lot of the burnout comes from. Right. So I think what you're saying is that perhaps a lot of these pieces that we all rely on, that our, our governments, you know, here in the United States, but also around the world should perhaps recognize as this is, like you said, this is infrastructure, and we should be. [00:48:29] Paying these people to keep the equivalent of the roads and, and, uh, all that working. [00:48:37] Mike: Yeah, I mean, I'm not, I'm not claiming that it's a perfect analogy. There's, there's, there's lots of questions that are unanswered in that, right? How do you, how do you ensure that a project is well maintained? What does that even look like? What does that mean? you know, you can look at a road and say, is it full of potholes or is it smooth as glass, right? [00:48:59] It's just perfectly obvious, but to a, to a digital project, it's, it's not as clear. So, yeah, but, but, but exploring those new ways because turning everybody into a businessman so that they can, they can keep their project going, it, it, it itself is not sustainable, right? so yeah, and that's why everything turns into a SaaS because a SaaS is easy to control. [00:49:24] It's easy to gatekeep behind a paywall and it's easy to charge for, whereas a library on GitHub. Yeah. You know, what do you do there? You know, obviously GitHub has sponsors, the sponsors feature. You've got Patreon, you've got Open Collective, you've got Tidelift. There's, there's other, you know, experiments that have been run, but nothing has risen to the top yet. [00:49:47] and it's still, it's still a bit of a grind. but yeah, we'll see, we'll see what happens, but hopefully people will keep experimenting and, and maybe, maybe governments will start. Thinking in the direction of, you know, what does it mean to have a budget for digital infrastructure maintenance? [00:50:04] Jeremy: Yeah, it's interesting because we, we started thinking about like, okay, where can we find spaces for other Sidekiqs? But it sounds like maybe, maybe that's just not realistic, right? Like maybe we need more of a... Yeah, a rethinking of, I guess the, the structure of how people get funded. Yeah. [00:50:23] Mike: Yeah, sometimes the best way to solve a problem is to think at a higher level. You know, we, the, the sustainability problem in American Silicon Valley based open source developers is naturally going to tend toward venture capital and, and capitalism. And I, you know, I think, I think that's, uh, extremely problematic on a, on a lot of different, in a lot of different ways. [00:50:47] And, and so sometimes you need to step back and say, well, maybe we're, maybe we just don't have the right tool set to solve this problem. But, you know, I, I. More than that, I'm not going to speculate on because it is a wicked problem to solve. [00:51:04] Jeremy: Is there anything else you wanted to, to mention or thought we should have talked about? [00:51:08] Mike: No, I, I, I loved the talk, of sustainability and, and open source. And I, it's, it's a, it's a topic really dear to my heart, obviously. So I, I am happy to talk about it at length with anybody, anytime. So thank you for having me. [00:51:25] Jeremy: All right. Thank you very much, Mike.

Stephanie interviews Edward Loveall, a former thoughtbotter, now software developer at Relevant Healthcare. Part of their discussion centers around Edward's blog post on the tech industry's over-reliance on GitHub. He argues for the importance of exploring alternatives to avoid dependency on a single platform and encourages readers to make informed technological choices. The conversation broadens to include how to form opinions on technology, the balance between personal preferences and team decisions, and the importance of empathy and nuance in professional interactions. Both Stephanie and Edward highlight the value of considering various perspectives and tools in software development, advocating for a flexible, open-minded approach to technology and problem-solving in the tech industry. Relevant (https://relevant.healthcare/) Let's make sure Github doesn't become the only option (https://blog.edwardloveall.com/lets-make-sure-github-doesnt-become-the-only-option) And not but (https://blog.edwardloveall.com/and-not-but) Empathy Online (https://thoughtbot.com/blog/empathy-online) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. And today, I'm joined by a very special guest, a friend of the pod and former thoughtboter, Edward Loveall. EDWARD: Hello, thanks for having me. STEPHANIE: Edward, would you share a little bit about yourself and what you're doing these days? EDWARD: Yes, I am a software developer at a company called Relevant Healthcare. We do a lot of things, but the maybe high-level summary is we take very complicated medical data and help federally-funded health centers actually understand that data and help their population's health, which is really fun and really great. STEPHANIE: Awesome. So, Edward, what is new in your world? EDWARD: Let's see, this weekend...I live in a dense city. I live in Cambridge, Massachusetts, and it's pretty dense there. And a lot of houses are very tightly packed. And delivery drivers struggle to find the numbers on the houses sometimes because A, they're old and B, there is many of them. And so, we put up house numbers because I live in, like, a three-story kind of building, but there are two different addresses in the same three stories, which is very weird. And so [laughs], delivery drivers are like, "Where is number 10 or 15?" or whatever. And so, there's two different numbers. And so, we finally put up numbers after living here for, like, four years [chuckles]. So, now, hopefully, delivery drivers in the holiday busy season will be able to find our house [laughs]. STEPHANIE: That's great. Yeah, I have kind of a similar problem where, a lot of the times, delivery folks will think that my house is the big building next door. And the worst is those at the building next door they drop off their packages inside the little, like, entryway that is locked for people who don't live there. And so, I will see my package in the window and, you know, it has my name on it. It has, like, my address on it. And [laughs] some strategies that I've used is leaving a note on the door [laughter] that is, like, "Please redeliver my package over there," and, like, I'll draw an arrow to the direction of my house. Or sometimes I've been that person to just, like, buzz random [laughter] units and just hope that they, like, let me in, and then I'll grab my package. And, you know, if I know the neighbors, I'll, like, try to apologize the next time I see them. But sometimes I'll just be like, I just need to get my package [laughs]. EDWARD: You're writing documentation for those people working out in the streets. STEPHANIE: Yeah. But I'm glad you got that sorted. EDWARD: Yeah. What about you? What's new in your world? STEPHANIE: Well, I wanted to talk a little bit about a thing that you and I have been doing lately that I have been enjoying a lot. First of all, are you familiar with the group chat trend these days? Do you know what I'm talking about? EDWARD: No. STEPHANIE: Okay. It's basically this idea that, like, everyone is just connecting with their friends via a group chat now as opposed to social media. But as a person who is not a big group chat person, I can't, like, keep up with [chuckles], like, chatting with multiple people [laughter] at once. I much prefer, like, one-on-one interaction. And, like, a month ago, I asked you if you would be willing to try having a shared note, like, a shared iOS note that we have for items that we want to discuss with each other but, you know, the next time we either talk on the phone or, I don't know, things that are, like, less urgent than a text message would communicate but, like, stuff that we don't want to forget. EDWARD: Yeah. You're, like, putting a little message in my inbox and vice versa. And yeah, we get to just kind of, whenever we want, respond to it, or think about it, or use it as a topic for a conversation later. STEPHANIE: Yeah. And I think it is kind of a playbook from, like, a one-on-one with a manager. I know that that's, like, a strategy that some folks use. But I think it works well in the context of our friendship because it's just gotten, like, richer over time. You know, maybe in the beginning, we're like, oh, like, I don't know, here are some random things that I've thought about. But now we're having, like, whole discussions in the note [laughter]. Like, we will respond to each other, like, with sub-bullets [laughs]. And then we end up not even needing to talk about it on the phone because we've already had a whole conversation about it in the note. EDWARD: Which is good because neither of us are particularly brief when talking on the phone. And [laughs] we only dedicate, like, half an hour every two weeks. It sort of helps clear the decks a little. STEPHANIE: Yeah, yeah. So, that's what I recommend. Try a shared note for [laughs] your next friendship hangout. EDWARD: Yeah, it's great. I heartily recommend it. STEPHANIE: So, one of the things that we end up talking about a lot is various things that we've been reading about tech on the web [laughs]. And we share with each other a lot of, like, blog posts, or articles, various links, and recently, something of yours kind of resurfaced. You wrote a blog post about GitHub a little while ago about how, you know, as an industry, we should make sure that GitHub doesn't become our only option. EDWARD: Yeah, this was a post I wrote, I think, back in May, or at least earlier this year, and it got a bunch of traction. And it's a somewhat, I would say, controversial article or take. GitHub just had their developer conference, and it resurfaced again. And I don't have a habit of writing particularly controversial articles, I don't think. Most of my writing history has been technical posts like tutorials. Like, I wrote a whole tutorial on how to write SQL, or I did write one about how to communicate online. But I wasn't, like, so much responding to, like, a particular person's communication or a company's communication. And this is the first big post I've written that has been a lot more very heavily opinionated, very, like, targeted at a particular thing or entity, I guess you'd say. It's been received well, I think, mostly, and I'm proud of it. But it's a different little world for me, and it's a little scary, honestly. STEPHANIE: Yeah, I hear that, having an opinion [laughs], a very strong and maybe, like, a less popular opinion, and publishing that for the world. Could you recap what the thesis of it is for our listeners? EDWARD: Yeah, and I think you did a great job of it, too. I see GitHub or really any singular piece of technology that we have in...I'll say our stack with air quotes, but it's, you know, all the tools that we use and all the things that we use. It's a risk if you only have one of those things, let's say GitHub. Like, if the only way you know how to contribute to a code repository with, you know, 17 people all committing to that repository, if the only way you know how to do that is a pull request and GitHub goes away, and you don't have pull requests anymore, how are you going to contribute to code? It's not that you couldn't figure it out, or there aren't multiple ways or even other pull request equivalents on other sites. But it is a risk to rely on one company to provide all of the things that you potentially need, or even many of the things that you potentially need, without any alternatives. So, I wanted to try to lay out A: those risks, and B: encourage people to try alternatives, to say that GitHub is not necessarily bad, although they may not actually fit what you need for various reasons, or someone else for various reasons. But you should have an alternative in your back pocket so that in case something changes, or you get locked out, or they go away, or they decide to cancel that feature, or any number of other scenarios, you have greatly diminished that risk. So, that's the main thrust of the post. STEPHANIE: Yeah, I really appreciated it because, you know, I think a lot of us probably take GitHub for granted [laughs]. And, you know, every new thing that they kind of add to the platform is like, oh, like, cool, like, I can now do this. In the post, you kind of lay out all of the different features that GitHub has rolled out over the last, you know, couple of years. And when you see it all like that, you know, like, in addition to being, like, a code repository, you now have, like, GitHub Actions for CI/CD, you know, you can deploy static pages with it. It now has, like, an in-browser editor, and then, you know, Copilot, which, like, the more things that they [laughs] roll out, the more it's becoming, like, the one-stop shop, right? That, like, do all of your work here. And I appreciated kind of, like, seeing that and being like, oh, like, is this what I want? EDWARD: Right. Yeah, exactly. Yeah. And you mentioned a bunch. There's also issues and discussions. You mentioned their in-browser editor. But so many people use VS Code, which, while it was technically made by Microsoft, it's based on Electron, which was developed at GitHub. And GitHub even, like, took away their other Electron-based editor, Atom. And then now officially recommends VS Code. And everything from deploying all the way down to, like, thinking about and prioritizing features and editing the code and all of that pretty much could happen on GitHub. I think maybe the only thing they don't currently do is host non-static sites, maybe [laughs]. That's maybe about it. And who knows? Maybe they're working on that; as far as I know, they are, so... STEPHANIE: Yeah, absolutely. You also mentioned one thing that I really liked about the content in the post was that you talked about alternatives to GitHub, even, like, alternatives to all of the different features that we mentioned. I guess I'm wondering, like, what were you hoping that a reader from your blog post, like, what they would get out of reading and, like, what they would take away from kind of sharing your opinion? EDWARD: I wanted to try to meet people where I think they might be because I think a lot of people do use GitHub, and they do take it for granted. And they do sort of see it as this thing that they must use, or they want to use even, and that's fine. That's not necessarily a bad thing. I want them to see those alternatives and have at least some idea that there is something else out there, that GitHub doesn't become just not only the default, but, like, the only thing. I mean, to just [chuckles] re-paraphrase the title of the post, I want to make sure GitHub does not become the only option, right? I want people to realize that there are other options out there and be encouraged to try them. And I have found, for me, at least, the better way to do that is not to only focus on, like, hey, don't use GitHub. Like, I hope people did not come away with only that message or even that message at all. But that it is more, hey, maybe try something else out and to encourage you to try something out. I'm going to A: share the risks with you and B: give you some actual things to try. So, I talk about the things I'm using and some other platforms and different paradigms to think about and use. So, I hope they take those. We'll see what happens in the next, you know, months or years. And I'll probably never know if it was actually just from me or from many other conversations, and thoughts, and articles, and all that kind of stuff. But that's what it takes, so... STEPHANIE: Yeah. I think the other fun thing about kind of the, like, meta-conversation we're having about having an opinion and, like, sharing it with the world is that you don't even really say like, "This is better than GitHub," or, like, kind of make a statement about, like, you shouldn't use...you don't even say, "You shouldn't use GitHub," right? The message is, like, here are some options: try it out, and, like, decide for yourself. EDWARD: Yeah, exactly. I want to empower people to do that. I don't think it would have been useful if I'd just go and say, "Hey, don't do this." It's very frustrating to me to see posts that are only negatives. And, honestly, I've probably written those posts, like, I'm not above them necessarily. But I have found that trying to help people do what you want them to do, as silly and maybe obvious as that sounds, is a more effective way to get them to do what you want them to do [laughs], as opposed to say, "Hey, stop doing the thing I don't want you to do," or attack their identity, or their job, or some other aspect of their life. Human behavior does not respond well to that generally, at least in my experience. Like, having your identity tied up in a tool or a platform is, unfortunately, pretty common in, like, a tech space. Like, oh, like, Ruby on Rails is the best piece of software or something like that. And it's like, well, you might like it, and that might be the best thing for you. And personally, I really like Ruby on Rails. I think it does a great job of what it does. But as an example, I would not use Ruby on Rails to maybe build an iOS app. I could; I think that's possible, but I don't think that's maybe the best tool for that job. And so, trying to, again, meet people where they are. STEPHANIE: I guess it kind of goes back to what you're saying. It's like, you want to help people do what they are trying to do. EDWARD: Yeah. Maybe there's a little paternalistic thinking, too, of, like, what's good for the industry, even if it feels bad for you right now. I don't love that sort of paternalistic thinking. But if it's a real risk, it seems worth at least addressing or pointing out and letting people make that decision for themselves. STEPHANIE: Yeah, absolutely. I am actually kind of curious about how do you, like, decide something for yourself? You know, like, how do you form your own opinion about technology? I think, yeah, like, a lot of people take GitHub for granted. They use it because that's just what's used, and that may or may not be a good reason for doing so. But that was a position I was in for a long time, right? You know, especially when you're newer to the industry, you're like, oh, well, this is what the company uses, or this is what, like, the industry uses. But, like, how do you start to figure out for yourself, like, do I actually like this? Does this help me meet my goals and needs? Is it doing what I want it to be doing? Do you have any thoughts about that? EDWARD: Yeah. I imagine most people listening to this have tried lots of different pieces of software and found them great, or terrible, or somewhere in between. And I don't think there's necessarily one way to do this. But I think my way has been to try lots of things, unsurprisingly, and evaluate them based on the thing that I'm trying to do. Sometimes I'll go into a new field, or a new area, or a new product, or whatever, and you just sort of use what's there, or what people have told you about, or what you heard about last, and that's fine. That's a great place to start, right? And then you start seeing maybe where it falls down, or where it is frustrating or doesn't quite meet those needs. And it takes a bit of stepping back. Again, I don't think I'm, like, going to blow anyone's mind here by this amazing secretive technique that I have for, like, discovering good software. But it's, like, sitting there and going through this iterative loop of try it, evaluate it. Be honest with, is it meeting or not meeting some particular needs? And then try something else. Or now you have a little more info to arm yourself to get to the next piece that is potentially good. As you go on in your career and you've tried many, many, many pieces of things, you start to see patterns, right? And you know, like, oh, it's not like, oh, this is how I make websites. It's like, ah, I understand that websites are made with a combination of HTML, and CSS, and JavaScript and sometimes use frameworks. And there's a database layer with an ORM. And you start to understand all the different parts. And now that you have those keywords and those pieces a little more under your control or you have more experience with them, you can use all that experience to then seek out particular pieces. I'm looking for an ORM that's built with Rust because that's the thing I need to do it for; that's the platform I need to work with. And I needed to make sure that it supports MySQL and Postgres, right? Like, it's a very targeted thing that you wouldn't know when you're starting out. But over years of experience, you understand the difference and the reasons why you might need something like that. And sometimes it's about kind of evaluating options and maybe making little test projects to play around with those things or side projects. That's why something like investment time or 20% time is so helpful and useful for that if you're the kind of person who, you know, enjoys programming on your own in your own free time like I am. And that's also a great time to do it, although it's certainly not required. And so, that's kind of how I go through and evaluate whatever tool it is that I need. For something maybe more professional or higher stakes, there's a little more evaluation upfront, right? You want to make sure you make the right choice before you spend thousands of hours using it and potentially regretting [laughs] it and having to roll it back, causing even more thousands of hours of time. So, there's obviously some scrutiny there. But, again, that also takes experience and understanding the kind of need that you have. So, yeah, it's kind of a trade-off of, like, your time, and your energy, and your experience, and your interest. You will have many different inputs from colleagues, from websites, from posts on the internet, from Twitter, or fediverse-type kind of blogging and everything in between, right? So, you take all that in, and you try a bunch of stuff, and you come out on the other side, and then you do it again. STEPHANIE: Yeah, it sounds like you really like to just experiment, and I think that's really great. And I actually have to say that I am not someone who likes to do that [laughs]. Like, it's not where I focus a lot of my time. And it's why I'm, like, glad I'm friends with you, first of all. EDWARD: [laughs] STEPHANIE: But also, I've realized I'm much more of, like, a gatherer in terms of information and opinions. Like, I like hearing about other people's experience to then, like, help inform an opinion that I might develop myself. And, you know, it's not to say that, like, I am, like, oh yeah, like, so and so said this, and so, therefore, yeah, I completely believe what they have to say. But as someone who does not particularly want to spend a ton of my time trying out things, it is really helpful to know people who do like to do that, know people who I do trust, right? And then kind of like you had mentioned, just, like, having all these different inputs. And one thing that has changed for me with more experience is, previously, a lot of, like, the basis of what I thought was the quote, unquote, "right way" to develop software was, like, asking, like, other people and, you know, their opinions becoming my own. And, you know, at some point, though, that, like, has shifted, right? Where it's like, oh, like, you know, I remember learning this from so and so, and, like, actually, I think I disagree now. Or maybe it's like, I will take one part of it and be like, yeah, I really like test-driven development in this particular way that I have figured out how I do it, but it is different still from, like, who I learned it from. And even though, like, that was kind of what I thought previously as, like, oh yeah, like, this is the way that I've adopted without room for adjustment. I think that has been a growth, I guess, that I can point to and be like, oh yeah, like, I once was in a position where maybe opinions weren't necessarily my own. But now I spend a lot more time thinking about, like, oh, like, how do I feel about this? And I think there is, like, some amount of self-reflection required, right? A lot, honestly. Like, you try things, and then you think about, like, did I like that? [laughs] One without the other doesn't necessarily fully informed opinion make. EDWARD: Yeah, absolutely. I mean, I'm really glad you brought up that, like, you've heard an opinion, or a suggestion, or an idea from somebody, and you kind of adopt it as your own for a little bit. I like to think of it as trying on ideas like you try on clothing. Or something like, let me try on this jacket. Does this fit? And maybe you like it a little bit. Or maybe you look ridiculous, and it's [laughs] not quite for you. And you don't feel like it's for you. But you have to try. You have to, like, actually do it. And that is a completely valid way to, like, kick-starting some of those opinions, getting input from friends or colleagues, or just the world around you. And, like, hearing those things and trying them is 100% valid. And I'm glad you mentioned that because if I mentioned it, I think I kind of skipped over it or went through it very quickly. So, absolutely. And you're talking about how you just take, like, one part of it maybe. That nuance, that is, I think, really critical to that whole thought, too. Everything works differently for different people. And every tool is good for other, like, different jobs. Like, it will be like saying a hammer is the best tool, and it's, like, well, it's a good tool for the right thing. But, like, I wouldn't use a hammer to, like, I don't know, level the new house numbers I put on my house, right? But I might use them to, like, hit the nail to get them in. So, it's a silly analogy, but, like, there is always nuance and different ways to apply these different tools and opinions. STEPHANIE: I like that analogy. I think it would be really funny if there was someone out there who claimed that the hammer is the best tool ever invented [laughs]. EDWARD: Oh, I'm sure. I'm sure there is, you know. I'm not going to use a drill to paint my house, though [laughs]. STEPHANIE: That's a fair point, and you don't have to [chuckles]. EDWARD: Thank you [laughs]. STEPHANIE: But, I guess, to extend this thought further, I completely and wholeheartedly agree that, like, yeah, everyone gets to decide for themselves what works for them. But also, we work in relation with others. And I'm very interested in the balance of having your own ideas and opinions about tooling, software practices, like, whatever, and then how to bring that back into, like, working on a team or, like, working with others. EDWARD: Yeah. Well, I don't know if this is exactly what you're asking, but it makes me think of: you've gone off; you've discovered a whole bunch of stuff that you think works really well for you. And then you go to work, or you go to a community that is using a very different way of working, or different tools, or different technologies. That can be a piece of friction sometimes of, like, "Oh my gosh, I love Ruby on Rails. It's the best." And someone else is like, "I really, really don't like Ruby on Rails for reasons XYZ. And we don't use it here." And that can be really tough and, honestly, sometimes even disheartening, depending on how strongly you feel about that tool and how strongly they feel about their tools. And as a young developer many years ago, I definitely had a lot more of my identity wrapped up in the tools and technologies that I used. And that has been very useful to try to separate those two. I don't claim to be perfect at it or done with that work yet. But the more I can step away and say, you know, like, this is only a tool. It is not the tool. It is not the best tool. It is a tool that can be very effective at certain things. And I've found, at least right now, the more useful thing is to get to the root of the problem you're trying to solve and make sure you agree with everybody on that premise. So, yes, you may have come from a world where fast iteration and a really fluent language interface like Ruby has and a really fast iteration cycle like Rails has, is, like, the most important need to be solved because other things have been solved. You understand what you're doing for your product, or maybe you need to iterate quickly on that product. You've figured out an audience. You're getting payroll. You're meeting all that as a business. But then you go into a business that's potentially, like, let's say, much less funded. Or they have their market fit, and now they're working on, like, extreme performance optimization, or they're working on getting, like, government compliance, or something like that. And maybe Rails is still great. This is maybe a...the analogy may fall apart here. But let's pretend it isn't for some reason. You have to agree that, hey, like, yes, we've solved problem X that Rails really helps you solve. And now we're moving on to problem Y, and Rails may not help you solve that, or whatever technology you're using may not help you solve that. And I've found it to be much more useful to stop worrying about the means, and the tools, the things in between, and worry about the ends, worry about the goal, worry about the problems you're actually trying to solve. And then you can feel really invested in trying to solve that problem together as a group, as a team, as a community. I've found that to be very helpful. And I would also like to say it is extremely difficult to let some of that stuff go. It takes a lot of work. I see you nodding along. Like, it's really, really hard. And, like I said, I'm not totally done with it either. But that's, I think, it's something I'm really working on now and something I feel really strongly about. STEPHANIE: Yeah. You mentioned the friction of, like, working in an environment where there are different opinions, which is, you know, I don't know, just, like, reality, I guess [laughs]. EDWARD: Human nature. STEPHANIE: Yeah, exactly. And one thing I was thinking about recently was, like, okay, like, so someone else maybe made a decision about using a type of technology or, like, made a decision about architecture before my time or, like, above me, or whatever, right? Like, I wasn't there, and that is okay. But also, like, how do I maintain what I believe in and hold fast to, like, my opinions based on my value system, at least, without complaining? [laughs] Because I've only seen that a little bit before, right? When it just becomes, like, venting, right? It's like, ugh, like, you know, I have seen people who are coming from maybe, like, microservices or more of a JavaScript world, and they're like, ugh, like, what is going on with Rails? Like, this sucks [laughs]. And one thing I've been trying lately is just, like, communicating when I don't agree that something's a great idea. But also, like, acknowledging that, like, yeah, but this is how it is for this team, and I'm also not in a position to change it. Or, like, I don't feel so strongly about it that I'm like, "Hey, we should totally rethink using this, like, background job [laughs] platform." But I will be like, "Hey, like, I don't like this particular thing about it. And, you know, maybe here are some things that I did to mitigate whatever thing I'm not super into," or, like, "If I had more time, this is what I would do," and just putting it out there. Sometimes, I don't get, like, engagement on it. But it's a good practice for me to be, like, this is how I can still have opinions about things, even if I'm not, at least in this particular moment, in a position to change anything. EDWARD: It sounds to me like you in, at least at the lowest level, like, you want to be acknowledged, and you want to, like, be heard. You want to be part of a process. And yes, it doesn't always go with Stephanie's initial thought, or even final thought, or Edward's final thought. But it is very helpful to know that you are heard and you are respected. And it isn't someone just, like, completely disregarding any feeling that you have. As much as we like to say programming is this very, like, I don't know, value neutral, zero emotion kind of job, like, there's tons of emotion in this job. We want to do good things for the world. We want our technology to serve the people, ultimately, at least I do, and I know you do. But we sometimes disagree on the way to do that. And so, you want to make sure you're heard. And if you can't get that at work, like, and I know you do this, but I would encourage anyone listening out there to, like, get a buddy that you can vent to or get somebody that you can express, and they will hear you. That is so valuable just as a release, in some ways, to kind of get through what you need to get through sometimes. Because it is a job, and you aren't always the person that's going to make the decisions. And, honestly, like, you do still have one decision left, which is you can go work somewhere else if it really is that bad. And, like, it's useful to know that you are staying where you are because you appreciate the trade-offs that you have: a steady paycheck, or the colleagues that you work with, or whatever. And that's fine. That's an okay trade-off. And at some point, you might want to make a different trade-off, and that's also fine. We're getting real managery and real here. But I think it's useful. Like you said, this can be a very emotional career, and it's worth acknowledging that. STEPHANIE: Yeah, you just, you know, raised a bunch of, like, very excellent points. Yeah, at the end of the day, like, you know, you can do your best to, like, propose changes or, like, introduce new tooling and, like, see how other people feel about it. But, like, yeah, if you fundamentally do not enjoy working with a critical tool that, you know, a lot of the foundation of the work that you're doing day to day is built off of, then maybe there is a place where, like, another company that's using tools that you do feel excited or, like, passionate or, like, are a better alignment with what you hope to be doing. Kind of just going back to that theme that we were talking about earlier, like, everyone gets to decide for themselves, right? Like, the tools to help them do what they want to be doing. EDWARD: And you could even, like, reframe it for yourself, where instead of it being about the tools, maybe it's about the problem. Like, you start being more invested in, like, the problem that you're solving and, okay, maybe you don't want to use microservices or whatever, but, like, maybe you can get behind that if you realign yourself. The thing you're trying to solve is not the tool. The thing you're trying to solve is the problem. And that can be a useful, like, way to mitigate that or to, like, help yourself feel okay about the thing, whatever that is. STEPHANIE: Yeah. Now, how do I have this conversation with everyone [laughter] who claims on the internet that X is the solution to all their problems or the silver bullet, [laughs] or whatever? EDWARD: Yeah, that's tough because there are some very strong opinions on the internet, as I'm sure [laughs] you've observed. I don't know if I have the answer [laughs]. Once again, nuance and indecisions. I have been currently approaching it from kind of a meta-perspective of, like, if someone says, "X is the best tool," you know, "A hammer is the best tool," right? I'm not going to go write the post that's like, "No, hammer is, in fact, not the best tool. Don't use hammers." I would maybe instead write a post that's like, "Consider what makes the best tool." I've effectively, like, raised up one level of abstraction from, we're no longer talking about is X, or Y, or Z, the best tool? We're talking about how do we even decide that? How do we even think about that? One post...I'm now just promoting my blog posts, so get ready. But one thing I wrote was this post called And Not But. And I tried to make the case that instead of saying the word but in a sentence, so, like, yeah, yeah, we might want to use hammers, but we have to use drills or whatever. I'm trying to make the case that you can use and instead. So yeah, hammers are really good, and drills are really good in these other scenarios. And trying to get that nuance in there, like, really, really putting that in there and getting people to, like, feel that better, I think, has been really helpful, for me, certainly to get through. And part of the best thing about writing a blog post is just getting your own thoughts...I mean, it's another way to vent, right? It's getting your own thoughts out somewhere. And sometimes people respond to them. You'd be surprised who just reaches out and been like, "Hey, yeah, like, I really appreciated that post. That was really great." You weren't trying to reach that person, but now you have another connection. So, a side benefit for writing blog posts [inaudible 30:17] do it, or just even getting your thoughts out via a podcast, via a video, whatever. So, I've kind of addressed that. I also wrote a post when I worked at thoughtbot called Empathy Online. And that came out of, like, frustration with seeing people being too divisive or, in my opinion, unempathetic or inconsiderate. And instead of, again, trying to just say, "Stop it, don't do that," [laughs] but trying to, like, help use what I have learned when communicating in a medium that is kind of inherently difficult to get across emotion and empathy. And so, again, it's, in some ways, unsatisfying because what you really want to do is go talk to that person that says, "Hammer is the best tool," and say, "No, stop it [laughs]," and, like, slap them on the head or whatever, politely. But I think that probably will not get you very far. And so, if your goal, really, is to change the way people think about these things, I find it way more effective to, like, zoom out and talk about that on that sort of more meta-level and that higher level. STEPHANIE: Yeah. I liked how you called it, like, a higher level of abstraction. And, honestly, the other thing I was thinking about as you were talking about the, like, divisiveness that opinions can create, there's also some aspect of it, as a reader, realizing that one person sharing their opinion does not take away your ability to have a differing opinion [laughs]. And sometimes it's tough when someone's like, "Tailwind sucks [laughs], and it is a backward step in, you know, how we write CSS," or whatever. Yes, like, sometimes that can be kind of, like, inflammatory. But if you, like, kind of are translating it or, like, reading between the lines, they're just writing about their perspective from the things that they value. And it is okay for you to value different things and, for that reason, have a different perspective on the same thing. And, I don't know, that has helped me sometimes avoid getting into that, like, headspace of wanting to argue with someone [laughs] on the internet. Or they'll be like, "This is why I am right." [laughs] Now I have to write something and share it on the internet in response [laughs]. EDWARD: There's this idea of the narcissism of minor differences. And I believe the idea is this, like, you know, you're more likely to argue with someone who, like, 90% agrees with you. But you're just, like, quibbling over that last 10%. I mean, one might call it bikeshedding. I don't know if you've heard that phrase. But the thing that I have often found, too, is that, like the GitHub post, I will get people arguing with me, like, there's the kind of stuff I expected, where it's like, "Oh, but GitHub is really good," and XYZ and that's fine. And we can have that conversation. But it's kind of surprising, and I should have expected it, that people will sometimes be like, "Hey, you didn't go far enough. You should tell people to, like, completely delete their GitHub or, like, you know, go protest in the street." And, like, maybe that's true. I'm not saying it is or isn't. But I think one thing I try to think about is, in any post, in any trying convincing argument, like, you're potentially moving someone 1 step forward, even if there's ten steps to go. But they're never going to make those ten steps if they don't make the first 1. And so, you can kind of help them get there. And someone else's post can absolutely take them from step 5 to 6 or 6 to 7 or 7 to 8. And you won't accomplish it all at once, and it's kind of a silly thing to try, and your efforts are probably lost [laughs]. Unfortunately, it's a little bit of preaching to the choir because, like, yeah, the people that are going to respond to, like, the extreme, the end are, like, the people that already get it. And the people that you're trying to convince and move along are not going to get that thing. I do want to say that I could see this being perceived as, like, a very privileged position of, like, if there's some, like, genuine atrocity happening in the world, like, it is appropriate to go to extremes many times and sometimes, and that's fine, and people are allowed to be there. I don't want to invalidate that. It's a really tricky balance. And I'm trying to say that if your goal is to vent, that's fine. And if your goal is to move people from step 3 to 4, you have to meet people at step 3. And all that's valid and okay to try to help people move in that way. But it is very tricky. And I don't want to invalidate someone who's extremely frustrated because they're at step 10, and no one else is seeing the harm that not everybody else being at step 10 is. Like, that's an incredibly reasonable place to be and an okay place to be. STEPHANIE: Yeah, yeah. The other thing you just sparked, for me, is also the, like, power of, yeah, being able to say like, "Yeah, I agree with this 50%, or 60%, or, like, 90%." And also, there's this 10% that I'm like, oh, like, I wish were different, or I wish they'd gone further, or I wish they didn't say that. Or, you know, I just straight up disagree with this step 1 sentence, but the rest of the article, you know, I really related to. And, like, teasing that apart has been very useful for me, right? Because then I'm no longer like being like, oh, was this post good or bad? Do I agree with it or don't agree with it? It's like, there's room for [laughs] all of it. EDWARD: Yeah, that's that nuance that, you know, I liked this post, and I did not agree with these two parts of it, or whatever. It's so useful. STEPHANIE: Well, thanks, Edward, so much for coming on the show and bringing that nuance to this conversation. I feel really excited about kind of what we talked about, and hopefully, it resonates with some of our listeners. EDWARD: Yeah, I hope so too. I hope I can take them from step 2 to step 3 [laughs]. STEPHANIE: On that note, shall we wrap up? EDWARD: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

This is expected to be the busiest holiday travel season ever. Triple A's Robert Sinclair Jr., shared the best and worst times to leave on Newsline with Brigitte Quinn.

Sara is a team lead at thoughtbot. She talks about her experience as a professor at Kanazawa Technical College, giant LAN parties in Rochester, transitioning from Java to Ruby, shining a light on maintainers, and her closing thoughts on RubyConf. Recorded at RubyConf 2023 in San Diego. -- A few topics covered: Being an Assistant Arofessor in Kanazawa Teaching naming, formatting, and style Differences between students in Japan vs US Technical terms and programming resources in Japanese LAN parties at Rochester Transitioning from Java to Ruby Consulting The forgotten maintainer RubyConf Other links Sara's mastodon thoughtbot This Week in Open Source testdouble Ruby Central Scholars and Guides Program City Museum Japan International College of Technology Kanazawa RubyKaigi Applying mruby to World-first Small SAR Satellite (Japanese lightning talk) (mruby in space) Rochester Rochester Institute of Technology Electronic Gaming Society Tora-con Strong National Museum of Play Transcript You can help correct transcripts on GitHub. [00:00:00] Jeremy: I'm here at RubyConf, San Diego, with Sara Jackson, thank you for joining me today. [00:00:05] Sara: Thank you for having me. Happy to be here. [00:00:07] Jeremy: Sara right now you're working at, ThoughtBot, as a, as a Ruby developer, is that right? [00:00:12] Sara: Yes, that is correct. Teaching in Japan [00:00:14] Jeremy: But I think before we kind of talk about that, I mean, we're at a Ruby conference, but something that I, I saw, on your LinkedIn that I thought was really interesting was that you were teaching, I think, programming in. Kanazawa, for a couple years. [00:00:26] Sara: Yeah, that's right. So for those that don't know, Kanazawa is a city on the west coast of Japan. If you draw kind of a horizontal line across Japan from Tokyo, it's, it's pretty much right there on the west coast. I was an associate professor in the Global Information and Management major, which is basically computer science or software development. (laughs) Yep. [00:00:55] Jeremy: Couldn't tell from the title. [00:00:56] Sara: You couldn't. No.. so there I was teaching classes for a bunch of different languages and concepts from Java to Python to Unix and Bash scripting, just kind of all over. [00:01:16] Jeremy: And did you plan the curriculum yourself, or did they have anything for you? [00:01:21] Sara: It depended on the class that I was teaching. So some of them, I was the head teacher. In that case, I would be planning the class myself, the... lectures the assignments and grading them, et cetera. if I was assisting on a class, then usually it would, I would be doing grading and then helping in the class. Most of the classes were, uh, started with a lecture and then. Followed up with a lab immediately after, in person. [00:01:54] Jeremy: And I think you went to, is it University of Rochester? [00:01:58] Sara: Uh, close. Uh, Rochester Institute of Technology. So, same city. Yeah. [00:02:03] Jeremy: And so, you were studying computer science there, is that right? [00:02:07] Sara: I, I studied computer science there, but I got a minor in Japanese language. and that's how, that's kind of my origin story of then teaching in Kanazawa. Because Rochester is actually the sister city with Kanazawa. And RIT has a study abroad program for Japanese learning students to go study at KIT, Kanazawa Institute of Technology, in Kanazawa, do a six week kind of immersive program. And KIT just so happens to be under the same board as the school that I went to teach at. [00:02:46] Jeremy: it's great that you can make that connection and get that opportunity, yeah. [00:02:49] Sara: Absolutely. Networking! [00:02:52] Jeremy: And so, like, as a student in Rochester, you got to see how, I suppose, computer science education was there. How did that compare when you went over to Kanazawa? [00:03:02] Sara: I had a lot of freedom with my curriculum, so I was able to actually lean on some of the things that I learned, some of the, the way that the courses were structured that I took, I remember as a freshman in 2006, one of the first courses that we took, involved, learning Unix, learning the command line, things like that. I was able to look up some of the assignments and some of the information from that course that I took to inform then my curriculum for my course, [00:03:36] Jeremy: That's awesome. Yeah. and I guess you probably also remember how you felt as a student, so you know like what worked and maybe what didn't. [00:03:43] Sara: Absolutely. And I was able to lean on that experience as well as knowing. What's important and what, as a student, I didn't think was important. Naming, formatting, and style [00:03:56] Jeremy: So what were some examples of things that were important and some that weren't? [00:04:01] Sara: Mm hmm. For Java in particular, you don't need any white space between any of your characters, but formatting and following the general Guidelines of style makes your code so much easier to read. It's one of those things that you kind of have to drill into your head through muscle memory. And I also tried to pass that on to my students, in their assignments that it's. It's not just to make it look pretty. It's not just because I'm a mean teacher. It is truly valuable for future developers that will end up reading your code. [00:04:39] Jeremy: Yeah, I remember when I went through school. The intro professor, they would actually, they would print out our code and they would mark it up with red pen, basically like a writing assignment and it would be like a bad variable name and like, white space shouldn't be here, stuff like that. And, it seems kind of funny now, but, it actually makes it makes a lot of sense. [00:04:59] Sara: I did that. [00:04:59] Jeremy: Oh, nice. [00:05:00] Sara: I did that for my students. They were not happy about it. (laughs) [00:05:04] Jeremy: Yeah, at that time they're like, why are you like being so picky, right? [00:05:08] Sara: Exactly. But I, I think back to my student, my experience as a student. in some of the classes I've taken, not even necessarily computer related, the teachers that were the sticklers, those lessons stuck the most for me. I hated it at the time. I learned a lot. [00:05:26] Jeremy: Yeah, yeah. so I guess that's an example of things that, that, that matter. The, the aesthetics or the visual part for understanding. What are some things that they were teaching that you thought like, Oh, maybe this isn't so important. [00:05:40] Sara: Hmm. Pause for effect. (laughs) So I think that there wasn't necessarily Any particular class or topic that I didn't feel was as valuable, but there was some things that I thought were valuable that weren't emphasized very well. One of the things that I feel very strongly about, and I'm sure those of you out there can agree. in RubyWorld, that naming is important. The naming of your variables is valuable. It's useful to have something that's understood. and there were some other teachers that I worked with that didn't care so much in their assignments. And maybe the labs that they assigned had less than useful names for things. And that was kind of a disappointment for me. [00:06:34] Jeremy: Yeah, because I think it's maybe hard to teach, a student because a lot of times you are writing these short term assignments and you have it pass the test or do the thing and then you never look at it again. [00:06:49] Sara: Exactly. [00:06:50] Jeremy: So you don't, you don't feel that pain. Yeah, [00:06:53] Sara: Mm hmm. But it's like when you're learning a new spoken language, getting the foundations correct is super valuable. [00:07:05] Jeremy: Absolutely. Yeah. And so I guess when you were teaching in Kanazawa, was there anything you did in particular to emphasize, you know, these names really matter because otherwise you or other people are not going to understand what you were trying to do here? [00:07:22] Sara: Mm hmm. When I would walk around class during labs, kind of peek over the shoulders of my students, look at what they're doing, it's... Easy to maybe point out at something and be like, well, what is this? I can't tell what this is doing. Can you tell me what this does? Well, maybe that's a better name because somebody else who was looking at this, they won't know, I don't know, you know, it's in your head, but you will not always be working solo. my school, a big portion of the students went on to get technical jobs from after right after graduating. it was when you graduated from the school that I was teaching at, KTC, it was the equivalent of an associate's degree. Maybe 50 percent went off to a tech job. Maybe 50 percent went on to a four year university. And, and so as students, it hadn't. Connected with them always yet that oh, this isn't just about the assignment. This is also about learning how to interact with my co workers in the future. Differences between students [00:08:38] Jeremy: Yeah, I mean, I think It's hard, but, group projects are kind of always, uh, that's kind of where you get to work with other people and, read other people's code, but there's always that potential imbalance of where one person is like, uh, I know how to do this. I'll just do it. Right? So I'm not really sure how to solve that problem. Yeah. [00:09:00] Sara: Mm hmm. That's something that I think probably happens to some degree everywhere, but man, Japan really has groups, group work down. They, that's a super generalization. For my students though, when you would put them in a group, they were, they were usually really organized about who was going to do what and, kept on each other about doing things maybe there were some students that were a little bit more slackers, but it was certainly not the kind of polarized dichotomy you would usually see in an American classroom. [00:09:39] Jeremy: Yeah. I've been on both sides. I've been the person who did the work and the slacker. [00:09:44] Sara: Same. [00:09:46] Jeremy: And, uh, I feel bad about it now, but, uh, [00:09:50] Sara: We did what we had to do. [00:09:52] Jeremy: We all got the degree, so we're good. that is interesting, though. I mean, was there anything else, like, culturally different, you felt, from, you know, the Japanese university? [00:10:04] Sara: Yes. Absolutely. A lot of things. In American university, it's kind of the first time in a young person's life, usually, where they have the freedom to choose what they learn, choose where they live, what they're interested in. And so there's usually a lot of investment in your study and being there, being present, paying attention to the lecture. This is not to say that Japanese college students were the opposite. But the cultural feeling is college is your last time to have fun before you enter the real world of jobs and working too many hours. And so the emphasis on paying Super attention or, being perfect in your assignments. There was, there was a scale. There were some students that were 100 percent there. And then there were some students that were like, I'm here to get a degree and maybe I'm going to sleep in class a little bit. (laughs) That is another major difference, cultural aspect. In America, if you fall asleep in a meeting, you fall asleep in class, super rude. Don't do it. In Japan, if you take a nap at work, you take a nap in class, not rude. It's actually viewed as a sign of you are working really hard. You're usually working maybe late into the night. You're not getting enough sleep. So the fact that you need to take maybe a nap here or two here or there throughout the day means that you have put dedication in. [00:11:50] Jeremy: Even if the reason you're asleep is because you were playing games late at night. [00:11:54] Sara: Yep. [00:11:55] Jeremy: But they don't know that. [00:11:56] Sara: Yeah. But it's usually the case for my students. [00:11:59] Jeremy: Okay. I'm glad they were having fun at least [00:12:02] Sara: Me too. Why she moved back [00:12:04] Jeremy: That sounds like a really interesting experience. You did it for about two years? Three years. [00:12:12] Sara: So I had a three year contract with an option to extend up to five, although I did have a There were other teachers in my same situation who were actually there for like 10 years, so it was flexible. [00:12:27] Jeremy: Yeah. So I guess when you made the decision to, to leave, what was sort of your, your thinking there? [00:12:35] Sara: My fiance was in America [00:12:37] Jeremy: Good. [00:12:37] Sara: he didn't want to move to Japan [00:12:39] Jeremy: Good, reason. [00:12:39] Sara: Yeah, he was waiting three years patiently for me. [00:12:44] Jeremy: Okay. Okay. my heart goes out there . He waited patiently. [00:12:49] Sara: We saw each other. We, we were very lucky enough to see each other every three or four months in person. Either I would visit America or he would come visit me in Kanazawa. [00:12:59] Jeremy: Yeah, yeah. You, you couldn't convince him to, to fall in love with the country. [00:13:03] Sara: I'm getting there [00:13:04] Jeremy: Oh, you're getting Oh, [00:13:05] Sara: it's, We're making, we're making way. [00:13:07] Jeremy: Good, that's good. So are you taking like, like yearly trips or something, or? [00:13:11] Sara: That was, that was always my intention when I moved back so I moved back in the Spring of 2018 to America and I did visit. In 2019, the following year, so I could attend the graduation ceremony for the last group of students that I taught. [00:13:26] Jeremy: That's so sweet. [00:13:27] Sara: And then I had plans to go in 2020. We know what happened in 2020 [00:13:32] Jeremy: Yeah. [00:13:33] Sara: The country did not open to tourism again until the fall of 2022. But I did just make a trip last month. [00:13:40] Jeremy: Nice [00:13:40] Sara: To see some really good friends for the first time in four years. [00:13:43] Jeremy: Amazing, yeah. Where did you go? [00:13:46] Sara: I did a few days in Tokyo. I did a few days in Niigata cause I was with a friend who studied abroad there. And then a few days in Kanazawa. [00:13:56] Jeremy: That's really cool, yeah. yeah, I had a friend who lived there, but they were teaching English, yeah. And, I always have a really good time when I'm out there, yeah. [00:14:08] Sara: Absolutely. If anyone out there visiting wants to go to Japan, this is your push. Go do it. Reach out to me on LinkedIn. I will help you plan. [00:14:17] Jeremy: Nice, nice. Um, yeah, I, I, I would say the same. Like, definitely, if you're thinking about it, go. And, uh, sounds like Sara will hook you up. [00:14:28] Sara: Yep, I'm your travel guide. Technical terms in Japanese [00:14:31] Jeremy: So you, you studied, uh, you, you said you had a minor in Japanese? Yeah. So, so when you were teaching there, were you teaching classes in English or was it in Japanese? [00:14:42] Sara: It was a mix. Uh, when I was hired, the job description was no Japanese needed. It was a very, like, Global, international style college, so there was a huge emphasis on learning English. They wanted us to teach only in English. My thought was, it's hard enough learning computer science in your native language, let alone a foreign language, so my lectures were in English, but I would assist the labs in japanese [00:15:14] Jeremy: Oh, nice. Okay. And then, so you were basically fluent then at the time. Middle. Okay. Yeah. Yeah. Hey, well, I think if you're able to, to help people, you know, in labs and stuff, and it's a technical topic, right? So that's gotta be kind of a, an interesting challenge [00:15:34] Sara: I did learn a lot of new computer vocabulary. Yes. [00:15:39] Jeremy: So the words are, like, a lot of them are not the same? Or, you know, for, for specifically related to programming, I guess. [00:15:46] Sara: Hmm. Yeah, there are Japanese specific words. There's a lot of loan words that we use. We. Excuse me. There's a lot of loan words that Japanese uses for computer terms, but there's plenty that are just in Japanese. For example, uh, an array is hairetsu. [00:16:08] Jeremy: Okay. [00:16:08] Sara: And like a screen or the display that your monitor is a gamen, but a keyboard would be keyboard... Kībōdo, probably. [00:16:20] Jeremy: Yeah. So just, uh, so that, they use that as a loan word, I guess. But I'm not sure why not the other two. [00:16:27] Sara: Yeah, it's a mystery. [00:16:29] Jeremy: So it's just, it's just a total mix. Yeah. I'm just picturing you thinking like, okay, is it the English word or is it the Japanese word? You know, like each time you're thinking of a technical term. Yeah. [00:16:39] Sara: Mm hmm. I mostly, I, I I went to the internet. I searched for Japanese computer term dictionary website, and kind of just studied the terms. I also paid a lot of attention to the Japanese professors when they were teaching, what words they were using. Tried to integrate. Also, I was able to lean on my study abroad, because it was a technical Japanese, like there were classes that we took that was on technical Japanese. Computer usage, and also eco technology, like green technology. So I had learned a bunch of them previously. [00:17:16] Jeremy: Mm. So was that for like a summer or a year or something [00:17:20] Sara: It was six weeks [00:17:21] Jeremy: Six weeks. [00:17:21] Sara: During the summer, [00:17:22] Jeremy: Got it. So that's okay. So like, yeah, that must have been an experience like going to, I'm assuming that's the first time you had been [00:17:30] Sara: It was actually the second time [00:17:31] Jeremy: The second [00:17:32] Sara: Yeah. That was in 2010 that I studied abroad. [00:17:35] Jeremy: And then the classes, they were in Japanese or? Yeah. Yeah. That's, uh, that's, that's full immersion right there. [00:17:42] Sara: It was, it was very funny in the, in the very first lesson of kind of just the general language course, there was a student that was asking, I, how do I say this? I don't know this. And she was like, Nihongo de. [00:17:55] Jeremy: Oh (laughs) ! [00:17:56] Sara: You must, must ask your question only in [00:17:59] Jeremy: Yeah, Programming resources in Japanesez [00:17:59] Jeremy: yeah. yeah. That's awesome. So, so it's like, I guess the, the professors, they spoke English, but they were really, really pushing you, like, speak Japanese. Yeah, that's awesome. and maybe this is my bias because I'm an English native, but when you look up. Resources, like you look up blog posts and Stack Overflow and all this stuff. It's all in English, right? So I'm wondering for your, your students, when, when they would search, like, I got this error, you know, what do I do about it? Are they looking at the English pages or are they, you know, you know what I mean? [00:18:31] Sara: There are Japanese resources that they would use. They love Guguru (Google) sensei. [00:18:36] Jeremy: Ah okay. Okay. [00:18:38] Sara: Um, but yeah, there are plenty of Japanese language stack overflow equivalents. I'm not sure if they have stack overflow specifically in Japanese. But there are sites like that, that they, that they used. Some of the more invested students would also use English resources, but that was a minority. [00:19:00] Jeremy: Interesting. So there's a, there's a big enough community, I suppose, of people posting and answering questions and stuff where it's, you don't feel like, there aren't people doing the same thing as you out there. [00:19:14] Sara: Absolutely. Yeah. There's, a large world of software development in Japan, that we don't get to hear. There are questions and answers over here because of that language barrier. [00:19:26] Jeremy: Yeah. I would be, like, kind of curious to, to see, the, the languages and the types of problems they have, if they were similar or if it's, like, I don't know, just different. [00:19:38] Sara: Yeah, now I'm interested in that too, and I bet you there is a lot of research that we could do on Ruby, since Ruby is Japanese. [00:19:51] Jeremy: Right. cause something I've, I've often heard is that, when somebody says they're working with Ruby, Here in, um, the United States, a lot of times people assume it's like, Oh, you're doing a Rails app, [00:20:02] Sara: Mm hmm. [00:20:03] Jeremy: Almost, almost everybody who's using Ruby, not everyone, but you know, the majority I think are using it because of Rails. And I've heard that in Japan, there's actually a lot more usage that's, that's not tied to Rails. [00:20:16] Sara: I've also heard that, and I get the sense of that from RubyKaigi as well. Which I have never been lucky enough to attend. But, yeah, the talks that come out of RubyKaigi, very technical, low to the metal of Ruby, because there's that community that's using it for things other than Rails, other than web apps. [00:20:36] Jeremy: Yeah, I think, one of the ones, I don't know if it was a talk or not, but, somebody was saying that there is Ruby in space. [00:20:42] Sara: That's awesome. Ruby's everywhere. LAN parties in college [00:20:44] Jeremy: So yeah, I guess like another thing I saw, during your time at Rochester is you were, involved with like, there's like a gaming club I wonder if you could talk a little bit about your experience with that. [00:20:55] Sara: Absolutely, I can. So, at RIT, I was an executive board member for three or four years at the Electronic Gaming Society. EGS for short, uh, we hosted weekly console game nights in, the student alumni union area, where there's open space, kind of like a cafeteria. We also hosted quarterly land parties, and we would actually get people from out of state sometimes who weren't even students to come. Uh, and we would usually host the bigger ones in the field house, which is also where concerts are held. And we would hold the smaller ones in conference rooms. I think when I started in 2006, the, the, the LANs were pretty small, maybe like 50, 50 people bring your, your, your huge CRT monitor tower in. [00:21:57] Jeremy: Oh yeah, [00:21:57] Sara: In And then by the time I left in 2012. we were over 300 people for a weekend LAN party, um, and we were actually drawing more power than concerts do. [00:22:13] Jeremy: Incredible. what were, what were people playing at the time? Like when they would the LANs like, [00:22:18] Sara: Yep. Fortnite, early League of Legends, Call of Duty. Battlegrounds. And then also just like fun indie games like Armagedtron, which is kind of like a racing game in the style of [00:22:37] Jeremy: okay. Oh, okay, [00:22:39] Sara: Um, any, there are some like fun browser games where you could just mess with each other. Jackbox. Yeah. [00:22:49] Jeremy: Yeah, it's, it's interesting that, you know, you're talking about stuff like Fortnite and, um, what is it? Battlegrounds is [00:22:55] Sara: not Fortnite. Team Fortress. [00:22:58] Jeremy: Oh Team Fortress! [00:22:59] Sara: Sorry. Yeah. Oh, yeah, I got my, my names mixed up. Fortnite, I think, did not exist at the time, but Team Fortress was big. [00:23:11] Jeremy: Yeah. that's really cool that you're able to get such a big group there. is there something about Rochester, I guess, that that was able to bring together this many people for like these big LAN events? Because I'm... I mean, I'm not sure how it is elsewhere, but I feel like that's probably not what was happening elsewhere in the country. [00:23:31] Sara: Yeah, I mean, if you've ever been to, um, DreamHack, that's, that's a huge LAN party and game convention, that's fun. so... EGS started in the early 2000s, even before I joined, and was just a committed group of people. RIT was a very largely technical school. The majority of students were there for math, science, engineering, or they were in the computer college, [00:24:01] Jeremy: Oh, okay. [00:24:01] Sara: GCIS, G C C I S, the Gossano College of Computing and Information Sciences. So there was a lot of us there. [00:24:10] Jeremy: That does make sense. I mean, it's, it's sort of this, this bias that when there's people doing, uh, technical stuff like software, um, you know, and just IT, [00:24:21] Sara: Mm hmm. [00:24:23] Jeremy: there's kind of this assumption that's like, oh, maybe they play games. And it seems like that was accurate [00:24:27] Sara: It was absolutely accurate. And there were plenty of people that came from different majors. but when I started, there were 17, 000 students and so that's a lot of students and obviously not everyone came to our weekly meetings, but we had enough dedicated people that were on the eboard driving, You know, marketing and advertising for, for our events and things like that, that we were able to get, the good community going. I, I wasn't part of it, but the anime club at RIT is also huge. They run a convention every year that is huge, ToraCon, um. And I think it's just kind of the confluence of there being a lot of geeks and nerds on campus and Rochester is a college town. There's maybe like 10 other universities in [00:25:17] Jeremy: Well, sounds like it was a good time. [00:25:19] Sara: Absolutely would recommend. Strong Museum of Play [00:25:22] Jeremy: I've never, I've never been, but the one thing I have heard about Rochester is there's the, the Strong Museum of Play. [00:25:29] Sara: Yeah, that place is so much fun, even as an adult. It's kind of like, um, the, the Children's Museum in Indiana for, for those that might know that. it just has all the historical toys and pop culture and interactive exhibits. It's so fun. [00:25:48] Jeremy: it's not quite the same, but it, when you were mentioning the Children's Museum in, um, I think it's in St. Louis, there's, uh, it's called the City Museum and it's like a, it's like a giant playground, you know, indoors, outdoors, and it's not just for kids, right? And actually some of this stuff seems like kind of sketch in terms of like, you could kind of hurt yourself, you know, climbing [00:26:10] Sara: When was this made? [00:26:12] Jeremy: I'm not sure, but, uh, [00:26:14] Sara: before regulations maybe. ha. [00:26:16] Jeremy: Yeah. It's, uh, but it's really cool. So at the, at the Museum of Play, though, is it, There's like a video game component, right? But then there's also, like, other types of things, [00:26:26] Sara: Yeah, they have, like, a whole section of the museum that's really, really old toys on display, like, 1900s, 1800s. Um, they have a whole Sesame Street section, and other things like that. Yeah. From Java to Ruby [00:26:42] Jeremy: Check it out if you're in Rochester. maybe now we could talk a little bit about, so like now you're working at Thoughtbot as a Ruby developer. but before we started recording, you were telling me that you started, working with Java. And there was like a, a long path I suppose, you know, changing languages. So maybe you can talk a little bit about your experience there. [00:27:06] Sara: Yeah. for other folks who have switched languages, this might be a familiar story for you, where once you get a job in one technology or one stack, one language, you kind of get typecast after a while. Your next job is probably going to be in the same language, same stack. Companies, they hire based on technology and So, it might be hard, even if you've been playing around with Ruby in your free time, to break, make that barrier jump from one language to another, one stack to another. I mean, these technologies, they can take a little while to ramp up on. They can be a little bit different, especially if you're going from a non object oriented language to an object oriented, don't. Lose hope. (laughs) If you have an interest in Ruby and you're not a Rubyist right now, there's a good company for you that will give you a chance. That's the key that I learned, is as a software developer, the skills that you have that are the most important are not the language that you know. It's the type of thinking that you do, the problem solving, communication, documentation, knowledge sharing, Supporting each other, and as Saron the keynote speaker on Wednesday said, the, the word is love. [00:28:35] Jeremy: [00:28:35] Sara: So when I was job hunting, it was really valuable for me to include those important aspects in my skill, in my resume, in my CV, in my interviews, that like, I'm newer to this language because I had learned it at a rudimentary level before. Never worked in it really professionally for a long time. Um, when I was applying, it was like, look, I'm good at ramping up in technologies. I have been doing software for a long time, and I'm very comfortable with the idea of planning, documenting, problem solving. Give me a chance, please. I was lucky enough to find my place at a company that would give me a chance. Test Double hired me in 2019 as a remote. Software Consultant, and it changed my life. [00:29:34] Jeremy: What, what was it about, Ruby that I'm assuming that this is something that you maybe did in your spare time where you were playing with Ruby or? [00:29:43] Sara: I am one of those people that don't really code in their spare time, which I think is valuable for people to say. The image of a software developer being, well, if you're not coding in your spare time, then you're not passionate about it. That's a myth. That's not true. Some of us, we have other hobbies. I have lots of hobbies. Coding is not the one that I carry outside of the workplace, usually, but, I worked at a company called Constant Contact in 2014 and 2015. And while I was there, I was able to learn Ruby on Rails. [00:30:23] Jeremy: Oh, okay. So that was sort of, I guess, your experience there, on the job. I guess you enjoyed something about the language or something about Rails and then that's what made you decide, like, I would really love to, to... do more of this [00:30:38] Sara: Absolutely. It was amazing. It's such a fun language. The first time I heard about it was in college, maybe 2008 or 2009. And I remember learning, this looks like such a fun language. This looks like it would be so interesting to learn. And I didn't think about it again until 2014. And then I was programming in it. Coming from a Java mindset and it blew my mind, the Rails magic also, I was like, what is happening? This is so cool. Because of my typecasting sort of situation of Java, I wasn't able to get back to it until 2019. And I don't want to leave. I'm so happy. I love the language. I love the community. It's fun. [00:31:32] Jeremy: I can totally see that. I mean, when I first tried out Rails, yeah, it, like, you mentioned the magic, and I know some people are like, ah, I don't like the magic, but when, I think, once I saw what you could do, And how, sort of, little you needed to write, and the fact that so many projects kind of look the same. Um, yeah, that really clicked for me, and I really appreciated that. think that and the Rails console. I think the console is amazing. [00:32:05] Sara: Being able to just check real quick. Hmm, I wonder if this will work. Wait, no, I can check right now. I [00:32:12] Jeremy: And I think that's an important point you brought up too, about, like, not... the, the stereotype and I, I kind of, you know, showed it here where I assumed like, Oh, you were doing Java and then you moved to Ruby. It must've been because you were doing Ruby on the side and thought like, Oh, this is cool. I want to do it for my job. but I, I thought that's really cool that you were able to, not only that you, you don't do the programming stuff outside of work, but that you were able to, to find an opportunity where you could try something different, you know, in your job where you're still being paid. And I wonder, was there any, was there any specific intention behind, like, when you took that job, it was so that I can try something different, or did it just kind of happen? I'm curious what your... The appeal of consulting [00:32:58] Sara: I was wanting to try something different. I also really wanted to get into consulting. [00:33:04] Jeremy: Hmm. [00:33:05] Sara: I have ADHD. And working at a product company long term, I think, was never really going to work out for me. another thing you might notice in my LinkedIn is that a lot of my stays at companies have been relatively short. Because, I don't know, I, my brain gets bored. The consultancy environment is... Perfect. You can go to different clients, different engagements, meet new people, learn a different stack, learn how other people are doing things, help them be better, and maybe every two weeks, two months, three months, six months, a year, change and do it all over again. For some people, that sounds awful. For me, it's perfect. [00:33:51] Jeremy: Yeah, I hadn't thought about that with, with consulting. cause I, I suppose, so you said it's, it's usually about half a year between projects or is It [00:34:01] Sara: varies [00:34:01] Jeremy: It varies widely. [00:34:02] Sara: Widely. I think we try to hit the sweet spot of 3-6 months. For an individual working on a project, the actual contract engagement might be longer than that, but, yeah. Maintainers don't get enough credit [00:34:13] Jeremy: Yeah. And, and your point about how some people, they like to jump on different things and some people like to, to stick to the same thing. I mean, that, that makes a lot of, sense in terms of, I think maintaining software and like building new software. It's, they're both development, [00:34:32] Sara: Mm hmm. [00:34:32] Jeremy: they're very different. Right. [00:34:35] Sara: It's so funny that you bring that up because I highly gravitate towards maintaining over making. I love going to different projects, but I have very little interest in Greenfield, very little interest in making something new. I want to get into the weeds, into 10 years that nobody wants to deal with because the weeds are so high and there's dragons in there. I want to cut it away. I want to add documentation. I want to make it better. It's so important for us to maintain our software. It doesn't get nearly enough credit. The people that work on open source, the people that are doing maintenance work on, on apps internally, externally, Upgrades, making sure dependencies are all good and safe and secure. love that stuff. [00:35:29] Jeremy: That's awesome. We, we need more of you. (laughs) [00:35:31] Sara: There's plenty of us out there, but we don't get the credit (laughs) [00:35:34] Jeremy: Yeah, because it's like with maintenance, well, I would say probably both in companies and in open source when everything is working. Then Nobody nobody knows. Nobody says anything. They're just like, Oh, that's great. It's working. And then if it breaks, then everyone's upset. [00:35:51] Sara: Exactly. [00:35:53] Jeremy: And so like, yeah, you're just there to get yelled at when something goes wrong. But when everything's going good, it's like, [00:35:59] Sara: A job well done is, I was never here. [00:36:02] Jeremy: Yeah. Yeah. Yeah. I don't know how. To, you know, to fix that, I mean, when you think about open source maintainers, right, like a big thing is, is, is burnout, right? Where you are keeping the internet and all of our applications running and, you know, what you get for it is people yelling at you and the issues, right? [00:36:23] Sara: Yeah, it's hard. And I think I actually. Submitted a talk to RubyConf this year about this topic. It didn't get picked. That's okay. Um, we all make mistakes. I'm going to try to give it somewhere in the future, but I think one of the important things that we as an industry should strive for is giving glory. Giving support and kudos to maintenance work. I've been trying to do that. slash I have been doing that at ThoughtBot by, at some cadence. I have been putting out a blog post to the ThoughtBot blog called. This week in open source, the time period that is covered might be a week or longer in those posts. I give a summary of all of the commits that have been made to our open source projects. And the people that made those contributions with highlighting to new version releases, including patch level. And I do this. The time I, I, I took up the torch of doing this from a co worker, Mike Burns, who used to do it 10 years ago. I do this so that people can get acknowledgement for the work they do, even if it's fixing a broken link, even if it's updating some words that maybe don't make sense. All of it is valuable. [00:37:54] Jeremy: Definitely. Yeah. I mean, I, I think that, um, yeah, what's visible to people is when there's a new feature or an API change and Yeah, it's just, uh, people don't, I think a lot of people don't realize, like, how much work goes into just keeping everything running. [00:38:14] Sara: Mm hmm. Especially in the world of open source and Ruby on Rails, all the gems, there's so many different things coming out, things that suddenly this is not compatible. Suddenly you need to change something in your code because a dependency, however many steps apart has changed and it's hard work. The people that do those things are amazing. [00:38:41] Jeremy: So if anybody listening does that work, we, we appreciate you. [00:38:45] Sara: We salute you. Thank you. And if you're interested in contributing to ThoughtBot open source, we have lots of repos. There's one out there for you. Thoughts on RubyConf [00:38:54] Jeremy: You've been doing programming for quite a while, and, you're here at, at RubyConf. I wonder what kind of brings you to these, these conferences? Like, what do you get out of them? Um, I guess, how was this one? That sort of thing. [00:39:09] Sara: Well, first, this one was sick. This one was awesome. Uh, Ruby central pulled out all the stops and that DJ on Monday. In the event, in the exhibit hall. Wow. Amazing. So he told me that he was going to put his set up on Spotify, on Weedmaps Spotify, so go check it out. Anyway, I come to these conferences for people. I just love connecting with people. Those listening might notice that I'm an extrovert. I work remotely. A lot of us work remotely these days. this is an opportunity to see some of my coworkers. There's seven of us here. It's an opportunity to see people I only see at conferences, of which there are a lot. It's a chance to connect with people I've only met on Mastodon, or LinkedIn, or Stack Overflow. It's a chance to meet wonderful podcasters who are putting out great content, keeping our community alive. That's, that's the key for me. And the talks are wonderful, but honestly, they're just a side effect for me. They just come as a result of being here. [00:40:16] Jeremy: Yeah, it's kind of a unique opportunity, you know, to have so many of your, your colleagues and to just all be in the same place. And you know that anybody you talk to here, like if you talk about Ruby or software, they're not going to look at you and go like, I don't know what you're talking about. Like everybody here has at least that in common. So it's, yeah, it's a really cool experience to, to be able to chat with anybody. And it's like, You're all on the same page, [00:40:42] Sara: Mm hmm. We're all in this boat together. [00:40:45] Jeremy: Yup, that we got to keep, got to keep afloat according to matz [00:40:49] Sara: Gotta keep it afloat, yeah. [00:40:51] Jeremy: Though I was like, I was pretty impressed by like during his, his keynote and he had asked, you know, how many of you here, it's your first RubyConf and it felt like it was over half the room. [00:41:04] Sara: Yeah, I got the same sense. I was very glad to see that, very impressed. My first RubyConf was and it was the same sort of showing of [00:41:14] Jeremy: Nice, yeah. Yeah, actually, that was my first one, too. [00:41:17] Sara: Nice! [00:41:19] Jeremy: Uh, that was Nashville, Yeah, yeah, yeah. So it's, yeah, it's really interesting to see because, the meme online is probably like, Ah, Ruby is dead, or Rails is dead. But like you come to these conferences and yeah, there's, there's so many new people. There's like new people that are learning it and experiencing it and, you know, enjoying it the same way we are. So I, I really hope that the, the community can really, yeah, keep this going. [00:41:49] Sara: Continue, continue to grow and share. I love that we had first timer buttons, buttons where people could self identify as this is my first RubyConf and, and then that opens a conversation immediately. It's like, how are you liking it? What was your favorite talk? [00:42:08] Jeremy: Yeah, that's awesome. okay, I think that's probably a good place to start wrapping it. But is there anything else you wanted to mention or thought we should have talked about? [00:42:18] Sara: Can I do a plug for thoughtbot? [00:42:20] Jeremy: yeah, go for it. [00:42:21] Sara: Alright. For those of you out there that might not know what ThoughtBot does, we are a full software lifecycle or company lifecycle consultancy, so we do everything from market fit and rapid prototyping to MVPs to helping with developed companies, developed teams, maybe do a little bit of a Boost when you have a deadline or doing some tech debt. Pay down. We also have a DevOps team, so if you have an idea or a company or a team, you want a little bit of support, we have been around for 20 years. We are here for you. Reach out to us at thoughtbot.com. [00:43:02] Jeremy: I guess the thing about Thoughtbot is that, within the Ruby community specifically, they've been so involved with sponsorships and, and podcasts. And so, uh, when you hear about consultancies, a lot of times it's kind of like, well, I don't know, are they like any good? Do they know what they're doing? But I, I feel like, ThoughtBot has had enough, like enough of a public record. I feel It's like, okay, if you, if you hire them, um, you should be in good hands. [00:43:30] Sara: Yeah. If you have any questions about our abilities, read the blog. [00:43:35] Jeremy: It is a good blog. Sometimes when I'm, uh, searching for how to do something in Rails, it'll pop up, [00:43:40] Sara: Mm hmm. Me too. Every question I ask, one of the first results is our own blog. I'm like, oh yeah, that makes sense. [00:43:47] Jeremy: Probably the peak is if you've written the blog. [00:43:50] Sara: That has happened to my coworkers They're like, wait, I wrote a blog about this nine years ago. [00:43:55] Jeremy: Yeah, yeah. So maybe, maybe that'll happen to you soon. I, I know definitely people who do, um, Stack Overflow. And it's like, Oh, I like, this is a good answer. Oh, I wrote this. (laughs) yeah. Well, Sara, thank you so much for, for chatting with me today. [00:44:13] Sara: Absolutely, Jeremy. Thank you so much for having me. I was really glad to chat today.

Today we bring you our conversation with the incredible Haley Mae Campbell live from Off the Rails in Worcester. We talk about life, her music and her Irish heritage! Check it out now!

David was the chief software architect and director of engineering at Stitch Fix. He's also the author of a number of books including Sustainable Web Development with Ruby on Rails and most recently Ruby on Rails Background Jobs with Sidekiq. He talks about how he made decisions while working with a medium sized team (~200 developers) at Stitch Fix. The audio quality for the first 19 minutes is not great but the correct microphones turn on right after that. Recorded at RubyConf 2023 in San Diego. A few topics covered: Ruby's origins at Stitch Fix Thoughts on Go Choosing technology and cloud services Moving off heroku Building a platform team Where Ruby and Rails fit in today The role of books and how different people learn Large Language Model's effects on technical content Related Links David's Blog Mastodon Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today. I want to share another conversation from RubyConf San Diego. This time it's with David Copeland. He was a chief software architect and director of engineering at stitch fix. And at the start of the conversation, you're going to hear about why he decided to write the book, sustainable web development with Ruby on rails. Unfortunately, you're also going to notice the sound quality isn't too good. We had some technical difficulties. But once you hit the 20 minute mark of the recording, the mics are going to kick in. It's going to sound way better. So I hope you stick with it. Enjoy. Ruby at Stitch Fix [00:00:35] David: Stitch Fix was a Rails shop. I had done a lot of Rails and learned a lot of things that worked and didn't work, at least in that situation. And so I started writing them down and I was like, I should probably make this more than just a document that I keep, you know, privately on my computer. Uh, so that's, you know, kind of, kind of where the genesis of that came from and just tried to, write everything down that I thought what worked, what didn't work. Uh, if you're in a situation like me. Working on a product, with a medium sized, uh, team, then I think the lessons in there will be useful, at least some of them. Um, and I've been trying to keep it up over, over the years. I think the first version came out a couple years ago, so I've been trying to make sure it's always up to date with the latest stuff and, and Rails and based on my experience and all that. [00:01:20] Jeremy: So it's interesting that you mention, medium sized team because, during the, the keynote, just a few moments ago, Matz the creator of Ruby was talking about how like, Oh, Rails is really suitable for this, this one person team, right? Small, small team. And, uh, he was like, you're not Google. So like, don't worry about, right. Can you scale to that level? Yeah. Um, and, and I wonder like when you talk about medium size or medium scale, like what are, what are we talking? [00:01:49] David: I think probably under 200 developers, I would say. because when I left Stitch Fix, it was closing in on that number of developers. And so it becomes, you know, hard to... You can kind of know who everybody is, or at least the names sound familiar of everybody. But beyond that, it's just, it's just really hard. But a lot of it was like, I don't have experience at like a thousand developer company. I have no idea what that's like, but I definitely know that Rails can work for like... 200 ish people how you can make it work basically. yeah. [00:02:21] Jeremy: The decision to use Rails, I'm assuming that was made before you joined? [00:02:26] David: Yeah, the, um, the CTO of Stitch Fix, he had come in to clean up a mess made by contractors, as often happens. They had used Django, which is like the Python version of Rails. And he, the CTO, he was more familiar with Rails. So the first two developers he hired, also familiar with Rails. There wasn't a lot to maintain with the Django app, so they were like, let's just start fresh, fresh with Rails. yeah, but it's funny because a lot of the code in that Rails app was, like, transliterated from Python. So you could, it would, it looked like the strangest Ruby code in the world because it was basically, there was no test. So they were like, let's just write the Ruby version of this Python just so we know it works. but obviously that didn't, didn't last forever, so. [00:03:07] Jeremy: So, so what's an example of a, of a tell? Where you're looking at the code and you're like, oh, this is clearly, it came from Python. [00:03:15] David: You'd see like, very, very explicit, right? Like Python, there's a lot of like single line things. very like, this sounds like a dig, but it's very simple looking code. Like, like I don't know Python, but I was able to change this Django app. And I had to, I could look at it and you can figure out immediately how it works. Cause there's. Not much to it. There's nothing fancy. So, like, this, this Ruby code, there was nothing fancy. You'd be like, well, maybe they should have memoized that, or maybe they should have taken that into another class, or you could have done this with a hash or something like that. So there was, like, none of that. It was just, like, really basic, plain code like you would see in any beginning programming language kind of thing. Which is at least nice. You can understand it. but you probably wouldn't have written it that way at first in Ruby. Thoughts on Go [00:04:05] Jeremy: Yeah, that's, that's interesting because, uh, people sometimes talk about the Go programming language and how it looks, I don't know if simple is the right word, but it's something where you look at the code and even if you don't necessarily understand Go, it's relatively straightforward. Yeah. I wonder what your thoughts are on that being a strength versus that being, like, [00:04:25] David: Yeah, so at Stitch Fix at one point we had a pro, we were moving off of Heroku and we were going to, basically build a deployment platform using ECS on AWS. And so the deployment platform was a Rails app and we built a command line tool using Ruby. And it was fine, but it was a very complicated command line tool and it was very slow. And so one of the developers was like, I'm going to rewrite it in Go. I was like, ugh, you know, because I just was not a big fan. So he rewrote it in Go. It was a bazillion times faster. And then I was like, okay, I'm going to add, I'll add a feature to it. It was extremely easy. Like, it's just like what you said. I looked at it, like, I don't know anything about Go. I know what is happening here. I can copy and paste this and change things and make it work for what I want to do. And it did work. And it was, it was pretty easy. so there's that, I mean, aesthetically it's pretty ugly and it's, I, I. I can't really defend that as a real reason to not use it, but it is kind of gross. I did do Go, I did a small project in Go after Stitch Fix, and there's this vibe in Go about like, don't create abstractions. I don't know where I got that from, but every Go I look at, I'm like we should make an abstraction for this, but it's just not the vibe. They just don't like doing that. They like it all written out. And I see the value because you can look at the code and know what it does and you don't have to chase abstractions anywhere. But. I felt like I was copying and pasting a lot of, a lot of things. Um, so I don't know. I mean, the, the team at Stitch Fix that did this like command line app in go, they're the platform team. And so their job isn't to write like web apps all day, every day. There's kind of in and out of all kinds of things. They have to try to figure out something that they don't understand quickly to debug a problem. And so I can see the value of something like go if that's your job, right? You want to go in and see what the issue is. Figure it out and be done and you're not going to necessarily develop deep expertise and whatever that thing is that you're kind of jumping into. Day to day though, I don't know. I think it would make me kind of sad. (laughs) [00:06:18] Jeremy: So, so when you say it would make you kind of sad, I mean, what, what about it? Is it, I mean, you mentioned that there's a lot of copy and pasting, so maybe there's code duplication, but are there specific things where you're like, oh, I just don't? [00:06:31] David: Yeah, so I had done a lot of Java in my past life and it felt very much like that. Where like, like the Go library for making an HTTP call for like, I want to call some web service. It's got every feature you could ever want. Everything is tweakable. You can really, you can see why it's designed that way. To dial in some performance issue or solve some really esoteric thing. It's there. But the problem is if you just want to get an JSON, it's just like huge production. And I felt like that's all I really want to do and it's just not making it very easy. And it just felt very, very cumbersome. I think that having to declare types also is a little bit of a weird mindset because, I mean, I like to make types in Ruby, I like to make classes, but I also like to just use hashes and stuff to figure it out. And then maybe I'll make a class if I figure it out, but Go, you can't. You have to have a class, you have to have a type, you have to think all that ahead of time, and it just, I'm not used to working that way, so it felt, I mean, I guess I could get used to it, but I just didn't warm up to that sort of style of working, so it just felt like I was just kind of fighting with the vibe of the language, kind of. Yeah, [00:07:40] Jeremy: so it's more of the vibe or the feel where you're writing it and you're like this seems a little too... Explicit. I feel like I have to be too verbose. It just doesn't feel natural for me to write this. [00:07:53] David: Right, it's not optimized for what in my mind is the obvious case. And maybe that's not the obvious case for the people that write Go programs. But for me, like, I just want to like get this endpoint and get the JSON back as a map. Not any easier than any other case, right? Whereas like in Ruby, right? And you can, I think if you include net HTTP, you can just type get. And it will just return whatever that is. Like, that's amazing. It's optimized for what I think is a very common use case. So it makes me feel really productive. It makes me feel pretty good. And if that doesn't work out long term, I can always use something more complicated. But I'm not required to dig into the NetHttp library just to do what in my mind is something very simple. [00:08:37] Jeremy: Yeah, I think that's something I've noticed myself in working with Ruby. I mean, you have the standard library that's very... Comprehensive and the API surface is such that, like you said there, when you're trying to do common tasks, a lot of times they have a call you make and it kind of does the thing you expected or hoped for. [00:08:56] David: Yeah, yeah. It's kind of, I mean, it's that whole optimized for programmer happiness thing. Like it does. That is the vibe of Ruby and it seems like that is still the way things are. And, you know, I, I suppose if I had a different mindset, I mean, because I work with developers who did not like using Ruby or Rails. They loved using Go or Java. And I, I guess there's probably some psychological analysis we could do about their background and history and mindset that makes that make sense. But, to me, I don't know. It's, it's nice when it's pleasant. And Ruby seems pleasant. (laughs) Choosing Technology [00:09:27] Jeremy: as a... Software Architect, or as a CTO, when, when you're choosing technology, what are some of the things you look at in terms of, you know? [00:09:38] David: Yeah, I mean, I think, like, it's a weird criteria, but I think what is something that the team is capable of executing with? Because, like, most, right, most programming languages all kind of do the same thing. Like, you can kind of get most stuff done in most common popular programming languages. So, it's probably not... It's not true that if you pick the wrong language, you can't build the app. Like, that's probably not really the case. At least for like a web app or something. so it's more like, what is the team that's here to do it? What are they comfortable and capable of doing? I worked on a project with... It was a mix of like junior engineers who knew JavaScript, and then some senior engineers from Google. And for whatever reason someone had chosen a Rails app and none of them were comfortable or really yet competent with doing Ruby on Rails and they just all hated it and like it didn't work very well. Um, and so even though, yes, Rails is a good choice for doing stuff for that team at that moment. Not a good choice. Right. So I think you have to go in and like, what, what are we going to be able to execute on so that when the business wants us to do something, we just do it. And we don't complain and we don't say, Oh, well we can't because this technology that we chose, blah, blah, blah. Like you don't ever want to say that if possible. So I think that's. That's kind of the, the top thing. I think second would be how widely supported is it? Like you don't want to be the cutting edge user that's finding all the bugs in something really. Like you want to use something that's stable. Postgres, MySQL, like those work, those are fine. The bugs have been sorted out for most common use cases. Some super fancy edge database, I don't know if I'd want to be doing, doing that you know? Choosing cloud services [00:11:15] Jeremy: How do you feel about the cloud specific services and databases? Like are you comfortable saying like, oh, I'm going to use... Google Cloud, BigQuery. Yeah. [00:11:27] David: That sort of thing. I think it would kind of fall under the same criteria that I was just, just saying like, so with AWS it's interesting 'cause when we moved from Heroku to AWS by EC2 RDS, their database thing, uh, S3, those have been around for years, probably those are gonna work, but they always introduce new things. Like we, we use RabbitMQ and AWS came out with. Some, I forget what it was, it was a queuing service similar to Rabbit. We were like, Oh, maybe we should switch to that. But it was clear that they weren't really ready to support it. So. Yeah, so we didn't, we didn't switch to that. So I, you gotta try to read the tea leaves of the provider to see are they committed to, to supporting this thing or is this there to get some enterprise client to move into the cloud. And then the idea is to move off of that transitional thing into what they do support. And it's hard to get a clear answer from them too. So it takes a little bit of research to figure out, Are they going to support this or not? Because that's what you don't want. To move everything into some very proprietary cloud system and have them sunset it and say, Oh yeah, now you've got to switch again. Uh, that kind of sucks. So, it's a little trickier. [00:12:41] Jeremy: And what kind of questions or research do you do? Is it purely a function of this thing has existed for X number of years so I feel okay? [00:12:52] David: I mean, it's kind of similar to looking at like some gem you're going to add to your project, right? So you'll, you'll look at how often does it change? Is it being updated? Uh, what is the documentation? Does it look like someone really cared about the documentation? Does the documentation look updated? Are there issues with it that are being addressed or, or not? Um, so those are good signals. I think, talking to other practitioners too can be good. Like if you've got someone who's experienced. You can say, hey, do you know anybody back channeling through, like, everybody knows somebody that works at AWS, you can probably try to get something there. at Stitch Fix, we had an enterprise support contract, and so your account manager will sometimes give you good information if you ask. Again, it's a, they're not going to come out and say, don't use this product that we have, but they might communicate that in a subtle way. So you have to triangulate from all these sources to try to. to try to figure out what, what you want to do. [00:13:50] Jeremy: Yeah, it kind of makes me wish that there was a, a site like, maybe not quite like, can I use, right? Can I use, you can see like, oh, can I use this in my browser? Is there, uh, like an AWS or a Google Cloud? Can I trust this? Can I trust this? Yeah. Is this, is this solid or not? [00:14:04] David: Right, totally. It's like, there's that, that site where you, it has all the Apple products and it says whether or not you should buy it because one may or may not be coming out or they may be getting rid of it. Like, yeah, that would... For cloud services, that would be, that would be nice. [00:14:16] Jeremy: Yeah, yeah. That's like the Mac Buyer's Guide. And then we, we need the, uh, the technology. Yeah. Maybe not buyers. Cloud Provider Buyer's Guide, yeah. I guess we are buyers. [00:14:25] David: Yeah, yeah, totally, totally. [00:14:27] Jeremy: it's interesting that you, you mentioned how you want to see that, okay, this thing is mature. I think it's going to stick around because, I, interviewed, someone who worked on, I believe it was the CloudWatch team. Okay. Daniel Vassalo, yeah. so he left AWS, uh, after I think about 10 years, and then he wrote a book called, uh, The Good Parts of AWS. Oh! And, if you read his book, most of the services he says to use are the ones that are, like, old. Yeah. He's, he's basically saying, like, S3, you know you're good. Yeah. Right? but then all these, if you look at the AWS webpage, they have who knows, I don't know how many hundreds of services. Yeah. He's, he's kind of like I worked there and I would not use, you know, all these new services. 'cause I myself, I don't trust [00:15:14] David: it yet. Right. And so, and they're working there? Yeah, they're working there. Yeah. No. One of the VPs at Stitch Fix had worked on Google Cloud and so when we were doing this transition from Heroku, he was like, we are not using Google Cloud. I was like, really? He's like AWS is far ahead of the game. Do not use Google Cloud. I was like, all right, I don't need any more info. You work there. You said don't. I'm gonna believe you. So [00:15:36] Jeremy: what, what was his did he have like a core point? [00:15:39] David: Um, so he never really had anything bad to say about Google per se. Like I think he enjoyed his time there and I think he thought highly of who he worked with and what he worked on and that sort of thing. But his, where he was coming from was like AWS was so far ahead. of Google on anything that we would use, he was like, there's, there's really no advantage to, to doing it. AWS is a known quantity, right? it's probably still the case. It's like, you know, you've heard the nobody ever got fired for using IBM or using Microsoft or whatever the thing is. Like, I think that's, that was kind of the vibe. And he was like, moving all of our infrastructure right before we're going to go public. This is a serious business. We should just use something that we know will work. And he was like, I know this will work. I'm not confident about. Google, uh, for our use case. So we shouldn't, we shouldn't risk it. So I was like, okay, I trust you because I didn't know anything about any of that stuff at the time. I knew Heroku and that was it. So, yeah. [00:16:34] Jeremy: I don't know if it's good or bad, but like you said, AWS seems to be the default choice. Yeah. And I mean, there's people who use Azure. I assume it's mostly primarily Microsoft. Yeah. And then there's Google Cloud. It's not really clear why you would pick it, unless there was a specific service or something that only they had. [00:16:55] David: Yeah, yeah. Or you're invested in Google, you know, you want to keep everything there. I mean, I don't know. I haven't really been at that level to make that kind of decision, and I would probably choose AWS for the reasons discussed, but, yeah. Moving off Heroku [00:17:10] Jeremy: And then, so at Stitch Fix, you said you moved off of Heroku [00:17:16] David: yeah. Yeah, so we were heavy into Heroku. I think that we were told that at one point we had the biggest Heroku Postgres database on their platform. Not a good place to be, right? You never want to be the biggest customer person, usually. but the problem we were facing was essentially we were going to go public. And to do that, you're under all the scrutiny. about many things, including the IT systems and the security around there. So, like, by default, a Postgres, a Heroku Postgres database is, like, on the internet. It's only secured by the password. all their services are on the internet. So, not, not ideal. they were developing their private cloud service at that time. And so that would have given us, in theory, on paper, it would have solved all of our problems. And we liked Heroku and we liked the developer experience. It was great. but... Heroku private spaces, it was still early. There's a lot of limitations that when they explained why those limitations, they were reasonable. And if we had. started from scratch on Heroku Private Spaces. It probably would have worked great, but we hadn't. So we just couldn't make it work. So we were like, okay, we're going to have to move to AWS so that everything can be basically off the internet. Like our public website needs to be on the internet and that's kind of it. So we need to, so that's basically was the, was the impetus for that. but it's too bad because I love Heroku. It was great. I mean, they were, they were a great partner. They were great. I think if Stitch Fix had started life a year later, Private Spaces. Now it's, it's, it's way different than it was then. Cause it's been, it's a mature product now, so we could have easily done that, but you know, the timing didn't work out, unfortunately. [00:18:50] Jeremy: And that was a compliance thing to, [00:18:53] David: Yeah. And compliance is weird cause they don't tell you what to do, but they give you some parameters that you need to meet. And so one of them is like how you control access. So, so going public, the compliance is around the financial data and. Ensuring that the financial data is accurate. So a lot of the systems at Stichfix were storing the financial data. We, you know, the warehouse management system was custom made. Uh, all the credit card processing was all done, like it was all in some databases that we had running in Heroku. And so those needed to be subject to stricter security than we could achieve with just a single password that we just had to remember to rotate when someone like left the team. So that was, you know, the kind of, the kind of impetus for, for all of that. [00:19:35] Jeremy: when you were using Heroku, Salesforce would have already owned it then. Did you, did you get any sense that you weren't really sure about the future of the platform while you're on it or, [00:19:45] David: At that time, no, it seemed like they were still innovating. So like, Heroku has a Redis product now. They didn't at the time we wish that they did. They told us they're working on it, but it wasn't ready. We didn't like using the third parties. Kafka was not a thing. We very much were interested in that. We would have totally used it if it was there. So they were still. Like doing bigger innovations then, then it seems like they are now. I don't know. It's weird. Like they're still there. They still make money, I assume for Salesforce. So it doesn't feel like they're going away, but they're not innovating at the pace that they were kind of back in the day. [00:20:20] Jeremy: it used to feel like when somebody's asking, I want to host a Rails app. Then you would say like, well, use Heroku because it's basically the easiest to get started. It's a known quantity and it's, it's expensive, but, it seemed for, for most people, it was worth it. and then now if I talk to people, it's like. Not what people suggest anymore. [00:20:40] David: Yeah, because there's, there's actual competitors. It's crazy to me that there was no competitors for years, and now there's like, Render and Fly. io seem to be the two popular alternatives. Um, I doubt they're any cheaper, honestly, but... You get a sense, right, that they're still innovating, still building those platforms, and they can build with, you know, all of the knowledge of what has come before them, and do things differently that might, that might help. So, I still use Heroku for personal things just because I know it, and I, you know, sometimes you don't feel like learning a new thing when you just want to get something done, but, yeah, I, I don't know if we were starting again, I don't know, maybe I'd look into those things. They, they seem like they're getting pretty mature and. Heroku's resting on its laurels, still. [00:21:26] Jeremy: I guess I never quite the mindset, right? Where you You have a platform that's doing really well and people really like it and you acquire it and then it just It seems like you would want to keep it rolling, right? (laughs) [00:21:38] David: Yeah, it's, it is wild, I mean, I guess... Why did you, what was Salesforce thinking they were going to get? Uh, who knows maybe the person at Salesforce that really wanted to purchase it isn't there. And so no one at Salesforce cares about it. I mean, there's all these weird company politics that like, who knows what's going on and you could speculate. all day. What's interesting is like, there's definitely some people in the Ruby community who work there and still are working there. And that's like a little bit of a canary for me. I'm like, all right, well, if that person's still working there, that person seems like they're on the level and, and, and, and seems pretty good. They're still working there. It, it's gotta be still a cool place to be or still doing something, something good. But, yeah, I don't know. I would, I would love to know what was going on in all the Salesforce meetings about acquiring that, how to manage it. What are their plans for it? I would love to know that stuff. [00:22:29] Jeremy: maybe you had some experience with this at Stitch Fix But I've heard with Heroku some of their support staff at least in the past they would, to some extent, actually help you troubleshoot, like, what's going on with your app. Like, if your app is, like, using a whole bunch of memory, and you're out of memory, um, they would actually kind of look into that, for you, which is interesting, because it's like, that's almost like a services thing than it is just a platform. [00:22:50] David: Yeah. I mean, they, their support, you would get, you would get escalated to like an engineer sometimes, like who worked on that stuff and they would help figure out what the problem was. Like you got the sense that everybody there really wanted the platform to be good and that they were all sort of motivated to make sure that everybody. You know, did well and used the platform. And they also were good at, like a thing that trips everybody up about Heroku is that your app restarts every day. And if you don't know anything about anything, you might think that is stupid. Why, why would I want that? That's annoying. And I definitely went through that and I complained to them a lot. And I'm like, if you only could not restart. And they very patiently and politely explained to me why that it needed to do that, they weren't going to remove that, and how to think about my app given that reality, right? Which is great because like, what company does that, right? From the engineers that are working on it, like No, nobody does that. So, yeah, no, I haven't escalated anything to support at Heroku in quite some time, so I don't know if it's still like that. I hope it is, but I'm not really, not really sure. Building a platform team [00:23:55] Jeremy: Yeah, that, uh, that reminds me a little bit of, I think it's Rackspace? There's, there's, like, another hosting provider that was pretty popular before, and they... Used to be famous for that type of support, where like your, your app's having issues and somebody's actually, uh, SSHing into your box and trying to figure out like, okay, what's going on? which if, if that's happening, then I, I can totally see where the, the price is justified. But if the support is kind of like dropping off to where it's just, they don't do that kind of thing, then yeah, I can see why it's not so much of a, yeah, [00:24:27] David: We used to think of Heroku as like they were the platform team before we had our own platform team and they, they acted like it, which was great. [00:24:35] Jeremy: Yeah, I don't have, um, experience with, render, but I, I, I did, talk to someone from there, and it does seem like they're, they're trying to fill that role, um, so, yeah, hopefully, they and, and other companies, I guess like Vercel and things like that, um, they're, they're all trying to fill that space, [00:24:55] David: Yeah, cause, cause building our own internal platform, I mean it was the right thing to do, but it's, it's a, you can't just, you have to have a team on it, it's complicated, getting all the stuff in AWS to work the way you want it to work, to have it be kind of like Heroku, like it's not trivial. if I'm a one person company, I don't want to be messing around with that particularly. I want to just have it, you know, push it up and have it go and I'm willing to pay for that. So it seems logical that there would be competitors in that space. I'm glad there are. Hopefully that'll light a fire under, under everybody. [00:25:26] Jeremy: so in your case, it sounds like you moved to having your own platform team and stuff like that, uh, partly because of the compliance thing where you're like, we need our, we need to be isolated from the internet. We're going to go to AWS. If you didn't have that requirement, do you still think like that would have been the time to, to have your own platform team and manage that all yourself? [00:25:46] David: I don't know. We, we were thinking an issue that we were running into when we got bigger, um, was that, I mean, Heroku, it, It's obviously not as flexible as AWS, but it is still very flexible. And so we had a lot of internal documentation about this is how you use Heroku to do X, Y, and Z. This is how you set up a Stitch Fix app for Heroku. Like there was just the way that we wanted it to be used to sort of. Just make it all manageable. And so we were considering having a team spun up to sort of add some tooling around that to sort of make that a little bit easier for everybody. So I think there may have been something around there. I don't know if it would have been called a platform team. Maybe we call, we thought about calling it like developer happiness or because you got developer experience or something. We, we probably would have had something there, but. I do wonder how easy it would have been to fund that team with developers if we hadn't had these sort of business constraints around there. yeah, um, I don't know. You get to a certain size, you need some kind of manageability and consistency no matter what you're using underneath. So you've got to have, somebody has to own it to make sure that it's, that it's happening. [00:26:50] Jeremy: So even at your, your architect level, you still think it would have been a challenge to, to. Come to the executive team and go like, I need funding to build this team. [00:27:00] David: You know, certainly it's a challenge because everybody, you know, right? Nobody wants to put developers in anything, right? There are, there are a commodity and I mean, that is kind of the job of like, you know, the staff engineer or the architect at a company is you don't have, you don't have the power to put anybody on anything you, you have the power to Schedule a meeting with a VP or the CTO and they will listen to you. And that's basically, you've got to use that power to convince them of what you want done. And they're all reasonable people, but they're balancing 20 other priorities. So it would, I would have had to, it would have been a harder case to make that, Hey, I want to take three engineers. And have them write tooling to make Heroku easier to use. What? Heroku is not easy to use. Why aren't, you know, so you really, I would, it would be a little bit more of a stretch to walk them through it. I think a case could be made, but, definitely would take some more, more convincing than, than what was needed in our case. [00:27:53] Jeremy: Yeah. And I guess if you're able to contrast that with, you were saying, Oh, I need three people to help me make Heroku easier. Your actual platform team on AWS, I imagine was much larger, right? [00:28:03] David: Initially it was, there was, it was three people did the initial move over. And so by the time we went public, we'd been on this new system for, I don't know, six to nine months. I can't remember exactly. And so at that time the platform team was four or five people, and I, I mean, so percentage wise, right, the engineering team was maybe almost 200, 150, 200. So percentage wise, maybe a little small, I don't know. but it kind of gets back to the power of like the rails and the one person framework. Like everything we did was very much the same And so the Rails app that managed the deployment was very simple. The, the command line app, even the Go one with all of its verbosity was very, very simple. so it was pretty easy for that small team to manage. but, Yeah, so it was sort of like for redundancy, we probably needed more than three or four people because you know, somebody goes out sick or takes a vacation. That's a significant part of the team. But in terms of like just managing the complexity and building it and maintaining it, like it worked pretty well with, you know, four or five people. Where Rails fits in vs other technology [00:29:09] Jeremy: So during the Keynote today, they were talking about how companies like GitHub and Shopify and so on, they're, they're using Rails and they're, they're successful and they're fairly large. but I think the thing that was sort of unsaid was the fact that. These companies, while they use Rails, they use a lot of other, technology as well. And, and, and kind of increasing amounts as well. So, I wonder from your perspective, either from your experience at StitchFix or maybe going forward, what is the role that, that Ruby and Rails plays? Like, where does it make sense for that to be used versus like, Okay, we need to go and build something in Java or, you know, or Go, that sort of thing? [00:29:51] David: right. I mean, I think for like your standard database backed web app, it's obviously great. especially if your sort of mindset bought into server side rendering, it's going to be great at that. so like internal tools, like the customer service dashboard or... You know, something for like somebody who works at a company to use. Like, it's really great because you can go super fast. You're not going to be under a lot of performance constraints. So you kind of don't even have to think about it. Don't even have to solve it. You can, but you don't have to, where it wouldn't work, I guess, you know, if you have really strict performance. Requirements, you know, like a, a Go version of some API server is going to use like percentages of what, of what Rails would use. If that's meaningful, if what you're spending on memory or compute is, is meaningful, then, then yeah. That, that becomes worthy of consideration. I guess if you're, you know, if you're making a mobile app, you probably need to make a mobile app and use those platforms. I mean, I guess you can wrap a Rails app sort of, but you're still making, you still need to make a mobile app, that does something. yeah. And then, you know, interestingly, the data science part of Stitch Fix was not part of the engineering team. They were kind of a separate org. I think Ruby and Rails was probably the only thing they didn't use over there. Like all the ML stuff, everything is either Java or Scala or Python. They use all that stuff. And so, yeah, if you want to do AI and ML with Ruby, you, it's, it's hard cause there's just not a lot there. You really probably should use Python. It'll make your life easier. so yeah, those would be some of the considerations, I guess. [00:31:31] Jeremy: Yeah, so I guess in the case of, ML, Python, certainly, just because of the, the ecosystem, for maybe making a command line application, maybe Go, um, Go or Rust, perhaps, [00:31:44] David: Right. Cause you just get a single binary. Like the problem, I mean, I wrote this book on Ruby command line apps and the biggest problem is like, how do I get the Ruby VM to be anywhere so that it can then run my like awesome scripts? Like that's kind of a huge pain. (laughs) So [00:31:59] Jeremy: and then you said, like, if it's Very performance sensitive, which I am kind of curious in, in your experience with the companies you've worked at, when you're taking on a project like that, do you know up front where you're like, Oh, the CPU and memory usage is going to be a problem, or is it's like you build it and you're like, Oh, this isn't working. So now I know. [00:32:18] David: yeah, I mean, I, I don't have a ton of great experience there at Stitch Fix. The biggest expense the company had was the inventory. So like the, the cost of AWS was just de minimis compared to all that. So nobody ever came and said, Hey, you've got to like really save costs on, on that stuff. Cause it just didn't really matter. at the, the mental health startup I was at, it was too early. But again, the labor costs were just far, far exceeded the amount of money I was spending on, on, um, you know, compute and infrastructure and stuff like that. So, Not knowing anything, I would probably just sort of wait and see if it's a problem. But I suppose you always take into account, like, what am I actually building? And like, what does this business have to scale to, to make it worthwhile? And therefore you can kind of do a little bit of planning ahead there. But, I dunno, I think it would kind of have to depend. [00:33:07] Jeremy: There's a sort of, I guess you could call it a meme, where people say like, Oh, it's, it's not, it's not Rails that's slow, it's the, the database that's slow. And, uh, I wonder, is that, is that accurate in your experience, or, [00:33:20] David: I mean, most of the stuff that we had that was slow was the database, because like, it's really easy to write a crappy query in Rails if you're not, if you're not careful, and then it's really easy to design a database that doesn't have any indexes if you're not careful. Like, you, you kind of need to know that, But of course, those are easy to fix too, because you just add the index, especially if it's before the database gets too big where we're adding indexes is problematic. But, I think those are just easy performance mistakes to make. Uh, especially with Rails because you're not, I mean, a lot of the Rails developers at Citrix did not know SQL at all. I mean, they had to learn it eventually, but they didn't know it at all. So they're not even knowing that what they're writing could possibly be problematic. It's just, you're writing it the Rails way and it just kind of works. And at a small scale, it does. And it doesn't matter until, until one day it does. [00:34:06] Jeremy: And then in, in the context of, let's say, using ActiveRecord and instantiating the objects, or, uh, the time it takes to render templates, that kinds of things, to, at least in your experience, that wasn't such of an issue. [00:34:20] David: No, and it was always, I mean, whenever we looked at why something was slow, it was always the database and like, you know, you're iterating over some active records and then, and then, you know, you're going into there and you're just following this object graph. I've got a lot of the, a lot of the software at Stitch Fix was like internal stuff and it was visualizing complicated data out of the database. And so if you didn't think about it, you would just start dereferencing and following those relationships and you have this just massive view and like the HTML is fine. It's just that to render this div, you're. Digging into some active record super deep. and so, you know, that was usually the, the, the problems that we would see and they're usually easy enough to fix by making an index or. Sometimes you do some caching or something like that. and that solved most of the, most of the issues [00:35:09] Jeremy: The different ways people learn [00:35:09] Jeremy: so you're also the author of the book, Sustainable Web Development with Ruby on Rails. And when you talk to people about like how they learn things, a lot of them are going on YouTube, they're going on, uh, you know, looking for blogs and things like that. And so as an author, what do you think the role is of, of books now? Yeah, [00:35:29] David: I have thought about this a lot, because I, when I first got started, I'm pretty old, so books were all you had, really. Um, so they seem very normal and natural to me, but... does someone want to sit down and read a 400 page technical book? I don't know. so Dave Thomas who runs Pragmatic Bookshelf, he was on a podcast and was asked the same question and basically his answer, which is my answer, is like a long form book is where you can really lay out your thinking, really clarify what you mean, really take the time to develop sometimes nuanced, examples or nuanced takes on something that are Pretty hard to do in a short form video or in a blog post. Because the expectation is, you know, someone sends you an hour long YouTube video, you're probably not going to watch that. Two minute YouTube video is sure, but you can't, you can't get into so much, kind of nuanced detail. And so I thought that was, was right. And that was kind of my motivation for writing. I've got some thoughts. They're too detailed. It's, it's too much set up for a blog post. There's too much of a nuanced element to like, really get across. So I need to like, write more. And that means that someone's going to have to read more to kind of get to it. But hopefully it'll be, it'll be valuable. one of the sessions that we're doing later today is Ruby content creators, where it's going to be me and Noel Rappin and Dave Thomas representing the old school dudes that write books and probably a bunch of other people that do, you know, podcasts videos. It'd be interesting to see, I really want to know how do people learn stuff? Because if no one reads books to learn things, then there's not a lot of point in doing it. But if there is value, then, you know. It should be good and should be accessible to people. So, that's why I do it. But I definitely recognize maybe I'm too old and, uh, I'm not hip with the kids or, or whatever, whatever the case is. I don't know. [00:37:20] Jeremy: it's tricky because, I think it depends on where you are in the process of learning that thing. Because, let's say, you know a fair amount about the technology already. And you look at a book, in a lot of cases it's, it's sort of like taking you from nothing to something. And so you're like, well, maybe half of this isn't relevant to me, but then if I don't read it, then I'm probably missing a lot still. And so you're in this weird in be in between zone. Another thing is that a lot of times when people are trying to learn something, they have a specific problem. And, um, I guess with, with books, it's, you kind of don't know for sure if the thing you're looking for is going to be in the book. [00:38:13] David: I mean, so my, so my book, I would not say as a beginner, it's not a book to learn how to do Rails. It's like you already kind of know Rails and you want to like learn some comprehensive practices. That's what my book is for. And so sometimes people will ask me, I don't know Rails, should I get your book? And I'm like, no, you should not. but then you have the opposite thing where like the agile web development with Rails is like the beginner version. And some people are like, Oh, it's being updated for Rails 7. Should I get it? I'm like, probably not because How to go from zero to rails hasn't changed a lot in years. There's not that much that's going to be new. but, how do you know that, right? Hopefully the Table of Contents tells you. I mean, the first book I wrote with Pragmatic, they basically were like, The Table of Contents is the only thing the reader, potential reader is going to have to have any idea what's in the book. So, You need to write the table of contents with that in mind, which may not be how you'd write the subsections of a book, but since you know that it's going to serve these dual purposes of organizing the book, but also being promotional material that people can read, you've got to keep that in mind, because otherwise, how does anybody, like you said, how does anybody know what's, what's going to be in there? And they're not cheap, I mean, these books are 50 bucks sometimes, and That's a lot of money for people in the U. S. People outside the U. S. That's a ton of money. So you want to make sure that they know what they're getting and don't feel ripped off. [00:39:33] Jeremy: Yeah, I think the other challenge is, at least what I've heard, is that... When people see a video course, for whatever reason, they, they set, like, a higher value to it. They go, like, oh, this video course is, 200 dollars and it's, like, seems like a lot of money, but for some people it's, like, okay, I can do that. But then if you say, like, oh, this, this book I've been researching for five years, uh, I want to sell it for a hundred bucks, people are going to be, like no. No way., [00:40:00] David: Yeah. Right. A hundred bucks for a book. There's no way. That's a, that's a lot. Yeah. I mean, producing video, I've thought about doing video content, but it seems so labor intensive. Um, and it's kind of like, It's sort of like a performance. Like I was mentioning before we started that I used to play in bands and like, there's a lot to go into making an even mediocre performance. And so I feel like, you know, video content is the same way. So I get that it like, it does cost more to produce, but, are you getting more information out of it? I, that, I don't know, like maybe not, but who knows? I mean, people learn things in different ways. So, [00:40:35] Jeremy: It's just like this perception thing, I think. And, uh, I'm not sure why that is. Um, [00:40:40] David: Yeah, maybe it's newer, right? Maybe books feel older so they're easier to make and video seems newer. I mean, I don't know. I would love to talk to engineers who are like... young out of college, a few years into their career to see what their perception of this stuff is. Cause I mean, there was no, I mean, like I said, I read books cause that's all there was. There was no, no videos. You, you go to a conference and you read a book and that was, that was all you had. so I get it. It seems a whole video. It's fancier. It's newer. yeah, I don't know. I would love to hear a wide variety of takes on it to see what's actually the, the future, you know? [00:41:15] Jeremy: sure, yeah. I mean, I think it probably can't just be one or the other, right? Like, I think there are... Benefits of each way. Like, if you have the book, you can read it at your own pace without having to, like, scroll through the video, and you can easily copy and paste the, the code segments, [00:41:35] David: Search it. Go back and forth. [00:41:36] Jeremy: yeah, search it. So, I think there's a place for it, but yeah, I think it would be very interesting, like you said, to, to see, like, how are people learning, [00:41:45] David: Right. Right. Yeah. Well, it's the same with blogs and podcasts. Like I, a lot of podcasters I think used to be bloggers and they realized that like they can get out what they need by doing a podcast. And it's way easier because it's more conversational. You don't have to do a bunch of research. You don't have to do a bunch of editing. As long as you're semi coherent, you can just have a conversation with somebody and sort of get at some sort of thing that you want to talk about or have an opinion about. And. So you, you, you see a lot more podcasts and a lot less blogs out there because of that. So it's, that's kind of like the creators I think are kind of driving that a little bit. yeah. So I don't know. [00:42:22] Jeremy: Yeah, I mean, I can, I can say for myself, the thing about podcasts is that it's something that I can listen to while I'm doing something else. And so you sort of passively can hopefully pick something up out of that conversation, but... Like, I think it's maybe not so good at the details, right? Like, if you're talking code, you can talk about it over voice, but can you really visualize it? Yeah, yeah, yeah. I think if you sit down and you try to implement something somebody talked about, you're gonna be like, I don't know what's happening. [00:42:51] David: Yeah. [00:42:52] Jeremy: So, uh, so, so I think there's like these, these different roles I think almost for so like maybe you know the podcast is for you to Maybe get some ideas or get some familiarity with a thing and then when you're ready to go deeper You can go look at a blog post or read a book I think video kind of straddles those two where sometimes video is good if you want to just see, the general concept of a thing, and have somebody explain it to you, maybe do some visuals. that's really good. but then it can also be kind of detailed, where, especially like the people who stream their process, right, you can see them, Oh, let's, let's build this thing together. You can ask me questions, you can see how I think. I think that can be really powerful. at the same time, like you said, it can be hard to say, like, you know, I look at some of the streams and it's like, oh, this is a three hour stream and like, well, I mean, I'm interested. I'm interested, but yeah, it's hard enough for me to sit through a, uh, a three hour movie, [00:43:52] David: Well, then that, and that gets into like, I mean, we're, you know, we're at a conference and they, they're doing something a little, like, there are conference talks at this conference, but there's also like. sort of less defined activities that aren't a conference talk. And I think that could be a reaction to some of this too. It's like I could watch a conference talk on, on video. How different is that going to be than being there in person? maybe it's not that different. Maybe, maybe I don't need to like travel across the country to go. Do something that I could see on video. So there's gotta be something here that, that, that meets that need that I can't meet any other way. So it's all these different, like, I would like to think that's how it is, right? All this media all is a part to play and it's all going to kind of continue and thrive and it's not going to be like, Oh, remember books? Like maybe, but hopefully not. Hopefully it's like, like what you're saying. Like it's all kind of serving different purposes that all kind of work together. Yeah. [00:44:43] Jeremy: I hope that's the case, because, um, I don't want to have to scroll through too many videos. [00:44:48] David: Yeah. The video's not for me. Large Language Models [00:44:50] Jeremy: I, I like, I actually do find it helpful, like, like I said, for the high level thing, or just to see someone's thought process, but it's like, if you want to know a thing, and you have a short amount of time, maybe not the best, um, of course, now you have all the large language model stuff where you like, you feed the video in like, Hey, tell, tell, tell me, uh, what this video is about and give me the code snippets and all that stuff. I don't know how well it works, but it seems [00:45:14] David: It's gotta get better. Cause you go to a support site and they're like, here's how to fix your problem, and it's a video. And I'm like, can you just tell me? But I'd never thought about asking the AI to just look at the video and tell me. So yeah, it's not bad. [00:45:25] Jeremy: I think, that's probably where we're going. So it's, uh, it's a little weird to think about, but, [00:45:29] David: yeah, yeah. I was just updating, uh, you know, like I said, I try to keep the book updated when new versions of Rails come out, so I'm getting ready to update it for Rails 7. 1 and in Amazon's, Kindle Direct Publishing as their sort of backend for where you, you know, publish like a Kindle book and stuff, and so they added a new question, was AI used in the production of this thing or not? And if you answer yes, they want you to say how much, And I don't know what they're gonna do with that exactly, but I thought it was pretty interesting, cause I would be very disappointed to pay 50 for a book that the AI wrote, right? So it's good that they're asking that? Yeah. [00:46:02] Jeremy: I think the problem Amazon is facing is where people wholesale have the AI write the book, and the person either doesn't review it at all, or maybe looks at a little, a little bit. And, I mean, the, the large language model stuff is very impressive, but If you have it generate a technical book for you, it's not going to be good. [00:46:22] David: yeah. And I guess, cause cause like Amazon, I mean, think about like Amazon scale, like they're not looking at the book at all. Like I, I can go click a button and have my book available and no person's going to look at it. they might scan it or something maybe with looking for bad words. I don't know, but there's no curation process there. So I could, yeah. I could see where they could have that, that kind of problem. And like you as the, as the buyer, you don't necessarily, if you want to book on something really esoteric, there are a lot of topics I wish there was a book on that there isn't. And as someone generally want to put it on Amazon, I could see a lot of people buying it, not realizing what they're getting and feeling ripped off when it was not good. [00:47:00] Jeremy: Yeah, I mean, I, I don't know, if it's an issue with the, the technical stuff. It probably is. But I, I know they've definitely had problems where, fiction, they have people just generating hundreds, thousands of books, submitting them all, just flooding it. [00:47:13] David: Seeing what happens. [00:47:14] Jeremy: And, um, I think that's probably... That's probably the main reason why they ask you, cause they want you to say like, uh, yeah, you said it wasn't. And so now we can remove your book. [00:47:24] David: right. Right. Yeah. Yeah. [00:47:26] Jeremy: I mean, it's, it's not quite the same, but it's similar to, I don't know what Stack Overflow's policy is now, but, when the large language model stuff started getting big, they had a lot of people answering the questions that were just. Pasting the question into the model [00:47:41] David: Which because they got it from [00:47:42] Jeremy: and then [00:47:43] David: The Got model got it from Stack Overflow. [00:47:45] Jeremy: and then pasting the answer into Stack Overflow and the person is not checking it. Right. So it's like, could be right, could not be right. Um, cause, cause to me, it's like, if, if you generate it, if you generate the answer and the answer is right, and you checked it, I'm okay with that. [00:48:00] David: Yeah. Yeah. [00:48:01] Jeremy: but if you're just like, I, I need some karma, so I'm gonna, I'm gonna answer these questions with, with this bot, I mean, then maybe [00:48:08] David: I could have done that. You're not adding anything. Yeah, yeah. [00:48:11] Jeremy: it's gonna be a weird, weird world, I think. [00:48:12] David: Yeah, no kidding. No kidding. [00:48:15] Jeremy: that's a, a good place to end it on, but is there anything else you want to mention, [00:48:19] David: No, I think we covered it all just yeah, you could find me online. I'm Davetron5000 on Ruby. social Mastodon, I occasionally post on Twitter, but not that much anymore. So Mastodon's a place to go. [00:48:31] Jeremy: David, thank you so much [00:48:32] David: All right. Well, thanks for having me.

In this episode, Jason, Chris, and Andrew welcome guest, Amanda Perino, ExecutiveDirector from the Rails Foundation. Today, they discuss their experiences at RailsWorld, touching on the importance of community enthusiasm and the benefits of in-person events. Amanda shares how the Rails Foundation coordinated Rails World andmanaged feedback, with a special mention of the EventStack team. They highlight thecustom design elements of the conference and the speaker experience. Amandaemphasizes the significance of having a strong team, and they discuss the decision tohost the next Rails World 2024 in Toronto and the potential for future rotations to diverseregions. There's also a conversation about the importance of communal spaces fornetworking at conferences, and they touch on documentation improvements and theneed for technically knowledgeable contributors.Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

We released episode one of this podcast on June 11, 2012. Now, more than a decade later, we're celebrating the 500th episode of our show. In honor of this milestone, Victoria, Will, and Chad caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. We chatted about what they're up to now, what they liked and learned from hosting the show, their time at thoughtbot, and more! Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. CHAD: And I'm your other host, Chad Pytel. We released episode one of this podcast on June 11, 2012. Now more than a decade later, were celebrating this: the 500th episode of our show. In honor of this milestone, Victoria, Will, and I caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. We chatted about what they're up to now, what they liked and learned from hosting the show and their time at thoughtbot, and more. First up: Ben Orenstein. Ben was the very first host of the show back in 2012 when he was a developer at thoughtbot. He is now the co-founder and Head of Product at Tuple, a remote pair programming tool for designers and developers. Ben, it's great to talk to you again. It's been a while since you and I talked. How have you been? BEN: I've been decent, yeah. It's fun to be back to my roots a little bit. I told some folks that I work with that I was coming back to the pod for the 500th Episode, and they were stoked. So, it's kind of a treat to get to be on these airwaves again. CHAD: What have you been up to since you left this show and thoughtbot? BEN: Well, I started a company. So, I was at thoughtbot for a while; I think it was seven years. And I eventually sort of struck out to start my own thing–had a false start or two here and there. And then, I ended up starting a company called Tuple, and we still exist today, fortunately. Tuple is a tool for doing remote pair programming. We started off on macOS and then wrote a Linux client. And we're launching a Windows client now. But it's sort of, like, screen sharing with remote control for developers who are actually writing code and want to have great, low latency remote control and who care about screen share quality and that sort of thing. I started that about five years ago with two co-founders. Today, we are a team of 11, I think it is. And it's been going well. Our timing was really great, it turned out. We launched a little bit before COVID. So, remote work turned into a lot more of a thing, and we were already in the market. So, that helped us a ton. It was quite a wild ride there for a bit. But things have calmed down a little lately, but it's still fun. I'm, like, really enjoying being a co-founder of a software company. It was what I've always sort of wanted to do. And it turns out it actually is pretty fun and pretty great. Although there are, of course, the ups and downs of business ownership. It is never quite as calm or relaxing as being an employee somewhere else. CHAD: You started Tuple instigated by...full disclosure: thoughtbot's an early customer of Tuple. We're still a customer. We use it a lot. BEN: Woo-hoo. I appreciate that. Thank you. CHAD: If I remember right, you started and were sort of instigated to create Tuple because there was a prior product that then Slack bought, and then it started to degrade. And now, it no longer exists in the same way that it did before. BEN: Yeah. So, there was this tool called Screenhero, which I actually started using -- CHAD: [inaudible 02:14] BEN: Yeah, first at thoughtbot. Some other thoughtboter introduced me to it, and we would use it for pair programming. And I was like, oh, this is nice. And then yeah, Slack kind of acqui-hired it and more or less ended up shutting the product down. And so, there was this gap in the market. And I would ask my friends, I would ask thoughtboters and other developers, like, "What are you using now that Screenhero is gone?" And no one had a good answer. And so, after a while of this thing sort of staring me in the face, I was like, we have to try to solve this need. There's clearly a hole in the market. Yeah, so we were heavily inspired by them in the early days. Hopefully, we've charted our own path now. But they were definitely...the initial seed was, you know, let's do Screenhero but try to not get bought early or something. CHAD: [laughs] How did you or did you feel like you captured a lot of the Screenhero customers and reached them in those early days? BEN: I think so. The pitch for it was sort of shockingly easy because Screenhero had kind of blazed this trail. Like, I would often just be like, "Oh, we're making a thing. Do you remember Screenhero?" And they'd go, "Oh yeah, I loved Screenhero". I'd be like, "Yeah, we're going to try to do that." And they'd be like, "Nice. Sign me up." So, it for sure helped a ton. I have no idea what percentage of customers we converted. And they were a pretty large success, so probably a small fraction, but it definitely, like, made the initial days much easier. CHAD: Yeah. And then, like you said, COVID happened. BEN: COVID happened, yeah. I think we had been around for about a year when COVID hit. So, we were getting our feet underneath us. And we were already, like, the company was already growing at a pretty good rate, and we were feeling pretty good about it. I don't think we had quite hit ramen profitable, but we were probably pretty close or, like, flirting with it. Yeah, the business, like, I don't know, tripled or quadrupled in a matter of months. We had a few big customers that, like, just told everyone to start using Tuple. So, we had, like, thousands and thousands of new users kind of immediately. So, it was a crazy time. Everything melted, of course. We hadn't quite engineered for that much scale. We had a really rough day or so as we scrambled, but fortunately, we got things under control. And then had this, like, very nice tailwind. Because we started the company assuming that remote work would grow. We assumed that there would be more remote developers every year. And, you know, it's probably maybe 5% of dev jobs are remote or maybe even less, but we expect to see this number creeping up. We don't think that trend will reverse. And so, COVID just, like, it just yanked it, you know, a decade in the future. CHAD: You haven't tripled or quadrupled your team size, have you? BEN: No. Well, I mean, I guess, I mean, we started as 3, and now we're 11, so kind of. CHAD: [laughs] Yeah, that's true. BEN: Expenses have not grown as fast as revenue, fortunately. CHAD: That's good. That's basically what I was asking [laughs]. BEN: Yeah, yeah. We're still a pretty small team, actually. We have only, like, four or five full-time engineers on the team at the moment, which is kind of wild because we are now, you know, we have three platforms to support: Linux, Windows, and Mac. It's a pretty complicated app doing, like, real-time streaming of audio, webcams, desktops, caring about OS-level intricacies. So, I think we will be hiring more people soon, although we haven't said that for a long time. We sort of have always had a bit of a hire-slow mentality to try to get the right team members and, like, feel a real pain before we hire someone into it. But we have been getting a bit more aggressive with hiring lately. VICTORIA: Well, I really appreciate Tuple. I installed it when I first started working here at thoughtbot. And we have random pairings with everyone across the company. So, I'll randomly get to meet someone halfway across the world who's working on similar projects. And I think they really enjoy that I have a tool they like working to share what they're working on. So, I want to thank you for that. And I'm curious about when you really started to scale during COVID, what were some of the technology architecture trade-offs you came across, and where did you land with it? BEN: Well, we got fairly...I don't know if it was lucky, but we...for a long time, for years, even through COVID, maybe the first four years of the company, all Tuple calls were purely peer-to-peer. And there was no server that we owned intermediating things. This was, like, kind of one of the keys of, like, not having expenses. The scale of revenue was we could have lots more calls happen. And it wouldn't cost us bandwidth or server capacity. To this day, still, for any calls with three or fewer participants, they're purely peer-to-peer. And this is nice for latency purposes because it just...we can find the most direct path to the internet between two people. It's also nice from our cost perspective because we don't need to pay to send that data. And that was hugely useful as call volume went up immensely. Didn't have to worry too much about server load and didn't have to worry too much about bandwidth costs. CHAD: Today, is there a central service that makes the initial connection for people? BEN: Yes, yeah, yeah. So, there is a signaling server. So, when you launch the app, you sign in, and you see, like, oh, which of my co-workers are online? So, there is actually a Rails app that handles that, actually, increasingly less the Rails app. We have now...I think it's a Go service that actually manages all those. I'm further and further from the code every year. Some of the technical questions might be a little bit beyond me, or I might have slightly out-of-date info. But back to the architecture question for a second, we did a pretty big refactor when we decided to go from just being a Mac client to supporting other platforms, where we split out a cross-platform real-time communication engine written in C++ so that we could use that for all of the heavy lifting, all the managing of the connections, and the tricky bandwidth estimation, and all this stuff, and use that across different platforms. And so, today, you have the cross-platform engine, and then on top of that is a, like, a less specific layer for each of the operating systems that we support. CHAD: So, you mentioned you're less and less in the code these days. So, what do you spend your time doing then? BEN: It's a mix of things. These days, it's basically mostly -- CHAD: Just cocktails on the beach, right? BEN: Cocktails, yes [laughs], cocktails on the beach, appearing on podcasts trying to sound important and impressive, yeah. Mostly product work. So, right before this, I just got off a call with some folks from The Browser Company. They are some of our first alpha users for our new Windows clients. So, I hopped on the call with them and, like, watched three of them install the product and inevitably run into some bugs. And, you know, chatted through those with the engineer that was working on it, prioritized some stuff, made some decisions about what's coming up next, and what we're going to ignore. So, mostly product work these days. For the first five years of the company, I was CEO, so I was doing kind of everything: marketing, and also hiring, and also product. About two months ago, I stepped down as CEO, and one of my other co-founders, Spencer, stepped up. And so, now my focus has narrowed to be mostly just product stuff and much less on the marketing or hiring side. VICTORIA: Yeah, you mentioned that it was a little more comfortable to be an employee than to be a founder. I don't know if you could say more about that because, certainly, a lot of engineers are smart enough and capable enough to run their own company. But what really informed your choice there, and do you regret it? [laughs] BEN: I definitely don't regret it. thoughtbot was a close second in terms of wonderful professional experiences. But running my own thing has been the most interesting professional thing I've done by a big margin. It has also been more stressful. And, Chad, I don't know if you remember, I think, like, maybe eight years ago, you tweeted something like, if you want to sleep well at night, and, like, value that, like, peace of mind, like, don't start a company or something. I have experienced that. CHAD: [laughs] BEN: A lot more, yeah, like waking up in the middle of the night worrying about things. It feels a little bit like the highs are higher; the lows are lower. Being an employee somewhere, it's like, if this company fails, I know I can go get another job, right? Like, you're a developer. You're extremely employable. But as the owner of the company, if the company fails, like, a huge chunk of your net worth is gone. Like, this thing you poured your life into is gone. It's way more stressful and traumatic to have that happen, or have that threatened to be happening, or just imagine that happening. So, overall, I have found the trade-off to be totally worth it. It's awesome to make your own decisions and chart your own path. And when it works, it can work in a way that being a salaried employee can't. So, I'm happy with those trade-offs. But I think that is a good question for people to ask themselves as they consider doing something like this is, like: is that the kind of trade-off that you want to make? Because it has significant downsides for sure. WILL: I am a big fan of Tuple also. I love it. It [inaudible 10:08] easy, especially with remote work. You hit the jackpot with COVID and remote work, so kudos for that [laughs]. Was there anything...because I know from our previous companies, about over...hopefully a lot more of the good stuff than the bad stuff. But was there anything that you learned? Because you were at thoughtbot for seven years. Was there anything that you're like, oh my gosh, I learned that, and it's helped me till this day while I'm running my company? BEN: Yeah, quite a bit, actually. I think it'd be hard to tease apart exactly which lessons, but I do...so I ran Upcase for thoughtbot and also FormKeep. So, I got a chance to kind of run a small division of the company, while still being a normal employee and, like, having not much of that risk. And I think that was a really wonderful opportunity for me to, like, practice the skills that I was interested in. Just, like, how do you market a thing? How do you design a product and have it be good? How do you prioritize user feedback? There were a ton of lessons from those days that I feel like made me better at running our company when we actually took a shot at it. So, there were, like, the specific things that I learned by the work I was doing there. But then just, like, I mean, I think I am the programmer I am today because of, like, the weekly dev discussions that happened. Like, spending so much time with Joe Ferris and, like, trying to copy as much of his brain as possible, like, really, like, imprinted on me as, like, a programmer. And also, just, like, a lot of the sort of cultural things from my time at thoughtbot of, like, you should be sharing the things you're learning. Like, writing blog posts is a great use of time. Like, doing open-source work is a great use of time. And maybe you can't directly trace how doing, like, working in public or sharing information benefits the company. It's hard to, like, attribute it from a marketing sense. But if you sort of have faith that in the large, it's going to work out, it probably will. That feels like a thoughtbot lesson to me, and I think it has served us really well; where I recorded a weekly podcast for a long time called The Art of Product. I'm recording a new podcast called Hackers Incorporated with Adam Wathan of Tailwind fame. And I don't ever think, like, hmm, how many new leads do we think we get per episode, and how many hours has that taken? What's the ROI? I just have this sort of reflex that I developed from thoughtbot time of, like, you should be putting stuff out there, or you should be giving back. You should help other people. And that will probably help your business and make it work in the long term. CHAD: That's a good lesson [laughs]. One of the other things, you know, while you were a host of Giant Robots, you were the first host. I remember, you know, encouraging you to be the first host, and I think we talked about that in one of the episodes along the way. But we also transitioned the format a little bit, especially as you started to work on products here; you know, it was more about the building of those products and following along with those. And one of the things that sort of half-jokingly defined, I think, your impact on a lot of products was pricing, experimenting with pricing, learning about pricing, increasing prices more than people were maybe comfortable doing so. How has that worked out with Tuple, pricing in particular? BEN: It's really hard to say. It's hard to know what, like, the other path would have been through the world-. We sort of decided from, like, the early days that we wanted to have, like, a fairly premium price. Like, we wanted to be the product that was really good and was, like, a little bit annoyingly expensive, but you still paid for it because it felt worth it. And I think people could debate in both directions whether we nailed that or not. We have had a price increase that we ended up rolling back. We went, like, a little too far one time and said, "You know what? I think we're a little bit over," and we reverted that. But I would say even today, we are still a fairly pricey product. I mean, I'm pretty happy with how the company has done. I can't prove to you that, like, if the price were half what it is, we would have, you know, better success or not. CHAD: I think it'd be very hard to make the argument that if it was half that, you would have double the number of customers. BEN: Yeah, that's probably not true. CHAD: Not with the customers that you have, who are companies that will pay for products that they use as much as Tuple. BEN: Yeah, I'm happy serving the kind of companies, and they end up being mostly tech companies that really value developer happiness. When their developers come to them and they say, "We don't want to pair over Zoom. We like this thing. It's better. It feels nicer to use," they say, "Okay," and they buy the tool for them. There are places where that's not the case. And they say, "We already have a thing that does screen sharing. You're not allowed to buy this." We don't invest a lot of time trying to sell to those people or convince them that they're wrong. And I'm pretty happy serving sort of the first group. CHAD: So, you've mentioned that you've still been podcasting. To be honest, I didn't realize you were starting something new. Is it live now? BEN: It is live now, yeah. CHAD: Awesome. Where can people find that? BEN: hackersincorporated.com. It's about the transition from developer to founder, which is kind of what we've been touching on here. Yeah, hopefully, the audience is developers who want to start something or have started something who are maybe a little bit further behind progression-wise. And it's kind of, like, I have some lessons, and Adam has some lessons, and, you know, we don't think that we're experts. But sometimes it's useful to just hear, like, two people's story and sort of see, like, what seemingly has worked for them. So, we've been trying to share things there. And I think people will find it useful. VICTORIA: I was going to ask you for a lesson, maybe give us a little sample about how would you advise someone who's built a product and wants to market it, and it's targeted towards developers since you mentioned that previously as well. BEN: Yeah, in a way, the question already contains a problem. It's like, oh, I built the product; now how do I market it? It's a little bit indicative of a very common failure mode for developers, which is that. They sort of assume, okay, after you make the product, you then figure out how you're going to market it. And marketing is sort of a thing you layer on later on when you realize that just, like, throwing it on Twitter or Product Hunt didn't really work. When we started building Tuple, I was out there marketing it already. So, I had two co-founders, so this is a luxury I had. My two co-founders were writing code, and I was out doing stuff. I was recording podcasts. I was tweeting about things. I was making videos. I was giving conference talks. And I was getting people to hear about our product well before it was done. In fact, I was even selling it. I was taking pre-orders for annual subscriptions to the app while it was still vaporware. So, I would say, like, you basically can't start marketing too early. If you start marketing early and no one really cares, well, then you don't really have to build it probably. I would actually even go a little further and say, like, I started marketing Tuple before we had a product available. But in reality, I started marketing Tuple seven or so years before that when I started publishing things through thoughtbot. It's like when I was traveling around giving talks about Ruby, and when I was making screencasts about Vim, and when I was running Upcase, I was, over time, building an audience. And that audience was useful for thoughtbot, and it also was useful for me so that when I left, I had something like 10,000 Twitter followers or something, a few thousand people on our mailing list. But there were a lot of developers that already sort of knew me and trusted me to make fairly good things. And so, when I said, "Hey, I've made a new thing, and it's for you," I really benefited from those years of making useful content and trying to be useful on the internet. And in the early days, we had people sign up, and they would say, "I don't even really think I'm going to use this. But I've learned so much from you over the years that I want to support you, so I'm going to pay for a subscription." VICTORIA: I like your answer because I think the same thing when people ask me, like, because I am an organizer for Women Who Code, and I know all these great people from showing up for years in person months over months. And so, then people will ask, "Oh, how do I recruit more women in my company?" I'm like, "Well, you got to start showing up [laughs] now and do that for a couple of years, and then maybe people will trust you," right? So, I really like that answer. WILL: How has your relationship with Chad continued to grow since you left? Because seven years at the company is a lot. And it seems like you're still on really, really good terms, and you're still friends. And I know that doesn't happen at every company. BEN: I mean, it was tough deciding to leave. I think, like, both of us felt pretty sad about it. That was the longest I'd ever worked anywhere, and I really enjoyed the experience. So, I think it was tough on both sides, honestly. But we haven't kept in that much touch since then. I think we've emailed a handful of times here and there. We're both sociable people, and we sort of get each other. And there's a long history there. So, I think it's just easy for us to kind of drop back into a friendly vibe is sort of how I feel about it. CHAD: Yeah. And the way I explain it to people, you know, when you're leading a company, which Ben and I both are, you put a lot of energy into that and to the people who are on that team. If you're doing things right, there's not really hard feelings when someone leaves. But you need to put in a lot of effort to keep in touch with people outside of the company and a lot of energy. And, to be honest, I don't necessarily do as good a job with that as I would like because it's a little bit higher priority to maintain relationships with them, the people who are still at thoughtbot and who are joining. BEN: What you're saying is I'm dead to you [laughter]. That's CEO, for you're dead to me. CHAD: No. It's just...no hard feelings. BEN: Totally. CHAD: I think one of the things that has been great about the show over the years is that we haven't been afraid to change the format, which I think has been important to keeping it going. So, there is sort of; in fact, the website now is organized into seasons. And I went back and re-categorized all the episodes into seasons. And when the seasons were made up of, like, sort of the format of the show or particular hosts...when we started, it was just an interview show, and it was largely technical topics. And then we started The Bike Shed, and the technical topics sort of moved over there. But it also went with your interests more under the product and business side. Then you started working on products at thoughtbot, so it started to go even more in that. And I think Chris joined you on the show, and that was sort of all about those topics. BEN: Yeah, that makes sense. I think if you don't let the hosts kind of follow their interests, they're going to probably burn out on the thing. It's not fun to force yourself, I think, to record a podcast. CHAD: Yeah. And then when you left, you know, I took over hosting and hosted by myself for a while, went back to the interview format, but then was joined by Lindsey for a little while. We experimented with a few different things: one, interviews, but then we did a whole, just under a year, where we followed along with three companies. And each month, we would have an interview episode where we talked to them, all three companies, about the same topic. And then, we also did an episode with just Lindsey and I talking about that topic and about what we learned from the startup companies that we were following along with for the year. And now we're back to interview freeform, different guests, different topics. It seems like we're going to stick with that for a little while. But, obviously, as Will and Victoria have said, like, we'll probably change it again in some way, you know, a year, two years, three years from now. VICTORIA: Yeah, and I'm definitely bringing my interest around DevOps and platform engineering, so you'll see more guests who have that focus in their background. And with that, sometimes my interview style is more; how do I ask a question that I can't read from your developer docs and that I might not understand the answer to? [laughs] That's kind of where I like to go with it. So yeah, I'm really excited about...it's probably one of my favorite parts of my job here at thoughtbot because I get to meet so many interesting people. And, hopefully, that's interesting to everyone else [laughs] and our guests, yeah. BEN: Totally. Well, I dramatically underestimated how awesome it would be to meet all kinds of cool people in the industry when I started the podcast. I didn't truly connect in my head, like, wait a second, if I have a 45-minute conversation with, like, a lot of prominent, awesome people in our field, that's going to be really interesting and useful for me. So, I think, yeah, it's nice to be in the hosting seat. VICTORIA: And it's so surprising how I'll meet someone at a conference, and I'll invite them onto the podcast. And the way it winds up is that whatever we're talking about on the show is directly relevant to what I'm working on or a problem that I have. It's been incredible. And I really appreciate you for coming back for our 500th Episode here. CHAD: Ben, thanks very much again for joining us, and congratulations on all the success with Tuple. And I wish you the best. BEN: Thank you so much. Thanks for being a continuing customer. I really appreciate it. CHAD: Next, we caught up with Chris Toomey, who had a run as co-host of the show with Ben throughout 2016. CHRIS: Hi there. Thanks for having me. So, we're talking with all of the past hosts. I know you joined the show, and you were on it with Ben. And then you moved over to The Bike Shed, right? CHRIS: Yeah. So, I had co-hosted with Ben for about six months. And then I think I was transitioning off of Upcase, and so that ended sort of the Giant Robots “let's talk about business” podcast tour for me. And then, I went back to consulting for a while. And, at some point, after Derek Prior had left, I took over as the host of The Bike Shed. So, I think there was probably, like, a year and a half, two-year gap in between the various hostings. CHAD: Are you doing any podcasting now? CHRIS: I'm not, and I miss it. It was a lot of fun. It was, I think, an ideal medium for me. I'm not as good at writing. I tend to over-edit and overthink. But when you get me on a podcast, I just start to say what's in my head, and I tend to not hate it after the fact. So [chuckles], that combination I found to be somewhat perfect for me. But yeah, lacking that in my current day-to-day. CHAD: Well, what's been taking up your time since you left? CHRIS: I had decided it was time to sort of go exploring, try and maybe join a startup, that sort of thing. I was sort of called in that direction. So, just after I left thoughtbot, I did a little bit of freelancing, but that was mostly to sort of keep the lights on and start to connect with folks and see if there might be an opportunity out there. I was able to connect with a former thoughtbot client, Sam Zimmerman, who was looking to start something as well. And so, we put our act together and formed a company called Sagewell, which was trying to build a digital financial platform for seniors, which is a whole bunch of different complicated things to try and string together. So, that was a wonderful experience. I was CTO of that organization. And I think that ran for about two and a half years. Unfortunately, Sagewell couldn't quite find the right sort of sticking point and, unfortunately, shut down a little bit earlier in this year. But that was, I would say, the lion's share of what I have done since leaving thoughtbot, really wonderful experience, got to learn a ton about all of the different aspects of building a startup. And I think somewhat pointedly learned that, like, it's messy, but I think I do like this startup world. So, since leaving Sagewell, I've now joined a company called August Health, which has a couple of ex-thoughtboters there as well. And August is post their Series A. They're a little bit further along in their journey. So, it was sort of a nice continuation of the startup experience, getting to see a company a little bit further on but still with lots of the good type of problems, lots of code to write, lots of product to build. So, excited to be joining them. And yeah, that's mostly what's taking up my time these days. CHAD: So, I know at Sagewell, you made a lot of technical architecture, team decisions. It was Rails in the backend, Svelte in the frontend, if I'm not mistaken. CHRIS: Yep, that's correct. CHAD: You know, hindsight is always 2020. Is there anything you learned along the way, or given how things ended up, that you would do differently? CHRIS: Sure. I was really happy with the tech stack that we were able to put together. Svelte was probably the most out there of the choices, I would say, but even that, it was sort of relegated to the frontend. And so, it was a little bit novel for folks coming into the codebase. Most folks had worked in React before but didn't know Svelte. They were able to pick it up pretty quickly. But Inertia.js was actually the core sort of architecture of the app, sort of connected the frontend and the backend, and really allowed us to move incredibly quickly. And I was very, very happy with that decision. We even ended up building our mobile applications, both for iOS and Android. So, we had native apps in both of the stores, but the apps were basically wrappers around the Rails application with a technology similar to Turbolinks native–if folks are familiar with that so, sort of a WebView layer but with some native interactions where you want. And so, like, we introduced a native login screen on both platforms so that we could do biometric login and that sort of thing. But at the end of the day, most of the screens in the app didn't need to be differentiated between a truly native mobile app and what like, mobile WebView would look like. So, we leaned into that. And it was incredible just how much we were able to do with that stack and how quickly we were able to move, and also how confidently we were able to move, which was really a nice thing. Having the deep integration between the backend and the frontend really allowed a very small team to get a lot done in a short time. CHAD: Does that code live on in any capacity? CHRIS: No. CHAD: Oh. How does that make you feel? [chuckles] CHRIS: It makes me feel very sad, I will say. That said, I mean, at the end of the day, code is in service of a business. And so, like, the code...there are, I think, probably a couple of things that we might be able to extract and share. There were some interesting...we did some weird stuff with the serializers and some, like, TypeScript type generation on the frontend that was somewhat novel. But at the end of the day, you know, code is in service of a business, and, unfortunately, the business is not continuing on. So, the code in the abstract is...it's more, you know, the journey that we had along the way and the friends we made and whatnot. But I think, for me, sort of the learnings of I really appreciate this architecture and will absolutely bring it to any new projects that I'm building from, you know, greenfield moving forward. VICTORIA: I'm curious what it was like to go from being a consultant to being a big player in a startup and being responsible for the business and the technology. How did that feel for you? CHRIS: I would say somewhat natural. I think the consulting experience really lent well to trying to think about not just the technical ramifications but, you know, what's the business impact? How do we structure a backlog and communicate about what features we want to build in what order? How do we, you know, scope a minimal MVP? All those sorts of things were, I think, really useful in allowing me to sort of help shape the direction of the company and be as productive of an engineering team as we could be. CHAD: A lot of the projects you worked on at thoughtbot were if not for startups, helping to launch new products. And then, a lot of the work you did at thoughtbot, too, was on Upcase, which was very much building a business. CHRIS: Yes. I definitely find myself drawn in that direction, and part of like, as I mentioned, I seem to be inclined towards this startup world. And I think it's that, like, the intersection between tech and business is sort of my sweet spot. I work with a lot of developers who are really interested in getting sort of deeper into the technical layers, or Docker and Kubernetes and orchestration. And I always find myself a little bit resistant to those. I'm like, I mean, whatever. Let's just...let's get something out there so that we can get users on it. And I am so drawn to that side, you know, you need both types of developers critically. I definitely find myself drawn to that business side a little bit more than many of the folks that I work with, and helping to bridge that gap and communicate about requirements and all those sort of things. So, definitely, the experience as a consultant really informed that and helped me have sort of a vocabulary and a comfort in those sort of conversations. WILL: How did Upcase come about? Because I know I've talked to numerous people who have gone through Upcase. I actually went through it, and I learned a ton. So, how did that come about? CHRIS: I think that was a dream in Ben Orenstein's eye. It started as thoughtbot Learn many, many years ago. There was a handful of workshops that had been recorded. And so, there were the video recordings of those workshops that thoughtbot used to provide in person. Ben collected those together and made them sort of an offering on the internet. I think Chad, you, and I were on some podcast episode where you sort of talked about the pricing models over time and how that went from, like, a high dollar one-time download to, like, $99 a month to $29 a month, and now Upcase is free. And so, it sort of went on this long journey. But it was an interesting exploration of building a content business of sort of really leaning into the thoughtbot ideal of sharing as much information as possible, and took a couple of different shapes over time. There was the weekly iterations of the video series that would come out each week, as well as the, like, longer format trails, and eventually some exercises and whatnot, but very much an organic sort of evolving thing that started as just a handful of videos and then became much more of a complete platform. I think I hit the high points there. But, Chad, does that all sound accurate to you? CHAD: Yeah, I led the transition from our workshops to Learn, which brought everything together. And then, I stepped away as product manager, and Ben took it the next step to Upcase and really productized it into a SaaS sort of monthly recurring billing model and took it over from there. But it still exists, and a lot of the stuff there is still really good [laughs]. CHRIS: Yeah, I remain deeply proud of lots of the videos on that platform. And I'm very glad that they are still out there, and I can point folks at them. VICTORIA: I love that idea that you said about trying to get as much content out there as possible or, like, really overcommunicate. I'm curious if that's also stayed with you as you've moved on to startups, about just trying to get that influence over, like, what you're doing and how you're promoting your work continues. CHRIS: I will say one of the experiences that really sticks with me is I had followed thoughtbot for a while before I actually joined. So, I was reading the blog, and I was listening to the podcasts and was really informing a lot of how I thought about building software. And I was so excited when I joined thoughtbot to, like, finally see behind the curtain and see, like, okay, so, what are the insider secrets? And I was equal parts let down...actually, not equal parts. I was a little bit let down but then also sort of invigorated to see, like, no, no, it's all out there. It's like, the blog and the open-source repos and those sort of...that really is the documentation of how thoughtbot thinks about and builds software. So, that was really foundational for me. But at the same time, I also saw sort of the complexity of it and how much effort goes into it, you know, investment time Fridays, and those sort of things. Like, a thoughtbot blog post is not a trivial thing to put up into the world. So many different people were collaborating and working on it. And so, I've simultaneously loved the sharing, and where sharing makes sense, I've tried to do that. But I also recognize the deep cost. And I think for thoughtbot, it's always made sense because it's been such a great mechanism for getting the thoughtbot name out there and for getting clients and for hiring developers. At startups, it becomes a really interesting trade-off of, should we be allocating time to building up sort of a brand in the name and getting ourselves, you know, getting information out there? Versus, should we be just focusing on the work at hand? And most organizations that I've worked with have bias towards certainly less sharing than thoughtbot, but just not much at all. Often, I'll see folks like, "Hey, maybe we should start a blog." And I'm like, "Okay, let's just talk about how much effort that [laughs] actually looks like." And I wonder if I'm actually overcorrected on that, having seen, you know, the high bar that thoughtbot set. CHAD: I think it's a struggle. This is one of my [laughs] hot topics or spiels that I can go on. You know, in most other companies, that kind of thing only helps...it only helps in hiring or the people being fulfilled in the work. But at most companies, your product is not about that; that's not what your business is. So, having a more fulfilled engineering team who is easier to hire—don't get me wrong, there are advantages to that—but it doesn't also help with your sales. CHRIS: Yes. CHAD: And at thoughtbot, our business is totally aligned with the people and what we do as designers and developers. And so, when we improve one, we improve the other, and that's why we can make it work. That is marketing for the product that we actually sell, and that's not the case at a SaaS software company. CHRIS: Yes, yeah, definitely. That resonates strongly. I will say, though, on the hiring side, hiring at thoughtbot was always...there was...I won't say a cheat code, but just if someone were to come into the hiring process and they're like, "Oh yeah, I've read the blog. I listen to the podcast," this and that, immediately, you were able to skip so much further into the conversation and be like, "Okay, what do you agree with? What do you disagree with? Like, let's talk." But there's so much. Because thoughtbot put so much out there, it was easy to say, like, "Hey, this is who we are. Do you like that? Is that your vibe?" Whereas most engineering organizations don't have that. And so, you have to try and, like, build that in the context of, you know, a couple of hour conversations in an interview, and it's just so much harder to do. So, again, I've leaned in the direction of not going anywhere near thoughtbot's level of sharing. But the downside when you are hiring, you're like, oh, this is going to be trickier. CHAD: Yeah. One of the moments that stands out in my mind, and maybe I've told this story before on the podcast, but I'll tell it again. When we opened the New York studio, it was really fast growing and was doing a lot of hiring. And one of the people who had just joined the company a couple of weeks before was doing an interview and rejected the person was able to write an articulate reason why. But it all boiled down to this person is, you know, not a fit for thoughtbot. Based on what they were able to describe, I felt very confident with the ability or with the fact that they were able to make that call, even though they had been here only a couple of weeks, because they joined knowing who we were, and what we stand for, and what our culture and our values are, and the way that we do things, and all that kind of thing. And so, yeah, that's definitely a huge benefit to us. VICTORIA: I've certainly enjoyed that as well, as someone who hires developers here and also in meeting new companies and organizations when they already know thoughtbot. That's really nice to have that reputation there, coming from my background—some really more scrappier startup kind of consulting agencies. But, you know, I wanted to talk a little bit more about your podcasting experience while you're here. So, I know you were on both The Bike Shed and Giant Robots. Which is the better podcast? [laughter] So, what's your...do you have, like, a favorite episode or favorite moment, or maybe, like, a little anecdote you can share from hosting? CHRIS: Well, I guess there's, like, three different eras for me in the podcasting. So, there's Giant Robots with Ben talking more about business stuff, and I think that was really useful. I think it was more of a forcing function on me because I sort of...Both Ben and I were coming on; we were giving honest, transparent summaries of our, like, MRR and stats and how things were growing, and acted as sort of an accountability backstop, which was super useful but also just kind of nerve-wracking. Then, when I joined the Bike Shed, the interviewing sequence that I did each week was just a new person that I was chatting with. And I sort of had to ramp them up on, hey, here's a quick summary on how to think about podcasting. Don't worry, it'll be great. Everybody have fun. But I was finding each of the guests. I was sort of finding a topic to talk about with them. So, that ended up being a lot more work. And then, the last three years chatting with Steph that was by far my favorite. There was just such a natural back-and-forth. It really was just capturing the conversations of two developers at thoughtbot and the questions we would ask each other as we hit something complicated in a piece of code or, "Oh, I saw this, you know, article about a new open-source repository. What do you think about that?" It was so much easier, so much more natural, and, frankly, a lot of fun to do that. And, two, I actually do have an answer to the favorite podcast episode, which is the first episode that Steph was ever on. It was before she actually joined as a co-host. But it was called “What I Believe About Software.” And it was just this really great, deep conversation about how we think about software. And a lot of it is very much, like, thoughtbot ideals, I would say. But yeah, Steph came in and just brought the heat in that first episode, and I remember just how enjoyable that experience was. And I was like, all right, let's see if I can get her to hang out a little bit more, and, thankfully, she was happy to join. WILL: What was your favorite position, I guess you can call it? Because you say you like the mixture of business and, you know, development. So, you've been in leadership as development director, CTO. You've been a web developer. You've been over content, like, with Upcase. What was your favorite position [inaudible 16:43] you were doing, and why was it your favorite? CHRIS: The development director role feels like sort of a cheating answer, but I think that would be my answer because it contained a handful of things within it. Like, as development director, I was still working on client projects three days a week. And then, one day a week was sort of allocated to the manager-type tasks, or having one-on-ones with my team sort of helping to think about strategy and whatnot. And then, ideally, still getting some amount of investment time, although the relative amounts of those always flexed a little bit. Because that one sort of encompassed different facets, I think that's going to be my answer. And I think, like, some of what drew me to consulting in the first place and kept me in that line of work for seven years was the variety, you know, different clients, as well as, even within thoughtbot, different modes of working in podcasts or video. Or there was a bootcamp that I taught, a session of Metis, which that was a whole other experience. And so, getting that variety was really interesting. And I think as sort of a tricky answer to your question, the development director role as a singular thing contained a multitude, and so I think that was the one that would stand out to me. It's also the most, you know, the one that I ended on, so [laughs] it might just be recency bias, but yeah. VICTORIA: Oh, I love that. Is there anything else that you would like to promote on the podcast today? CHRIS: No, although as you ask the question, I feel like I should, I don't know, make some things to promote, get back into some, I don't know, content generation or something like that. But for now, no. I'm, you know, diving into the startup life, and it's a wonderful and engrossing way to do work, but it does definitely take up a lot of my headspace. So, it's an interesting trade-off. But right now, I don't know; if folks are online and they want to say hi, most of my contact information is readily available. So, I would love to say hi to folks, anyone that listened in the past or, you know, has any thoughts in the now. Would love to connect with folks. But otherwise, yeah, thank you so much for having me on. CHAD: In 2017, I took over from Ben as solo host of the show but was joined by Lindsey Christainson as cohost in 2019. After some time away from thoughtbot, Lindsey is back with us and we sat down to catch up with her. VICTORIA: Why don't you tell me about your current role with thoughtbot? LINDSEY: I am currently supporting marketing and business development at thoughtbot, as well as working as a marketing consultant for thoughtbot clients. VICTORIA: Great. And I understand that you had worked with thoughtbot many years ago, and that's when you also came on as a co-host of Giant Robots. Is that right? LINDSEY: Yeah, a couple of years ago. I left thoughtbot in spring of 2021. And I forget how long my stint was as a co-host of Giant Robots, but over a year, maybe a year and a half, two years? CHAD: Yeah, I think that's right. I think you started in 2019. LINDSEY: Yeah. Yeah, that sounds right. And Chad and I were co-hosts, I think, similar to the setup today in which sometimes we hosted together, and sometimes we were conducting interviews separately. CHAD: And then we sort of introduced a second season, where we followed along with a batch of companies over the course of the entire season. And that was fun, and we learned a lot. And it was nice to have consistent guests. LINDSEY: Yeah, that was a lot of fun. I really liked that format. I don't know; they almost were, like, more than guests at that point. They were just like other co-hosts [laughs] that we could rely on week in, week out to check in with them as they're working on early-stage companies. So, every time we checked in with them, they usually had some new, exciting developments. WILL: I really like that idea. How did y'all come up with that? CHAD: I'm not sure. I think a few years before I had taken over hosting of the show, and I forget...my memory maybe is that I went to Lindsey and said, "You know, let's do something different." But I'm not sure. Does that match your memory, Lindsey? LINDSEY: Yeah, I think there were two main drivers; one was I think you were feeling like you were having similar conversations in the interviews every time. Like, you couldn't get to a certain depth because every time you were interviewing someone, you were doing, like, the, "Well, tell me your founding story." And, you know, how did you raise funding? It kind of got a little bit repetitive. And then, on the side, the few we had done together, I think we both really enjoyed. So, we were thinking, like, what's the format in which the two of us could co-host together more regularly? Because I'm a pleasure to talk to [laughter]. I think you were like, I need to talk to Lindsey more. [inaudible 3:13] VICTORIA: What is your hosting style? How would you describe your approach to hosting a podcast? LINDSEY: I mean, obviously, it's a podcast about products and business. I think as a marketer, I am, you know, drawn a lot to the marketing side, so tending to ask questions around go-to-market audience, users. That's always just, like, a particular interest of mine. But then also, like, the feelings. I love asking about the feelings of things, you know, how did it feel when you started? How did it feel when you made this tough decision? So, that's another thing I think I noticed in my interviews is asking about some of the emotions behind business decisions. VICTORIA: And I like hearing about how people felt at the time and then how they felt afterwards [laughs]. And, like, how people around them supported each other and that type of thing. That's really fun. I'm curious, too, from your marketing background and having to do with podcasts like; some founders, I think, get the advice to just start a podcast to start building a community. But I'm curious on your thoughts about, like, how does podcasting really play into, like, business and marketing development for products? LINDSEY: Oh yeah. It's become definitely, like, a standard channel in B2B these days. I feel like that it's pretty typical for a company to have a podcast as one way that they engage their audience and their users. In marketing, you're really vying for people's attention, and people's attention span is getting shorter and shorter. So, like, if you have an ad or a blog, you're getting, like, seconds, maybe minutes of someone's attention. And whereas something like a podcast offers a unique channel to have someone's undivided attention for, you know, 30 minutes, an hour, and if you're lucky, you know, checking back in week over week. So, it became a really popular method. That said, I think you're probably also seeing the market get saturated [laughs] with podcasts now, so some diminishing returns. And, you know, as always, kind of looking for, you know, what's the next way? What's the next thing that people are interested in in ways to capture their attention? CHAD: What is the next thing? LINDSEY: I don't know, back to micro-content? TikTok videos -- CHAD: Yeah, I was going to say TikTok, yeah. LINDSEY: Yeah, you know, 10-30 seconds, what can you communicate? VICTORIA: I see people live streaming on Twitch a lot for coding and developer products. LINDSEY: Yeah, I think we've seen some of that, too. We've been experimenting more at thoughtbot with live streaming as well. It's another interesting mechanism. But yeah, I don't know, it's interesting. It's another form of, like, community and how people engage with their communities. So, it's always evolving. It's always evolving, and sometimes it's not. Sometimes, people just do want to get in a room together, too, which is always interesting. WILL: What has been, in your experience, the good the bad? Like, how do you feel about the way that it has shifted? Because I think you started in, like, 2000, like, kind of earlier 2000, 2005, something around there. And it was totally different than now like you're saying. Because I feel like, you know, Channel 5 30-second ad, you know, with some of the marketing depending on what you're doing, to now to where you're, like, you're paying influencers to advertise your product, or you're doing an ad. Or it's more social media-driven and tech-driven. What has been your opinion and feelings on the way that it has grown and evolved? LINDSEY: Marketing, in general, yeah, I graduated college in 2005 and started my marketing career. And yeah, you could, like, actually get people to click on banner ads back then, which was pretty [inaudible 07:14] [laughs]. WILL: I forgot about banner ads [laughs]. LINDSEY: I don't know, yeah. I don't know. In order for myself to not just get too frustrated, I think I've got to, like, view it as a game kind of. What new things are we going to try? You know, what do we see work? But it can really depend. And I've always been in B2B side of things. And consumer, I'm sure, has its own kind of evolution around how people engage and how they consume content and byproducts. But in B2B, you know, it can really depend on industry too. You know, I'm working with a client right now in the senior living space, and they're really big in in-person conferences. So, that's how people consume, get a lot of their information and, make connections, and learn about new products. So, it's been interesting to work in an industry that what might be considered, like, a little bit more old-school channels are still effective. And then just thinking about how you weave in the new channels with the existing ones without ignoring them. They might get information in conferences, but they're still a modern human who will then, you know, search online to learn more, for example. VICTORIA: It reminds me of a phrase I like to say, which is that, like, technology never dies; you just have more of it. There's just more different options and more different ways to do things. And some people are always, you know, sometimes you have to be flexible and do everything. CHAD: So, tell us more about what you did in between...after you left thoughtbot, what did you do? LINDSEY: I was heading up B2B marketing for a company called Flywire, which is headquartered in Boston but is a global company now. And they were just kind of starting their B2B business unit, which, as I mentioned, B2B is my personal specialty. I had been connected to their CMO through the Boston startup community. And yeah, I was helping them kind of launch their go-to-market for B2B. The industries they were in before...they got their start in higher education and then expanded in healthcare and found a niche in luxury travel, and then we were figuring out the B2B piece. But yeah, I was there for about a year and a half. They actually went public the second week I was there, which was an interesting [laughs] experience. I knew they were, like, on that journey, but it was kind of funny to be there the second week, and people were, like, "Congrats." And I was like, "Well, I definitely didn't have anything to do with it because I just finished my onboarding, but thank you," [laughs]. CHAD: One of the things that really impressed me when you joined thoughtbot was the way in which you learned about who we were and really internalized that in a way where you were then able to pretty meaningfully understand our market, our positioning in the market, and come up with new strategies for us. I assume that's something you're good at in general [laughs]. How do you approach it? How did you approach it when you joined Flywire, for example? And how was it the same or different than how you approached thoughtbot? LINDSEY: Ooh, yeah, that's a good question. And I appreciate that comment because it's difficult. But I think, yeah, with any new organization that I'm joining, you know, I think starting out with your kind of mini-listening tour of your key stakeholders across, you know, the different departmental focuses to get a sense of, what are the challenges? What are the opportunities? It's actually like, you know, it's the SWOT analysis, kind of trying to fill in your own mind map of a SWOT analysis of where the company is. What are the major hurdles you're facing? Where are people trying to go? What have they tried that's worked? What have they tried that's failed? But then, like, I think for the culture component, I think a part of that maybe is, like, feel, and maybe something that I do have a knack for. Again, maybe this is, like, you know, emotional intelligence quotient, where it's like, you know, but it's the company, you know, who is this company? What is important to them? How do they work and go about things? I know thoughtbot is certainly very unique, I think, in that arena in terms of being, like, a really value-driven company, and one where especially, like, marketing and business work is, like, distributed across teams in a really interesting way. You know, I'm sure the fact that it fascinated me and was something I could get passionate and get behind was something that also helped me understand it quickly. CHAD: I was excited that...or it was sort of a coincidence because I had reached out to you and without realizing that you had left Flywire. And Kelly, who had been doing a combined sales and marketing role, was going on parental leave. And so, it was fortuitous [laughs] that you were able to come back and help us and provide coverage, like, Kelly was out. LINDSEY: Yeah, it definitely felt like stars aligned moment, which, you know, I'm pretty woo-woo, so I believe in [laughter]...I believe in that kind of thing. You know, yeah, it was wild. It really did feel like your email came out of nowhere. And, you know, I mentioned it, obviously, to my partner and my friends. And they were like, "Oh, he definitely knows, like, that you left your last company." And I'm like, "I actually don't think he does [laughter]. I actually don't think he does." Yeah, and then we started chatting about me coming back to help. And it was great. thoughtbot makes it hard to work anywhere else [laughs]. So, I was happy to come back. I missed the team. CHAD: And one of the exciting things, and you've mentioned it, is you're not just doing marketing for thoughtbot now. We have started to offer your services to our clients. LINDSEY: Yeah, I'm super excited about this. And it's something I'd started thinking about. I had decided to take some time off between Flywire and my next thing and had started thinking about doing marketing, consulting. And as I'm doing that, I'm thinking a lot about how thoughtbot does consulting and, you know, wanting to emulate something like that. So, I started back up at thoughtbot. That wasn't part of the plan. I was just going to, you know, fill in for Kelly and help with marketing things. But then, you know, a good opportunity arose to work on a client, and I was really excited. When, you know, Chad, you and I chatted through it, we came to the conclusion that this was something worth exploring under the, you know, thoughtbot umbrella. And it's been a really great experience so far. And we now have brought on another client now. And if you're listening and need early-stage B2B marketing support, reach out to lindsey@thoughtbot.com. CHAD: Definitely. And Lindsey is pretty good, so you're going to like it [laughs]. LINDSEY: Yeah, you're going to like the way you look. WILL: Yeah, definitely. Because I can even feel your presence here, you know, coming back. Because even like, you know, the market where it's at now and some of the suggestions that, you know, you've been helping us. For example, like, I do a lot of React Native, and you're like, "Hey, you know, blog posts have done a lot of traction, you know, let's get some more blog posts out in the market to help with the traffic and everything." So, the question I have with that is, like, thank you for even suggesting that because it's, like, those little things that you don't even think about. It's like, oh yeah, blog posts, that's an easy transition to help the market, clients, things like that. But with the market the way it is, what has been your experience working during this time with the market? I don't know if you want to call it struggling, but whatever you want to call it that, it's doing [laughs]. LINDSEY: Yeah, I mean, the economy is difficult now. We also went through a really tough spot when I was here last time. During COVID, you know, we faced a major company challenge. And, I mean, I'll let Chad speak to it, but I would imagine it's probably one of the bigger, like, economic inflection points that you faced. Would you say that? CHAD: Yeah, definitely. The thing about it that made it worse was how quickly it happened. You know, it was something that you didn't see coming, and then, you know, about 40% of our business went away in a single month. That's the kind of thing that was a real shock to the system. I think the thing that made it difficult, too, was then the aspects of COVID, where we were no longer able to go into our studios. We were all working remotely. We were isolated from each other. And so, that made executing on what needed to be done in order to make the company survive additionally challenging. LINDSEY: Yeah, so I think, like, going through that experience, also, and seeing how the team and the leadership team rallied together to get through it. And then, you know, ultimately, I think 2021 and 2022 have, like, really good years. That was a really positive experience. And something I'll definitely take with me for a while is just, like, keeping a cool head and just knowing you have, like, really smart, talented folks with you working on it and that you can get through it. And just, like, doing some, I mean, we relied on what we did best, which was, like, design thinking, using design exercise to think about, like, how we might re-organize the company, or what other services we might try launching, or how might we re-package, you know, larger services into smaller more palatable services when people have, like, kind of tighter purse strings. So, that was, like, a great educational experience, and I think something we just continue to do now: be open to change, be open to changing how we package services, what clients we go after, and coming at it with, like, an agile, experimental mindset and try to find out what works. VICTORIA: I really appreciate that. And it aligns now with the new service we've developed around you and the marketing that you provide. And I'm curious because I've had founders come up to me who say they need help with marketing or they need to, like, figure out their marketing plans. So, say you've met a founder who has this question, like, what questions do you ask them to kind of narrow down what it is they really need and really want to get out of a marketing plan? LINDSEY: I've been thinking about this a lot recently. And, like, obviously, I see other marketing leaders in the market. Marketers like to talk about what they do on LinkedIn [laughs], so I get to...I read a lot about different people's approaches to this. And some people kind of go in and are like, okay, this is what you need. This is how we're going to do it, and they start executing on it. And I really do take a very collaborative approach with founders. I think they're, especially in early stage, they're your most important asset in a way, and a lot of their intuition around the market and the business, you know, it's gotten them to where they're at. And so, I think starting from the point of, like, taking what they view as priorities or challenges, and then helping them better explore them or understand them with my own marketing experience and expertise, to