Rails 20th Anniversary, Writing Culture

Show Notes

In this episode, we celebrate the 20th anniversary of Ruby on Rails, reflecting on its impact and vibrant community. We share Rails origin stories from the late 2000s and early 2010s. You'll hear about different companies' reading and writing cultures, including practices like decision documents, meeting notes, and internal newsletters.

You'll hear updates on current projects, with Colin discussing a major documentation initiative and the challenges of balancing meta-work with actual work. CJ provides an update on a large-scale refactoring project, detailing the process of converting enums to models across various parts of the codebase. You'll also get book recommendations, including "The PARA Method" about note-taking and personal knowledge management, and "Unreasonable Hospitality" which explores creating exceptional customer experiences.

Finally, we discuss the concept of "unreasonable hospitality" and how to delight customers through thoughtful, personalized interactions.

Resources
  • Unreasonable Hospitality - https://www.amazon.com/Unreasonable-Hospitality-Remarkable-Giving-People/dp/0593418573
  • PARA method - https://fortelabs.com/blog/para/ 
  • Amazon's working backwards - https://www.productplan.com/glossary/working-backward-amazon-method/ 



Full Transcripts

colin_1_08-01-2024\

_100949: Welcome back, CJ. Happy birthday to Rails 20th anniversary. cj_1_08-01-2024\

_130949: That is a surprisingly mature framework. If I do say so myself. colin_1_08-01-2024\

_100949: is, it's two decades. it almost can drink. cj_1_08-01-2024\

_130949: Yes. Recently I've been reflecting a lot about the future of rails and wondering about, you know, how easy it is to hire people who want to use rails. There's a few projects coming up where, it might be something that I sort of build as a microsite and hand over to someone else. And I want to use rails to do that, but I'm also like, maybe there's not going to be someone to maintain it. And I don't know, is that a concern that you've bumped into from other folks or. Thought about colin_1_08-01-2024\

_100949: not so much. Like I think, like you said, the maintainability and like finding people who know Rails, there's like this convention that is not in most frameworks, even. net. JavaScript, things like that, where you can build your structure any way you want. So if you build it in rails, like someone who's familiar with rails is going to be able to pick it up. And I think the death of that community is very much, largely overblown. Like just because rails conf isn't going to be happening anymore. It does not mean that. That all of a sudden, all these 20 years of rails veterans are going to just disappear and they're going to switch frameworks. They're going to, they're going to go to rails world. They're going to go to Ruby comps. They're going to go to blue Ridge Ruby. They're going to go to, you know, mountain West Ruby or whatever, you know, all those different ones. I think you'll be able to find some people to support it cj_1_08-01-2024\

_130949: totally. Yeah. I am also very optimistic and hopeful, that, the community will continue to grow. With the future of rails and with large language models, helping us write code is the power of convention over configuration. is so much stronger when you're using an LLM and you're in a framework that expects, you know, these conventions, because the predictability of the way to implement something is influenced by like all of the past art. And so being able to look at most rails apps and like. Squint your eyes a bit and see, okay, they're all roughly the same shape. And so if I want to do something that is similar than, you know, co pilot should be able to just spit out the things that you want for rails, whereas it might be much harder in other languages, especially like really bespoke new funky languages or when you're in a really funky environment. colin_1_08-01-2024\

_100949: for sure. Yeah. I'm curious. What is your rails origin story? How did you get into rails? cj_1_08-01-2024\

_130949: yeah. In college. I took a class about databases and it was like, go implement, or learn a bunch of different types of databases, learn about the cap theorem and how to set up relational databases, what are no SQL databases and things like that. And at the very end, the project was like, To go set up a rails application and use associations, rails associations, and try to like, just see the power of, an ORM and what it can give you. And so my first ever experience was touching it. I think probably this was probably like 2009, 2010 ish. but then I didn't really do anything serious with it until 2013. colin_1_08-01-2024\

_100949: Nice. cj_1_08-01-2024\

_130949: Yeah. What about you? colin_1_08-01-2024\

_100949: I can't remember how I first found it because I. I was already starting to use it. So in two, let's see, in college, I was the editor of the web editor of the college newspaper. And we were using a platform called college publisher, which was like all the schools used it. And what was cool is that then college publisher would go sell ads. Against all these newspapers and then put them in the website and we would make commission make some money off of that. MTV bought College Publisher and they won. They took away all of the ad revenue from everybody And they just plastered it with MTV ads, like they thought that was their target demo, And so we decided as a newspaper to start our own software and probably not the greatest idea in the world, but we decided to build our own CMS, for publishing the newspaper. And that was when I remember, I actually wish I had it on my shelf here, but I've been and I have a stack of my first Ruby on Rails books. that, It's very timely and they're hard to give up even though they're like comically out of date now. but I remember going to RailsConf in 2007 and I don't know if it was 2007 or 2008, but someone got up on stage and demoed this like Rails app wrapped around Git and letting you like create pull requests and see comments. And that was like the early version of GitHub. And it was really cool because this was like back when Y was still going to Rails confs. And there were a lot of people who I just did not know who they were. And they were not really well known at the time. So then we fast forward. I remember specifically leaving that first Rails book on an airplane. and I'm a college student. So you know, it's not insignificant to like, Oh, I got to go buy this computer book again. And so I went and bought it again. I hope someone found it and came to, to be a Rails developer after they found that book. But, yeah. We built the CMS, we ran it for two years, because I think I was like sophomore, junior year. And then we quickly realized that I'm going to graduate and no one can support this thing. And we moved to WordPress, and I left the Rails world for a little while, and went full throttle into the WordPress world. but I think since then, the newspaper's been on WordPress and still rocking. and then I've come back to Rails many times since then. cj_1_08-01-2024\

_130949: In terms of like use cases, a newspaper is a great use case for WordPress. CMS, easy to edit, whatever. but yeah. Wow. So you've been in the, in and around rails for a super long time. That's so colin_1_08-01-2024\

_100949: Yeah, it feels like a long time. I know that we used to have a Reno RB group. I know that I think maybe even Twitter helped me get into Rails, just because I think it was built on Rails in the early days, or at least Ruby. And so it was the known quantity. And I No, that I was on Twitter pretty early. I don't know when those all intersected. It's like I could have ended up in Django and my path would be very different. Or like I found with WordPress, it was just that you're not likely to find a programmer who's going to be running the newspaper versus someone who can do WordPress plugins and themes and stuff like that. So just made sense. cj_1_08-01-2024\

_130949: I remember one of the first startup weekends. I don't know if you remember the year that startup weekends was kicked off in Reno, but, we did the hackathon. and then I remember being at the collective, like working on our startup after startup weekend. And there was a Reno RB talk that night at the collective. And this was like back when we were in the upstairs colin_1_08-01-2024\

_100949: The clubhouse. cj_1_08-01-2024\

_130949: yeah, clubhouse, like locations, many locations ago. And someone gave a talk on Capybara. And also like just, I think it was, yeah, just like different test frameworks that they were using and having success with. So it's probably 2010, 11 ish. And I remember thinking, Whoa, like Ruby is such a cool thing. And we were building like our startup weekend hackathon tool with net. And I was like, Yeah. I was like embarrassed that we were using like a corporate, you know, not the cool, hot new frameworks, that Ruby was. colin_1_08-01-2024\

_100949: Yeah, it was a golden era, I think, for software and like the internet. Just like people building things for fun. I feel like some of that is coming back around I think like less AI pendant startups I don't think we need more of those in the world as much as we need these like fun little internet toys and Things that you just do for fun and I think Yeah, we'll see where that comes, but like 2008, 2012, like that four year period was just like such a golden era for frameworks and tools built all on rails or built, you know, tangentially, or, you know, things like node knockout node was starting to come up around then too. so yeah, happy birthday to rails. cj_1_08-01-2024\

_130949: Yeah. Very cool. Very cool. I wanted to just like chat a little bit about reading and writing cultures and what your experience was with them and what I've seen. this sort of started because there's a few cultural habits and things that I picked up from Stripe that I really like, and that I'm trying to bring over to craftwork, the latest of which being a decision document where you work together in written word on a shared Google doc to try to come to a decision. I remember when I first started at Stripe being insanely intimidated by how much reading and how much writing there was. Many things if you wanted to get them done, the way that you did that was by writing a doc. A lot of stuff doesn't really happen without, support and stakeholder buy in and whatever. And when you're at a small company, you can just make a comment and then it happens. Whereas at a bigger company, you need a little bit more organization. And so by writing a doc, you can get stakeholder buy in and iterate on the thinking behind the doc and other things. But I do remember thinking, wow, this is a ton of reading. And like the first month of Stripe, I probably read more than I had, like in the previous several years combined, just, pouring over, whether it was like onboarding or new, Teams would publish newsletters on a weekly cadence of here's what we met about. Here's the progress we made. Here's where we're at. Here's what we're thinking for the future. Here's what's next. there were so many different cultural things around reading and writing. And I don't know. I think it's a interesting to learn from. And I'm curious, like in your, in your career so far, would you say that the companies that you've worked with and for have had a really strong reading and writing culture? And what does that look like for you? colin_1_08-01-2024\

_100949: Yeah, I think the last couple of companies, especially with the advent of notion, I know like when I worked with Strava, they use Dropbox paper a lot. it was just docs and docs. at Orbit, we had a pretty heavy notion culture because it was so both reading and writing. Because we were distributed from San Francisco all the way to East Europe. Especially I think with the async nature of work to be able to, again, like outline all the things, get stakeholder buy in, also get any sorts of side effects that maybe you didn't think about that someone else has experience with things like that. and at discord, we do things like, PRDs for product review, RFCs for technical things before we write any code. it's definitely interesting. And it's funny that When we talk a little bit later about what we're working on, there is that, like how much meta work do you do versus doing the work, but in bigger companies, you can't just ship it without any consideration for what it's going to do to the user, to the team, to how a lot of people expect things to work today, things like that. So I think it does help to fully flesh things out and then pump the brakes a little bit and just make sure that you thought through things. cj_1_08-01-2024\

_130949: totally. It sounds like, uh, Amazon's working backwards culture seems pretty powerful to where they I think they write the press release. I didn't know about the fact document, but like writing a press release of what the new product will be announced, like how it will be announced and then writing a frequently asked questions document that kind of helps you think about what people ask about that. is interesting. Another thing that I've heard of Amazon doing on the dev side is like starting with an API design document or like almost starting with an open API spec. I think they use something else called Swifty or something, but, starting with that open API spec, writing the examples, writing, here's the arguments that go in, here's the response you're going to get back. And then using that as a sort of guiding document. both are examples of working backwards, but, yeah, I don't know. Both of those sort of seem useful. I don't know. Sometimes it can be tricky and feel a little bit fake to try to write a press release, like before you know the product. it's almost you're doing a, Oh, gosh. What is it like? Sometimes in an interview, you'll do role playing or they're like, okay, now I'm going to be the customer and you're going to be the salesperson or whatever. try to sell me on this thing. It's okay, this feels a little bit cheesy colin_1_08-01-2024\

_100949: Sell me this cj_1_08-01-2024\

_130949: right? Yeah, exactly. Exactly. colin_1_08-01-2024\

_100949: like the FAQ document though, because it's putting yourself in the shoes of the customer. And even if it like, say it's something we're working on, if you can't write a press release about it, should you be building it? Is it going to improve the customer experience? Is it going to improve some bottom line? Is it going to, is it going to move the needle at all? If you really can't write that post, there's probably some reflection to do. when we build things and we announce them, we write these posts in our Discord developer server called DDevs. And we almost always write a changelog thing. And most of the time, it gets written afterwards. but I have this saying that I don't know where I picked up. I'm sure it's from somewhere where it's begin with the end in mind. And it's very similar to working backwards in the Amazon way, but I have taken to like writing the docs first or once I see a PRD or an RFC, I think okay, and this is like for developer products, but this could be the same for what is the, what does the instruction manual look like? What does the user update look like? Whatever it might be. And just writing the docs first, because then. If you try to explain someone how they're going to use it or how it's going to affect them, you're going to anticipate the questions that they have. You're going to put yourself in their shoes. what about this? And what about this? And that way you're not like, announce the thing and then be inundated with reactive comms. And you guys didn't think about this or, you know, what other things are you going to put out that you know, are half baked or something like that. cj_1_08-01-2024\

_130949: you think that, being a documentarian or being a docs writer becomes harder when. You might not have the same developer experience, like not having like actually built the, build stuff in the past. Like I could imagine it being really hard to be that thoughtful and anticipating someone's questions if I hadn't used a rest API, but I'm trying to write the docs for rest API. I colin_1_08-01-2024\

_100949: that's, there's like lots of layers there because like it depends on what the rest of the API is even doing, right? if you've never implemented subscriptions in Stripe, do you know the gotchas? Do you know the things you have to consider and like dunning periods and failed cards? And the API design is probably not going to show you all those things because those are like things that happen in real life. I like to think of it almost like TDD where like writing the docs first is the test first and maybe it's, you're literally writing tests first or, instead of an API design, I think just writing in pure words and like painting a picture of what the dream state is. I do think it gets into that meta work of Oh, we have to move fast and we can't get the dream state. So what does half look like? And it's would you write a press release for half of this thing? are you going to be triumphantly celebrating this thing if it's only half, or is it only celebratory if it's fully finished? so I think it's important. I think. what you're calling out is just like making it inherent in the culture that this is something we do here versus Colin does this and CJ does this, but everyone else is doing their own thing. you know, what does that culture look like and how can you build that? You mentioned a few other things like five 15s meeting notes. How do all those kind of roll up into this? cj_1_08-01-2024\

_130949: think there are also, other cultural things like, okay, if we have a meeting coming up cause there's a Google calendar event for it, then in the description of the calendar event, there's a link to a doc. It's expected that you've read the doc before left comments and we've had like a thoughtful discussion and we have everything out on the table, before we actually meet and then once we meet, there's also like notes of who said what during the meeting. With action items at the bottom, and you've you've gone in with a clear, agenda of what you want to, brainstorm or make a decision about or whatever. and then you come out of the meeting with clear, next steps and who's owning what and, you know, or deeper connection, in some way, deeper collaboration in some way. So that like meeting notes is another one where I'm that I am trying to bring to the crew like, all right, before we meet, let's always have an agenda that has like several things on it when we meet, we'll go over those things after we meet there's action items and there's, you know, things that are everyone at the meeting can take away from it. so that becomes also like a living artifact of What was the decision that was made and why, and what were like some of the thoughts that were behind it and why, we do have a lot of documentation in notion. That's just you know, company documentation about like holidays and, you know, how do you book a trip and how do you, I don't know, like basic stuff in notion, but, yeah, that's also really valuable though. having consistency. And, I don't know, just standard processes about how things work and should work and, maybe like documenting processes too, in Notion is valuable. I don't know, another one that comes to mind too is readme. in your GitHub, readme for your project, does it have all the instructions to get set up? Does it have all the instructions for, like, how to use the tools that are inside of that? Code base and, and so on. So yeah, lots of little different writing artifacts. I've been trying to rack my brain about, it's been a while, but like just other things that, that I really liked from Stripe even before that, I think my VR had a pretty. like more of a deck heavy culture where it was like, okay, we're going to have a meeting. So let's put together a Google slides presentation. Everyone's like responsible for a slide and you have to go in and add bullets about X, Y, or Z. so yeah, there's definitely like different ways to do it, but colin_1_08-01-2024\

_100949: the deck one is interesting. Like we have multiple teams and multiple all hands and to be honest Like I would prefer a bulleted pre read and then if there's stuff to show and deck and all that stuff Like that's one thing but if the all hands is the first time ever hearing about it Like I don't Yet no questions I have and during these usually we have questions in a separate session. so there is time for that, but I do enjoy like the pre reads ahead of time. So you're not like coming into a meeting and everyone only has, you know, some people are coming in late and some people can't make it and some people on PTO and in bigger companies like having both the pre read and the post read means that if you missed it, you can just read that and you can comment on async. If you. And I think that creates a healthier culture than, you know, a lot of people say Oh, if you're not in the office, you're probably not, you know, as connected to your team. And you're probably not going to get promoted. It's that's because you've got a really in person culture. And if you missed it, you missed it. And no one's taking notes. Cause I think there's like that, even in boards and stuff for like nonprofits. And so it feels like the secretary seems to be the job that nobody wants. And. Sometimes it's a literal role and sometimes it rotates between all the board members of who's writing the minutes or the notes for the meeting and That feels like something AI could solve a little bit like let's just have once this is good enough Have it write the notes for us We have an AI that does this and it also pulls out the action items and who talked and who did what? So that's super nice cj_1_08-01-2024\

_130949: Which one are you using? colin_1_08-01-2024\

_100949: It's homegrown It's only, it's like internal, like only inside of our like team discords. Yeah. cj_1_08-01-2024\

_130949: that's cool. I just recently tried tactic with a Q out. there's a few that I'm just like bouncing between just experimenting and trying to see Which is the least intrusive? Because I find that like when there have been a couple that I've tried that join the Google, like the Google Meet call or the Zoom call, it joins as like a separate person. It's who is this creepy like other person? And there's others that are much less intrusive where it's like a Google Chrome extension that just happens to be there. Oh, colin_1_08-01-2024\

_100949: you want other people on the call to know that's happening. Like these are all internal calls. So we all, and they joined the discord. So like this bot joins the discord. We are discord. So we can. Record the audio, send it over, you know, and I think because we home built it, it's not like we're sending all of our private meetings off to open AI or whatever. and then it afterwards creates a notion doc with all the notes. It has some fun flair where it then takes all the people who are in there and based on their behaviors creates a screen play based on how people were like acting in the meeting. they're like, this person, in the theme of, Deadpool, and this person was Deadpool, this person was Wolverine, and yeah, it's just really, it's very much like, when it works, it's pretty funny, and then above that, it has the action items and the actual meeting notes. cj_1_08-01-2024\

_130949: Nice. I like that. It's like adding, yeah. Adding a little bit of a RIS to colin_1_08-01-2024\

_100949: Little whimsy. cj_1_08-01-2024\

_130949: the culture. Yeah. the last thing that I wanted to mention too, before we move on, is that like one of the behaviors that I recognize from some of the like higher level engineers that I worked with, at Stripe, it's like L4, L5 at other places, I think they would be considered like L6, L7 is that they send internal newsletters. So whether, whatever meetings happen, maybe you like take the meeting notes and you send an email after with just to the people who were at that meeting, or maybe to the teams that were at that meeting about here's what we talked about. And here's what we're going to do. and then the really like high functioning folks would take, those meeting notes. And, maybe over the course of a month, synthesize all of those and then publish an internal only newsletter that would be sent to a Google group that anybody could join. and that gave them a lot of visibility. And it also was like a way to just like brag about their team. So it like elevated their team. And yeah, if you're out there and you're you know, mid level and you want to get promoted, I think this is a pretty effective way to Get discovered is to write an internal newsletter that is, you know, bragging about your own team. So colin_1_08-01-2024\

_100949: Yeah. I don't think I think in startups you don't see as much of this type of culture and stuff cause they're small and they got to move fast. But there's this habit of when you're, whether you're fundraising or bootstrapping or whatever you're doing, usually it's given as investor advice, which is everyone you're meeting and talking to you ask if they can, if you can put them on your newsletter, or say Hey, do you want to get updates? You're not asking for money. Like you say, Hey, I want to have coffee. I want to, you know, give you a pitch, but maybe you're asking for advice. Similarly, if you want money, ask for advice. If you want advice, ask for money type of situation. So ask if you can be like, Hey, maybe it's not the right time for you. Can I put you on updates? If you're bootstrapping, it's also valuable because then when you're. Putting out updates on Oh, I'm trying to do this thing. I'm trying to hire, I'm trying to do whatever. Like you now have this list that you can use when you do a beta, when you do a Kickstarter, when you do whatever, you now have this following and maybe it's Twitter, maybe it's email, whatever that might be. but it's more like building public that you can control and creates a list and a following. And, I've been talking to somebody who's trying to start a coworking space and I'm like, you can't open on day one with no customers. you need to have pre sold this place. people need to be having pre committed to the first three months and you open full, do not maybe half full, but I see posts of Oh, I'm starting a business and I have no customers on day one and I've spent two years coding and no one's ever seen it. or coworking space opens and it's three months in and we haven't had a single tour. This is where you got to write down and talk about what you're working on. and I think all of this helps, right? There's these internal newsletters, external newsletters. If you're a one person team, create your own little council that you're talking to and documenting and getting feedback from. cj_1_08-01-2024\

_130949: I love that idea. I'm going to steal that. The like investor updates, but like to colin_1_08-01-2024\

_100949: Yeah. I want the, the board of the personal board of directors, right? cj_1_08-01-2024\

_130949: yes. Yeah. So good. So good. cool. What are you building? What are you working on these days? Colin? colin_1_08-01-2024\

_100949: Yeah, this one kind of follows up with this, but I hit a point yesterday where I was like, I just need to start writing. so I'm working on a big docs project again, and I realized that I was like getting caught up in answering questions and in some cases, like verifying that some of these things work the way that they do. I was doing a little bit of reorganizing Asana tickets and then I spent like an hour in Asana and I was like okay that was an hour that I did not get actual work done like the meta work sometimes is the work when you're like delegating and having a team but like I'm the one who's going to be writing these docs so I like closed everything put myself in do not disturb and just Turned on some good music and just started writing and I got like Surprisingly like a good skeleton and everything built out And like I think I was telling myself like let's get this done by the in two weeks from now And I think I'm gonna get done like tomorrow Which will be at least like a first draft so that then the team can go read it And a lot of it in what we just talked about is stuff that has not shipped yet. And so I want to document and point out like this doesn't work the way we think it does, or we're missing something or Hey, like this thing that we're doing is going to like by the time this episode comes out, hopefully all of this will have shipped. So I can talk about it, but like some of it is Hey, this breaking change does affect people more than we think it will. And this is the guide that they're going to have to follow to, to do that upgrade. cj_1_08-01-2024\

_130949: Nice. It's exciting when you like get a big chunk of work done that you didn't, that you thought might take longer, but, yeah, it worked out to be much, colin_1_08-01-2024\

_100949: I've got all the raw material already. It's just it's easy to feel like you're being productive by moving it around and it's no, like we need to turn this into gold now and do the work. How about you? cj_1_08-01-2024\

_130949: Totally. Oh gosh. doing a big refactor, changing a bunch of things from enums to models still. And, yeah, anyone who's done that knows that there is, it's like a three PR process at least to make the new field, migrate all the data from the old field to the new field, deprecate the old field. make sure you're not using the old field, update all the tests and then remove the old field, drop the column and then move on from there. and we've got I think we ended up touching like 20 different models and like of those lots and lots of different stuff. very close, but, colin_1_08-01-2024\

_100949: Are you doing that model by model, like three PRS per model? Or are you doing one giant, make all the new columns across all the models and then migrate all the data? cj_1_08-01-2024\

_130949: It's a little bit of both. I did like a big group together at once and then updated like the integration points for all of those. And now I'm doing another big group and then I'm doing, I'll be able to do the last big group, but yeah, it's, it was interesting trying to think through how to attack it. Cause depending on where you start, it can end up being like, colin_1_08-01-2024\

_100949: This code's dependent on this code. cj_1_08-01-2024\

_130949: exactly. Yeah. The first in the first time I went through, it was like. It was actually like seven or eight PRS that were all, you know, a couple of hundred lines here and there. And then the second time I did it, I was like, Oh, I think I could do more. Let me just bite off, like a whole big chunk. And so that PR was like 1500 lines or something and touched a hundred files. And there was like two or three bugs that fell out of it. And so that one was like, obviously a little bit more cowboy ish. But, yeah, I think just, yeah. Yeah. doing it in chunks. So we're almost there. colin_1_08-01-2024\

_100949: I'm sure the first one taught you how to do the next one in a slightly different way. cj_1_08-01-2024\

_130949: Yeah. There's a lot of, so have you ever used the strong migrations Okay. Yeah. So the, I'm like pretty new to it, but what's nice about it is like, It helps avoid these like foot guns of okay, I'm dropping a column. And then I'm trying to use that data from that column to populate a new column or something, or I'm renaming something. And it, when you try to run the migration, it's oh, actually you should do this in two steps. And here's the steps that you should do. And first you should add a check constraint in one migration. And then in another migration, different transaction or whatever, You check the check constraint, change the nullability of the column, and then re add the check constraint. And so it makes it so that you have less downtime instead of just being like, All right. I'm deploying now. Everyone hold on. colin_1_08-01-2024\

_100949: Insert the hold on to your butts gif right here cj_1_08-01-2024\

_130949: Yeah, exactly. Yeah. You get like a flood of errors from production that like are just transient do it like mid deploy or whatever. So yeah, I think we definitely had a handful, but I tried my best to minimize like the colin_1_08-01-2024\

_100949: Yeah, I know I've used it. I don't know under the hood how it works, but I, it reminds me a lot of like terraform plan versus apply where it's let's do a dry run of this and see if there's anything that we didn't think about or like how long would it simulated, like how long would it take simulation like wise so that we can plan around downtime or whatever. but if, have you used terraform at all? cj_1_08-01-2024\

_130949: just a little bit. yeah, just experimenting for some striped content, but colin_1_08-01-2024\

_100949: Yeah, when it works, it's you feel so powerful. Like you're just like, all right, I'm planning this thing and we're creating all these services and all these boxes and all these databases. And you're just like, terraform it up, terraform it down. it's very nice. cj_1_08-01-2024\

_130949: That's so cool. I, yeah, I do remember feeling you know, when you like grab the little scale, auto scale bar and you're like, all right, let's auto scale this thing up to 10 boxes or whatever. It's so funny because you feel so powerful. And also I don't know. I it, because when I was doing this in the past, I was the one paying for the Heroku boxes. It always made me nervous to be like, all right, we're gonna scale this up to 20, You know, 20 workers right now to chew through colin_1_08-01-2024\

_100949: just thrown money into a fire. cj_1_08-01-2024\

_130949: yes, exactly. Terraform is gasoline to the money fire that is like AWS colin_1_08-01-2024\

_100949: Yeah. I'm sure that there are still startups, but there was one called cloudability. They probably are still around that manages your, watches your cloud spend and like detects anomalies, which I feel like in an AI world and all this, it should be so much easier, like just send all your cloud watch logs to something and be like, do you tell me if we see a spike in price or like this box is running and no traffic's going to it and you know, all that stuff. So cool. cj_1_08-01-2024\

_130949: along those lines, I like totally got saved the other day by open AI's spend limit. I think I put my platform limit at 20 bucks and I wrote a background job or I kicked off a background job to re summarize all of my articles. And, And all the podcast episodes or something, and it went through and while it was doing it, there was like a bug and sidekick was just retrying the job over and over and over until I spent 20 bucks. I was like, oops, like I just kept retrying to summarize and like when the summary came back from opening, I like wasn't going in the database because there was no field. I was like, colin_1_08-01-2024\

_100949: They're just like, throw this data away, go get it again, throw it away, go get it again. cj_1_08-01-2024\

_130949: Yeah, try again, but yeah, there was, I don't know, I've got some videos on YouTube probably from about a year ago that was how I built my like, summarization for articles on my website. It was, it's so funny looking at it because back then the context windows were so small that I had to do this crazy chunking thing where it was like break up the entire article into 20 different chunks, summarize each of the chunks and then summarize the summaries into a new summary. And now it's just just take the entire thing, throw it at GPT four. And it gives you a beautiful summary. That's a thousand times better than what we had before. colin_1_08-01-2024\

_100949: Amazing. cj_1_08-01-2024\

_130949: yeah, crazy colin_1_08-01-2024\

_100949: Yep. On the learning front, I'm very excited about the book you're reading, but I'll quickly tease mine because I just got it. I have not started reading it yet. I'm blaming Aaron Francis and, more Ian Landsman for this one, but I use Obsidian in the most messiest books. inconsistent way. And he has been running into this, trying to find the perfect notes, obsidian sinking situation. And he keeps mentioning the Paris system. So I picked up the Paris system book. I don't really want to do this like whole second brain, huge, like repository I have to keep up, but I want to add some sort of structure and I have not successfully stuck to something. So this area, the Paris stands for like project area responsibility, and then It's something else for the last A. and we'll talk about it more in the future episode I think once I get through it. cj_1_08-01-2024\

_130949: I also want to read this and I'm just now starting to get curious enough that I think I'm going to start one. Mike just showed me he's using log sack. I think, other people that I've seen use obsidian. And I was noticing that I have been taking notes that have nothing to do with work, but are like stuff about life, like people that we run into or like parents of our kids, friends that I want to be like thoughtful about. those interactions or networking and, maybe we have stuff going on with the rental property or whatever, like just things that are happening, vacation, whatever, like stuff that's happening that I want to take notes about that I want to be linked together and right now I'm literally just sending myself colin_1_08-01-2024\

_100949: yeah. We gotta upgrade that game. cj_1_08-01-2024\

_130949: I know. Yeah. And so I, part of it for me though, is that it has to be easy to update on mobile and on a desktop. and so I don't know. Yeah, maybe let's like do an colin_1_08-01-2024\

_100949: do an episode on, second braining for sure. cj_1_08-01-2024\

_130949: yes, yeah. definitely worth digging into. I was actually going to ask you right before we started about a second brand. I didn't know that Paris system was colin_1_08-01-2024\

_100949: It's one of the many, one of the many that are out there. So I'm not sure if I'll stick to it, but I've also gone down the rabbit hole of Asana and notion and people use their notion to organize their life and have all these like trackers and notes and stuff like that. And I've paid for a few of them to see like how their templates work and how that, and it becomes this. meta work again of maintaining and grooming your notion. I need a system that can get out of my way. but, yeah, I think, what book are you reading? And I'm curious how far you are because it's one of my favorite books. cj_1_08-01-2024\

_130949: Oh, really? Okay. Yeah. So I just finished this book called unreasonable hospitality. it is amazing. Mike recommended it. We're actually reading it as like a book club, like a company book club. And, yeah. So what was your introduction to this or like, how did you colin_1_08-01-2024\

_100949: So I found it, Somewhat through co working so like I guess it shouldn't be surprising but like hospitality I mean co working and hospitality is like the new buzzword right now Where everyone went from like we are community instead of just office space and then now it's like really focused on hospitality Which I think is swinging too far in another direction where they're like, you need to have baristas and like these 4, 000 espresso machines on site. And it's I know none of you are making enough money to afford this. So it's just throwing good after bad, I think. Similar to restaurants, though, you have such low margins. And what I love about this book is it comes from one of the founders of 11 Madison Park, which is on my website. bucket list of restaurants to go to. just this idea of someone expects one thing, but then you do one thing times a hundred, and you didn't need to, and you're not charging for it, you did it to bring surprise and delight. and yeah, I just think like some of the stories that they do are like, so over the top. But also so amazing. so I think it makes a lot of sense for you and, you know, in the team to be doing this, cause there's a lot there where people don't expect little moments of surprise and delight when interacting with somebody across the text message or, you know, checking into an Airbnb or, you know, any of those steps along the way are opportunities for that surprise. cj_1_08-01-2024\

_130949: Totally. the book is all about how to form authentic human connection with. The people that you're serving and that, by doing so you will see outside unexpected returns. And, so the, there are so many really fun examples throughout the book that they give about, just insane stuff that they do. you know, one example might be if someone is sitting down to dinner and they mentioned that they have to get up midway to go feed the meter. they'll just ask Oh, what does your car look like? And where'd you park? And then they'll take care of it. They're just like, go out, feed the meter for you so that you don't have to get up and go and little things like that. Also, you know, someone mentions that it's their birthday to the reservationist the day before, then when you come in, they've already like Googled your name, they know what you look like and they can welcome you by name and say happy birthday, welcome, and bring you in, take your coat. You sit down, have your dinner. And then after your dinner, they already know which coat is yours through all these different like little systems that they've built to scale their like hospitality. and yeah, I think it's, it was really inspiring. And also there's this, role at the company that they've created called a dream weaver, which is like a person who is responsible for building these ad hoc one off magical moments or like moments of delight. There was a couple of people that I worked with at Stripe, Edwin and SMCA Sam, who would go on Twitter and people would post about like their experience with Stripe and they would come up with these like crazy over the top things. And so like Chris Oliver, they sent him like this massive, like one of those giant checks. Cause he like made a joke about you know, what if the Stripe API had like this giant check thing and. Other people, they sent you know, little, there was one that I think it was like a skateboard shop or something, and they sent them like a skateboard, like a little finger skateboard deck with like their own logos. And, yeah, just like really interesting ways to, be unreasonable about how you serve your customers and how you like show up for them individually. and just build that authentic connection, which I think really goes a long way. colin_1_08-01-2024\

_100949: there was a little bit of this like movement with delivering happiness from Tony Hsieh and Zappos because they're, they also believed very much in this and it was funny because someone at the collective was like, that, that, I just read the book and there's no way that would happen. And, somehow this was in the earlier days of Twitter when you could tweet and actually cut through some of the noise, but I think he tweeted at, Zappos and GaryVee That like, I bet they won't send us a pizza and they both sent pizzas to the collective. And the funny thing was like Gary V sent a local pizza place. Someone from Gary V's team probably found a local place and sent a pizza and Zappos sent like Domino's, but we got two pizzas and, It was interesting because like we were not necessarily customers of either of them, but it was that, that, I think that was really popular and in vogue at the time of doing things that people don't expect and all that. But I think the important thing is that like they truly care about doing it. When I see it happening and some of the coworking and stuff, it's Oh, our, we got a building and we threw Ikea in it and no one's showing up. So now we're going to, Community wash and say, Oh, but we're so focused on community and they don't really mean it. And so then community was like, Oh, community didn't work. So now let's do hospitality. And it's almost like hospitality washing. It's okay, how can you, how is that possible? Like you're still offering this amazing experience, but like you can tell that they, with this dream weaver role and every little interaction, like they have baseball signs to be able to tell people things, when it's time to refill water, instead of yelling across the street. The space or having someone even have to ask for water that they're just, they're anticipating, or like we talked about earlier, like what their needs are versus doing it to make another dollar. Like they know this is going to cost them. But when you're thinking about where am I going to go to dinner for a celebration, a big moment in my life, like the meter one is a good example. The people are spending 500 a person on dinner to have to go out and put money in the meter. Seems like a mismatch of the experience. So that is a simple thing. The pizza one I really loved. We're like, we're in New York and we never got to have New York pizza. So they like send out someone, they get pizza, bring it to the chef. The chef like does it up a little bit, doesn't change it too much, but does fancy presentation and they're like, you know, here's your full dinner. But then also we wanted to really make sure you had some New York pizza before you left. cj_1_08-01-2024\

_130949: Both Colin and I have read it and remembered, several stories, but the book is just jam packed with like dozens and dozens of different stories of like how they delighted their customers. So I think it's a great way to get inspired too, if this is something that interests you about Oh, how could I do that for my. Whatever, fill in the blank business, colin_1_08-01-2024\

_100949: And it doesn't have to cost money either. Like I think some of those are expensive options, but they have high ticket customers. So like even little thoughts like, you know, in our case when members come in, like we could just say hi, but like taking that extra time, like when we do tours, I do look people up and if, especially if they're software people, cause I don't think they expect us to know who or what their companies are. And it's if we know what the company is, if, It helps because I'm in software, so I know these companies like it, it just goes a little bit further and I guarantee nine times out of 10 we end up getting that member more than if they went to some other place and they're like, didn't even have a greeting at the door and there's no one there to even figure out what the next step is. You could just meet this, the anticipation, but you're going that next step. And it could be an email. It could be a phone call. It could just be like remembering something about somebody and bringing it back around and having them be heard or seen. it doesn't have to be these huge, grandiose, things that cost money. cj_1_08-01-2024\

_130949: Yep. Totally. colin_1_08-01-2024\

_100949: Cool. cj_1_08-01-2024\

_130949: highly recommend. colin_1_08-01-2024\

_100949: Yeah. We'll put some links for sure for that one. and the Paris system we'll do the build and learn book club, the Paris system. cj_1_08-01-2024\

_130949: nice. Yeah, let's do it. colin_1_08-01-2024\

_100949: Very cj_1_08-01-2024\

_130949: You can head over to build and learn. dev to check out those links and resources and transcripts and all the notes from this episode. Thank you so much for listening and hanging out. colin_1_08-01-2024\

_100949: We'll see you next time. cj_1_08-01-2024\

_130949: Bye friends. All audio, artwork, episode descriptions and notes are property of CJ Avilla, Colin Loretz, for Build and Learn, and published with permission by Transistor, Inc. Broadcast by