Podcast appearances and mentions of chris let

In this episode of Building Texas Business, I learned valuable lessons from Patrick Terry, founder of the popular Austin-based restaurant chain P Terry's Burger Stand. Patrick explains how the company's success has been centered around its commitment to natural ingredients, competitive pricing, and exceptional customer and employee care. We explored the challenges of maintaining price discipline amidst rising costs and inflation, including during the COVID-19 pandemic. Patrick also shared insights from his origin story, hiring practices that bring on passionate individuals, and the importance of company culture. He also touched on the strategic considerations that underpin P Terry's expansion plans into new markets like Houston and the employee support programs in place. SHOW HIGHLIGHTS I discussed the inception of P Terry's Burger Stand in 2005 with founder Patrick Terry, focusing on their strategy of using high-quality, natural ingredients at competitive prices to differentiate from fast food giants like McDonald's and Starbucks. Patrick emphasized the importance of customer feedback and employee well-being in ensuring operational efficiency and customer satisfaction, without relying heavily on marketing or advertising. We explored the challenges of maintaining pricing discipline amidst inflation and supply chain disruptions, particularly during the COVID-19 pandemic, and how P Terry's managed to outperform competitors with consistent pricing strategies. Patrick shared the origin story of P Terry's, highlighting their commitment to quality food and a strategic hiring process that prioritizes employees' passion for the restaurant business. The unique approach to food preparation at P Terry's through their own commissary was discussed, showcasing how it helps maintain quality and cost control, along with their plans for expansion into Houston. We delved into the significance of company culture and employee care, including P Terry's innovative non-interest loan program for staff in financial need, as a means to foster loyalty and engagement. Patrick recounted the emotional journey of running the business, his brief hiatus from leadership in 2019, and the decision to reengage with renewed vigor, underscoring the importance of leadership in maintaining company culture. The strategic expansion from Austin to San Antonio and the considerations involved, such as logistical feasibility and location selection based on cost and accessibility, were discussed. We highlighted the balance between choosing affordable locations and ensuring they are accessible to customers, using demographic trends and growth areas to inform business decisions. Patrick shared personal anecdotes, including his early entrepreneurial ventures and the cultural philosophy at P Terry's, emphasizing the importance of setting high standards and leading by example. LINKSShow Notes Previous Episodes About BoyarMiller About P.Terry's GUESTS Patrick TerryAbout Patrick TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode you will meet Patrick Terry, founder and owner of P Terry's Burger Stand. Patrick attributes the success of P Terry's to two fundamental strategies First, work hard and listen to your customer. And second, take care of your people and they will take care of your customer. Patrick, I want to thank you for coming on Texas building Texas business and it's just a pleasure to have you on as a guest. Patrick: Well, thanks, I'm honored to be here. I really am. Chris: So I think the first place to start is for you just to tell us, those that don't know of P Terry's, what is P Terry's and kind of. What are you known for? Patrick: Well, so my wife and I started P Terry's 2005. So we'll be celebrating our 20th anniversary next month, next year, and the idea behind it we sell we're a quick service hamburger stand, and the idea behind it was if we were going to compete with, you know, the giants in the industry the McDonald's and the Burger Kings and the Jack in the Boxes and the Chick-fil-A's you know everybody. You know we're going to have to find a way to be different and you know I talk about so often. People want to get into business and they find a retail store or a restaurant or a concept that they like and they go across the street and pretty much do the same thing as the guy that they liked. And when you do that, all you've done in a best case scenario, is you take half his business. It's pretty hard to take all of his business. If you're going to do the same thing, then you're going up against the fact that he's established. Clearly he's doing okay because you liked it and he's there. And so I think that's the biggest mistake new business owners and entrepreneurs make is they like a yogurt stand and they go across the street and they do the same yogurt stand. And so, all that said we were going to be different, and where we were going to be different was that we were going to offer the quality beef and the food that we serve is really that of an upscale restaurant, to be honest and we were going to do it through a drive-thru and a dine-in at a fast food restaurant, but we weren't. Because of that, we weren't, of course, able to charge any more than the fast food guy across the street, so what we were trying to do was make ourselves bulletproof. We were going to offer a quality product that you couldn't get at a fast food restaurant at a price that was the same as the guy across the street that wasn't serving that quality food. And obviously, if you're able to pull that off, it's a huge advantage. And by doing so what we did, we established right away that we were going to look for a fair profit, and that was what it was going to be. And so if I could sell an order of French fries and I might be able to get $2.50 for that order of French fries, I looked at the cost and I'm thinking well, actually, my overall cost of goods, I only have to sell those franchise at $2.15. We have very low overhead. We have a small office with a G&A under 6% and we work hard and we work smart and we don't spend money on marketing or advertising. We don't have that luxury. We don't pay, of course, any franchise fees because we own the business. And so we were able to pull it off. And so we serve a black Angus, all natural beef, and what that means is it's antibiotic free, it's hormone free, it's a vegetarian fed, it's a pure beef. I mean it really is a great product. We serve the same thing with a hormone-free chicken. And you know, our buns don't have high fructose corn syrup. Our potatoes come from Idaho and they're fresh and they're cooked in a canola oil which doesn't have any hydrogenated oils. I mean, we literally just went down the line and said, okay, this is what we're going to do. Now we're going to have to make it work and by keeping our costs down and, frankly, working really hard, really hard with a lot of smart people, we were able to pull it off. We opened up our 34th store two weeks ago in Cibolo, outside of San Antonio, and, as you know, we're on our way to Houston. We have our first Houston location in Richmond I believe it is in October, and we're going to have five. We plan for five Houston locations. One of the other things that we do that makes this unique is that we have our own commissary. We cook we do a lot of cooking and for our restaurants ourselves, so we bake our own banana bread, we bake our own cookies from scratch, we make our own veggie burgers from scratch. We take chicken breast all chicken breast, boneless, skinless breast and we actually grind it into a patty for a chicken burger and for our chicken bites. And all that's done in the commissary by our own staff. We share the offices, share a space with the commissary, and every morning three or four trucks go out and deliver that product to the stands, and so we're able to keep our costs down by doing that as well. We pretty much just take charge of everything we do, yeah and that's what separated us. Chris: Well, it sounds like what I'm hearing is a very focused, you know thought into what you wanted this business to be and I guess what you didn't want it to be. So you know what I heard you talk about is, you know, obviously very cost conscious, so that you could be profitable, but also singular, focused on this. You know premium quality food at a lower price point and you know really it sounds like in the beginning, very focused on what profit margins would look like, what your cost of goods would be. Before you even opened a store it seems like. Patrick: Yeah, and I don't want to make it sound like we're smarter than we are, because a lot of that stuff just you know fortunately just works itself out. Now where it got tricky is when COVID hit and the supply chain issues and the inflation that we've seen and where we've benefited from that is by having always done what we've done in the last 19 years and everyone's read about. You know the McDonald's Big Mac combo meal. It's for $16 in Idaho and you know McDonald's are great operators. So I got nothing bad to say. But every time you take a price increase if you're not looking over your shoulder when you do that if you're not conscious of? am I really doing everything I can before I go up on this price? Patrick: way I can make this a nickel instead of a diamond. Unless you've done that from the start, you find yourself taking price increases to cover up mistakes or issues of the day, and it becomes this band-aid that's very hard to take off, right. Chris: We've seen that in your industry right, where the classic pass it on to the consumer, and then in the fast food wars just over the recent months, the consumers rebelling. Patrick: Absolutely, absolutely. And so when you know Starbucks and McDonald's show, you know negative comp store sales, last quarter, for the first time since you know COVID hit, we were up 8% in our compor sales. And because, frankly, when you take our strategy and you stick with it and the hard part is sticking with it it's really easy to look around and go, man, that guy over there he's getting six bucks for that burger and I'm only getting five. I could probably go up a quarter and that's the illusion, right, you get into that game and there's a mind game and if you're able to keep pushing that off and, trust me, it's a hell of a lot easier going up a quarter. When you're able to pull that off, then you don't go down that rabbit hole and find yourself in a situation where so many of our competitors have found themselves. I mean, I look around and see what similar pricing is, I mean what similar menu items are and what the pricing of our competitors are, and I'm astounded. I mean there are some of our competitors are 20 percent higher than we are on their menu, and you know we're all serving food out of a drive-thru and so it's a dangerous game. It really is. And so I think that I think you've hit on it exactly the way it is, it's a discipline and it's every day. Chris: Yeah, well, that's what Jim Collins talks about in Good to Great. You know, discipline, people with disciplined thought and disciplined action is how you get from good to great. Yeah, so let me, let me take you back, cause I mean I love the thought that went into to the concept from the beginning, but what inspired you to, in 2005, open up a hamburger stand? Patrick: Well, thank you for asking. It's almost embarrassing, I apparently. When I finally did it, a score of my friends contacted me to remind me how much I had been boring them for so many years that I had always wanted to open up a hamburger stand. And do not ask me where that came from. I have no idea, other than to say that I love the idea of serving a hamburger, french fries and a milkshake. I just, I just think that's glorious and I know that's probably way over the top, but there's something so satisfying and it's probably because it's my favorite meal that I just can't get past it. So I had always wanted to do it and I had a particular location that I had in mind and I lost it five years earlier and it sat empty for five years and finally it became available, and so that's when we opened up at Lamar and Barton Springs in Austin. Chris: I love that. Well, I mean. So, like, like any good entrepreneur, in my view, you followed your passion, your favorite meal, something that you have a passion about doing. Patrick: Let me tell you, if you don't love this business, you better not get in it, because it is consuming, it's all consuming. And so you know I look around. When I used to, you know, when I would hire somebody, I would remind them that if they didn't really love the restaurant business or what we do every day, you are not going to be happy, and if you do love it, you're going to be very happy, because we're drinking out of a fire hose here pretty much every day. Chris: Let's talk a little bit about hiring, because I think that's really regardless of the industry, really regardless of the industry. I mean, companies are made of people and you've got to get the right people to help, you know, maybe bring your vision to light, your strategies to life. What have you done over the years to make sure that you are making that right hire decision? I assume it's evolved over time and I think there's at least a couple of pieces. I'd love to maybe hear how it was starting out, but oh, yeah, it was. I know that coming out of COVID it had to be even more challenging, because people wouldn't even come to work. Patrick: Right. Well, when we first opened, the first day we opened, my wife Kathy was there and she had no restaurant experience. I had some and I put her through it. It was. You know, it was very difficult, and she likes to tell the story that she looked around the very first day and realized that there was no way we were going to do this by ourselves. And so the first three years we were in the stands every day. I mean, I worked every day, morning to night, and by doing that I got to know, obviously, everything that it took to run the stand, every position. But I also got to see the people that were there and I was able to separate the ones that were working out and the ones that weren't. And I was not a good hire at first. There is this you know, boy, it's easy to take what you think is the simple route and just put a body in place and, man, if it's the wrong body, everyone's miserable, and so it took me a while. I just had a certain, but I was not going to give in. I had a certain level of employee or stand or team member that I was, that I had envisioned, and so I wasn't going to lower the bar. And so the first three years were really difficult because a lot of people you bring in had other unfortunately had other fast food experience and they brought a lot of bad habits with them. And so you know, it's one of those deals when you hire somebody, frankly, they either have to be scared of you or they have to like you, and I'm not the guy that they're going to be scared of. That's just not the role I want to play. It's not the business I want to run. We're not always going to agree, but my hope is that we like and respect each other and respect each other. The other thing is what we learned being there every day is we learned so? Many of our employees' lives are completely different than mine. You know I've been around for a long time. I had some money in the bank. You know I had a college education, I had a career before this, so it's really easy to live in your bubble and not recognize it, and so I tell this story a lot. We had an employee, vinny and this was 18 years ago and, by the way, I'm proud to say Vinny still works for us, as do a lot of those people in those first few years. They're still with us and Vinny's truck broke down and I had worked all day and I didn't want to do his job that night, so I convinced him just to get in a cab and I would pay for the cab. And then when Vinny got there, I said what's going on with the truck? And he said well, it's going to cost $150 to get fixed and I don't have $150. So I handed him $150 and I said pay me when you can, because I need you here and I need your truck fixed Now if I'm in a corporate office, then he probably loses his job because he didn't show up. Right, right, I don't answer the phone, we don't have that conversation. So then I've lost an employee that I've had for 18 years. But, more importantly, I understand the position they're in, and so the very first thing we did from that is we created a non-interest loan program for all of our employees. So if you walk in to my office right now or you don't even have to do that you tell your manager, and the manager is going to make a phone call and you say I'm behind in my rent or I have a, you know, whatever it is, you're going to get a loan, and if it's under, if it's five hundred dollars or under, we don't even ask, we just you get it. If it's more than that, we want to know what's going on, you know. And so what we did is we made hiring easier. This is a really hard thing to do every day. The last thing I need to do is make it more difficult. So so we started by taking care of our people better than most, and they told their friends, they told their relatives, and so they understood that this is a two-way street and I'm going to take care of you, but you have to take care of me and, of course, the way you take care of me is you take care of the customer. Advert: Hello friends, this is Chris Hanslick, your Building Texas business host. Did you know that Boyer Miller, the producer of this podcast, is a business law firm that works with entrepreneurs, corporations and business leaders? Our team of attorneys serve as strategic partners to businesses by providing legal guidance to organizations of all sizes. Get to know the firm at boyMillercom. And thanks for listening to the show. Chris: That's great. I mean the idea and I think it's true in any organization. If the people that work for you think that you genuinely care about them as a person, not just that they get the job done, you're going to create loyalty and engagement with that employee. Naturally, hearing your story leads me to the question about culture. Let's talk about that. How would you describe the culture at P Terry's? Obviously, the fundamental philosophy you just described, I would assume, is some of the foundational elements of the culture that you're trying to build or have built. So what can you share about that? Patrick: Well, I'll tell you the obvious. You and your listeners already know this culture is the most important thing. There's nothing even close to second when it comes to running your business. The culture that you establish speaks for who you are, not only to your employees, but to your customers. Speaks for who you are, not only to your employees, but to your customers. There's nothing more important. I can't even think of number two. I'll tell you an interesting story very quickly. I hope it's real. I had a person call me and want to visit with me about the business, and they had a very successful online clothing company and they were about to open up stores for the first time. Everything they had always sold was online, and he asked me what it took to open the store and take care of the employees for the very first time. Right, this is all of a sudden. It's not a click, it's a conversation, and I probably talked for 15 or 20 minutes about everything we do every day for our employees. I thought I really thought his head was going to explode. I mean, he. It was so beyond the realm for him. And I get it right. This is like, and what I was trying to explain to him was you're, you may be selling the same item, but you've got an entirely different business model now. I mean, now you have, for the very first time, you have a person representing you selling that product to someone. And boy, you better get that right. And so that's really what it boils down to is understanding what we do every day and what our people do, and the culture has to be led by me. You know, I read a great line a couple of weeks ago. Somebody said to the person running the company, what's your job? And he said my job is to be right. And so when you accept that as your job and, by the way, I don't do it by myself, oh my Lord, not even close right, I mean, I've got all. I got these people around me that are just terrific, and but I certainly go to them and we certainly talk about everything. But the first thing that this has to be established is I'm here and I answer my phone and if, if you're in the hospital, I need to be there and make sure everything's okay. If you have a family member that has an issue, if there's something I can do, I got to do it. And then you have to understand everyone has to understand that there's a bar set and no one goes below the bar, and I can never go below the bar, obviously, and so it's really for me and for P Terry's, it's really by example, and if you know, dogs and kids can spot a phony a mile away. And so if you're not sincere in what you're trying to do and what you believe in and I've had some people that work for me that I could tell immediately you know you're faking it and you know you just don't feel the same way the rest of us do, and nobody wants to be in that position. So you're not happy here and I'm not happy with you here, so let's just shake hands and walk away from each other. So there's a lot of that going on, but the culture and what we do every day, the first thing we do is we just take care of our people and then we count on them to take care of the customer. Chris: Yeah, Some of what you're saying there I've heard others speak to. We certainly have that philosophy here in the business we run in this firm and that is we say we hire and fire from culture. Right, you have to know what the culture is. You have to look for the people the best you can through interview processes and hire from culture. More importantly, when you figure out someone's, you know you set the standard and you can't go below it. But if you see someone that's consistently going below it or faking it, then you've got to move fast and they need to be out of the organization. And it doesn't have to be harsh to your point. Chris: They're not happy, no one's happy. They're going to be happier somewhere else that has a different set of standards that connect with them. But you've established your standards. You've tied behavior that you can demonstrate is consistent with that that comes from the top down, and then everyone can be on the same page. Patrick: And it has to be. It's almost like, you know, being in the middle of an orchestra. You know we're all playing the song and we've all got a part to play, and if one of us, you know, drops the violin, it's not going to feel sound the same. Yeah, so true. Chris: So you know, reading up on, you know the goings on at P Terry's. I want to kind of turn the conversation a little bit to the last maybe I guess it's been four or five years you did something that is not easy for a founder to do in 2019. You decided to step down as CEO of you know, your proverbial baby let's talk about that. Obviously not the first time an entrepreneur has done that and kind of handed reins over. What led to that decision and how was it for you to kind of transition out of the CEO role? Patrick: Well, if it's okay, I want to step back a couple more years before that and talk about something that it really doesn't make the papers very often. That, and talk about something that it really doesn't make the papers very often. We had at one point I had just kind of hit a wall. I was exhausted. I was working with a kind of a person that I had next to me that was, you know, my right hand man. It was just it was. We had been going at such a pace for so long. You know, my wife and I have funded, had funded this business all by ourselves. The entire time we borrowed money but we didn't have any other investors, so everything kind of fell on us every day and the idea came up that maybe we should sell because this is just exhausting. And we did a dog and pony show and had a half a dozen legitimate buyers and we got a wonderful offer. You know, as I said to the person when I turned him down, you offered me enough money to go live on an island and I've got two little girls. I don't get to live on an island even if I wanted to. So I appreciate the offer very much and I think what I was doing when I did it, and it was sincere, I wasn't trying to waste anybody's time. But I think after the offer came in and my wife and I both agreed that we didn't want to do that. This is not how we wanted our legacy to end. I think I was looking for validation. I had never been validated for the work I had done, other than you know that the we were allowed to expand. Our business was good, our customers were very appreciative, but from an industry standpoint, I didn't know what we had created. I really didn't. I'm not the guy that I'm terrible at networking. I don't go to. I don't go to meetings, I don't go to conventions, I just I really it's not my deal, I really just work. And so I got that validation and then I made a decision that the next decision we made was do we want to leave Central Texas? You know the Austin area, and I had never done that. And so I thought well, I got some great advice one time that I don't want to learn something that somebody else has already learned, that I don't want to learn something that somebody else has already learned, and so I chose to bring somebody in with the experience of having done that, and Todd came in. Todd Korver came in. He had a great resume, same moral compass that we have here, a really good guy. And what I was finding was that, no matter what, I'm still here, and there are certain things that I'm just comfortable with, that, if I'm going to be alive and still owning the business, that it's important to me that we do every day. And so it wasn't that Todd did a bad job. It's just that I looked around and said, you know, there's stuff going on that I think we can do a little differently. Maybe we can do it better. I don't know, because I don't have all the answers, but I think I'm more comfortable in the front seat than I am in the back. The departure was amicable, he's a good guy. He's got a great job here in Austin. He's going to do very well there. But I just found that if I'm going to be in the office every day, you know I might as well do what I really want to do, and so that led to me coming back, and so, you know, I think it also gave me a new energy that I hadn't had because Todd did some heavy lifting for four years, and so we kind of have come back with the vengeance. We got the idea four days after Christmas that maybe we should really take a serious look at serving chicken bites. We compete against everybody in the business and Chick-fil-A is, you know, the leader, and so a lot of our customers had told us hey, the only fight in our family. You know, my kid wants a chicken bite at Chick-fil-A and I want a hamburger or a chicken burger from P Terry's. And so, you know, the 29th of December we had this conversation and the 16th of March they were for sale in our stores. We made them out of our own kitchen and we created them and, you know, worked on sauces and stuff, and so we've really been going very fast at that. But that you know, and I found that I'm just much more happier if I'm going to, if I'm going to be around, if it's going to still be my company. I'm just happier being the guy that's running it. Chris: I understand. Well, it had to be difficult, especially so it sounds like you stepped out of the CEO seat but stayed, I guess, involved in the company. That had to be challenging, right, it was one thing if you kind of, like you said, go to some Island or just complete a separate business, but and I, you know, I did my best. Patrick: I didn't think it was fair to, you know, be in Todd's office every day pounding the desk, going why aren't we doing this, why can't you do this? I, you know, I let him run the company because that was the only fair thing to do, but I was in the office next door and so you know, you're right, I'm not on an island and so, yeah, at some point it just was like easier for me just to do it. Chris: So let's let's talk a little bit about the expansion. You mentioned that you had expanded beyond kind of the Austin area into kind of San Antonio. You just mentioned a store in that area your plans to come to Houston you mentioned just a minute ago, and ultimately five stores, what? I want to talk about maybe have you share, is kind of what goes into that thinking of the strategy, of when it's right to kind of take those steps which I would assume are, you know, somewhat trepidatious. Patrick: Yo, absolutely, and what we found is that we were interested to see in the challenge. Absolutely, and what we found is that we were interested to see in the challenge. And you know we really had established ourselves in central Texas. We have a lot of stores here, you know we're. I mean I have there's Lamar Boulevard in Austin. I have three stores on Lamar Boulevard, you know, and about three miles apart. So we're pretty inundated and I just wanted to see, I believe that our concept traveled outside of Austin. I believe that our concept really works most places and I wanted to see what we could do. And so San Antonio made the most sense because of our commissary and our delivery, so we can be in San Antonio in just over an hour. And that made it. And, by the way, we just went down, you know, i-35 and we opened a store in Kyle and one in San Marcus and one in New Braunfels and then into San Antonio and so so from a logistics standpoint it made sense, but it was really kind of a challenge. Now, I don't, you know, there is something I truly believe in and you know I have to tell you real quickly, I spoke at a UT, at the MBA program, one time it was a wonderful class, and the professor called me after the class and he said I got to tell you the students loved it and I thank you for coming. And I said well, I appreciate that. And he said but I got to tell you I'm probably not going to be inviting you back. And I said totally fine, can you ask, can you tell me why? And he said well, there's nowhere on the syllabus that just says work hard and listen to your customers. And I said okay, well, I get it, cause that's, frankly, all I know to do, to the God's honest truth is that's all I need, that's all I know what to do. And so you know we take. What I was getting to is, at some point you take a leap of faith and you've listened to the people around you and at some point, obviously, you're the one that has to make the final decision. And then you, just you know, you trust your experience over all these years and you know you make the jump. You just make the jump. Chris: So I guess just you know, since I live in Houston, what was it about Houston that makes you think that you know again the concept travels? Why the first location in Richmond? What are some of the things there that you know, you and your team see and are excited about that you and your team see and are excited about. Patrick: So we picked that part of Houston because we could drive from Austin again for our commissary until at some point we will hopefully have a satellite commissary in Houston. But a lot of it is the loops are of interest. There's a lot of growth there, there's a lot of room for expansion and, frankly, when you get in the middle of all of your fair city it gets very expensive. So you kind of go to the loops because the land is cheaper and the leases are cheaper. So there's definitely some of that. I'm just being very honest about it. I mean, there's some great locations but I can't spend $300,000 a year on a ground lease, you know it doesn't, I think it's a well. Chris: the transparency is what we're after here, and I think, again, kind of for a listener to go look, you may have some great ideas, but be smart about that expansion. It goes back to the first thing you said. You've been mindful in this business of controlling cost, and obviously I can speak to it. You're picking locations where the population's growing, so that's not a bad thing either. Right, your demographics must line up with the things that you know makes a store successful. Patrick: And at the same time and I've got a competitor across the street from me, across the highway from me, in San Marcos, and you know he picked a really bad location and my assumption is he picked it because it was cheap. So you know there's a balance here, right? You know you got the land for $60,000 a year and the reason is because nobody can get to it, so you got to be careful about that. You know, I had a friend of mine come to me. He and his wife came to me years ago and said I think we're going to get into the restaurant business. And I said why? And he said, well, we're going to sell, I think we're going to sell sandwiches. And I said what are you going to do that? And he said, well, people have to eat. And I said yeah, but they don't have to eat at your restaurant. And unfortunately, you know there is. You know, you just have to look at this stuff so realistically. And that balance of, yeah, I'd love to be in that location, but it's a wonderful location, but it costs me so much. All I'm going to do is sell burgers and, you know, not make any money, that's right, I get to pay the landlord to sell burgers, right? Yeah, that's exactly what it is. That boy, that's a tough. That's a tough way to spend your day. Chris: Well, patrick, thank you so much for sharing the story and the ups and downs, but I'm looking forward to having a burger once you get here you said you did it in Austin, obviously, and it is as good as you described. I want to turn a little bit to just a little personal side of things. Obviously, you've said a couple of times you just know how to work hard. What was your first job, even as a kid? Patrick: So I had a lemonade, a Kool-Aid, stand in front of my, in front of our house I was probably five or six and my dad was, and my parents were always there and always had suggestions and my dad came up to me and he said you need to put the because we lived in West Texas. I grew up in Abilene and you think your summers are hot, so my dad said you need to put the temperature on the. On your poster and and I said so I wrote it's 102, kool-aid, five cents. And you know the car stopped and it was such a great idea and so I always had that influence. I said that was my probably my first inroad. I remember in seventh grade I started selling candy bars there was no you know, costco or Walmart or anything back then or Sam's to the grocery store and buy a little six-pack of Hershey's. My mom would go and take me and I started selling so many candy bars at the 10.30 break that I was messing up the senior store at noon and the superintendent called me in and told me to stop. So that's funny, all right. Chris: So this is a question I ask everyone, and I'm incredibly intrigued to get your answer, because you're the self-described hamburger guy. Right, I got to know do you prefer Tex-Mex or barbecue? Patrick: Oh, I'll go to Tex-Mex all day, okay. Chris: I'll go to Tex-Mex. Patrick: And I love barbecue, don't get me wrong. But I got to tell you if I can have chicken enchiladas with the verde sauce and a side of rice and beans. I am doing just fine. Chris: Okay, so it's your second favorite meal. Patrick: it sounds like yeah, absolutely, my poor children. I'll tell you this real quick. I know you want to wind it down. My daughter is 16 now and when she was 10, she went on a water ski camp and she spent the day. And she got in the car and she said I said what'd you have for lunch? And she said they served these submarine sandwiches. And I said, oh, what'd you get? And she said a meatball sandwich. And I said, oh, that's great. And I said you don't seem like you're in a good mood. And she said I didn't know those existed because my poor children eat P Terry's every day. So that's, you know, that's it's a family deal. I love it. Chris: It reminds me of the story of you know, it was in a movie a while back right when the parents try to tell convince the kids that yogurt was vanilla ice cream exactly. Patrick, thanks again. Really enjoyed meeting you and hearing your story. Congratulations on the success and best of luck as you expand and move into the Houston market. Patrick: I appreciate it Well. I'd love to meet you one day and grab a burger. Chris: Let's do it, in fact, let's stay in touch on when that Richmond store is open, and I'll be there. Patrick: Absolutely, absolutely, and I'll even buy. Chris: What do you think? That's a heck of a deal. Very good, well, thanks again. Patrick: Thank you, I enjoyed it very much.

In this episode of Building Texas Business, I sit down with Rob Holmes of Texas Capital Bank. Rob shares the bank's dramatic turnaround story since he became President and CEO in 2021 amid challenges, including a failed merger. Rob explains how Texas Capital improved its standing through strategic moves like fortifying capital levels and attracting talent from global institutions. We explore Texas Capital's community focus through initiatives increasing volunteerism and launching a charitable foundation. Rob highlights how their junior program brings diverse talent while nurturing a vibrant culture. Wrapping up, Rob discusses maintaining liquidity amid regional banking stress, their strong capital position, and diversification that sets them apart. SHOW HIGHLIGHTS Rob and I discuss the transformation of Texas Capital under Rob's leadership since 2021, highlighting the strategic moves that improved the bank's financial standing and attracted top-tier talent. Rob explains how Texas Capital's strong capital position and strategic diversification helped it navigate the regional banking stress of 2023. We explore Texas Capital's commitment to community engagement, including extensive volunteer hours, the founding of a new charitable foundation, and various philanthropic activities across Texas. Rob elaborates on the bank's innovative junior program, which has attracted diverse and talented professionals to Texas Capital. We discuss the importance of maintaining a respectful, collaborative workplace culture and the value of in-office collaboration for fostering a strong, healthy culture and achieving better customer outcomes. Rob shares insights on the challenges facing the banking industry, such as regulatory inconsistencies, the inverted yield curve, technology integration, and commercial real estate risks. We discuss Texas Capital's strategic initiatives to expand services, including public finance and equity research in oil and gas. Rob reflects on the lessons he has learned from his career, emphasizing the importance of candor, transparency, and servant leadership. Rob recounts personal anecdotes about his first jobs and leisure pursuits, offering a glimpse into his personal life and leadership style. We touch on the role of media in shaping perceptions of regional banks and the distinct advantages of regional banks in serving local communities and businesses. LINKSShow Notes Previous Episodes About BoyarMiller About Texas Capital GUESTS Rob HolmesAbout Rob TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode, you will meet Rob Holmes, President and CEO of Texas Capital. Rob shares an inspiring story on how Texas Capital has rebuilt itself and become the first full-service financial services institution headquartered in Texas. Rob, I want to thank you for joining me here on Building Texas Business. Welcome to the show. Thank you very much. Let's start. I know you're the CEO Building Texas Business. Welcome to the show. Thank you very much. Let's start. I know you're the CEO of Texas Capital. Tell the listeners a little bit about what Texas Capital is and the type of services it provides here in Texas. Rob: Great. Well, thank you very much for having me. So Texas Capital had a very proud founding in the late 90s by Texas business people to found a bank to serve Texas businesses with local decision making. After all, the banks failed in the late 80s and they had a very proud run and 05 went public and did very well. Then about the mid teens we kind of started going a little sideways and by the time I got there the bank needed to be kind of rebuilt and so we had a failed merger with a bank about a third our size and that tells you anything, and really because of COVID. But after that they needed new leadership and so what we did was we started over and we went fast. So we raised a perpetual deferred deal with sub-debt securitization, got out of a line of business correspondent banking that attracted a lot of capital and improved the capital by about 270 basis points in about eight weeks, and that's my bet as we run the bank very conservatively. We also brought in a lot of new talent. So the entire operating committee is new. We have a new junior program we can get into that later. But then we started on the journey to build and this is kind of interesting. I think you'll find it interesting. We're the first full service financial services firm ever to be headquartered in Texas and if you think about it it makes perfect sense. So in the 80s you had Glass-Steagall and stuff. You had a lot of big banks. They failed. They were replaced by larger institutions from out of state that saw this as a very attractive market. But the in-market banks never went into the full service direction. So regional banks are made from community banks and they get bigger and they didn't have the products and services. They just had NIM banks, if you will Sure. Chris: Well, that's an impressive thing to have a claim to being the only one headquartered in Texas. I would not have thought that, you know, given some of the other Texas yeah. So I mean you're not kidding when you said a full restart just a few years ago. Rob: Full restart. So we have think about who we're able to attract, and this says more about Texas than Texas Capital. But the woman that runs treasury services for us ran treasury services for JPMorgan Chase globally. Our chief risk officer was the head of risk for JPMorgan's investment bank and then chief risk officer was the head of risk for JP Morgan's investment bank and then chief risk officer for the commercial bank and then head of risk for real estate globally. Our head of ops was a head of ops and tech for Stan O'Neill at Merrill Lynch. The CEO Started in the mailroom, ended up reporting as CEO head of ops and tech for Merrill Lynch. I think he can do it here and that so and that just kind of it keeps going. Our CHRO came from Cilindes and our CIO has an impressive background. Our head of commercial banking all of them had bigger jobs at much larger institutions. Chris: Yeah, what that tells me, Rob, is that those people saw a bright future in the business climate in Texas to make those kind of moves to join you and the Dallas headquarters. Rob: There's no doubt about it and, by the way, I wouldn't have tried this anywhere else, I mean for sure. So, as you know, texas is eighth largest economy in the world, second largest workforce, youngest workforce, fastest growing. We've created 46,. We've created more jobs in 46 last 48 months, so it's a very attractive place to be overall? Chris: What was it about just speaking to you? I know you joined in 2021, that based on the career you had built to that moment where you saw this as the right opportunity for you. Rob: I was very happy where I was. So I was primarily in the investment bank at JPMorgan Chase, but my last 10 years I ran the large corporate bank and the commercial bank ended up taking that to 22 countries. So I ran that business. Globally it was over $180 billion in assets. It was a third treasury, a third lending and a third investment banking. Great business, great people. But when this bank kind of went sideways, I had two or three people call me and say, hey, I'm thinking about this, would you come run it? And it surprised me. I'm like, why are you calling me? But then I started looking at it and, like you, I'm from Texas. I commuted to New York for 25 of the 31 years that I worked for JP Morgan. But people kind of said, why don't you come home and build something special with where you're from? And that, through more and more dialogue, became very appealing to me and I did not know and shame on me that as bad a shape as a bank was when we got there. But it ended up being a blessing because you know like today it'd be very difficult to do what we did. I mean to have a board, investor base, regulators, constituents. Let you reinvest. We reinvested over a third of our non-interest expense and then more, and we said to the investor community and the board and others that we're going to have negative operating leverage for about a year and a half. That'd be very hard to do in this climate, right? And so the other thing we had to do became a blessing because you had to do it all at once, and so I'm glad that's behind us. Today the bank is. It used to have just mono banking, like a community or regional bank. Today we have segmentation, so you have business banking for small businesses, middle market banking for a little larger businesses, a little more sophistication, and then we have a corporate banking group like a money center bank. And when you have a corporate banking group you have to have industry expertise. So we have energy, diversified FIG, government, not-for-profit healthcare, tmt and mortgage, so we have the industry expertise of any money center bank right here in Texas. And then we have private wealth and then we rebuilt all of treasury. So it's a brand new bank. We have a new payments platform, new lockbox, new card, new merchant, new digital onboarding that we came up with. And so we people say the banks can't compete on technology like with the big bank, but we can because we have one platform. Those big banks have many platforms because they're a combination of many banks. We can go in that if you want. And then we have one platform. Those big banks have many platforms because they're a combination of many banks. We can go in that if you want. And then we have, as I said, private wealth, investment banking, and we can go into as many of those areas as you want. Chris: So you basically built it like you said. As businesses are coming to Texas, you're ready to serve whatever need they have. Rob: For sure. So we want to be very relevant to our clients and we are a one-stop shop, so you won't outgrow us. We were a top 10 arranger of bank debt for middle market companies in the years. We've done about $110 billion of notional trades in about 18 months. Wow, it's profitable. Chris: So what's your vision for the future, then for Texas Capital, and kind of, how are you working to achieve? Rob: that it's actually pretty simple. It's maturing the platform that we built. So we are the number one lender to Texas-based businesses of any Texas-based bank. Now that's new. We've had tremendous success. Business owners and decision makers love the local decision making. They love the fact that when they hire us, they're getting a very talented, experienced MD working for them instead of maybe the money center bank, whatever, a VP or something assigned to it. They just like the local decision making, local access. But the go forward strategy is People ask me this all the time what's next? And they think that we have a big bang answer. The big bang answer is delighting clients and banking the best clients in our markets, and we've always said, or I've always said we'll be defined by our clients, and so we have been blessed to have clients be attracted to the strategy and platform. So we're going to just do more of what we've done. Chris: So what I like about that strategy is the simplicity. I think there's a lesson there for entrepreneurs and other business owners in what you've done in the last few years, and that to me is get the foundation right and your core right Correct, and then do the fundamentals really well. Right, it's blocking and tackling is what you're doing. Rob: It's executing now for sure. And I had one CEO of a very renowned New York financial firm ask him to come see me. They had heard about what we were doing and he wanted to understand it because we actually we took what he would say was the very best person from his sales and trading floor who had been there 18 years. He didn't understand how we could attract that person because that person drove a U-Haul to Dallas with his wife and kids before we were even open. And he said tell me your strategy. And I went through it and, to be honest with you, I was hoping he would like it because I was pretty long the strategy. And so he did. And I said what do you think? He said I think y'all are going to be very successful. And this was early on. And I said why is that? He said do you have a differentiated strategy with differentiated talent in a differentiated market? And I think that's true. But then he said what do you think? And I said well, our talent's really. This is back in 21. Now we've done all these things, but I said that the talent is really good, but we've got to do everything with this jersey on now and delight our clients with TCB jersey, not another jersey. And he said look, rob, do it once, it'll be hard, do it three times, you'll be good. The fifth time you're an expert and I kind of he kind of and he's pretty renowned. It was a pretty simple lesson but it's kind of true. And now we have done it and we are good at what we're doing. But we still can mature the platform, that treasury platform we talked about. It's literally second to none. We're doing open banking for clients. We're doing a digital onboarding. You can open a commercial account tomorrow at a money center bank. That take eight weeks or six weeks. But that platform to scale to get the most out of it, I mean we could run it without any more investment for five years. So we got to scale the business and, by the way, it's happening. So that treasury platform is it's called P times V, price times volume that's how many transactions are going through the factory or warehouse financial transactions. That's usually for a bank it's a 2% business at best. It grows the economy, it grows the GDP. We're going 17%, quarter over quarter, year, quarter after quarter. That's remarkable Because of new clients moving to the platform. So it is scaling but we just need to continue to do that Right. Chris: So you talked about the platform a couple of times. What type of I guess technology or emerging technologies do you see having the biggest impact in the banking industry over the next, say, three to five years? Rob: I think real-time payments, I think open banking, and people don't really understand what open banking is. What open banking is? It's actually very simple, so think well, here's, here's one simple way. Part of it is you don't have to leave your internal financial platform to go to our platform. We'll put an API on yours and so you can just push a button and be into our system and send ACH or wire or what. So I think AI, I think open banking and I think real-time payments. Okay. Chris: Well, I can speak from experience, as we transitioned to Texas Capital a year ago and, to your point of the ease of that transition and being able to deal with decision makers made it seamless. Good Well thank you. It's been a great relationship for us, for sure. Rob: Good Well thank you. Chris: What you're saying is true, Well, thank you. It's been a great relationship for us for sure. Good, Well, thank you. I can attest to that. What you're saying is true, Well, thank you. Let's talk a little bit about where you see corporate leadership whether that's your C-suite or just the company as it exists and community impact. What type of initiatives is Texas Capital working on to be a meaningful member of the community? Rob: Yeah, well, that's a. Thank you very much for the for the easy pitch. So I think we do. We bat way above our weight in community impact. So we do tens of thousands of hours of employee volunteer in the community. We, as part of this transformation, when we were investing in the platform, we took time to also found our first foundation. We never had a foundation before. So we have a foundation and we do volunteer hours and we just were part of the group that bought Opal Lear Newhouse. We were the first one to open a branch in West Dallas. We gave the founding seed money for Southern Gateway in Dallas. We're big supporters of Rodeo here in Houston. Last year I think we sponsored the opening night, so I think you're going to see us pretty much all over the state of Texas in terms of giving and more than just money but time, resources, expertise to philanthropies. We hosted a great event about three weeks ago. People came from all over the country and it was for veterans and we had veteran not-for-profits and we had veteran-owned businesses and we just brought them together and talked about issues and how they could work together and synergies between the two and advancing veterans on a go-forward basis, and the people that came would just blow you away and the feedback of it. I happened to be out of town on a three-day weekend afterwards out of the country and somebody approached me and I didn't know them and they didn't know me, but I guess they'd seen my picture or something and they thanked me for having that veteran event. Wow, and so it had a far, far impact. It will do things like that. We have a nonprofit event in every city, getting nonprofits together, helping them learn how to raise money and trade best practices, and we do that and we'll do that in every city during the summer. So you know, our giving is good, Our volunteer hours are fantastic, Our sharing of expertise is good. Our investment in the community is great, Good. Chris: Let's circle back to because that kind of made me think of team building, right, so you talked about basically a wholesale change with the team around you. What are some of the things that you look for to make sure you're you know, through that recruiting and hiring process, that you're getting the right person for the position? Rob: Yep, so this is a great question and this was the key to what we've done so far and how we're going to reach our 25 goals. So in September of 21, when we announced a strategic plan, which was pretty dramatic, we said we're not going to achieve our financial goals until 25. With that came a lot of change and a lot of talent. So 80% of the people at the firm are new since I got there. That's 80% of over 2,000 people. So that's a lot of change, managing through a lot of change through a transformation, through a regional quote, unquote regional banking practice that I'd love to talk about, regional banking practice, regional banking stress that I'd love to talk about transformation. So there's a lot going on there, both internally and externally, that we had to manage through. And what we did is we started at the top and the bottom, so we put new leadership with new skill sets and new expectations and new goals of banking the best clients in our markets instead of just being a bank, etc. And we also started a junior program. It was the first junior program in the history of the bank. Chris: You mentioned that earlier, so tell us a little more about the junior program. Rob: It's awesome If you have a kid and they want to get into finance and they don't want to go to New York but they want to work at a great financial services firm to have them join us. So we post in. So I got there in January of 21. It so I got there in January 21. It's COVID Nobody's in the office. We'd just been through this internal stress with the failed merger, new CEO, the whole bit. I said we need a junior program. We posted 60 positions. We got 800 applications. We hired 60-something. A third of those had their masters. That wasn't required. The average GPA was over 374. So people love what we're doing right. The next year there's over 2,000 applicants and our junior program is great. And, by the way, I helped build one in the investment bank in my last firm and one in the commercial bank in my last firm. I thought they were both very good. This one's awesome. So you come in, you go through four or five months of training and then you go into your line of business. But we probably hired you after your internship the summer before, if that makes sense. Sure, the program has some of the diverse classes I've ever seen in banking and we didn't do that. This may be controversial. We do that on purpose. We did that because we hired the best people Exactly and they're the most diverse classes, and so we're really excited about that. And then the attrition rate there isn't nearly what we thought it would be. We built it for a higher attrition rate because those kids usually leave a large percentage after third year. Sure. They're not leaving. Rob: They like it, so that's been kind of fun. It's a good problem, right, it's a great problem and we'll use all of them. And, by the way, after that change you should just know the attrition stuff has dramatically slowed as the transformation slowed. We got all the talented people in place that we needed so we are ahead of corporate America, finance and Texas companies for attrition and excited about that in the new culture here. ADVERT Hello friends, this is Chris Hanslick, your Building Texas business host. Did you know that Boyer Miller, the producer of this podcast, is a business law firm that works with entrepreneurs, corporations and business leaders? Business law firm that works with entrepreneurs, corporations and business leaders. Our team of attorneys serve as strategic partners to businesses by providing legal guidance to organizations of all sizes. Get to know the firm at boyermillercom and thanks for listening to the show. Chris: Well that you know that low attrition rate leads to what you talked about earlier better customer experience, more stability. Rob: We need stability. Chris: Everybody needs stability. Yeah, for sure. Okay, so you mentioned regional banking stress. Tell me what you're referring to about that. Rob: Yeah, last spring of 23,. Eb failed, first Republic and the like. We were fortunate. So, november of 22, we sold a business to Truist for $3.5 billion with a very big premium on it. With the sale of that we became if you compare us to any $100 billion bank or above in the country or any Texas public bank we have the third most capital and I think in the next quarters we'll have the second most but third and we're number one in equity tangible common equity assets. So we're the least levered. We have third most capital. Our highly liquid assets are like 29% our cash and securities. Our AOCI problem, which is the mark on the bond portfolio. Banks are struggling with that. We're very good there. So our capital, our liquidity, et cetera, was very strong. So we didn't experience outflows of deposits or anything. What we did experience was a rotation, like every bank in the country, from non-interest-bearing deposits to interest-bearing deposits. So all banks if you want to call this cost of goods sold went up. But the regional banks for us the reason I wanted to come back and talk about that people call it a regional banking crisis. It was not. It had to do with certain banks were of the size that they define regional banks that had the wrong strategy, the wrong concentrations, and they failed, right. That's not because they're regional banks, right, they just happen to be that size. By the way, credit Suisse failed too. It is a global bank, right. So you know, I think this is sometimes where the media gets the message wrong and puts fear into the market, and they love it, and they love it and so I'm really proud of what the regional banks do and how they serve their clients in market and their local communities, giving back to their communities, being Main Street lenders, and I'm really proud of. You know how we do that. I think I told you before we went on the air. We're the number one lender of Texas-based businesses, of any Texas-based bank. That's a big deal because these money center banks they may be in the state or super regionals in the state or even regionals in the state but, if they decide, oh you know what, it's not okay to bank an energy company, they don't Well, guess what? We have those decisions here. We don't have somebody else deciding our social norms. Chris: Right, right, that's a great selling point. Going back to the kind of the junior program and this new team, let's talk about culture, I mean. So how would you define the culture at Texas Capitol and kind of, what do you think you've done to kind of foster that and what do you see as necessary to keep it growing? I think? Rob: the culture is transparent, curious, candid and relentless dissatisfaction, as my general counsel calls it. So, look, we've made a lot of change. We'll continue to make a lot of change. We just hired somebody to run public finance for us. We didn't have that before. Lot of change we just hired somebody to run public finance for us. We didn't have that before. We started into the foray of public equity, research and oil and gas. We're going to keep growing and building, doing things that serve our clients and our clients' needs. But the one thing that we kind of talk about a lot is and I'll say it little softer is you know just no jerks allowed. You could talk about, you can talk about Ivy League. You know culture and they have you know big words, but the simple thing is like we're gonna treat people with respect, period. Right now. You can be tough and you can be hard, but you gotta be fair, right, and you gotta be polite. And you know you can be hard but you've got to be fair and you've got to be polite and you can have high expectations while being compassionate. So we have high expectations, we are moving fast, but we do treat people with respect and we like working with one another and that's been part of the fun is, we've been in office because we think that's how you build a career and not a job, and that's how you collaborate to serve your client and that's what's best for our clients and best for employees. And we like being with one another. We don't want to work remote from a beach and not share life's experiences with our colleagues. Chris: Yeah, couldn't agree more. I mean, we got back to the office in May of 2020. I believe, and my partners here, you're a part of an organization for a reason. Organizations are a group of people together, right, correct, and we learn from each other. We can collaborate in a customer service-related industry. Like you and I are in the customer does better when we're collaborating to serve them, you and I are in the customer does better when we're collaborating to serve them, and we do that when we're together. Yep Hands down, no question. And we've been like you. We've been in office in person for a while now and you read as much as I do for the last six, seven months. You just see the pendulum swinging back because the other organizations are realizing they're losing customer satisfaction, they're losing engagement with their people. You can't have a culture if you're not together. In my view, or you can. Actually, you can have a culture. It's just not a healthy one in my view. Yeah, it's really bad, that's right. Rob: So, look, looking back, it seems like a really easy decision and, by the way, I was back in the office in 2022. But at this room, I didn't get there until January 21. Nobody's back in the office. You meant 22 as well. Yes, I did. I did. Excuse me, I did, but you know I got here in 21. We went back to office Memorial Day the Tuesday after Memorial Day of 21. And it was a harder decision then. It seems easy now Because, like even the day before, there was rumors of everybody in our ops organization that they were going to protest and walk out. You know at 901 and we decided, we made a conscious decision that this is what they're going to do and we wanted the people that wanted to be in the office right, and we may lose some people, and that's fine, and it would be harder in the short term, but the people that would be attracted to the platform and the business and us would be people that wanted careers, not jobs, and, by definition, those are the better employees, right, and I think those people attract those people and that's how we were able to transform so much while other people were sitting at home. Chris: Yeah. Now to your point. I mean, if you have a long-term strategy right, then you're willing to go through some short-term pain to get the right people that are going to help you achieve that For sure. A little bit about just your thoughts on what are some of the biggest challenges you think facing the banking industry as we sit here today and maybe for the foreseeable future. Obviously, for the last couple of years, every month everybody's watching the Fed, so that may be part of the answer. But just what do you see as the challenges? Rob: Yeah, so there's plenty for most industries though, too. So one is, and this is an excuse, but it is a challenge. The regulatory body needs to come together and be consistent and apply things consistently. That'd be helpful. We have an inverted yield curve now for the longest time, one of the longest periods in history, you know the two years four, seven something. The 10 years four two something. That makes banking very hard for a lot of technical reasons we can go into. For most banks, technology is a problem. Most banks are an aggregation of multiple banks. They're not like us that has one technology platform. That's, by the way, brand new and totally modern. Banks have not been willing to. It's been a cost cutting game because a lot of banks this is why our strategy is so good NIM banks. So net interest margin, which is loan only, the model of taking a deposit and making a loan and achieving a return above your cost of capital through cycle, I think is very difficult and that's why we supplemented our platform. You know loans, investment banking, private wealth. You know all the different things we do for a client so that we can achieve that return, because a lot of the banks to have that return would have to maybe make a riskier loan to get a higher spread or what have you? So I think the NIM banking model to get a higher spread or what have you? So I think the NIM banking model especially after spring of 23, is hard. I think the technology spend is hard. I think there's a lot of banks that have too much commercial real estate. So our commercial real estate is a very small percentage of our total capital. Regulators want you to be maybe 250 or 300%. There's a lot of banks that are 400. That's too much, yeah. And when you have that much commercial real estate, remember a lot of its construction loans, and so the construction loans. You made that decision today and you're funding it in two years. So you're going to you're that that concentration, because those paydowns are, you know, like a five-year low and commercial real estate is going to keep growing. So banks marginal loan the dollar to make the next loan. The cost just went up, so they're going to slow down their lending while the commercial real estate gets absorbed. They can't be relevant to their clients with anything other than the loan product and if they're not doing that, they're going to slow down their growth and slow down lending. They can't be relevant to their clients with anything other than the loan product, and if they're not doing that, they're going to slow down their growth and slow down lending. They don't have the margin to spend on technology. Chris: And those are some of the problems. Yeah, there's cascades, right, totally. Let's turn a little bit to just kind of you and leadership. How would you describe your leadership style today and maybe how you feel like it's evolved over your career? Rob: I think you've got to do what you want other people to do. So I'm in Houston today. We're seeing six clients we talk all the time about it's about the client, not us. Ops exists to serve a client, technology exists to serve a client. It's not for the bank. And so we have become pretty client obsessed at Texas Capital, delivering the best outcomes for our clients. I mean, like the one deal I think I told you about, we sole managed the largest debt deal in the country last year. The largest sole managed debt deal in the country last year. That's after a money center bank failed doing it. We gave the client the best advice, knowing they'd probably go with the other bank. They did. The other bank failed them. They came back to us and we did it. Now we have a client for life. So give the client the right advice, do the right thing for the client, but your people have to see you do what you want them to do. So I'm with clients. We are aggressively serving clients, but we've managed the place very conservatively. And then I think candor and transparency is really important. Chris: I think those are great qualities, anything that you could point to. I always think people I'll speak for myself, but I think I hear it in others as well a setback or failure that you encountered, that you learned from, that made you better as a leader, as a business person, anything that comes to mind, that where you look back and go, wow, that was transformational. Because of that, how long do you have? Rob: No, I think we talked about junior program, one that always comes to mind because there's early on the program of what early on my career was. When I was a junior, you know, I talked to that junior class a lot and one of the things I tell them is be careful, because you know, building your brand sometimes is too easy, like you know, if you do something great, like I had some successes early on as being a good client guy, then I was the client guy, but also my brand that I got early on was, as a junior was I wasn't very good at details and as a junior an analyst associate your only job was details Right, and so I learned the hard way that maybe I needed to focus on the details. Now I would suggest that the people that work with me think I'm too focused on the details. But that's because I learned the hard way as a junior and people corrected me Right and I'm not sure if they corrected me the wrong way or right way. That was the old days, but they certainly made an impression. So I think that was one of the things I learned is details matter and details are important, and I learned it as a junior and that stayed with me throughout my career. The other one was one I think is interesting is later on, when we were talking about a promotion, one of my bosses told me that I think this is really important for people to know, because I think it's true. He said rob, I don't it, my vote doesn't matter. The vote that matters is everybody else on the floor that works with you, because I'm not promoting you unless they want you promoted, right and so I do think that you know that's a pretty good lesson too. Chris: Yeah, kind of well servant the well, servant leadership, for sure, and that kind of team mentality For sure, team mentality. And I've said forever, I think the lessons you remember the most are the ones you learned the hard way. For sure, so the details right. Chris: So he's like I'm not going to let that happen again. For sure, that's great. Well, I appreciate you sharing those up, but I think it's a great quality leadership to have that vulnerability and humility about you for sure. So I'm going to kind of move away from the business stuff. Okay, to wrap things up, I want to know what was your first job, my? Rob: first job was uh bagging groceries and stocking grocery shelves in high school I did the same thing, did you? Chris: yeah, uh, it was hot and yeah, I tell people we had to wear like black pants. Oh, yeah, these kids get to wear shorts. Now I'm like this is going easy on them. Rob: Yeah, I think one day one of the guys got mad at me because they made me restack all the remember when people used to return the glass bottles. Yeah, and it was in a cage in the back of the alley of the grocery store. It was about 110. And nobody had organized them for about three months and I got fine job. Chris: Very good. All right, you're born and raised in Texas, so do you prefer Tex-Mex or barbecue? Rob: Both Like a brisket taco. Yeah, that's pretty good. Yeah, yeah, I like that All right. And last thing if you could take a 30-day sabbatical, where would you go and what would you do? I'd probably spend half of it fly fishing in Montana and half of it quail hunting in South Texas. There you go, Just not this time of year. Not this time of year. That's right. Chris: Rob, I want to thank you for taking the time. I mean, I had no idea the details behind the transformation at Texas Capital and obviously what you and your team are doing and have done is nothing short of remarkable. So thanks for sharing that. Rob: Well, thank you, I think you know. We think Texas does deserve its own full-service financial services firm. Chris: Well, I'm glad you're delivering it. Thank you, take care. And there we have it another great episode. Don't forget to check out the show notes at boyermiller.com forward slash podcast and you can find out more about all the ways our firm can help you at Boyermiller.com. That's it for this episode. Have a great week and we'll talk to you next time. Special Guest: Rob Holmes.

When Lee got the results back from his DNA test, he was stunned to discover that he had pages and pages of white cousins. All his life he'd been under the impression that 95% of his DNA traced to West Africa. This discovery opened up a new historical pathway, one that traces all the way back to 17th century Wales. In this episode, Lee takes us on the journey to discover his white ancestry. Later, Lee sits down with two newly-found white cousins to understand how differently history shaped the Black and White sides of one family. TranscriptLee Hawkins (host): We wanted to give a heads up that this episode includes talk of abuse and acts of violence. You can find resources on our website whathappenedinalabama.org. Listener discretion is advised.My name is Lee Hawkins, and this is What Happened In Alabama.[intro music starts]Back in 2015, I took a DNA test and found out some pretty shocking information. I always thought that I was 95% West African but it turned out that nearly 20% of my DNA was European. This revelation raised so many questions for me and led to years of research that would change my understanding of my own upbringing forever. Today I'll share that with you. We're going to go all the way back to 17th century Wales to uncover the path my ancestors took from Europe to the American South and how that, through slavery, led to me.I'll talk with experts and newly discovered white cousins to explore the history that connects the two sides. I want to find out how my family's experiences on the opposite ends of slavery and Jim Crow shaped our beliefs and our understanding of American history. But you'll get a whole lot more out of it if you go back and listen to the prologue first – that'll give you some context for putting the whole series in perspective. Do that, and then join us back here. Thanks so much. In many ways, the seeds for this project were planted in 1991, during the first trip I remember taking to Alabama.[cassette tape turning over, music starts] Tiffany: He would play an album on repeat. That's my sister, Tiffany. I call her Tiff. It's 1991, she's sitting in the backseat of our family's car, driving from Minnesota to Alabama. Tiffany: Dad used to like still stay up to date on, you know, pop culture, current music. There were certain songs that he would be like, “Oh, I like that,” you know, like Tony! Toni! Toné! It Feels Good. And things like that.My dad hated flying. He'd seen too much in his life, and he related flying to so many of the musicians he loved: Otis Redding, Stevie Ray Vaughn, Buddy Holly. They were all his contemporaries, and they all died in air crashes. So instead, we drove.I was 19 years old, and I was attending college at the University of Wisconsin Madison. At that time, I had just really gotten into the school newspaper. I was thinking about becoming a journalist or maybe a lawyer, but at that point, writing was more intriguing to me. I was excited about this family trip to Alabama, and I had no idea what was coming.Tiffany: Yeah, so Alabama, it's been kinda a, a mystery for me throughout my life because I wasn't able to ask questions that anyone would ask when you're wanting to know things about your parent.One of the big reasons my dad wanted to go to Alabama was to interview my great-Uncle Ike. He was the eldest patriarch of the family in Alabama, and he owned a farm near Greenville, dad's boyhood town. But most importantly, because he was in his 90s, he knew a lot about family history. And Dad had a lot of questions. I remember getting to Uncle Ike's and sitting in the living room, and across from me sat a caramel-skinned, white-haired man. For me, his reflection was like looking into a mirror and adding 70 years.Uncle Ike was in his early 90s, but those high cheekbones and blemish-free skin made it harder for me to believe that he was a day past 75. It was also hard to believe we were actually in Alabama, with Dad finally standing before his legendary, long-lost uncle, with a tape recorder in his hand. It was a trip we'd been talking about for months. Dad wanted to learn as much as possible about the Alabama family he left behind. Lee Sr.: Well, it's definitely, it's been a blessing to get to see you. As interested as I was in journalism, I was far from having the experience and interview skills to feel confident taking the lead. Plus, I knew that Dad needed this, so I deferred to him. The fact that he grew up there meant his questions would be far better than anything I could just randomly think of. But hearing his questions and how basic they were showed me just how far he'd strayed from his Alabama roots. Lee Sr.: Let me see, um, you were telling me about my father Lum. Now, how many brothers and sisters did he have? Most of the conversation was going over family tree details. Simple things like, how many siblings did my father have? And what were their names? We sat in that living room and asked Uncle Ike questions for just over an hour.Uncle Ike: I understand that all of them were named [unclear].Lee Sr.: Oh, we had a aunt, uh –Uncle Ike: Colby…When Uncle Ike answered, I struggled to catch every word of his southern accent. It was so thick, I thought it might even be a regional dialect, one that was unique to what my dad always humorously called, “LA,” Lower Alabama. I marveled at how quickly Uncle Ike started reciting family members. Even at his age, his recall, it was as swift as a rooster's crow at dawn! Lee Sr.: Oh yeah, Aunt Jem. I remember her…As we talked, my eyes began to drift to the fireplace, which was decorated with family photos. There, I saw a framed, weathered photo of a white man looking like he'd been plucked from a vintage Field and Stream ad. He appeared part outlaw, part GQ model. He was in hunting attire. There were hounds at his heels, and it looked like he was gripping a musket. Why, I thought, would Uncle Ike have a picture of some random white man hanging over his fireplace? Lee Sr.: Now this, what's this guy's name? Is this George Pugh up here on this picture? Uncle Ike: No, that's Isaac Pugh. Lee Sr.: That's your father? Uncle Ike: Yeah. They called him Ike, but his real name was Isaac. That made him my great-grandfather, Isaac Pugh Senior. I looked closer at the photo, into his eyes. His gaze was a determined one, as if he was daring me to look into the records and find out more. Who was this white man?[music starts]That day was more than 30 years ago. Since then, I've learned so much more about our family history. Seeing that picture of Isaac Pugh Senior on the mantel opened up an entirely new branch of my family tree – a white branch – that I had no idea existed. Digging through the records and existing research, I was able to trace that line all the way back to 17th century Wales.I recognized that I couldn't fully understand my family's experiences in America without uncovering the history of our white blood relatives on the other side of enslavement and Jim Crow. I had so many questions. Why did they come to America? What did they do when they got here? And most importantly, how were they connected to me? [sounds of a boat on water, sea gulls]In 1695, a man named Lewis Pugh boarded a boat near his hometown in Northwest Wales to sail for what was then called, “The New World.” The journey was long and grueling. Many people didn't survive. But the ones that did held on by a combination of luck and faith. Faith that the land that they were headed towards would help them prosper. He landed in Virginia, likely as an indentured servant. Several years later, he met and married a woman named Anne. The couple purchased land in Richmond County. They built a home, had seven kids, and many more grandchildren. Two of their great-grandchildren, the brothers Jesse and Lewis Pugh, decided to move south to Alabama at the start of the 19th century. The first thing they had to do was to get land. And to achieve that, they had to overcome one major obstacle. Chris: Well, it's important to remember that whites wanted Indian land from the moment they first stepped into the Americas. And so Indians have been removed since 1492, of course. This is Chris Haveman.Chris: Let me just talk briefly about terminology and the use of the word “Indian.” I've interviewed dozens and dozens of Native people throughout my career, and prior to talking to them, I always asked how they would prefer to be identified, and almost universally they say “Indian” or “American Indian.” Now, these folks tended to be a bit older, and as the younger generations come of age, the term seems to be falling out of favor, and when it does, historians including myself will adapt and adjust accordingly.He's an author of two books on the removal of Indigenous peoples from Alabama and Georgia to present-day Oklahoma, and a professor at the University of West Alabama.I've come to Professor Haveman to help me get a lay of the land in 19th century Alabama, when Jesse and Lewis Pugh arrived in the state around 1810.When the brothers got to Alabama, they were in Muscogee territory. The Muscogee were a loose union of multiple Indigenous groups, and they had millions of acres. Tribal leaders also use the name “Muscogee Nation.”Chris: Really, the story begins after the War of 1812, when whites decided that they really wanted that, that nice, nutrient rich soil in central Alabama. Over the years, throughout the 17 and early 1800s, this land was whittled away through treaties.The federal government started sending commissioners down to remove the Muscogee – and to do this, they had to coerce them into signing treaties first. This was done all over the American South and the rest of the country – and by the time the removal really got going, the Muscogee nation had already lost a large part of their land. But they were resisting. Chris: Commissioners were sent out, and Indians did not want to give up their land. And so a lot of times they resorted to threats, they resorted to some other shady tactics. And you had whites streaming into the Creek Land and they would, you know, just establish their farmstead illegally in the Creek Nation. Sometimes it would just overrun a Creek homestead and kick the family out and commandeer their crops for their, as their own. A lot of times they would get Creeks hooked on alcohol and uh, sell them merchandise on credit, get them indebted to them, and then they'd force them to give up their property as collateral. And things get really, really bad. Lee: What was the philosophy that was used to justify that? Chris: Conquest. The whites wanted it, and they were gonna take it regardless. There was no real justification, moral justification for it other than whites had the racist premise that they were civilized and the Indians were “savages” and that the whites could make better use of the land than Indians.Jesse and Lewis Pugh became landowners, both running plantations. They founded a church in Troy, Alabama, called Beulah Primitive Baptist Church. It still stands today. In my research, I found an article honoring the church. The paper hailed the brothers as “those daring ones, who braving the perils of the wilderness, came here and reclaimed this fair land from the planted savage.” The “planted savage,” I now know, refers to the Indigenous people who lived on the lands across the American South and beyond.Professor Haveman told me that on top of forced removal, there was a great deal of Muscogee land ceded by the tribe, but the conditions of these transactions make it hard to say how voluntary these handovers actually were. Chris: In 1832, the federal government gives a proposition to the Creek Indians, and they say, ‘Look, if you cede the rest of your land to us, we will allow each head of family to take 320-acre plots of land.' And this is where everything really goes downhill for the Creek Indians, because they gave up their sovereignty, uh, in exchange for a title or a deed. But what it does is basically, and I think you have to ask, it was so one-sided in favor of the federal government. You have to ask yourself, ‘Why would the Creek Indians agree to this?' And I think that they agreed to this because whites had illegally trespassed on their land so much between 1827 and 1832 that they realized that you know, whites usually liked a deed or a, you know, a title to their land, a piece of paper, something you could say, “This is my land.” And I think the Creeks tried to adopt that in order to stave off this encroachment that whites were giving on their land.So they, they had this deed and this title, and they thought that that would prevent whites from streaming onto their land, but it didn't. It actually, it just opened up massive amounts of fraud for them. And so you had 5 million acres of land in the Creek Nation in 1832. When this was ceded, all 5 million acres of land went to the federal government, and then parcels of 320 acres were then given to each Creek family. If you add up the over 6,000 families times 320 acres, it only comes out to like 2.1 million acres. And so almost 3 million acres of land will now be opened up for white settlement. And so the thing that they were trying to prevent – whites from encroaching on their land – is now gonna become legal.[music]On a January evening in 1837, Lewis Pugh was in his plantation fields in Alabama with his overseer. By this point, he owned land and enslaved people. That night, a man quietly snuck onto the roof of a house that overlooked the Pugh family cemetery on the plantation. The man fired a rifle from the top of the house, killing the overseer. Immediately afterwards, a swarm of 60 Muscogee swooped down on the plantation field. They killed Lewis, one of his sons, and an enslaved baby, who was in his mother's arms. Four enslaved men tried to defend themselves, the women, and the plantation. The Muscogee killed them too. The story captured the country. Lee: It was in every major newspaper across the country, uh, that Lewis Pugh, a prominent white settler, had been killed, um, and murdered by the Creek Indians. Why do you think it was so important that it be framed in that way? Chris: It made national news because the thing whites feared the most was an Indian uprising. And it's one of the reasons that whites who, um, had no means to become large-scale cotton planters still wanted the Indians gone because they were constantly terrified that Indians would rise up and attack them. Uh, and they had, you know, somewhat of a legitimate reason to be scared because whites treated the Indians so terribly and stole their land and, you know, created all these problems for them.It's clear that the Muscogee didn't just fold and concede their land. They retaliated, determined to defend it. And I can't help but think about it from the perspective of those enslaved people who died, fighting alongside their enslaver, to protect his life and his land – that's how closely their lives were intertwined. I'm still very curious about them, because they, too, might've been my relatives. Not long after I took that DNA test and first found out about the Pughs, I found a last will and testament belonging to Jesse Pugh, the brother of Lewis Pugh, the man who was murdered by the Muscogee in Alabama. In the will, it stated that Jesse enslaved a young girl named Charity, who was kept in bondage by the family into her adult years. Not long before Emancipation, she gave birth to a biracial son who she named Isaac Pugh. That was the white-looking man whose photo I saw on the mantel at great-Uncle Ike's house. Isaac Pugh, my great-grandfather. Doing my DNA test couldn't have been any simpler. I went online and ordered the $100 test, and the next day, I got a small box in the mail. Inside, I found a vial, and returned my saliva sample the following day. In just a few weeks, I got an email with my DNA results. It shows you who your cousins are, from first, all the way to distant. I had pages and pages of cousins, including many who were very, very white. I'm talking blond with blue eyes. There were a lot of Pughs in there. I was stunned by the sheer volume. One genealogist told me he had never seen anybody with so many pages of cousins who had also taken DNA tests. At that point, I had more than 216 fourth cousins or closer. One of the descendants was a man in his late 80s named Lloyd Pugh. We both descend from Ann and Lewis Pugh, but our relation wasn't close enough to show up on my DNA chart.Lloyd lives in Petersburg, Virginia, and last year I went to his house to meet him with my producer, Kyana. You'll sometimes hear her in the background throughout the interview.Lee: It's a nice, quaint neighborhood with a lot of brick homes in a colonial-style design typical of Virginia, I think. I met Lloyd through a man named Jim Pugh, another newly discovered cousin, but coincidentally, I've known Jim for 30 years through my early work as a journalist, back in Wisconsin. He was a PR guy for the state chamber of commerce. Every month, I called him for a comment on the employment rates. I wouldn't say we were friends back then, but we definitely liked each other. And then, through an odd twist of fate, I found out that we were related. Jim: When you reached out to me and say, “I think we're cousins,” I was like, “What?!” Let's do a call.I'd always noted that he had the same last name as my Grandma Opie, but it was only through an exchange on Facebook after I'd taken the DNA test, that Jim and I compared notes and figured out that we were both tied to the Pughs of Wales. Once Jim and I reconnected, he told me he had an elder cousin who was a family historian of sorts. That person was Lloyd Pugh.Lee: Oh, he has, okay, an American flag on his house and one on his car. [laughs] And here we are. [seat belts unbuckling] Let's go get started. Lloyd has worked on this long before genealogy exploded in the mainstream. His research is in the archives of the Library of Virginia. He has binders full of information he's gathered over the years on the Pughs. Lloyd: That book right there is one that's on the early, early Pughs. Lloyd is 88 years old. He's a tall, lean, active guy, full of warmth and southern charm. He was born and raised in Petersburg, a city known for being the site of a nine-month siege back beginning in 1864 that ended up costing the Confederacy the Civil War. Lloyd is absolutely fascinated with the Civil War, especially the Confederate side. He has tons of relics in his home, everything from swords and rifles to cannons, decommissioned bomb heads, and bullets. He also has a huge painting of General Robert E. Lee, hanging right above his couch. Lee: Why do you have a picture of General Lee in your front room? Lloyd: Because it's a part of my heritage. It has nothing to do with being anti-Black or slavery. It's just part of my heritage in that I had three grandfathers that served under Lee. [music starts]Lloyd and I couldn't be more polar opposite in our views about the Confederacy. But I didn't go to Virginia to condemn or to convert him. I went to his house to talk to him about history, our shared history. And he was interested in talking about it too. So he and his daughters invited Jim and I over, and we had a conversation that helped me understand how the white Pughs would come to shape the Black side of my family for generations. [music]Lee: Well, thank you everybody. Um, the man of the hour is Lloyd. Because Lloyd has done a tremendous amount of work around the Pugh family history. And really, I want to thank you, Lloyd, for opening up your home and showing us this museum of incredible Civil War history that you have, and also helping me gain a better understanding of my own history.Um, it's, uh, it's bittersweet to understand how we're connected, but it's also, the power of it is that I wouldn't know this history if we hadn't worked together to understand it and to identify it, and part of my goal in doing this work is to inspire other people across racial lines to do this work. Um, and it is hard, but we both love it, right? Lloyd: Right. Lee: Okay, so, uh, you've done a tremendous amount of work on the Civil War, and we'll get into that, but you've also done a lot around the Pugh family, and I think it's important to talk first about how the Pugh family got to America.Lloyd: There were actually three migrations. One migration of Pughs went to Norfolk, and from Norfolk, they went down through North Carolina, South Carolina, on into Alabama, and in that direction. Lee: That's my line. Lloyd: That's his line. Our line of Pughs landed at, uh, Richmond County, which is the upper neck over on the, uh, near the, on the east, west side of the Chesapeake Bay, and they migrated on down through, uh, came this way, Chesterfield, on to Amelia County, and eventually they end up on the, uh, east side of the Appalachian Mountains.And the third group came in, in New York, and they migrated down the west side of the Appalachian Mountains into Tennessee and Kentucky on down in that direction. So there are three distinct lines of Pughs, and I was happened to be the one that migrated down through the Chesapeake Bay into Richmond County.Lee: What did the Pughs do here initially? Lloyd: Farmers. Tobacco was king in Virginia. They raised other crops. They had to raise, uh, food crops, but the money crop was tobacco. Tobacco was critical to the expansion of the slavery economy in America, so it doesn't surprise me that the White Pughs were involved in the tobacco trade. But through talking to Lloyd, I learned more about their interactions with Black people, specifically through a man named John Boyd Pugh. He's Lloyd's great-grandfather, and he fought on the Confederate side of the war. In fact, he was so committed to the Confederacy and the slavery it represented, he refused for months – after being captured and imprisoned near the end of the war – to take the oath of allegiance to the United States. It blew me away to learn how deeply committed people I share heritage with were to white supremacy – John Boyd Pugh and others believed devoutly in it. They practiced it, and were willing to die for it. And after the war, he became an overseer for a prominent family named the Baylors.Lloyd: And the Baylor family, signers of the Declaration of Independence, founders of Baylor University, some kind of way found out about my grandfather, John Boyd Pugh, and they offered him the oversee of New Market Plantation, which is in Milford, Virginia.His salary was one fourth of all the crops, plus $50 a month salary. And so he took the job, and he moved from Albemarle County with his family up to Milford to New Market Plantation. And he was the overseer of that plantation, right there at Bowling Green, Virginia. When I heard that, my mind went back to all the books I've read in my research, including The Half Has Never Been Told, by Edward Baptist, which clearly outlined the role of overseers as the drivers of productivity on plantations, many using whipping and other torture techniques to get the most out of enslaved Black people. Baptist explained that on many plantations, overseers held the enslaved to strict quotas. They'd weigh the crops and assess the work at the end of the day, and if the quota wasn't met, the person would be whipped in front of all the other enslaved people, to make an example out of them.Hearing that I not only share heritage with enslavers, but also overseers, I was absolutely stunned. I began to see how far back the whip could be traced in my family.Lloyd stipulated that because John Boyd Pugh did his overseer work after Emancipation, he believes he probably wasn't involved in whipping. Lloyd: When John Boyd went to Newmarket, this was after the Civil War. So they had to have hired labor. And I think, I doubt that there were the whippings and the lashing and so forth when you have hired workers because they could say, “I'm leaving,” and just walk off the farm, so, yeah. To be fair, it's possible that Lloyd is right – maybe John Boyd Pugh was one of the few exceptions; an overseer who never resorted to violence. But I doubt it, and here's why: in my research, I found the archive to be packed with proof that whipping continued to be a foundational aspect of overseer duties for decades after Emancipation into Jim Crow.Lee: This is the hard part, you know, for me, because, you know, I think when I first talked with you, Jim, you were telling me that your great – great-great- grandfather was an overseer. And I didn't know – or you didn't know – what an overseer was, and when I looked at, you know, a lot of these movies that you see, the overseers are the guys that drove the production of the, of the plantation. Um, and that, for me, is just, that's inextricably tied with the capitalistic, sort of, reality of building America and how so much of the productivity was driven at the plantation level. How did you feel when I explained, especially the part that whipping was a big part of overseer work? How did you feel about that?Jim: Well, you know, you don't really know what you don't know until you find out. And that's when you learn about it, you know, 'cause you don't, you think of, um, overseeing, uh, like a agricultural operation today, you wouldn't have that 'cause you have machines, you know? So, um, but yeah, that was pretty, pretty shocking to find out about that, but it's also the reality of what, the way the world was at that time, you know. [music starts]My mind went back to that interview with my Uncle Ike in 1991, when he told us about Grandma Charity. He told us that when he was a kid working on his father, Isaac Pugh Senior's farm, she would beat the kids if she felt they weren't being productive enough. This, from a woman who was enslaved by Jesse Pugh, a cousin of John Boyd Pugh. It's almost as if, once she became emancipated and the family got its own farm, she became the overseer, and her grandchildren, the free labor. Lee: I've been always fascinated by the way, when we built our country, just how deeply rooted it was, not just in slavery, but also in the establishment of the land, how people got their land, you know, um, particularly from, from the Indigenous people.And I think that the problem, just in my opinion, is that everything is so controversial that people have decided they don't even want to even begin to study this work. And there, of course, are many, many academics who write powerfully beautiful detailed accounts of all of this history. Um, Doug Blackmon, Slavery by Another Name, um, Edward Baptist, The Half Has Never Been Told.And in a lot of this stuff, they give really detailed accounts of the economy of slavery and also the Civil War, and the way all of the different range of realities that were at stake as our country was starting to form itself into what we now know today. Um, when you study the Civil War and the Confederate side of it, what, how do you relate to that history in terms of your un– do you know anything about John Boyd Pugh or was the, the oral history lost?Lloyd: I knew absolutely nothing. No one in the family shared anything, ever shared anything with me. And what was learned, learned through my research. Clearly, family secrets are preserved on the white sides of the family, too. Dark secrets like the violent role of overseers, the fact that land was stolen, and the identity of white men who fathered Black children, were not often openly discussed. And those lies of omission make it harder for future generations of whites to acknowledge the causes of generational disparities and trauma – through ignorance or cognitive dissonance. But this work – especially the DNA testing – exposes the lies, and people doing it have to prepare themselves for unsettling discoveries. This work isn't about agreeing on everything. It's about opening up the family bibles and records to access information that neither side would have without the other. So it requires a rare form of tolerance, and a spirit of unity as opposed to division on the issue of genealogy. The truth is that I feel like I was blessed. I was fortunate to stumble on a white guy who I'd known for 30 years, and we discovered we were cousins. We already had trust between us, and he opened up the door for me to meet Lloyd. And the timing was perfect. Lee: I think for me, and especially the fact that, that you're basically a Republican dude [laughs] who, uh, you know, really like, and deeply rooted in the Republican party, um, and, and that you're a Republican dude who took me through to make this introduction so I could meet Lloyd so that we could study this together, to me, defies all of the conventional wisdom, which is that we're all divided and we're all, um, to be, you know, enemies on the other side of the issue.Jim: Well, Lee messaged me. I had posted about the, the trip where we did, we followed Lee's retreat back to Battle of White Oak Road. I think that was our last stop, and then we came home. And Lee, he said, ‘I, I see your, I think we're related.' And I said, I messaged him back and, and I'm thinking, ‘I don't want to put a bunch of this stuff in writing,' right? 'Cause I'm being like, it's not, this is sensitive stuff. I mean, we're dealing with race, and this is a war –Lee: You knew the political, the political – Jim: Yeah, I'm working in operatives, and he was working for the Wall Street Journal! And I'm thinking, ‘This is gonna be, this is not, this is gonna end bad,' right? So I, I said, “Lee…” He's like, “I think we're related.” He goes, ‘I've been doing family research. There's Willoughby and Spotsworth –.' And I said, ‘Oh, whoa, whoa, whoa, whoa. That sounds about right.' He said, ‘Can we do a call?' 'Cause I'm thinking, I want to, I want to turn off the typewriter. There's nothing good that's gonna come [Lee laughs] from this if it's typed forever and ever.And we did a call, and he's like, ‘Yeah.' And I said, ‘Well, how do you know?' He said, ‘I did 23andMe. And my DNA goes back to Wales,' and I said, ‘Well, you know, welcome to the family.' [laughter]Lee: And then I said, ‘I want my reparation.' Jim: Yeah.[laughter]And as the conversation continued, we drilled down deeper into the undeniable proof of our ancestors being enslavers, and Lloyd plainly stated the facts: Lloyd: Okay, let me, let me confirm that. I'm looking at the will of John Pugh in December 1827. His will, one negro hired by the name of Harry, worth $300. One woman, Judy, worth $200. One young man named Abram, $400. This is actually in the will, so that goes directly in our line, so there's, I mean, that's the proof of our line owning slaves.Lee: Do you feel guilty about it? Lloyd: No. Lee: Tell me what you think about it.Lloyd: It was a, it was a time. It's just like the Confederate statues in Richmond. It was history in a time, and you can't destroy it. Even though they've taken them down, they're still there in the minds of people, and they are people who are gonna keep them alive.Jim: But we're not white supremacists. Lloyd: No. Jim: We're not white supremacists, and that's the thing people need to understand. It's so easy to just shortcut from, ‘You're a conservative Republican or you're a libertarian or whatever' to, ‘You're a white supremacist,' and that's just not the case. I don't hold white people of today responsible for slavery and the actions of their ancestors. We're not responsible for the sins of our forefathers. But we should take responsibility for the present and the future by being transparent and honest about history. I know I joked with Jim about reparations, but that discussion isn't just between the white and Black families tied to slavery; it's between Black American descendants of slavery and the U.S. government, which includes states that enforced racist laws. Contrary to what many assume or imply, reparations wouldn't be about individual white citizens personally compensating Black people; it would be government obligation, funded by taxpayers like any other public expense – infrastructure, education, or foreign aid. Taxpayers don't get to opt out of funding highways they don't use, just as those from families who didn't own slaves can't opt out either. Slavery fueled America's economic rise – on the backs of Black people, largely on stolen land – a legacy from which today's Americans still benefit, no matter when they came here. [music starts]All in all, I spent two days with Lloyd, his daughters, and Jim. We had dinner and we talked a lot. He told me more about his life, like how he spent most of his career as an educator and superintendent, even helping oversee the desegregation of schools. I realized our families share many common values despite all our differences.Lee: When you hold all these documents and all the binders you've made, thinking of all the Pugh history, what do you feel?Lloyd: First of all, I feel thankful that I'm the result of all of that, that I'm able to carry on the family line. I just look at the Pugh family across the years as just good, sound, solid business people who did what they were supposed to do, and stayed out of jail, and paid their taxes, and didn't beat their families, and just good old southern Christian families is the way I look at it. The information I received from Lloyd deepened my understanding of why so many slavery-era customs appeared in my childhood. It helped me with my quest to begin to trace the whip back to the very plantation where it started. For me, that's part of where the healing comes from – not from any kind of validation I'd seek from Lloyd and Jim, but from the information that's allowed me to draw my own conclusions and undertake my own healing work. The Pugh family history is intertwined with America's story, from the Revolutionary War through the Civil War and into the Jim Crow era. Lloyd and I come from the same family, but our experiences reflect opposite sides of the American history it's rooted in. Meeting Lloyd helped me piece together our family history. It also triggered a need in me to uncover the story of how the white Pughs in America treated the most disenfranchised and exploited person in this saga, my great-great-grandmother, Charity, the matriarch of my family.That's on the next What Happened In Alabama.[outro music]CREDITSWhat Happened In Alabama is a production of American Public Media. It's written, produced and hosted by me, Lee Hawkins.Our executive producer is Erica Kraus. Our senior producer is Kyana Moghadam.Our story editor is Martina Abrahams Ilunga. Our lead writer is Jessica Kariisa.Our producers are Marcel Malekebu and Jessica Kariisa. This episode was sound designed and mixed by Marcel Malekebu. Our technical director is Derek Ramirez. Our soundtrack was composed by Ronen Lando. Our fact checker is Erika Janik.And Nick Ryan is our director of operations.Special thanks to the O'Brien Fellowship for Public Service Journalism at Marquette University; Dave Umhoefer, John Leuzzi, Andrew Amouzou and Ziyang Fu. And also thanks to our producer in Alabama, Cody Short. The executives in charge at APM are Joanne Griffith and Chandra Kavati.You can follow us on our website, whathappenedinalabama.org or on Instagram at APM Studios.Thank you for listening.

In this episode of Building Texas Business, I welcomed Jen Sudduth, CEO of Sudduth Search, for an insightful discussion on her journey in the executive search industry. Jen shared her story of transitioning from Taylor Winfield to launching her boutique firm focused on transformative growth companies. I learned how Sudduth Search crafts a supportive work culture that prioritizes both productivity and well-being. Our dialogue also uncovered nuances around balancing work responsibilities with life's pleasures. As we wrapped up, Jen reflected on life lessons from mentorship to her commitment to the Special Olympics community SHOW HIGHLIGHTS Jen Sudduth shares her transition from Taylor Winfield to founding Sudduth Search, focusing on middle market private equity and emphasizing the need for leaders who can drive change. We explore the importance of having a business and marketing strategy before starting a venture, as well as considering when to hire based on company growth and values alignment. Strategies for maintaining work-life balance in recruitment are discussed, including setting boundaries and fostering a culture that supports employee well-being alongside business success. The episode delves into the comprehensive selection process for executive search, particularly for pivotal roles such as CFOs, and the role of retained search firms in this process. Jen reflects on the role of empathy in leadership and the importance of mentorship, drawing from her own experiences and her involvement with the Special Olympics. Personal joys, such as a preference for Tex-Mex cuisine and planning for sabbatical destinations like Maine and Santa Fe, are shared as part of achieving a joyful living. The conversation covers the initial opportunistic hiring during COVID and the shift towards a more strategic hiring approach to raise the team's overall expertise. Chris and Jen discuss the benefits of leaving a company the right way, honoring agreements, and how transparency can lead to unexpected opportunities. Jen advises on the importance of planning for success, not just the startup phase, by having operational projections and growth strategies in place. The episode also touches on Jen's past experience as Director of Talent at a consultancy, highlighting how internal hiring insights can improve external recruitment advice. LINKSShow Notes Previous Episodes About BoyarMiller About Sudduth search GUESTS Jen SudduthAbout Jen TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In today's episode, you will meet Jen Sudduth, co-founder and CEO of Sudduth Search, a boutique executive search firm. Jen's advice to aspiring entrepreneurs is to be intentional and purposeful in your business planning, and don't forget to plan for success. Okay, jen, first off, welcome to Building Texas Business. Thanks for being here. Jen: Thank you. Chris: So I'm excited to have this conversation with you today. I want to start by just allowing you to introduce yourself and tell us what your company, Sudduth Search, is known for. Jen: Sure. So we are a seven-person boutique executive search firm, but I think what we do is a little bit unique. We work with the middle market private equity. Probably 75% of our clients are private equity backed. The other are public, private you name it individually owned, it doesn't matter. I think the common denominator with all of them is that all of the companies are going through some sort of transformation, and most of the time that's growth. It could have been that they raised capital. That's a trigger to bring us in and go and replace some of your leadership team. Could be some of our bigger companies going through some sort of culture change. We did 10 positions for a Blackstone-backed company and basically they wanted to pull from outside of their industry and they didn't know how to do that, and so we helped them come up with a concept of how to do that completely, you know, changed their recruiting processes from how they were doing them before, and then they brought in a whole new culture and that's what they wanted. They wanted a different culture than they had before. So it's just, it doesn't matter what the trigger is, but it's usually some sort of change, transformation. You need a leader that can drive that change right. You need someone that is fearless. A lot of times that can come in, and they're you. You know they can make things happen. Right and that's where we play most of the time. Chris: Well, what I find interesting about that is how laser focused it is what inspired you to kind of start a search firm that was so focused on that kind of niche industry. Jen: So I've actually done it for over 20 years and the firm I was with before was called Taylor Winfield. I only bring that up because a lot of people know Taylor Winfield. I started with Taylor Winfield and kind of worked my way up and that's what they focused on. They were more. You know that was 2000, so there was a lot of venture money out there, there was Silicon Valley and they worked a lot in California we did. I was just a lowly junior recruiter back then and that's where I learned the business and that's where I kind of learned that world. And it's not for everyone, both as a candidate and as a recruiter, because sometimes candidates will go well, what are they going to sell? Am I going to still have a job? I'm like, well, you're really not, you're not right for this, because that's not the mentality that we look for in a candidate. But so that's how I got my start and that's how I learned it. And then when I started this up my practice five years ago, I kind of I don't do a whole lot of venture. I have a few here and there. Usually they're a little bit more mature as a company. I think. As I've aged I'm not as patient with the venture. I think they've got a great thing going. But it's just a different world and I think sometimes those, the people that are willing to go and do something really earlier stage, are not the same people that I'm looking for the middle market series, b series, c type folks. So so that's how I had got into. It was really that's kind of what I've done my whole career. Chris: Gotcha. Well, I know that you started this company Suddeth Search around five years ago. Jen: Exactly. Chris: So you had to make some decision to leave and just start fresh on your own. Let's talk about that a little bit. What drove that decision? Jen: So the company that I worked for was actually owned by and I don't usually say this, so you're getting new information here by my stepmother, connie Adair, and I bring that up because she's fully retired now. She's been retired for about two years. But she brought me into the business, not as a multi-generational business. I had to earn my keep, earn my way Right, just like everyone else. She was very big on treating me like everyone else. Chris: The benefit for you that she did that. Jen: Absolutely and I learned from the best. She was really known as one of the best in the industry so I kind of got to see that world and that process. But she sold to private equity and it was a private equity roll up. Like some of them, it didn't go really well. The integration piece was a little rough. Chris: Not unique in that regard, right and I got no benefit from it. Jen: To be quite honest. I stuck around to try to support her and she did well. And then she got another bite of the apple and I tried for two years. I wasn't a big company person and I realized if I can make this kind of money for someone else, I should be doing it for myself. And so I kind of did it because I could, and she fully supported me. She knew that retirement was on the horizon and so when I told her she said you know, I think you should go for it. So that's what I did. Chris: That's great. Well, I mean good to have that encouragement for someone that you were close with but considered to be a trusted mentor Absolutely. So got to be a little bit trepidatious to just start out on your own, even though you know what you're doing and you, I think you can't do that unless you have confidence that it's going to work and confidence that it will work isn't a guarantee that it will Absolutely. But you know what were some of the things you did to kind of set yourself up in those early days of starting your own company, to try to pave the path towards success. Jen: So I will start with the fact that I had a very strict non-compete. I did not get any clients from the company or from her, and I am a devout follower of non-competes. Chris: Well, it's funny, you say that you bring that, yeah, you know, now we devise people, I mean literally every day, on both sides of those, and right because because they exist and obviously you know there's a lot of buzz recently because the ftc came out with the rule to ban them, uh, which is, you know, probably not going to take effect because lawsuits have already been filed to challenge it. Jen: But it's going to be interesting to see how that plays out yeah in the next, over the next few years, I think yeah, and not to say I don't think some non-competes go overboard. I have heard some ludicrous non-competes as I'm interviewing, so sure, I do think a lot of them go overboard. I think the fdc is in the is moving in the right direction with some of them, because I think they're a little too restrictive. Chris: But that's not your question yeah, and even as the rule's written, it doesn't apply to executives, so it wouldn't change your world. Jen: It wouldn't, and I'd been there a long time. Everything I got was under their umbrella. So what I did do was I planned for a long time. I've owned businesses before and so I had a business plan, I had a marketing plan, I had a strategy. The other advantage I had was that I had been I've been asked to be on the board of ACG and so that was a. I knew that was going to be great PR. It's gonna be great relationships there. That's how I met Steve Kasten here at the Boyer Miller and a few others, and so I knew that was coming. But it was pretty far out. You know my tenure had just started. Didn't know I was gonna be president, but I knew that was gonna be on the. I'd have a lot of visibility. So that helped quite a bit. I think that was one factor. Fun story unrelated to your question the day before I quit, the day before my last day, I gave like four months notice and they knew I was leaving. I was unwinding. I had some really big searches, so I was unwinding those and finishing those up for clients, kind of on the bench, but just doing that. So the day of the last day of employment I get a call from that client that I just mentioned wanted to change their culture Blackstone Back Company. He said I got 10 searches for you, jim. I said, well, I can't do them, I'm leaving, today is my last day. And he's well, I'm not doing it without you. And so I called the company and I said here's what's happening. Would you, would we, can we do a fee split? Didn't know that was coming, but that was really great cash flow. And they said yes, and so we worked out a fee split. I continued I worked with that client and then they brought in their team, but it was great cash flow right out of the gates. And and then they brought in their team, but it was great cash flow right out of the gates. And then I developed brand new clients from that point on. But I knew the industry. I think the industry knew me. Chris: So even if it wasn't somebody, I'd worked before, I had a plan and I went after those people. That's a really cool story to hear and there's a lesson. There's probably many lessons, but one that just struck me right between the eyes is the lesson in leaving the right way, when you leave a company versus leaving the wrong way and you just laid out a roadmap for the listeners. If you're thinking about leaving, you left the right way, honoring your agreements, and then, with the transparency to get the slug of business for your new business, for your new company, because you went to them and said here's the deal, because you've done everything else right. It's good to hear that. I guess they could have not honored that, but they did the right thing in my mind too, yeah, by saying yeah, it'd be fair to share this and, by the way, we should. Customer comes first. That's what they want. Let's make them happy. Jen: So customer comes first. That's what they want. Let's make them happy. So, yeah, and I completely agree and I try to tell people and I know there's exceptions, I know there's bosses that are just difficult and if they know you're even looking there, you're gone. I know that happens, but I think majority of the time people are reasonable and if you come to them and sometimes I'll have friends come to me and say I'm thinking about making a change- Grass is greener Right and I'm like I know they're in a great situation. I'm like have you had a really difficult conversation with your boss before you leave, before you start thinking about? Have you told them that you're unhappy You've been there? Chris: 14 years or you've been there seven years. Jen: Have you talked about it? And usually the answer is no, and so I try to encourage them to say go talk to them first and then if it's still you know, in a month you still feel like it's just not fulfilling then talk about leaving. Yeah, but you need to give them a chance. Chris: It's great advice. People unfortunately right. It's kind of human nature to avoid the difficult, uncomfortable conversation, or at least I'll say this, the ones we perceive have it that they're going to be difficult or uncomfortable. And to your point, I think, a lot of times if you actually have the courage to go have it, they usually aren't as difficult or uncomfortable as you work them up in your mind to be. Jen: Absolutely. Chris: And you know I can speak. You know as well as you can. If you give your employer, where you've been otherwise happy for a while, the chance to have that conversation most people if there's a tweak or two that would keep you there, it's probably going to save the company a ton of money. To consider that. Jen: And it might benefit the company. Talk to them about. You know I'd really like to do more sales. You know I'd really like to take on bigger projects. You know what We've been looking for someone that wants to take on bigger projects. You just never know what the company needs. Chris: So we can go back. You mentioned, and just for the listeners ACG Association of Corporate Growth. Jen: Yes. Chris: Indice Group industry in the kind of M&A, a lot of private equity. So sounds like part of that marketing plan was to plug yourself in to the right kind of networking system where you would meet people and build relationships. Jen: That's correct. Yeah, yeah, and I eventually was asked to be president I don't know if you know that and so it was a lot of it was a lot of visibility as well. That's half the battle. Chris: Yes. Jen: Because there's a lot of top of mind search firms out there. Yeah, getting top of mind and helping them see that. I understand private equity, I understand what their challenges are. I understand what they're trying to achieve. I understand how capital's raised. You know I've got the knowledge base to be able to convey that to candidates and to help find the right one that's going to fit that. So I think that helped a lot and it's it was educational for me. You know, going to conferences, hearing panels speak. I know a lot about a lot or a little about a lot. Chris: Let me rephrase that I shouldn't admit that, but it's true, but it does. Jen: It's real educational to hear those conversations and to hear what's happening in the market. You know from your peers that are in the organization. Chris: A couple other takeaways from what you said. That I hope people listening caught is that you had a plan before you did this right, absolutely. You sat down and put it to paper a business plan, a marketing plan, a strategy. Look, I think those are so important and can be overlooked. When people say, look, I'm just going to go chase this dream, that's great because you need the inspiration, but you also need some substance behind it, because if you eventually do go to and most will go to a bank or an investor or something, they're going to be asking about that. So you better be prepared. Jen: Absolutely. Chris: So one of the things and you and I were talking about this, I guess before we got the recording going, and that is you know about this, I guess before we got the recording going, and that is you know, you now have seven employees. Let's talk a little bit about you know. I think there's a few conversations. One is what was it that triggered you each time to make the decision Now it's time to take on an employee or another employee, because those are big investments and then how did you go about making sure they were the right fit? Jen: Yeah. So it was growth that predicated the need. That was the part I didn't plan was when am I going to hire what? You know what? At what point do we need to bring on another person? At what point do we need to bring on a junior person, et cetera, et cetera. I didn't plan that piece of it and I probably should have, but it was really just my bandwidth and being able to do what I needed to do. You know, we were super busy during COVID, which sounds really strange, but I had some. I had that one big client that was still going. I had just so, if you think about I had been in business for about a year and so that year I had been really busy doing marketing and business development and getting out there and making relationships, and so it just it paid off and I think a lot of those people one of my biggest clients I don't know if you know Dave Marchese, he'd be a good guest. Let's do it. He called me out of the blue in the middle of COVID and we had met like five years prior, but he had seen my posts and my marketing and my emails and so he said I can't go out. I'm not going to go out and interview five interview candidates, but we're in the or excuse me search firms because we're in the middle of COVID. So what you got Jen, and so I took it on, and we've probably done 15 different positions over three or four years. Wow, so he's one of our biggest clients. So there that, I think the prior relationships definitely helped us make it. You asked about employees, though. Chris: Yes, well, before we go there. Yeah, one of the things you so interesting. You said I didn't plan for growth. Yeah, probably should have. Jen: Yeah. Chris: So, looking back, what do you think you could have done in that regard that you might offer as advice to someone that you know is maybe about to do something similar that you did five years ago? You know, what have you learned? Looking back, to say I would have, if I was going to do it again, I would plan for growth in this way. Jen: Plan for success. I think I was so focused on how am I going to get there that I didn't say if, when I get there, if when I get there, how am I going to get to the next level? I never did that. I never said, okay, I can handle 12 searches, or whatever it is, at different in different phases. So if I get 14, what do I do? At what point do I, you know? Do I need to start hiring when I get to 9 searches, whatever it? So maybe it was a revenue. I think I should have projected and said, because I've been in the business a while, I know how many searches I can do by myself or with a team, and so I think that would have been very helpful to do kind of like an FB&A analysis, but on the operational side. Chris: Right, Very helpful, that's very helpful. Okay, so now let's go back to kind of set a search. You starting to decide I've hit the point, I can't do this all, I've got to bring someone on. Yeah, you know how did you go about sourcing. I know obviously you've probably had a lot of contacts, but you know just the whole process of how you interviewed to make sure they were going to be a good fit for your company. Jen: So my first hire, I got really lucky because she was a neighbor, a friend who got laid off during COVID and so we brought her on just to do some of this data pushing type stuff. She made phone calls, cold calls, she's fearless, and then she grew into being a really good recruiter. After that first hire it was, oh my God, I can't handle this. I just need a body that can help do, a professional person that can do all this. After that hire I was much more purposeful. After that it was we want experience. We want, you know, degree Now she was degreed. But we want degreed individuals that understand the business world, that understand you know degree Now she was degreed. But we want degreed individuals that understand the business world, that understand, you know. I think every time I made another hire I kind of elevated my expectations. Chris: Right. Jen: And not to say the first hire was. She was a phenomenal employee, but I think every time after that I was much more purposeful about how I, who I wanted to hire and what my expectations of them were. Chris: Yeah, that makes sense to me and you're right, it's not a condemnation of the earlier hires. It's if you're doing things right, I believe you're always learning and your processes can always get better, and it doesn't mean you didn't make bad hires before, but you can get more intentionality around the decisions you're making and I think that's part of growth and when you're a one person show or two because my husband did join me about six months in it's harder to attract talent you know, Now we're about to make an offer to a pretty senior person and we had a really good slate of people that were interested, that were like, yeah, I want to join a boutique firm, I want to do what you're doing. Jen: So it changes too. Advert: Hello friends, this is Chris Hanslick, your Building Texas business host. Did you know that Boyer Miller, the producer of this podcast, is a business law firm that works with entrepreneurs, corporations and business leaders? Our team of attorneys serve as strategic partners to businesses by providing legal guidance to organizations of all sizes. Get to know the firm at boyermillercom. And thanks for listening to the show. Well, that's validating. So you've gone through this process of sourcing people for your company, right, and what have you? What has that process and the learning? Jen: through that done to help you better advise your clients or vet candidates for them. What else about that I'm actually gonna go back to. So I took about five years. I left the executive search world and went to a consultancy and they I was director of talent. We tripled in size in about five years time and then they sold to Accenture about two years after I left. When I left, I think oil and gas was zero. The barrel, the barrel. Chris: I remember that yeah. Jen: So they made a strong comeback and then eventually sold. But being on the inside like that was the best education I could get, because it was. This is what happens when you make a really bad hire. This is what happens to the entire company when you make a really good hire. And we weren't huge I think we ended up being about a hundred but but it was really helpful to me to see. I also learned you know really short tenures on people's resume. There's a reason you know, I know there's reasons that people have to leave jobs absolutely there's good reasons, but when it's over and over and over, and then you hire that person because you're desperate for a data manager or whatever it is. You're desperate for that skill. You're going to find out why they can't stay in a job longer. I learned a lot being on the inside, you know, and I think that job is really what taught me kind of the hard knocks of making a mishire. Chris: Right. Well, I think you're to your point, right, it's if you look there are red flags, pay attention to them, and I know from our we're not perfect either in this business that I have, and you know sometimes you can convince yourself to overlook a red flag here or there, and more times than not you shouldn't. Right, there's exceptions to every rule, but we don't want to run a business based on exceptions necessarily You've got to be purposeful about those hires is really what it taught me. Jen: You know very purposeful. Chris: So just to kind of come back to Sutter's search a little bit so you have seven, about to have eight, and you talked about doing a search for a client where it was a culture change. Let's talk about culture at Sutter Search. What are you, as the kind of co-founder and CEO, doing to try to cultivate a culture? How would you describe it? And what are you doing to kind of, you know, foster it and breathe life into it? Jen: Yeah, it's hard with seven people, eight people, you know, to kind of create that, because you're like oh, we're just eight people, but they need it. Employees need training, they need to be developed, they need to evolve, they need to expand and grow, and so we actually started EOS at the beginning of this year. Are you familiar with entrepreneurial operating system? Chris: Yes. Jen: I think I don't know if Allie was the one that told me about it, but you know I've heard a lot of business owners that have done it, and so we actually started it and I think it's been evolutionary and I'm not selling it, I don't sell anything they do but it has really helped us be very purposeful about what we're doing for our employees, and so my one of our other managing directors is. She's in charge of kind of the HR and training, and so we have a weekly training every single week and it's sometimes it's heavier than others, but we have a weekly training every week and one of the employees actually gives it, so they have to go out and learn themselves and then they come and teach the rest of us. I try to. I'm a big advocate in the old school headhunting world is just dog eat, dog work, and so when I started my firm I was like I don't want to be that way. We're not working 12-hour days, we're not working both coasts, we're going to have a great and I hate to use the words work-life balance because I know it's overused. Chris: That's right. Jen: But we are, we're going to edit that part out. I'm kidding it is overused, but I think in some aspects it's important because you're a better employee if you take your vacation, if you didn't have to work until 9 pm the night before, if your managing director isn't calling you at 6 in the morning because she happens to be on the East Coast that is not the culture that we have. I'm always telling them you're going on vacation. Who's taking your emails? You're going on vacation. Who's taking your emails? You're going on vacation. Who's taking your calls? Did you put your out of? We require out of office messages to be turned on and I'm just, I'm always preaching that. I really think it's important to separate yourself and give your brain a break, because what we do is very, it's very repetitive, it's very. You know you may, if you have ten searches, that you have four candidates at least on what we usually have a hundred, but you have four finalists going through to offer yeah you think about the ups and downs every single day. Chris: It's a lot well, I mean, to your point, what you're doing, I mean, has to be stressful because you're affecting people's lives. Absolutely right, you got four candidates and or maybe see this as a great opportunity and are very hopeful, and you got a, a client, that needs to fill a hole and every day they don't have that whole field, they're losing money. So I can get that yeah to your point, the work-life balance and we could do a whole podcast on that. But I think what my experience has shown, or at least what I feel like I've learned through that, is our work-life balance is different at different times of our career. So it's hard to institutionalize that when everyone's at different stages. We try to use the term more like professional development. Developing our people to be great professionals means you tend to your business, but you tend to you have a life as well and you got to figure out how to manage both in a healthy way, knowing that the way it works for me now is totally different than it was 15 years ago right and that's okay because everything changes and we have new employees here that are going through totally different life stuff than I go through now. but how do we help give them the tools, the training to manage that and still be successful both in the office and in their personal life? Jen: Yeah, and we do we have different? Everybody kind of has a different work methodology. I shouldn't say hours, it's more like hours, you know a 20-something. They like to kind of work late in the day and have their workouts in the morning or whatever. Like everybody's kind of different. And then Hazel and I are about the same age and we like to not be disturbed until 8.30 or something. You know, like we like to go do our thing in the morning and work out and whatever. Read the paper and everybody's a little different, but we are very understanding of each other's different lifestyles. Right To your point. Chris: The key there comes to communication right. Yeah absolutely Absolutely, and so do you have. What is it that you're using as such to make sure those conversations are happening? Yeah, so that people understand how each other works differently, but together you can work for success. Jen: Yeah, we talk about it when they're hired. I say I'm not going to track your hours unless your productivity is not working Right, and then we're going to talk about it. Do you have too of a workload? Or, let's be honest, are you not working enough? You know, because last week you didn't have very many searches. This week you've got a lot. So if I need you to work till six, you gotta admit that last week you didn't have to. And they're very honest with me. A lot of times they'll say, hey, not going to be online until 10 or so, but I'm going to be working late or whatever. Or I stayed up for four hours last night sourcing. So you know I'll be available on phone but I'm not online. Perfectly okay, and we're very flexible that way. It's a little hard sometimes. You know, I'm always like are you working? I'm on the back of my brain and then I have to call myself and go. Of course they are, it's not producing. Chris: So that comes down to two fundamentals no matter what industry, communication, yeah, and what you're willing to do is have what some people might feel like is the harder conversation or uncomfortable conversation, but you approach it with kind of support and transparency. Jen: Yeah. Chris: The other thing. It comes down to productivity. Jen: Yeah, right. Chris: Absolutely. If we're running a business, we're running a for-profit business. We have to be productive to make the business go. So you can't lose sight of that. Some people, I fear at times the extracurriculars overweigh what we do to make our money and what is our. You go into the. This is what fuels our economic engine. We can't lose sight of that. It won't matter how many out-of policies or things we do, we won't have a business to support it. Jen: So it's finding a balance there, right? Yeah, I'd say the common denominator with all my employees is they thrive on success. They thrive on accomplishing things. They're not going to just shut things off if they're not done and they haven't accomplished what they set out to accomplish. They're very driven that way. That's a common denominator. Chris: Very good. So a little bit about your business. So you were saying you know, middle market focused, we're kind of approaching mid-year 2024, which is like just blows my mind that we're, you know, that far into the year already. But you know there are businesses out there that either use services like yourself or maybe contemplating that, and I know, at least in your world there's at least two different ways to go about it Retain, searches or kind of the contingency model. Can you just share maybe a little bit about what each is, the differences, pros and cons, and maybe flow into what a company should consider going one versus the other? Jen: Yeah. So I want to make it clear that I am not pro or con. Either way, I think there's a contingency, there's absolutely a place for it. I have several friends that are in the contingency recruiting world and they say I will never be in the retained world. So there is a place for it and I think if you have a large number of hires, you have a position or a company that is attractive to candidates and you want to get all the resumes you can get and then choose because they want to come to you, that's great. You can use contingency. What we do is a consultancy. So if you're a middle market working with a middle market firm right now, it's a downhole tool. Cfo position this position is critical that they get it right because they have big plans. I'm not going to tell you what those big plans are. They're private equity backed and they have big plans and it's going to happen, but if they don't have a financial expert that can devote time and devote, then it's not going to happen. And so it's critical, and in that situation you absolutely need to find the best person that you can find, and you need to interview a lot of people to make sure that you are choosing the right person, and so that's what we're doing. That's where we come in, and it doesn't have to be a CFO role. We can do. We do VPs and we do directors sure directors but we're going to look at 150 people that we know could do this job, and then we're going to reach out to every one of them and then we're going to interview 20 or 30. I'm going to interview half of those and then I'm going to present and rank the top. So it's not like we're going out and finding five people that are qualified and handing them to you. We're going out and finding 10 times that many maybe not 10 times, but a lot more than that and then finding you the best and ranking those for you to interview. So if it's a critical hire for your company to succeed, I would absolutely recommend retained, because they should be a retained firm, should be a consultancy, they should help you find that person. Chris: So that's really helpful, and hearing you describe it makes the difference very clear for me. I hope for the listeners and what I hear is you're doing a lot more upfront work on the retained side and I guess, as a consumer of these services, you should expect that your retained firm will do a lot more upfront work and vetting the best clients to bring to you. Jen: Yeah, absolutely. And the other thing I think that's important for my clients to know is our database is completely open. Our kimono is open. Is that a bad thing to say? Chris: No, we don't have video, so we're good. Jen: They can see everything we're doing, when we're doing, how we're doing. It's not a we'll talk to you in a month or two and we'll give you three great people. There's no magic thing that happens like that. It's a database they can go in. They can be like ooh, I know that guy and not going to work. Chris: Right, whatever reason, work right, whatever reason. So through, I guess, an online portal that you give them access to. Jen: okay and so it's a process to get to the fine. We meet once a week and I say here's why we chose, here's why we interview these people. What do you think? And a lot of times I'll say you know what? That company doesn't hire well, or they might be an acquisition on the horizon with that company. We can't talk to their people, so we have weekly conversations that get us closer and closer to the best person. And so it's a process, it's a very thorough process that gets us there. But that's 15, 30 minutes a week from our client, that's it. Chris: Okay, Well, they have to be invested, especially in these that are so critical. The positions to fill the client has to be invested. That's right and I like the somewhat. Maybe it's not. It sounds innovative to me that you are creating that opportunity for them to vet and see what's going on whenever they want. Right, but have those weekly check-ins. You know, it sounds like a kind of a white glove service, if you will. Jen: Yeah, and I think a lot of times people are scared, overtained. They're like what if it doesn't? What if you don't find someone? I'm like never happened in the history of 23 years, because we're talking to you and if we're not finding the right people, we're going to pivot, we're going to merge, we're going to figure out why is that happening. Is it the company reputation? Is it our pitch? Is it the way we're describing it? I mean, we're going after the wrong people. We will figure it out. We always fill the positions. Chris: Right Always, because you're invested in it. Right, right, it's not which. Jen: Because it's and it's not a. Here's three resumes, let me know. Chris: Right. Jen: That's not how it works. I got it. Chris: That makes sense. So a little bit, I just want to ask you're obviously, you know, leading this company. What, what would you or how would you describe your leadership style and how would you say that maybe has evolved over time based on your experience? Jen: So I would describe my leadership style as real. It's too real. I like to be pretty open with my employees and I have weekly calls with almost all of them I shouldn't say almost all of them. My fellow managing director we talk almost every day, so I don't have a weekly calls with almost all of them, I shouldn't say almost all of them. My fellow managing director we talk almost every day, so I don't have a weekly call with her. But the others, who I may not speak with, I have weekly calls. We talk about what's happening, what's going well, what is their workload like? I ask them what was the most challenging? Because we all work remote, so that's the other thing. We don't see each other every day right and I'll say what was the most challenging thing and what are you most proud of. And sometimes I had no idea. They're like oh well, I met that candidate at that event. I went to one of my. One of my employees told me that I'm like, I had no idea. Like you went to this networking event and happened to meet the right guy. So you know, just things like that. I try to have the communication very open yeah and they can tell me listen, I'm just not feeling well today or I'm mentally having some issues with home. I'm not going to tell you what it is, but I just need to sit back and I'm like, take the time, whatever you need to do. So I like to think I'm a pretty real manager. Chris: Yeah Well, it sounds like there's a lot of empathy that comes across in those calls, so they feel safe. Yeah, empathy, that comes across in those calls so they feel safe, and I think that's an important thing for a leader to be able to show empathy so that people will be more open and responsive, at whatever level your leadership is in the organization, is an important quality. It's interesting too, I think, that you asked about challenges, because I find it to be helpful to if you're kind of forced to reflect on what was really good about the last week and maybe what was a challenge, because we learn from both. Right, well, that's really good. Anything that you mentioned your stepmother earlier as a mentor, any learning from her that you kind of feel like you're implementing today and kind of carrying on some of the things you learned along the way from her Well, she is my free consultant, so you know, so I call her all the time. Jen: I'm like, okay, more free. Chris: Don't let her listen, she might start charging. Jen: She's fully retired, so she's like no problem. No, I think, being a peer to your clients and telling them no, sometimes you know she's not a yes man and I think I learned that, that you know you've got to push back. When you know, because of your 20 years experience, that something's wrong, you have to call the elephant in the room yeah and you have to say you, you may not skip this recruiting. You know, a lot of times my clients will get very excited about a candidate and they're like, well, can you just come see me tomorrow? And I'm like, no, he cannot because that's too fast for the candidate. They need time to process. You look too eager. I had one client that said it. He said I'm not coming to the first date with a diamond ring. You cannot come to the first date with a diamond ring, you have to let the process happen. But she was always very good about not being a yes man and I've learned that works and it pays off to help your clients be successful. Chris: It's funny that works and it pays off for to help your clients be successful. It's funny that reminds me there's an analogy that applies in all kinds of situations. But it's the cake right. So, just like you were saying, don't be too fast. Yeah, you can have all the right ingredients, mix it up, put it in the oven. If you pull it out too quick, it's going to flop yeah right. So you got to let the process, trust the process, let the process play out, and that applies in so many different aspects of business yeah, and these are humans that we're dealing with. Jen: These are people and they weren't thinking about a job change most likely. Chris: So you've got to let that change management process happen in their head, you know, let them go through that as well so good point to make and we'll repeat it that for what you're doing with these targeted executive searches, most likely the right person was not looking. The ones that are looking there could be one of those red flags there, Not always right, not always, but yeah. So, jen, this has been a fun conversation. Congratulations on your success, thank you. I want to ask you just a few things to wrap up. Yep, so obviously you've been in the search world, or executive search world, for you said 20 plus years. What was your first job? Jen: I remember you asked somebody else this, so I actually worked at a daycare for intellectually disabled kids and adults. Not that fun story that you wanted to hear, but it was fun. I absolutely loved it. I worked every summer. 0:36:20 - Chris: There had to be a lot of life lessons learned in that. Jen: Very challenging. These were kids that were not accepted at other daycares, even for special needs kids. And so I made $4.25 an hour. I was just telling this story because now I'm the chairman of the board for Special Olympics. Chris: Are you really? Jen: I am, and so they asked me my why, and I was like well, I did this for about five years, six years, all through college. I did summer camps and stuff, and so that population has a very soft spot in my heart. Chris: I love how that's come full circle in your life to be able to be doing what you're doing with Special Olympics. As an aside and maybe a plug, isn't Houston hosting the Special Olympics? Jen: next year, next year, I did not tell you that you didn't, but I just know we are right at rice, and is it 2025? Yeah, so that's a big deal, so huge those. Chris: Any listeners in houston, be on the lookout to go support that, what a great cause thank you, appreciate that all right. So my favorite question tex-mex or barbecue? Jen: tex-mex. I'm not a barbecue fan. My husband loves it, but I don't. Chris: Well, you know, you had no problem answering that question. Jen: Some people struggle so I love that In Texas only probably Right. Chris: So another question I get travel ideas from. So if you could do a 30-day sabbatical, where would you go and what would you do? Jen: Maine. Chris: Maine. Jen: We. If you could do a 30-day sabbatical, where would you go and what would you do? Maine, maine. We went to Maine last year. Oh my God, it's beautiful. We're empty nesters and so we're doing two-week working vacations. We just got back from Santa Fe and then we're hoping the next spring we're going to do Maine. Chris: Good for you. Yeah, I like that, kenny. Jen: Bunk or somewhere around there. Chris: Okay Well, you didn't let me finish a sentence, oh sorry, no, so I know you meant it right. Some people have to think about it. Jen: Oh, I knew. Yeah. Well, we're thinking about where we want to go now, so we've got a whole list. Chris: That's a fun process to go through. Yeah, it is so well, jen. Thanks again for coming. Special Guest: Jen Sudduth.

In today's episode of Building Texas Business, I chat with Sassie Duggleby, founder of Venus Aerospace, about her groundbreaking work developing hypersonic flight technology. Her vision is to connect the world through travel that spans continents in just one hour. She shares her motivation, sparked by living abroad and a desire to unite people across borders. We discuss Sassie's journey building Venus Aerospace from the ground up. She offers insights into raising capital, growing from a small team to over 70 employees, and prioritizing work-life balance for families. Sassie also talks about navigating challenges in aerospace, an evolving field with careful regulation. Our discussion delves deeper as Sassie reflects on balancing entrepreneurship and motherhood. She also addresses tackling biases facing women in STEM fields. With her tenacity, Sassie is clearing paths for others. SHOW HIGHLIGHTS Sassie Duggleby, CEO of Venus Aerospace, discusses the company's vision to revolutionize global transport with hypersonic flight, aiming to turn international travel into one-hour journeys. We explore Sassie's personal experiences, from living in Japan to leading a pioneering company, which fuel her ambition to make the world more connected through rapid travel. The conversation covers the evolution of Venus Aerospace from a small team to a 70-employee company, emphasizing the challenges and strategies of scaling a startup. Sassie shares the importance of cultivating a strong company culture that prioritizes family time and how it aligns with their vision of 'home for dinner'. We delve into the regulatory challenges faced by the company, such as securing permission for supersonic flights over land and navigating government relations. The episode touches on gender biases in the aerospace industry and how societal norms impact women, with Sassie recounting her own experiences as a female CEO. Sassie reflects on the need for potential changes in the academic system to accommodate different learning styles and to support women in STEM fields. Discussing personal challenges, Sassie emphasizes the importance of balancing motherhood with the demands of leading a startup and the intentionality required to maintain a work-life balance. A lighthearted discussion ensues about Tex-Mex versus barbecue, providing a glimpse into Sassie's personal preferences and her vision for a tech-free sabbatical in nature. We highlight Sassie's journey as a successful female entrepreneur and her contributions to the aerospace industry, particularly during International Women's Month in March 2024. LINKSShow Notes Previous Episodes About BoyarMiller About Venus Aerospace GUESTS Sassie DugglebyAbout Sassie TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode, you will meet Sassie Duggleby, co-founder and CEO of Venus Aerospace. Venus Aerospace is a startup company focused on engineering the future of hypersonic flight by making one-hour global transport possible to connect the world and make it safer. Sassy talks about the importance of cultivating a strong company culture, where at Venus, they are focused on making it home for dinner. She also shares how she balances being the CEO of a startup while also being the mother of two. Sassy, I want to welcome you on to Building Texas Business. Thank you for taking the time to be with us today. Yeah, thanks for having me so very intriguing stories. I was reading your bio and I just want to give you a chance to introduce yourself to the audience and the listeners. Tell us you know who you are and what you do. I know your company is Venus Aerospace, which sounds really cool, so let's tell us about who you are and then what Venus Aerospace is. Sassie: Yeah, so I'm the co-founder and CEO of Venus Aerospace. Venus, we are using a next generation rocket engine to enable super high speed vehicles. So what does that mean? High speed vehicles is in planes, drones, and we've got an engine that allows you to take off and get up to speeds around Mach 4. So four times the speed of sound and super efficiently cruise across the globe. You can push all the way up to Mach 9 if you really wanted to, and then come back down and land and it would let you go. You know, say, san Francisco to Tokyo in under two hours. Wow. Chris: That's a little crazy, huh yeah, so does that mean you're a true rocket scientist? Sassie: I'm actually married to a rocket scientist and I manage a ton of rocket scientists, but I would not claim that title for myself. Chris: Okay, all right, so, but you're the one of the few that would say, well, it's not rocket science, but it kind of is. Sassie: It is in this case for sure. Chris: Yeah, I love it. Okay, so that Venus Aerospace, so high speed travel. For what? For? Obviously for a normal consumer. Sassie: Yeah, so the ultimate goal is commercial travel. We have near term opportunities doing hypersonic flight testing for the Department of Defense and then hypersonic drones, kind of for national security and defense purposes, both for, you know, nato and the US Department of Defense. But that ultimate goal is you know kind of how does the world change, if you could get anywhere, you know, in two hours, you know whether it's business travel or it's, you know, delivering parts or it's, you know, global organ transplant. There's a bunch of opportunities that you know what's your time worth and if we could give you back time by helping you get across the globe faster. That's our ultimate vision. Chris: Wow, I mean that's. It is visionary. So what inspired you to get into this business? Sassie: Yeah, so prior to starting Venus, andrew and I. So we co-founded the company together. Andrew's, my husband and we were both working for Virgin Orbit, so we were launching rockets off the wings of 747s. And while we were working for Virgin Orbit, we actually deployed to Japan. So Andrew's in the Navy reserves and in the Navy he does ship repair. So I always joke why a PhD rocket scientist is doing ship repair. That's a whole different question. But 2018 was a really bad year for the Navy and there were a bunch of collisions out at sea and they couldn't get the Navy ships all the way back to the United States. They could only get them to Japan. And so he got a call in like February 2018 and said, hey, we need you Any chance you could come to Japan. And I looked at him and said, can we go? And so we pulled the kids from school, moved to Yokosuka, japan, and it was actually living in Japan that we realized you know how big the world really is. So, you know, I had, we had traveled internationally, but we'd never actually lived overseas. And so it was literally a Sunday afternoon. We were sitting out on our balcony overlooking Tokyo Bay. You could see the whole, you know American shipyard there and we were talking about my grandmother's birthday was coming up and how do we get home? Do I take the kids jet lag socks, like we were just having a normal Sunday conversation. And Andrew looks at me and he says well, you know, there's a new rocket engine coming on the pipeline. That's been theorized for about 30 years. They've been working on it at academia, at the universities, and he said I think if this engine's ever proven, I think we could put it on a plane and we could be home in an hour. And I literally laughed at him in that moment. But then he started explaining the physics to me and how the engine works and how it's way more efficient If you don't have to, if it's more efficient, you don't have to have as much fuel. And just was getting into it. And we started kind of dreaming like, well, what if this engine ever really comes along and it's proven? And so you know, fast forward, we get back to Southern California and we're back working at Virgin orbit after the deployment. And he comes home from work one day and he said, hey, purdue University, their research, one of the research labs proved this engine and it's called a rotating detonation rocket engine, which I know is a mouthful Rotating detonation rocket engine. And so this engine in an A B test. So the rocket engines that, like we use today, are only about 2% more efficient than the rocket engines that we sent, you know, astronauts to the moon with 50 years ago on the Apollo missions. So in 50 years we've gained about a 2% increase in efficiency, which is not much. Well, this engine, on the other hand, gains about 15% efficiency, and so it's just a total game changer. It's almost equivalent of going from like propellers to jets, like how much that impacted airplanes. It's the same thing. So going from a it's called a deflagration engine like a campfire burn in a chamber, which is what we've been using forever, so subsonic combustion, to detonation, which is supersonic combustion, and if you can detonate a propellant you extract more energy. It's just more efficient. And so we literally stand up that rotating detonation waves, so it rotates around and around in an annulus. If you go to our website you can see videos of it and with that detonation it's just more efficient. And so if you don't have to hear as much fuel, you can put wings and landing gear and all the things that actually would finally make kind of a rocket plane actually work. Chris: Wow, yeah, and I guess going that fast at me all I know is what I see, like on TV in the movies, that going mock speeds is challenging, I guess for pilots now, because it's only people in, you know, in jets that do it. But for passengers, I guess the cabin can be pressurized or contained where it's safe for the, or maybe that's where you're getting to, I don't know. Sassie: Yeah, well, so humans are really good at constant velocity. So once you get up to speed and you're going the same speed, I mean you know an airplane, you don't feel like you're trying to get there. I mean you don't feel like you're traveling what? 800 miles per hour across the globe or whatever the speed is. You know it's acceleration, like when you have G's, that that's what we're not as good as handling. So our vehicle, our plane experience, you would take off and it would be about kind of a 10 minutes of that takeoff experience where you're in the back of your seat, but then you'll hit constant acceleration, just like an airplane. So it's no different. I mean, think about astronauts in space or traveling what Mach 24, Mach 25, and orbit constantly, and you know that it's just the acceleration that's the hard thing. So okay, we've got one of the joys of being here in Houston is you know we've got Johnson Space Center down the road from us and you know we've had their human factors team look at you know our kind of trajectory and they've said oh, you're totally fine, you've got no problems at all. Chris: That's nothing. Right, yeah, exactly so. You have an idea and I love the story of on a balcony in Japan and just it's interesting to me because so many entrepreneurs they may not be in that same setting, but it is this conversation about an issue or a problem and how to solve it and they have the idea right and it boiled down to its basics, no different than what you and your husband were talking about. So how did you take that concept and the idea that, ok, Purdue proved it and turn that into Venus Aerospace? Sassie: Yeah. So as soon as Andrew came home and said, hey, they've proved it, I kind of looked at him. I said, do you have this? Because he intimately knew he was a former professor at Texas A&M, so we intimately knew how far academia could kind of push the technology. And we said, all right, we've got to go grab that technology and kind of pull it up and actually bring it to the world. So I incorporated the company and then I actually went and took a class on how do you raise venture capital. You know, while I have an engineering undergrad and an MBA, I had not ever, you know, raised VC money before. And so it was actually a group of women that I found they were teaching a course on how to one of the goals was to get more venture capital into the hands of female founders. So statistically, about 2% of venture funding goes to females, and so they were trying to help with that. So I took a class and learned how do you raise VC money and how to, you know, build a pitch deck and all the things. And then, as soon as we got Virgin Orbit to its first launch, we actually quit our jobs and went full time on Venus and we spent about. It took us about six months and, I think, 200 conversations, 200 pitches, until we finally, you know, found that investor that said, yes, I'm in, and we closed a seed round of $3 million in January 2021. And that was actually the same time we decided to move the company from Southern California to Houston. I'm a seventh generation Texan so wanted to get back home and Houston. One of the great things about Houston is it's got the Houston spaceport at Ellington Field and it's the Ellington Field. It's the only urban spaceport in America, which means, you know, we are literally firing rocket engines here at Ellington. You know our previous experience. You know Virgin Orbit our headquarters was Long Beach, but our testing all happened out in Mojave, and so Andrew, when he became head of launch operations, pretty much lived in Mojave. I was a single mom for a couple of years and we were, like you know, as a husband wife founding team. This is not like we have to find a place. We can do it all in one location. And Houston, you know, rose to the very top, and so we closed our seed round of funding and moved the family to Houston and it's been, you know, I really believe, the best move for what we could have done, you know, for the company. Chris: That's great. So let's talk a little bit about the challenges of raising venture capital money. I mean you obviously at 50,000 feet, you said 200 conversations before you got one bite. But you know, I have to believe. I know we have clients that go through this or come to us, you know, in the similar stage trying to capitalize on an idea of raising money around it, so they get a company off the ground. And I have to believe. Other listeners out there are curious as well. What are some of the lessons learned that you feel like you could pass on to someone that might either one help them understand what they're about to get into, or maybe it's. You know, I learned this and avoid doing this. It might make it your process easier, sure. Sassie: You know. So one of the things that Coach Tommy in learning is it only takes one, yes, right, and so you just need one person to believe in you, so kind of having that grit and just saying no, like Andrew and I knew we had a good idea, we knew we had something. One of the challenges was finding the right fit. You know so venture capitalists often have a thesis in terms of what they want to invest in. So if you're an enterprise, saas, software investor, you're probably not going to invest in a rocket company, and so it took a while for me to find, for us to find kind of those folks with the correct thesis and they get introductions to them. The other thing is we needed patient capital. So we're also not on this like super short journey. We're not going to throw a bunch of programmers in the room and, you know, spit out a program of a unicorn. You know we need time. We need time to build, we need hardware, we're capital intensive and so finding those people that understood those longer timelines, and we're okay with that. So that's one. The other thing I would say is we started off building our own pitch deck and thought surely the design doesn't matter, and fortunately we had a pretty early believer that said hey, I'm interested, I want to help you guys, but you need a better pitch deck. And so it kind of like crushed my soul to go pay a designer to build our pitch deck. But the minute we went from the one we designed ourselves to like a professionally designed one, our traction went way up. And so it and I look back in the pitch deck we have was horrible. In the pitch deck the designer built was beautiful. And so you know, I'm actually glad, I'm very glad we sent the money. Chris: I think that you know there's a lesson there for sure in the way I've seen it play out in a number of different scenarios with kind of startups because you need to figure out what's truly an expense versus an investment in the future of your business right and what you just described and hiring that professional. You're trying to say I can do this myself, I'm going to save a little money, but the investment you made, even though it seemed like an expense you probably were questioning whether you could afford, is actually a smart investment. That the return on that was crazy. And you know I can analogize that. Sometimes the startup legal stuff we tell clients or potential clients look, you're investing dollars, even though it seems like an expense on legal, but you're investing dollars and making sure your company's set up right. That will help you going forward. Sassie: Absolutely I completely agree. Chris: So you got the pitch deck going and and then I guess you continued on the road to pitch the idea to people. I also love kind of what you said about the honesty and being direct about what your business was and what this investment would look like and what it wasn't right. You weren't going to be returning a profit or return on the investment anytime soon. So you that I think you said someone paid capital or patient capital. Yeah, I love that. So you got that going. It was January, I guess, 2021, you said. And so take us now. How many employees have you grown to? Sassie: Yeah, so we're. You know that was January 21, 21, we're what? In March 24. So it's been three years. We've scaled about 70 full-time employees and we scaled really quickly. You know we did a $3 million seed and, what was fascinating, the minute our main investors are called Prime Movers Lab for our seed round put out a why we invested in Venus Aerospace. We got an incredible amount of well we would have invested. We would have invested. So we ended up capturing another 10 million in safes, so simple agreements for future equity. You know, built for a year and then the Prime Movers Lab actually did a preemptive A. They were like you guys are crushing it, here's 20 million more, keep going. And so, yeah, so we scaled pretty quick up to, you know, 50 ish. And that was an incredible challenge, like going from three where it's three people and a PowerPoint presentation, to 50 to 70 people like you. Just, you know you go. You've got to learn how to communicate better. It's no longer sitting around a kitchen table. You know. We literally started the company at our house and so everybody knew what was going on. Everybody was connected. I think once we hit 15 employees, we were like we have to find a location because we had two new people coming and we did not have a single spot in our house to put them Like we were about to start using our kids' bedrooms, and so that was the trigger. That was like, all right, we, you know, we ended up finding the hanger at Allington. But yeah, scaling is a fascinating, you know, and every stage, you know, it just gets a little bit different the minute you think you have it figured out. You grow again, and so we've started about 70 now for the last year, which I think has actually been really healthy for us because it's allowed us to build kind of better systems and processes into the organization for decision-making and for budgeting and all the things that I think will help us as we go to raise our next round of capital and want to really accelerate and start building, you know, mach 5 drones. We've got all the pieces in place to help us with that. Chris: So that you know you described, I think, any fast-moving business the challenges that scalability and managing it right, keeping your arms around it so it doesn't get out of control. I guess that's very hyper growth that you went through. So what were some of the things that you had to do through the hiring process to make sure you were making smart decisions on these hires while you were still trying to build processes and systems in place to kind of manage it once they were all there? Sassie: Yeah, you know, one of the things we early on put we call it the Venus values into place, kind of our culture and who we are and how we operate is just as important to us as the technology that we're building, and so we call it the Venus flight plan and so every kind of and it's all related to, you know, flight. But we do a lot of, we did a lot of culture. Yes, we want to make sure you can fit technically and can you do the skills, but then are you going to be a cultural fit? And so you know, even from an interview perspective, we'd have people doing technical interviews and understanding their technical skills. But then a cultural fit, are they really going to fit in culturally? And I actually think that is key. And then I do tons like I'm constantly I feel like I'm a broken record but talking about our values and who we are and how we're going to treat people, you know, I think the aerospace industry as a whole is often very broken. It was born out of war and it's. You know, I found myself at 38 as the oldest female engineer at Virgin Orbit and I don't know, I don't think 38 is that old. Chris: So I don't think so either. It seems like we're getting young, right now. Sassie: Yeah, so you look around the room and there'd be a ton of, you know, 25 year old female engineers a few 30, and by the time they're 40, they're all gone. And so you know we it was like what's wrong with the industry that you know there's no 40 year old engineers, that they all flee. And so we were very intentional. I mean, we actually named the company Venus because she's the only female planet. All the other planets Mars, jupiter, saturn, mercury they're all Roman gods, whereas Venus is a Roman goddess, and then she's also the goddess of love, and so we have a premise of like what would it actually look like if we love our employees as well? And so you know that's. I think that's been one of the key tenants of like kind of who we are as a company. You know we want to build that family friendly, female friendly aerospace company and that you know those shouldn't be in dissonance with one another, but they often are. Yeah, that's brilliant. Chris: Yeah, what you kind of started with. And to totally agree, culture's keen and I think it's important you know that. You emphasize that in the way you did and I hope our listeners took note. We believe here is the same thing. When we hire, yes, you have to have the technical skills and that's kind of a given and you can interview for that and test for, you know, while someone's here, through your training programs and whatnot. But culture, it doesn't matter how good you are technically, if you're not a cultural fit, you will never work. If the company is really committed to culture, right With this inclusive and loving the employees and wanting that environment where people want to be. Actually, I think Jack Welch said it, if you have a real high performer, that's not a cultural fit. He calls that cancer, right, and that can. We all know what cancer can do to things. So you can't allow that into your organization. But I think it's great with your focus on that. So what are some of the things that you do to make sure the culture is one defined but two cultivated and nurtured? Sassie: Yeah, so we do, you know, values shout outs. I mean, everybody has the Venus flight plan. I literally have it here on a mouse pad, you know. It's like this is who we are, it's on our website, it's on our screen savers kind of plastering around, and then we do a lot of Venus values shout outs. So we have like kind of managers and we expect like we want shout outs on certain places. You know we do awards. Anytime I send a communications email out to the company, I always, like, put some reminder about a Venus value. So I've just I just constantly say that, say it over and over, like this is who we are, this is how we operate. I feel like sometimes I'm a broken record, but you know they say you have to say something seven times before someone really hears it, and that's been a huge lesson for me, Like things that I feel like, oh, it's obvious, this is what we're going to go do as a company. This is our strategic goal. Well, I'm talking about it all the time to investors, but I realized sometimes, you know, our team might not be hearing it, and so that's been. Probably one of the biggest learnings is just how often you just have to say the same things over and over again. Chris: Yeah, I think you're right. I think it's that repetition and certainly top down, it has to be at the tops to become to infiltrate the entire organization. And I believe what I've experienced here is when you start tying your values and the behavior that you say defines your culture to behaviors that others in the organization are doing, so your shout outs as an example, right, when you say you know, jane did such a great job on this task and it demonstrated this value, right, people start personalizing going. Okay, I see what that value means in action. That's. I think that's great. And you said something there at the end I think is so true, cause your job is so external sometimes and I can relate to this you sometimes forget how important it is to make sure all those great things you say externally to keep the company going, that you're saying them internally to remind everyone how great the organization is and you know how important it is to keep this thing going. Oh for sure, for sure, what? Let's talk a little bit just about any challenges you've faced getting this company up and going and kind of what the lessons learned have from that and how it's kind of made you or the company stronger, cause you went through a rough patch or two. Sassie: You know, I say one of our biggest challenges we've been hitting is regulatory. So we're trying to fly a supersonic. Well, we actually flew a supersonic capable drone a couple weeks ago but we had to throttle it down to below Mach 1 because we didn't have the regulatory clearance to fly supersonic. It's illegal to fly supersonic over land without authority. Yeah, I mean the sonic boom does. It's legit, it does make a noise and so you know, they outlawed that back, I think the 50s or 60s, and so there are places, there are ranges in the United States that you can fly those speeds, but you have to get government approval and it's, you know it's been. Yes, you can go fly here, but it'll be three years. Well, we're a startup in three years like we're out of cash or we're growing super fast, and so that's regulatory hurdles have probably been one of our biggest challenges. That I kind of didn't expect. And then you know we're building technology that right now is one of the top priorities for the Department of Defense, and so in my mind you would think that DoD would be just throwing cash at us, but it's been very small. You know, we've got a little bit of DARPA money and a little bit of NASA money and a little bit of AFWARX Air Force money, you know, but not to the extent of what you know, based on the priorities of what you would think it is. And so I've had to learn, like, how do you play the DoD kind of Congress lobbying game and I call it a game because I feel like it is a game- and so I don't. Chris: I don't envy you at all, but I game, I think is the right way to say it sadly. Sassie: Yeah. So you know kind of learning that it's not necessarily a meritocracy, it's not the best technology wins, but it's. You know, do you have the right relationships? And were you in Capitol Hill at this time and we've been talking to this person? And the minute you build that relationship, then that person leaves that group and then you got to start over again. And so I joke, I've learned. I've had to learn how Adventure Capital World works and then the minute I figured that out, it's like now I've had to go figure out you know how congressional budgets and DoD and how all that works, and you know. So it's been. I've learned more in the last three years than I've learned, I think, in my previous 40, just because it's fascinating, but it's been a lot harder, I think. In my mind I thought the DoD, like if you build great tech, they will come, and that's not necessarily the case, and so we've had to start really building the right relationships and brought in a team that knows how to do government relations and so it's been a big learning curve. Chris: Yeah, you hate to hear that bureaucracy can get in the way of something so innovative and potentially transformative, but at the same time, I don't know anyone's gonna be shocked by that either. Right, it's kind of a sad statement. Sassie: Right, and there are lots. I've got to give the DoD credit. There's lots of groups are really pushing on innovation and recognizing that hey, we need to change and you know, one of the things that makes America great is our innovative ecosystem and how we can. You know the startup world and the venture capital and you know what happens in Silicon Valley and other places, and so there are definitely folks within the Department of Defense that recognize that's kind of the. That's what the US is, super power is, and how do we leverage it. But it's just a really slow flywheel and we'll get there. I know, because I know what we are building is so important that you know we'll be able to knock down the right barriers. But it's just been. It's been harder than I think I expected it was going to be. Chris: Yeah, it seems that way. So, as you were talking about that, I'm curious are there competitors to Venus out there, like others, that either have a similar or they've gotten permission to use the same technology, and not just necessarily in the US and other countries? Is this kind of like a you know back, going back to the 50s and 60s, when it was a race, you know, us and Russia were racing to the moon? Sassie: So in terms within the United States, you know. So, venus, our whole premise is that if you want to go really fast with a plane, instead of being a fast jet you should be a slow rocket. You know so our last rocket went mock, like when we were at Virgin orbit. It would go mock 10, split in half and then go on to mock 25. And so you know, when we're seeing mock four or even mock nine, that's slow compared to what our last last vehicle did, and so there's nobody else that's using the engine technology that we are to build fast, fast or slow rockets, and so we're kind of the only one in that realm. Like there are some other companies trying to build really fast jets. But we always say Top Gun Maverick was the perfect marketing story for us because, assuming you saw it, what happens in the very opening scenes of Top Gun Maverick? Chris: Yeah, he goes faster than what they told him he could, or why right he pushes? Sassie: he tries to push his plane to mock 10 and he literally melts his vehicle. Because if you fly fast through the soup of the atmosphere, you know it creates an incredible amount of friction and it creates an incredible amount of heat, and so it's really hard. And so, because you're a jet, the difference in a jet and a rocket is a jet has to bring. You know, go to campfire one to one. What do you need for a fire? You need fuel, oxygen and a spark. So a jet gets its oxygen from the air, which means it has to fly low enough in the atmosphere that can. It can feed its jets, which means it's got to fly through the soup. Right, we're a rocket, we're carrying our own oxygen with us in a tank, and so we can go up higher in the atmosphere where it's not as soupy, and thus fly where it's way cooler, so our vehicle won't melt. It's actually a much easier problem. So nobody that we know of in the world is looking using the engine that we're using for in the ways that we're using it Now. There are other people using this rocket engine, possibly for, you know, orbital launches, or you know we're working with NASA because they're really interested in it as a moon lander. But you know, we think we're the only ones. Now, that's not to say that some of our competitive you know, near peer competitors are not also looking at the same technology. Chris: Gotcha. Let's go back, because you said something that I found interesting you know we're going to get your take on it and that was around females in this industry and how you looked around at 38 and you were the oldest and that there aren't any in there Once you get to mid to late 30s, into the 40s. What is it? Do you think that was, or still is, maybe driving women out of the aerospace industry after you know they're in it for early, an early stage of life? Sassie: You know I've done a lot, spent a lot of time reflecting on this and I wish I knew the exact answer. I think I think it's multiple. I think one of them, when you don't have mentors, when you don't have someone older than you to mentor you and show you how it's done, you know, you decide like hey, maybe it's not worth it. I think some of it is. I mean, it wasn't unusual to have an 8pm meeting on a Thursday night when I was at Virgin Orbit sometimes, and so you know, if you're a mother and have young kids at home, like that's really hard. So just hours and expectations of hours, I can. You know. I think, as much as I would love to say it starts at a young age. There's no messaging sent to young kids, to young girls versus young boys, of like hey, you should be playing with these types of toys and boys can play with rockets. And I don't know that. I don't think society intentionally means to do that, but I think those messages still happen. I mean, I can tell you this happened recently. I was, we were given a tour here at Vina and it was with a group of very respected angels that went to a very respected university, I'm not gonna see what it is. And this gentleman came up to me and I introduced myself we hadn't started to tour anything and I said hey, I'm the CEO of Venus Aerospace. And he turns to me and he says you don't look like a very typical aerospace CEO. This is you know what 2024. Like I was so shocked by it, I didn't say anything and I wish now I'd said well, what makes me look different? Like what does an aerospace CEO look like? But that is still, I'm typically the only woman in the room when they're presenting for Venus as a founder of an aerospace company. It's just I wish I had better answers. You know, I've, even I've spent some time talking with some people that do kind of education on, you know, stem education and some of it. They even say, like you know, a lot of the engineering education is built based on how men learn, like men and women actually learn differently, and so based on how they teach, because it's been, you know, taught since, you know, for a thousand, hundreds and hundreds of years. Engineering is often taught with more how the male mindset works, and so it just tends women to be like, yeah, we're not going to go that route. Interesting. So I think it could need some changes in the academic system. But I mean, having come from a world where my husband was a professor, like there is no incentives for a professor to change how he teaches or she how she teaches. Sure, they're. They're actually, especially at a tier one research institution. They're there to, you know, do research and teaching just happens to be this little side gig, right. It's something they have to do right. It's something they have to do, not exactly? Chris: Yeah, I'm still a little shocked by the comment you got a couple of weeks ago. But so let's talk. You know, maybe digging a little bit on your own personal journey, because you're I think you said a mom of two, correct? So you know how have you managed that and navigated through. You know, still being a mom to those two, while you, I guess, one when you worked at Virgin. It couldn't have been easy, but even more challenge embarking on a startup and you know the growth that you told us about from zero or three to 50 so quickly and that. How have you tried to balance and manage your time, because I know there's clients in our firm, of our firm and listeners of this podcast that are in that same position. Sassie: Yeah, you know, I wish I could say it was easy, but it takes a lot of intentionality. So our company vision is home for dinner. We want to fly you across the globe and have you home for dinner. If you work for us, we want you home for dinner. And that's because we have, you know, as a husband and wife team, we have, you know, the two daughters that it's like we've got to be home for dinner with them because you know one of them is in high school and she's going to be out, hopefully, god willing, out of the house in a couple of years, and so we just put that in as a value from the very beginning. And so we are home, we eat dinner around the kitchen table with them almost every night I can't, you know, I can't say every night, but most of the time. Chris: No one would believe you if you said that. Sassie: Yeah, no, we don't. I mean, I just came back from two weeks of almost straight traveling and I did. I was heading to another event and I came out with my suitcase in the morning and my daughter literally looked at me and said, mom, you're leaving again. And so there are times that's hard, I can't say, I can't say I've got to figure it out, but it's being that being super intentional. And then when I do have time with them, you know, just making sure I make the most of it. It's like, you know, we do not at dinner ever have our phones out. We don't talk about Venus at all, because it's the last thing they want to hear about, you know. And then I do try we have tried to kind of sometimes bring what we're working on into their world. So I got to fly my younger daughter out to one of my events and she got to see me on stage and see what that world looks like. And so you know, getting them to understand like what we're doing, you know we've been trying to be more inclusive of that for them. Chris: I think that's great. I mean, to your point, everything's a balance, right, but I think that balance of not talking about business with them or around them all the time is smart. But introducing and incorporating a little bit about what mom and dad do isn't a bad thing. So it gives us some context about, because all they know is you leave the house and you're gone, right, and then you come back and introduce some context to that? Sassie: Well, one of my favorite stories we did. Actually we were trying to hire somebody, you know, maybe six months, a year ago, and so we were told the girls at dinner we were like, hey, we're trying to hire this person. You know, what do you think we could do to incentivize them to come? And my younger daughter was like well, what if you give them cookies? Chris: I was like you know everybody likes cookies. Sassie: That's true, So-. Chris: That would get me Exactly. Yeah, the innocence of that is, I mean, that's magical. So yeah, busy schedule, we balance this. How would you describe kind of your leadership style? Sassie: Well, that's a really interesting question. I try to lead how I would want to be led with super high integrity, positivity. I actually one of the analogies we use a lot is giving away our Legos. So I've really had to learn. We started the company and I was doing everything. Well, not the technical stuff, but I was setting up accounting, I was doing payroll, I was doing HR, I was doing all the fundraising, and so, as the company grows, I will never have more responsibility. Today is the most responsibility I will ever have, because hopefully, we'll continue to hand away Legos and so trying to really encourage people to share their Legos like the story we use all the time is, if we want to build the largest Legot Tower possible, the best way to do it is for everybody to contribute and build, and so in that case, I have to share my Legos. Chris: I love analogies. That's a good one for building a business and you're right, I think it's hard. It starts with trust, right? You have to be able to get to a level of trust to give a Lego away to someone, to take over HR, to take over accounting. Sassie: And my goal is to hire everybody smarter than I am and that's more of an expert in their area than I am, because if that's the case, then Venus will be so much better. And so I ultimately want the very best in whatever role it is, and let them have it, because they're going to be so much better equipped to do that role than I ever was. Chris: It's a great goal. Well, the story is fascinating, sassy. I can't wait to continue to watch where y'all take this, and what do you I mean unique and special opportunity right? You're literally going to change an industry. Sassie: I always say it's the adventure of a lifetime, and Andrew and I were two engineers with an idea, and it really shows the power of the American dream that there are investors out there I mean, we're not billionaires and so that there are investors out there that understand what a world changing technology can do and that are willing to back entrepreneurs and then continue to support us and help us grow. To me, it's what makes America by far the greatest country in the world. Is this type of ecosystem that happens, so it's truly just such an adventure. Chris: Let's have a little fun before we wrap up. So what was your first job? We were growing up? I was a lifeguard. Okay, and do you ever have to save any lives? Sassie: I had one time a little boy that just had walked too far out and was up under underwater. I wasn't even on duty and I would happen to be walking by and his mom was screaming and I just jumped in the water and grabbed him. Chris: Okay. Sassie: So thankfully, that was the extent of my life saving. Chris: Very good. So this is going to be an interesting question. Seventh generation Texan. You told me yeah, so do you prefer Tex-Mex or Barbecue Tex-Mex? All right, I think that's spoken like a seventh generation Texan. Sassie: I like Barbecue, but yeah, deep down anytime when we didn't live in Texas and like we lived in California, virginia, all over, the first meal that when I would come back and like stay at my parents' house, was always like greasy Tex-Mex. Chris: I can identify with that. Look, the question's not meant to be easy. It's a tough one. I mean, most people struggle, as I do, because I like them both. But you're right, that may be the best barometers what's the first meal after you've been away? Yeah, so all right. So, given what you're doing and the pace at what you're growing this company, this may be hard for you to envision. But if you could take a 30-day sabbatical, where would you go and what would you do? Sassie: I am an outdoor person, so I would go somewhere in the middle of no weather I don't know if it would be up into the mountains or on a foreign. I'd probably want to hop between like an island and like surf and snorkel and scuba and play in the water and fish and then be up in the mountains and hiking or skiing. Anything that gets me away from technology and out into nature would be my what I'd want to do. Chris: Okay, that's good, that's good. Well, sassy, thank you for taking the time. Yeah, as I mentioned, yeah, we're in a really yeah, this is March of 2024. This is International Women's Month. I can't think of a better guest to have on the podcast than you out there, showing women by example how you can be a successful entrepreneur. So, thank you. Sassie: Thank you, thanks for having me.

In today's episode of Building Texas Business, we sit down with Jerry Mooty, the CEO and Principal of @properties, Christie's International Real Estate in Dallas and Austin. Jerry takes us through his remarkable journey from managing partner at a law firm to heading a major real estate brokerage. He shares how resilience and adaptability allowed him to steer his business through the 2008 financial crisis and leverage opportunities arising from the pandemic. Jerry also provides insights into growing his firm through innovative hiring strategies and technological platforms that streamline agents' work. We explore lessons learned around overcoming adversity, strategic partnerships, and balancing operations with culture. His story offers a candid look inside one industry titan's challenges and triumphs in managing debt, acquisitions, and new ventures in sports and entertainment. SHOW HIGHLIGHTS Jerry Mooty shares his transition from being a managing partner at a law firm to creating and growing a real estate brokerage, including the challenges faced during the 2008 financial crisis and opportunities leveraged during the COVID-19 pandemic. We discuss Jerry's innovative business model that hires agent-attorneys and how it differentiates his brokerage in a competitive real estate market. The episode covers the technological advances at @properties, such as the Platform, which incorporates AI and a suite of tools to increase agent productivity. Jerry reflects on managing $60 million in personally guaranteed debt and the strategy behind transitioning to a debt-free business structure. Strategic partnerships and the process of acquisitions, especially in the technology sector, are explored along with Jerry's experience in due diligence and venture capital dynamics. Jerry discusses the significance of cultivating a company culture focused on employee well-being and the shift in his leadership style from operations to creating an enjoyable work environment. We touch on the importance of friendships in Jerry's professional journey and how they've influenced his career decisions and leadership approach. Challenges facing traditional real estate agencies like Remax are considered, with a focus on adapting to technological advancements and market changes. Jerry provides insights into his personal preferences, revealing his fondness for barbecue over tex-mex, adding a personal element to the conversation. The conversation highlights Jerry's efforts in expanding his business, including the recent launch of a sports and entertainment division and developer services to cater to specific client needs in the real estate market. LINKSShow Notes Previous Episodes About BoyarMiller About @properties,Christie's International Real Estate GUESTS Jerry MootyAbout Jerry TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode you will meet Jerry Mooty, ceo and principal of App Properties, christy's International Real Estate in Dallas and Austin. Jerry, by anyone's definition, is a serial entrepreneur, having started a law firm, credit card processing company, real estate development company and now a real estate brokerage firm. And Jerry tells aspiring entrepreneurs expect the unexpected. Jerry, I want to thank you for taking the time to come on and welcome you to building Texas business. Nice to see you. Thanks for having me. Good to see you too. It's been a while. Let's just start. You know you've done a number of things and we'll get into some of that, but currently, what's the business that you've started and you're currently today? Jerry: So Jerry Mooty from Dallas have a business now in the residential real estate brokerage industry. So I compete with Compass and some big national brands that most of the listeners will know about. Chris: And that company's called App Properties right. Jerry: Yes, sir, it's called App Properties Christy's International Real Estate. So we kind of have a working on that. Chris: And I know you're kind of got the Dallas area covered, but I think you've also recently expanded into Austin. Jerry: Yeah, so we started in Dallas proper with our headquarters, and then we opened a second office in Frisco, texas, and then we just recently, in the fall of 2023, opened up Austin, texas. Chris: So you know, as a recovering attorney, what was it that inspired you to get into the residential brokerage real estate business? Jerry: So, interesting enough, you kind of know my history, but I founded a law firm when I was 28 and I grew that into about 60 lawyers in four cities. As the managing partner, I started doing a lot of deals for the partners as opposed to practicing law, and I went down several paths. I had a litigation support company that I founded and grew that for the partners and then, you know, ironically got into a real estate development a little startup where I had a home building division building spec homes and I had a commercial division where I was doing some commercial projects. Raw land development had a resort under contract in Bernie, but, like a lot of people in real estate, 2009, 2010 came and that was the end of my glory days in real estate. All right. Chris: So then, what led you to? You know, get involved with app properties and then take this down, go down this rabbit trail. Jerry: Sure. So in 2012, I sold my interest in the law firm back to the partnerships. I didn't want to go back to practicing full time and then did quite a few different entrepreneurial things from about 2013 to about 2019. Any you know, I had a credit card processing company, backed by the Jones family, called Blue Star Payments that merged in with a tech company and we rebranded Blue Star Sports. We were backed by some pretty large VC firms Bain Capital and GenStar partners and Providence Equity and then obviously, the Jones family. So we acquired about 27 companies in about three years and then we sold that company in 2017. Then I was kind of looking for the next thing and I became the chief business and legal officer for a Silicon Valley tech company for a couple of years. They were in a big money raise and it wasn't going so well and I was deferring comp. So I started looking at what I was going to do next. One of the people in my network is a ex litigation real estate litigator. She had gone on and got married, had kids, got a real estate license and had a brokerage here in Dallas and her model was she was going and convincing unhappy lawyers to get the real estate license. So she had about 10 agents slash attorneys as her brokerage and she approached me to come in and run her brokerage for kind of like I did the law firm. So that piqued my interest enough so we went down that path. Sadly we didn't get to execute our documentation because they ended up having a divorce situation. And then two weeks later COVID hits and so I'm waiting to take my real estate license and not sure what I'm going to do after that. Come out of the first 90 days of COVID, the market's red hot, so I hang my license, I start doing deals for my network friends and start marketing myself as an agent. All the meanwhile I'm looking for something to buy or to own or start, and so that led me through developer relationship here in Dallas to the ownership group of at properties out of Chicago. They made that introduction, flew up and met with them and really fell in love with not only the brand and the culture but also the technology that they had built. Chris: Amazing story. There's a lot to dive into there. I may definitely want to go back some, but let's stay with that properties for now. And yeah, so you that's a. It's born out of COVID, I guess. Tell us, though you know, because I know just from you, know keeping up with you and then reading on the website you've experienced some like amazing growth in the last, I guess, three and a half years. Let's talk a little bit about that. And in talking about what you've done that you think has helped accelerate it, let's talk also about the maybe the pains with growing so fast. Jerry: Sure. So as I was looking to own something and this opportunity came up, I negotiated to purchase, you know, the North Texas territory. But I wasn't really prepared to launch because it was just me and I hadn't done a whole lot of recruiting. But I had some real estate deals in the pipeline that I needed to leave the current brokerage I was at before I papered those up. So I ended up launching at properties by myself just one agent, and got temporary space and, you know, true entrepreneurial spirit started recruiting, putting in my support team, landed a pretty big compass team right out of the gate and that kind of helped accelerate the visibility. And so the first, you know, six months we grew to 10 agents by Christmas. So it wasn't, we weren't a big brokerage, but we were putting things in place. By the next year we were about just under 40 agents. So we had a really good, successful year and, you know, quadrupling our size and then last year 2023, we doubled again to about 80 agents in Dallas. So we've been kind of there's been some faster growth brokerages, but we're very we're considered more luxurious. Our agents are more high producing agents and they take a little longer to transfer from one brokerage to another based on their pipeline and their restrictions. So now that we're three and a half years into this and Austin's really kind of been a little bit of a catalyst in the last six months because initially that territory wasn't available there was a Christie's affiliate there my corporate partner asked me if I wanted Austin about a year and a half ago. I said yes and so I started putting the play pieces in place and we launched that in September. We've added quite a few agents in the first 120 days over 70 something agents there. So all in we got about a hundred agents in Dallas, about 70 in Austin. So that's the good side of the business. The headaches, as you know as an entrepreneur, are several and many. Too many to list, but we'll cover a few. My most recent success story is I just hired a controller after three and a half years. So I've been doing the books, reporting to corporate, paying the royalties, paying the checks, paying the agents. So those are the things. As an entrepreneur, you really you put your blood, sweat and tears into these businesses and then you have to get to a certain level, to where you could start to relieve yourself of some of these pains. Chris: Yeah, that's so true, jerry. A lot of the people that I've had on before say exactly that that it's one when you're starting out, you're not big enough to outsource it or to hire for it, so you got to do it. But then it's getting to that point when you even when you are big enough and can afford it the level of trust and hiring the right person to hand off those key aspects of the business, so it frees you up to do the things as an entrepreneur or the visionary you want to be doing. So let's talk about that. What was it that you think helps get to a level of trust and comfort that it's time to hand off and it's the right person to hand off to? Jerry: Yeah, I think, based on my background of being an entrepreneur, you make a lot of friends and you kind of know. You learn the hard way. You hire the wrong person a few times and then, as you get older and more seasoned, you kind of know what to look for. In this instance, with that properties, I hired somebody I'd known for 35 years to come in and be my director of agents. I've known her since the SMU days, so the trust was already built in and then you're just very selective as you add the pieces to the puzzle to get those right people in place. So in half years we've let one or two people go, but we've been pretty successful in hitting the mark. Chris: That's great. So 70 agents or so you said. Have you started to implement any kind of processes that help with the integration process as you bring in these new people, so they understand kind of what the expectations are, what the benefits are for making the move? I mean, so where are you and what's the process you've gone through to kind of make that more institutionalized? Jerry: So the background for at properties and the corporate support we have is pretty important in how we've gotten here. They're a 25 year brokerage. They're the eighth largest in the country before acquiring the Christie's affiliate network, so they kind of had the processes in place. So it's buying. Whenever you buy a franchise and you wanna go down this path, you kind of get a little bit of assistance from and some help along the way on someone else putting the right pieces in place. I think what we've done a great job is integrate and implement those things that they've brought to the table, which I think revolves around a lot of our culture. You know, I think culture is so important in any business you have and so it's just we have fun things called at love, local events that came from corporate. So we'll pick a merchant somewhere in our geographical area, we'll partner with them, we'll send out a marketing campaign. Let's say it's a coffee shop and then whoever shows up at that coffee shop, our agents are there and we're running a tap for a coffee or a Danish in the morning. So that's kind of the community outreach piece. We use the word love strategically in all our marketing. So we say bringing the love to Dallas, bringing the love to Frisco and those types of things. So you know, recruiting is probably once you get the, once you get your overhead stabilized and your office space and those types of things. This is a business about relationships and recruiting. So I would say our two most important people outside of myself are our head of recruiting out of Frisco, head of recruiting out of the Dallas office, and so those have been very good hires. Chris: You know most, I think most businesses. It's hard to say they're not people, businesses or relationship, but certainly you know in the business you're in, where you're so customer facing right, you need good people that can go out and attract good customers, provide good service. But I have to imagine the last 18 months or so in residential real estate hasn't been the easiest. So can you talk a little bit about what you've done to help continue, promote one, promote the culture, to keep people positive and energized while managing through what has to have been a challenging time? Jerry: Yeah, absolutely so. Obviously we're all aware of how hot the market got, you know, a couple of years ago, you know, during COVID and post COVID. What that did in our industry is everybody wanted a real estate license because they saw all these transactions happen. So we had an influx of agents that came in that are young, inexperienced, but were here to make some money. And then, when the market turns, you kind of have the reverse effect. Those people were all eat what you kill, or 10, 9, 9 commissioned agents. They got to figure out how to pay the bills, and so we've had a pretty big exodus. Probably 15 to 20% of our agents across the nation have left the industry, and so that's been good for the sense of the people staying in it because you got less competition. But the ones that stayed in it most of them, have been through some of these ebbs and flows of the market, and so they kind of know how to prepare. And most of that revolves around when your transaction desk is slower, what are you ramping up to do? Are you ramping up your marketing, your postcard, social media content, are you revamping your website? And so those are all things that we, which the agents that work for us and part of our big, strong sales pitch based on the technology that we have. Chris: Got you Speaking of that on the marketing side, you know, are you seeing? I guess, one area or the other as far as marketing strategy work better, get more visibility or more return on investment. You see so much on social media, so it seems natural that that would be one, but I don't know if that's the leading one based on your experience or not. Jerry: Yeah, I think in pretty much every industry has been affected by the internet and no industry more so than real estate. I would say probably 10 years ago you saw a lot of print ads. You saw a lot of ads and you know business journals and those types of things trying to move property. But now it's really a digital world. We're using social media, we're using tools called AdWords, which is a retargeting tool to where it's essentially like if you went and looked at a pair of shoes at Nordstroms and then you left Nordstroms, those shoes are following you around. So we have the ability to target, geo track and geo target potential prospects and clients through our technology. Obviously, websites are important. Your collaboration tools that you're preparing a search for a prospect, like they're looking in this area for a certain price point. We have the ability to set those searches up and work with a prospect or a client on finding the home, ironically in the last price. I don't know when this started, but in the last year or so, almost 85% of buyers find the home they want before they hire an agent, or at least they zero it down based on how much information is on the internet. And so, really, as an agent, what you're trying to do is bring your expertise not only to get that transaction under contract, but then most of the work happens one second transactions under contract all the way through closing. Chris: Right, that is an amazing statistic 85%, but you're right. I mean, when everyone goes to the internet first, I think, to research or validate or do something. So it makes sense to me, but it's a big number. Sounds like you know here you use your work, technology and innovation and stuff quite a bit already since we started the interview. Some of this may have come from your franchise or some may have come from some things You're doing, but what are some of the things you believe are innovative in the way that you're operating the brokerage and helping your agents be successful? Jerry: Sure. So I think when you start understanding what different brokerages bring to the table in regards to support for their agent portfolio. Obviously marketing is a big one because they're pushing all the stuff out that we're talking about, but also the day-to-day operation of an agent is pretty important. Most brokerages large brokerages like Coldwell, banker, some of your biggest national brands are very antiquated when it comes to technology support. I would say there's two brokerages at the forefront. I'd say Compass is in second place and I think App Properties is in first place. And I say that because we've been building a technology stack called Platform, or our franchise or has, since 2003 and basically an agent logs in and does everything they need to do as an agent in one technology. When I interview agents and I show them the technology, they're blown away because they're in four or five, six different technologies throughout the day trying to get their social media posted or created, their transactions done over here, their docuSigns another technology they have to use, and we have everything in one place, and so that's been a real big selling point for us when we're recruiting these agents. Chris: Yeah, I mean anything to make your employees or, in your case, I guess, your contractor's life easier. Have you started to look into, or is this already incorporating any kind of versions of AI? Jerry: AI is already integrated. Nowadays, agents are always doing, as an easy example, they're doing descriptions of the properties. So now you can lean on AI to help you describe a $5 million house with five bedrooms, six baths by describing it into AI, and then it'll help you create that luxury description. So there's things like that. Obviously, our CRM has a lot of AI tied to it and so, yeah, that's the way of the future and it's getting more and more integrated and implemented into all our tools. Very nice, very nice yeah. Chris: All right. So I want to make you kind of reflect back. So yeah, this about, by your own description, not the first time you kind of started a new venture or stepped outside your comfort zone. So when you think about what you did I guess leaving, you know, maybe leaving the law firm or even some of the ventures you started while you were there, but going to credit card processing et cetera where are some of the lessons you learn through those ventures that you think prepared you for taking the step you did without properties and the steps you're taking now to grow so rapidly? Jerry: Yeah, I think if you're a serial entrepreneur like myself, I think the one thing you learn each time that you have an idea or you go down the path of starting something is you think you're going to get to the finish line a lot easier. It's your idea and you think you're going to do that. And I think probably in every instance including the law firm, including the credit card processing is one lesson is it just takes a lot to probably 10 times, 100 times more man hours and work and you got hurdles. That you're not expecting. But I think that's part of the reward too is why I'm built the way I am. You enjoy that when an obstacle comes and you get your way around it or over it. But I think you know frankly, it's probably what every entrepreneur says it's never as easy as you think it is. There's no get rich. You know we talked about most of what we do as lawyers and what I'm doing is a people game. You know you're hiring people and people disappoint, you know, and you're having to find different people sometimes, and so the lesson is just pride and expect the unexpected and you'll be okay and be able to sleep at night. Chris: I like that. Well, think about, is there a kind of a challenge or a failure setback that you can point to over the last, you know, 15 years, 20 years, whatever that you feel is maybe in some ways either a defining moment for you or one of the bigger learning moments that you got? You kind of got hit with a little headwind but you overcame it and because of that it's kind of helped propel you either in your own personal journey as a leader or, you know, in things you learned as an entrepreneur. Jerry: Yeah, I'd say you know, probably the biggest lesson learned of all time was me starting a real estate development company with a home builder and a commercial partner and, you know, diving into that with not a whole lot of experience, and so the challenge was obviously, in real estate, you're hoping to build something and sell it, and so the big challenges is if you build it and you borrow a bunch of money and you don't sell it. And so in 0809, 2010 is probably should have been my premier happiest days of my life. I'm on a law firm, I'm making some good you know coin on the law firm side, but I'm literally getting dragged through the mud financially on the real estate piece, and it's probably one of the reasons it's taken me 10 years to get back into it on the brokerage side, because I literally came out of that was some financial PSD. You know just could not sleep, you know got I mean health issues, depression, pretty much everything you can experience as an entrepreneur and so you figure out a lot about yourself when you're going through something like that, and you know you either stay in bed and talk about it or you pull up your socks and get out and try it again. Chris: That internal fortitude, you know I think any entrepreneurs got to have that or it's just not going to happen. I appreciate you sharing that. Were there some things that you did? You know that you know other than just I mean pure gutted out. You know, to help you kind of get through that. You know, leaning on family friends, I don't know. I mean I have to believe we've got some listeners and other people out there that you're going through the same thing. Jerry: Sure, I think where I lucked out was, you know, just to be frank, I was on about $60 million and personally guaranteed debt that was worth probably about 30 by the time I was trying to get out of it. So there wasn't going to be any family help. It was. It was hey with you, you know, in a loving way, of course. But when you dig a hole like that, you just got to figure out the best way out. And for me, where I benefited was I had a law degree and I was a lawyer and creditors could not touch the ownership interest in my law firm because it was tied to my license. So, through bankruptcy lawyers and all that stuff, I got educated on that and gave me the strategy to get through that situation and come out on the other end, which was one of the reasons I sold the interest of the law firm back to the partners, because that allowed me to have a little bit of a stream of income there in 2012, 13 and 14, while I got the credit card processing company going and getting these other things going. So there was, if there was, a silver lining, it was that fact, but it was still still pretty embarrassing financially and pretty embarrassing as a professional to really go through that over a three or four year period. Chris: You got to be hard but, like I said, I mean now that you've come through it, you know you can certainly appreciate the opportunities you have today and know that. You know I certainly probably learned some lessons of what to not do, going forward right. Jerry: Absolutely, I would say. The one lesson you learn in that scenario is you become a lot more frugal with your financial decisions and you know, especially in the banking industry, like one thing I'm proud of with that properties is we've never bought a bar to dollar. We got zero debt, and so those that's a probably a direct result of what I went through, you know, 15 years ago was I don't want to do another business where I got a bunch of debt and I'm trying to get that off and make money to live off of. Chris: That's great. So you mentioned earlier I think it was a credit card processing BlueStar, where you had some dealings with Bain Capital, and obviously you're dealing with a franchise or in this current business. So let's talk a little bit about maybe what you've learned through that. I kind of relate or maybe call those you know investors, partners, strategic partners. What have you learned as kind of some of the best ways to deal with them so you keep that relationship strong and healthy? And maybe it's something you know that happened that you're like I did this or they did. You know something that happened that soured the relationship, one they got to help our clients here at the firm you know, you know find themselves in those situations all the time, and so I'm curious you know what you know, what lessons you've learned through that process? Jerry: Yeah, so I would say getting involved in. And so when we had the credit card processing company, it was pretty a pretty simple model. We were going out and you know recruiting or or you know we're trying to sell merchants, you know restaurants Anybody who ran a credit card was it was a prospective client approached by a group who had an idea of buying up these technology companies in the youth sports space. So like, if you sign your kid up for soccer, you're there's usually a form and at the end of that form, whether it be the YMCA or anywhere else, you're paying a fee for your child to play that on that soccer team. So the model we had was take the credit card processing that we had built our own API and those types of things and bake it into a technology and go buy these companies. And interestingly, it was about how do you flip the model from a EBITDA and a multiple perspective. So these tech companies that weren't that large of companies because they were kind of geographically located, running different types of youth sports camps or whatnot, they weren't sophisticated enough and they were usually outsourcing their credit card processing to stripe or squares or something like that. So we would acquire these companies and bake in our own processing and from an ownership perspective, then that would change the multiple for maybe two times to 12 times because you have that reoccurring revenue stream coming into your business model. I literally probably learned more over that. First, 12 to 20 per month as we were acquiring these companies, doing due diligence on them, and I was the chief legal officer of the company, so I was in charge of all the due diligence. So we acquired 20 something companies and I bet I did due diligence on about 300 over two years. But it was really cool because I got to see what investors and power players in the venture capital market, how they looked at things and it's there's not a lot of emotion, it's numbers on paper and it's how do we make, how do we do this to this group of businesses, and then how do we sell it and make money. All about the return on investment, right. Chris: Exactly so. It's a. Jerry: It's very cutthroat which some businesses are, some aren't, but it was a great learning experience. I'd like to say I probably learned more in that two to three years Dealing with those big VC firms and listening to those meetings and kind of running point on due diligence than I probably learned in any other aspect of my life. Now, that's so, but that's so. Chris: Let's turn it back a little bit to app properties specifically. I know you've recently launched a new sports and entertainment division Tell us about that. What's going on behind that and what are you trying to accomplish so in the real estate brokerage? Jerry: world. There's different ways to market yourself right, and a lot of that boils down to your experience of your agent portfolio, and so some real estate brokerages are residential, some may just be commercial, but on our side we have, we've accumulated some agents that allowed us to create these divisions because of their experience levels. So land and ranch is one division, and then sports and entertainment is another division, and basically there's some criteria that we've put in place before an agent can say they're part of that team or that division dealing with professional athletes or celebrities on a number of occasions, some of the qualifications, but essentially, when somebody's moving like a professional athlete or a celebrity, there's a lot of sensitivity to that, or there's a lot of urgency, there's a lot more moving pieces, and so that specific division has agents who are, you know, experts in helping that transaction or that client Get from point A to B and solve a lot of problems along the way how to move their cars, how to move their kids into new schools, you know everything that comes along with kind of that type of transaction, as opposed to someone just buying a house and selling a house. So are we going to see? Chris: Super Bowl ads anytime soon, if I can at homecom I could afford it. Jerry: No, that's the goal is. We're really good because of how the clients affiliate network has come into play for us. I don't know if we mentioned this before the call or on the call, but you know our corporate partner ended up buying the Christie's affiliate network, which is a network of independently owned brokerages around the world. I think we have 900 offices in 54 countries, about 35,000 agents, and the reason Christie's the auction house, christie's the family who's owned that brand and that company for two hundred years. They sold the app properties because of the technology and we've been for two years bringing a worldwide global powerhouse network together into the technology to share referrals and data and information, and so that's been one of the one of the real keys to some credibility for us. Very cool. Chris: I think you just launched something else, maybe in the last week. Developer services Tell us about that. Jerry: So so again, we all know there's developers out here but we're not sure there's developers out here building multifamily building, you know, developing neighborhoods, multi-use, and so for a brokerage our size to have the ability to provide those services was kind of hard. So we ended up meeting a group of people out of Austin who came from Storybill and for those listeners who've heard about Storybill, that's a multi-billion dollar developer who went, ran out of money last summer. But we ended up negotiating their entire creative team to come over to Christie, our Christie's, and create this development services division. So starting with the chief marketing officer all the way down to their website development team, their on-site sales, so we've got a team of about 12 of superstars and they really fell in love with the Christie's brand to kind of move from Storybill into our umbrella, to kind of push those services out. So that'll be a huge win for us. Chris: So, as you sit there running all this, what is it that kind of triggers for you that this is an opportunity that makes sense, because not everybody can see that, and so there are things you're looking for. How do you go about making that decision and taking on the risk? Jerry: Yeah, so risk is a little less scary in our business because most everybody who works for our brokerage is a 1099 contractor. So we really have a pretty lean machine when it comes to we're running this right now with about seven full-time employees, three offices, so you got overhead from an office space perspective, but really you're kind of it's kind of a lean business model, which is one of the things that attracted me to it. And then obviously you have to have the people to be able to promote these different levels of services. So I think the thing that's been lucky for us is one our relationship and our network in Dallas to help get it started. And then obviously the people we've been able to add at such a young infancy of a company have given us the credibility and the numbers are reflecting that. Chris: Gotcha. So before I don't want to wrap this up without talking a little bit just about you and your leadership style, let's talk. You know, how would you describe your leadership style? How do you think that's evolved over time based on the scars and other lessons learned? Jerry: You know you work at a law firm, so you know running a law firm is you got a lot of smart people, a lot of egos, a lot of staff, a lot of overhead, and so I learned a lot about you know the operational side of a business in that seat. And then I think my ownership style has probably changed completely since I left the law firm. I'm a lot more interested in the well-being of my employees, a lot more sensitive to the culture. I think. When you talk about people coming to work and going home, in my mindset now I want that to be a great experience. I kind of use the word experience a lot in the last couple of years for some reason, and I think it's just. My evolution is like everything in our lives is an experience and you can make it a good one or you can make it a bad one, and so I think my leadership style is I want every experience to be a good one. At the best I can make it. Obviously you're going to have your headaches and your issues pop up, but we have the music on in our offices every day. We have happy hours on Thursdays. We built bars in both of our offices in Dallas and Frisco, and then we're putting one in our location in Austin so that we can have happy hours with our agents and our clients and our prospects. We hold a lot of events and I think our interaction with the community and the philanthropic stuff that we're doing is really cool. So I think where I've gotten is you know I'm 54 now and you know I started that law firm at 28 and I had a whole different picture in my mind at 28, right Till 35, of what life was going to be for me, and now I'm kind of trying to enjoy it a lot more. Chris: I love that man. Happy for you. You know clearly you're on the right track and couldn't agree more about how important culture is to any company. And I think I've said similar to you. I think life is about experiences. I think they're only really down to learning experiences good experiences and learning experiences as though, rather than bad, just learn from them and don't repeat them. Jerry: Yeah exactly right. Chris: So let's turn a little bit on the personal side of things and not as serious. What was your first job? Jerry: First job, I was a clerk in a law firm. Chris: Okay. Jerry: I was working in law school. Okay, my first job in high school. Like most of us, I grew up in Missouri in a small town. I had a yard. You know service with my best friend and we had our lawn mowers in the back of his truck and we mowed yards. So that was probably my first experience as a having a job. There you go, and first is an entrepreneur was leaving a 250 person firm to start a law firm with two other guys and being 28 years old and that was pretty exciting. We had metal chairs and you know fold up conference room table and laid out of the movie. Chris: Love it. Well, I can relate to the a little bit to that, but definitely relate to the mowing yards. That's what buddy of mine and I did in high school. So you know good money then I guess. Okay, personal preference, tex-mex or barbecue? Well, that's a tough one Probably barbecue. All right. And if you could, take a 30 day sabbatical. Where would you go? What would you do? Jerry: You know, this is my two sons who are a senior and sophomore at University of Texas right now. They called a year ago about this time and said, dad, we're going to go to Japan. And I was like, okay, and they got on a plane, just the two of them went to Japan for three weeks and after hearing that I kind of want to do that. Chris: How cool is that. The two of us went and did it on their own. Jerry: They did it on their own, traveled around on trains and backpack and love it. They're experienced when they told the stories and went through the pictures. I mean it's just a really cool culture. I'd like to go experience that. Chris: Okay, jerry, I can't thank you enough for taking the time to come on. It's hard to believe that you know I don't. I might add the numbers we met at SMU and, as undergraduates, went to law school together, so we had a lot of years together. So it's great to see where you are today and what you're doing. So proud of you. Jerry: Man. I appreciate that. And the same back at you. I followed you your whole career and super, super proud of you. What kind of legal person you are and lawyer and leader and everything you're about. So appreciate having me on and proud of you too, my man. Chris: All right, we'll do it again. We'll find a reason to do it again sometime soon. Awesome Sounds good. Special Guest: Jerry Mooty.

In today's episode of Building Texas Business, we sit down with Jerry Mooty, the CEO and Principal of @properties, Christie's International Real Estate in Dallas and Austin. Jerry takes us through his remarkable journey from managing partner at a law firm to heading a major real estate brokerage. He shares how resilience and adaptability allowed him to steer his business through the 2008 financial crisis and leverage opportunities arising from the pandemic. Jerry also provides insights into growing his firm through innovative hiring strategies and technological platforms that streamline agents' work. We explore lessons learned around overcoming adversity, strategic partnerships, and balancing operations with culture. His story offers a candid look inside one industry titan's challenges and triumphs in managing debt, acquisitions, and new ventures in sports and entertainment. SHOW HIGHLIGHTS Jerry Mooty shares his transition from being a managing partner at a law firm to creating and growing a real estate brokerage, including the challenges faced during the 2008 financial crisis and opportunities leveraged during the COVID-19 pandemic. We discuss Jerry's innovative business model that hires agent-attorneys and how it differentiates his brokerage in a competitive real estate market. The episode covers the technological advances at @properties, such as the Platform, which incorporates AI and a suite of tools to increase agent productivity. Jerry reflects on managing $60 million in personally guaranteed debt and the strategy behind transitioning to a debt-free business structure. Strategic partnerships and the process of acquisitions, especially in the technology sector, are explored along with Jerry's experience in due diligence and venture capital dynamics. Jerry discusses the significance of cultivating a company culture focused on employee well-being and the shift in his leadership style from operations to creating an enjoyable work environment. We touch on the importance of friendships in Jerry's professional journey and how they've influenced his career decisions and leadership approach. Challenges facing traditional real estate agencies like Remax are considered, with a focus on adapting to technological advancements and market changes. Jerry provides insights into his personal preferences, revealing his fondness for barbecue over tex-mex, adding a personal element to the conversation. The conversation highlights Jerry's efforts in expanding his business, including the recent launch of a sports and entertainment division and developer services to cater to specific client needs in the real estate market. LINKSShow Notes Previous Episodes About BoyarMiller About @properties,Christie's International Real Estate GUESTS Jerry MootyAbout Jerry TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode you will meet Jerry Mooty, ceo and principal of App Properties, christy's International Real Estate in Dallas and Austin. Jerry, by anyone's definition, is a serial entrepreneur, having started a law firm, credit card processing company, real estate development company and now a real estate brokerage firm. And Jerry tells aspiring entrepreneurs expect the unexpected. Jerry, I want to thank you for taking the time to come on and welcome you to building Texas business. Nice to see you. Thanks for having me. Good to see you too. It's been a while. Let's just start. You know you've done a number of things and we'll get into some of that, but currently, what's the business that you've started and you're currently today? Jerry: So Jerry Mooty from Dallas have a business now in the residential real estate brokerage industry. So I compete with Compass and some big national brands that most of the listeners will know about. Chris: And that company's called App Properties right. Jerry: Yes, sir, it's called App Properties Christy's International Real Estate. So we kind of have a working on that. Chris: And I know you're kind of got the Dallas area covered, but I think you've also recently expanded into Austin. Jerry: Yeah, so we started in Dallas proper with our headquarters, and then we opened a second office in Frisco, texas, and then we just recently, in the fall of 2023, opened up Austin, texas. Chris: So you know, as a recovering attorney, what was it that inspired you to get into the residential brokerage real estate business? Jerry: So, interesting enough, you kind of know my history, but I founded a law firm when I was 28 and I grew that into about 60 lawyers in four cities. As the managing partner, I started doing a lot of deals for the partners as opposed to practicing law, and I went down several paths. I had a litigation support company that I founded and grew that for the partners and then, you know, ironically got into a real estate development a little startup where I had a home building division building spec homes and I had a commercial division where I was doing some commercial projects. Raw land development had a resort under contract in Bernie, but, like a lot of people in real estate, 2009, 2010 came and that was the end of my glory days in real estate. All right. Chris: So then, what led you to? You know, get involved with app properties and then take this down, go down this rabbit trail. Jerry: Sure. So in 2012, I sold my interest in the law firm back to the partnerships. I didn't want to go back to practicing full time and then did quite a few different entrepreneurial things from about 2013 to about 2019. Any you know, I had a credit card processing company, backed by the Jones family, called Blue Star Payments that merged in with a tech company and we rebranded Blue Star Sports. We were backed by some pretty large VC firms Bain Capital and GenStar partners and Providence Equity and then obviously, the Jones family. So we acquired about 27 companies in about three years and then we sold that company in 2017. Then I was kind of looking for the next thing and I became the chief business and legal officer for a Silicon Valley tech company for a couple of years. They were in a big money raise and it wasn't going so well and I was deferring comp. So I started looking at what I was going to do next. One of the people in my network is a ex litigation real estate litigator. She had gone on and got married, had kids, got a real estate license and had a brokerage here in Dallas and her model was she was going and convincing unhappy lawyers to get the real estate license. So she had about 10 agents slash attorneys as her brokerage and she approached me to come in and run her brokerage for kind of like I did the law firm. So that piqued my interest enough so we went down that path. Sadly we didn't get to execute our documentation because they ended up having a divorce situation. And then two weeks later COVID hits and so I'm waiting to take my real estate license and not sure what I'm going to do after that. Come out of the first 90 days of COVID, the market's red hot, so I hang my license, I start doing deals for my network friends and start marketing myself as an agent. All the meanwhile I'm looking for something to buy or to own or start, and so that led me through developer relationship here in Dallas to the ownership group of at properties out of Chicago. They made that introduction, flew up and met with them and really fell in love with not only the brand and the culture but also the technology that they had built. Chris: Amazing story. There's a lot to dive into there. I may definitely want to go back some, but let's stay with that properties for now. And yeah, so you that's a. It's born out of COVID, I guess. Tell us, though you know, because I know just from you, know keeping up with you and then reading on the website you've experienced some like amazing growth in the last, I guess, three and a half years. Let's talk a little bit about that. And in talking about what you've done that you think has helped accelerate it, let's talk also about the maybe the pains with growing so fast. Jerry: Sure. So as I was looking to own something and this opportunity came up, I negotiated to purchase, you know, the North Texas territory. But I wasn't really prepared to launch because it was just me and I hadn't done a whole lot of recruiting. But I had some real estate deals in the pipeline that I needed to leave the current brokerage I was at before I papered those up. So I ended up launching at properties by myself just one agent, and got temporary space and, you know, true entrepreneurial spirit started recruiting, putting in my support team, landed a pretty big compass team right out of the gate and that kind of helped accelerate the visibility. And so the first, you know, six months we grew to 10 agents by Christmas. So it wasn't, we weren't a big brokerage, but we were putting things in place. By the next year we were about just under 40 agents. So we had a really good, successful year and, you know, quadrupling our size and then last year 2023, we doubled again to about 80 agents in Dallas. So we've been kind of there's been some faster growth brokerages, but we're very we're considered more luxurious. Our agents are more high producing agents and they take a little longer to transfer from one brokerage to another based on their pipeline and their restrictions. So now that we're three and a half years into this and Austin's really kind of been a little bit of a catalyst in the last six months because initially that territory wasn't available there was a Christie's affiliate there my corporate partner asked me if I wanted Austin about a year and a half ago. I said yes and so I started putting the play pieces in place and we launched that in September. We've added quite a few agents in the first 120 days over 70 something agents there. So all in we got about a hundred agents in Dallas, about 70 in Austin. So that's the good side of the business. The headaches, as you know as an entrepreneur, are several and many. Too many to list, but we'll cover a few. My most recent success story is I just hired a controller after three and a half years. So I've been doing the books, reporting to corporate, paying the royalties, paying the checks, paying the agents. So those are the things. As an entrepreneur, you really you put your blood, sweat and tears into these businesses and then you have to get to a certain level, to where you could start to relieve yourself of some of these pains. Chris: Yeah, that's so true, jerry. A lot of the people that I've had on before say exactly that that it's one when you're starting out, you're not big enough to outsource it or to hire for it, so you got to do it. But then it's getting to that point when you even when you are big enough and can afford it the level of trust and hiring the right person to hand off those key aspects of the business, so it frees you up to do the things as an entrepreneur or the visionary you want to be doing. So let's talk about that. What was it that you think helps get to a level of trust and comfort that it's time to hand off and it's the right person to hand off to? Jerry: Yeah, I think, based on my background of being an entrepreneur, you make a lot of friends and you kind of know. You learn the hard way. You hire the wrong person a few times and then, as you get older and more seasoned, you kind of know what to look for. In this instance, with that properties, I hired somebody I'd known for 35 years to come in and be my director of agents. I've known her since the SMU days, so the trust was already built in and then you're just very selective as you add the pieces to the puzzle to get those right people in place. So in half years we've let one or two people go, but we've been pretty successful in hitting the mark. Chris: That's great. So 70 agents or so you said. Have you started to implement any kind of processes that help with the integration process as you bring in these new people, so they understand kind of what the expectations are, what the benefits are for making the move? I mean, so where are you and what's the process you've gone through to kind of make that more institutionalized? Jerry: So the background for at properties and the corporate support we have is pretty important in how we've gotten here. They're a 25 year brokerage. They're the eighth largest in the country before acquiring the Christie's affiliate network, so they kind of had the processes in place. So it's buying. Whenever you buy a franchise and you wanna go down this path, you kind of get a little bit of assistance from and some help along the way on someone else putting the right pieces in place. I think what we've done a great job is integrate and implement those things that they've brought to the table, which I think revolves around a lot of our culture. You know, I think culture is so important in any business you have and so it's just we have fun things called at love, local events that came from corporate. So we'll pick a merchant somewhere in our geographical area, we'll partner with them, we'll send out a marketing campaign. Let's say it's a coffee shop and then whoever shows up at that coffee shop, our agents are there and we're running a tap for a coffee or a Danish in the morning. So that's kind of the community outreach piece. We use the word love strategically in all our marketing. So we say bringing the love to Dallas, bringing the love to Frisco and those types of things. So you know, recruiting is probably once you get the, once you get your overhead stabilized and your office space and those types of things. This is a business about relationships and recruiting. So I would say our two most important people outside of myself are our head of recruiting out of Frisco, head of recruiting out of the Dallas office, and so those have been very good hires. Chris: You know most, I think most businesses. It's hard to say they're not people, businesses or relationship, but certainly you know in the business you're in, where you're so customer facing right, you need good people that can go out and attract good customers, provide good service. But I have to imagine the last 18 months or so in residential real estate hasn't been the easiest. So can you talk a little bit about what you've done to help continue, promote one, promote the culture, to keep people positive and energized while managing through what has to have been a challenging time? Jerry: Yeah, absolutely so. Obviously we're all aware of how hot the market got, you know, a couple of years ago, you know, during COVID and post COVID. What that did in our industry is everybody wanted a real estate license because they saw all these transactions happen. So we had an influx of agents that came in that are young, inexperienced, but were here to make some money. And then, when the market turns, you kind of have the reverse effect. Those people were all eat what you kill, or 10, 9, 9 commissioned agents. They got to figure out how to pay the bills, and so we've had a pretty big exodus. Probably 15 to 20% of our agents across the nation have left the industry, and so that's been good for the sense of the people staying in it because you got less competition. But the ones that stayed in it most of them, have been through some of these ebbs and flows of the market, and so they kind of know how to prepare. And most of that revolves around when your transaction desk is slower, what are you ramping up to do? Are you ramping up your marketing, your postcard, social media content, are you revamping your website? And so those are all things that we, which the agents that work for us and part of our big, strong sales pitch based on the technology that we have. Chris: Got you Speaking of that on the marketing side, you know, are you seeing? I guess, one area or the other as far as marketing strategy work better, get more visibility or more return on investment. You see so much on social media, so it seems natural that that would be one, but I don't know if that's the leading one based on your experience or not. Jerry: Yeah, I think in pretty much every industry has been affected by the internet and no industry more so than real estate. I would say probably 10 years ago you saw a lot of print ads. You saw a lot of ads and you know business journals and those types of things trying to move property. But now it's really a digital world. We're using social media, we're using tools called AdWords, which is a retargeting tool to where it's essentially like if you went and looked at a pair of shoes at Nordstroms and then you left Nordstroms, those shoes are following you around. So we have the ability to target, geo track and geo target potential prospects and clients through our technology. Obviously, websites are important. Your collaboration tools that you're preparing a search for a prospect, like they're looking in this area for a certain price point. We have the ability to set those searches up and work with a prospect or a client on finding the home, ironically in the last price. I don't know when this started, but in the last year or so, almost 85% of buyers find the home they want before they hire an agent, or at least they zero it down based on how much information is on the internet. And so, really, as an agent, what you're trying to do is bring your expertise not only to get that transaction under contract, but then most of the work happens one second transactions under contract all the way through closing. Chris: Right, that is an amazing statistic 85%, but you're right. I mean, when everyone goes to the internet first, I think, to research or validate or do something. So it makes sense to me, but it's a big number. Sounds like you know here you use your work, technology and innovation and stuff quite a bit already since we started the interview. Some of this may have come from your franchise or some may have come from some things You're doing, but what are some of the things you believe are innovative in the way that you're operating the brokerage and helping your agents be successful? Jerry: Sure. So I think when you start understanding what different brokerages bring to the table in regards to support for their agent portfolio. Obviously marketing is a big one because they're pushing all the stuff out that we're talking about, but also the day-to-day operation of an agent is pretty important. Most brokerages large brokerages like Coldwell, banker, some of your biggest national brands are very antiquated when it comes to technology support. I would say there's two brokerages at the forefront. I'd say Compass is in second place and I think App Properties is in first place. And I say that because we've been building a technology stack called Platform, or our franchise or has, since 2003 and basically an agent logs in and does everything they need to do as an agent in one technology. When I interview agents and I show them the technology, they're blown away because they're in four or five, six different technologies throughout the day trying to get their social media posted or created, their transactions done over here, their docuSigns another technology they have to use, and we have everything in one place, and so that's been a real big selling point for us when we're recruiting these agents. Chris: Yeah, I mean anything to make your employees or, in your case, I guess, your contractor's life easier. Have you started to look into, or is this already incorporating any kind of versions of AI? Jerry: AI is already integrated. Nowadays, agents are always doing, as an easy example, they're doing descriptions of the properties. So now you can lean on AI to help you describe a $5 million house with five bedrooms, six baths by describing it into AI, and then it'll help you create that luxury description. So there's things like that. Obviously, our CRM has a lot of AI tied to it and so, yeah, that's the way of the future and it's getting more and more integrated and implemented into all our tools. Very nice, very nice yeah. Chris: All right. So I want to make you kind of reflect back. So yeah, this about, by your own description, not the first time you kind of started a new venture or stepped outside your comfort zone. So when you think about what you did I guess leaving, you know, maybe leaving the law firm or even some of the ventures you started while you were there, but going to credit card processing et cetera where are some of the lessons you learn through those ventures that you think prepared you for taking the step you did without properties and the steps you're taking now to grow so rapidly? Jerry: Yeah, I think if you're a serial entrepreneur like myself, I think the one thing you learn each time that you have an idea or you go down the path of starting something is you think you're going to get to the finish line a lot easier. It's your idea and you think you're going to do that. And I think probably in every instance including the law firm, including the credit card processing is one lesson is it just takes a lot to probably 10 times, 100 times more man hours and work and you got hurdles. That you're not expecting. But I think that's part of the reward too is why I'm built the way I am. You enjoy that when an obstacle comes and you get your way around it or over it. But I think you know frankly, it's probably what every entrepreneur says it's never as easy as you think it is. There's no get rich. You know we talked about most of what we do as lawyers and what I'm doing is a people game. You know you're hiring people and people disappoint, you know, and you're having to find different people sometimes, and so the lesson is just pride and expect the unexpected and you'll be okay and be able to sleep at night. Chris: I like that. Well, think about, is there a kind of a challenge or a failure setback that you can point to over the last, you know, 15 years, 20 years, whatever that you feel is maybe in some ways either a defining moment for you or one of the bigger learning moments that you got? You kind of got hit with a little headwind but you overcame it and because of that it's kind of helped propel you either in your own personal journey as a leader or, you know, in things you learned as an entrepreneur. Jerry: Yeah, I'd say you know, probably the biggest lesson learned of all time was me starting a real estate development company with a home builder and a commercial partner and, you know, diving into that with not a whole lot of experience, and so the challenge was obviously, in real estate, you're hoping to build something and sell it, and so the big challenges is if you build it and you borrow a bunch of money and you don't sell it. And so in 0809, 2010 is probably should have been my premier happiest days of my life. I'm on a law firm, I'm making some good you know coin on the law firm side, but I'm literally getting dragged through the mud financially on the real estate piece, and it's probably one of the reasons it's taken me 10 years to get back into it on the brokerage side, because I literally came out of that was some financial PSD. You know just could not sleep, you know got I mean health issues, depression, pretty much everything you can experience as an entrepreneur and so you figure out a lot about yourself when you're going through something like that, and you know you either stay in bed and talk about it or you pull up your socks and get out and try it again. Chris: That internal fortitude, you know I think any entrepreneurs got to have that or it's just not going to happen. I appreciate you sharing that. Were there some things that you did? You know that you know other than just I mean pure gutted out. You know, to help you kind of get through that. You know, leaning on family friends, I don't know. I mean I have to believe we've got some listeners and other people out there that you're going through the same thing. Jerry: Sure, I think where I lucked out was, you know, just to be frank, I was on about $60 million and personally guaranteed debt that was worth probably about 30 by the time I was trying to get out of it. So there wasn't going to be any family help. It was. It was hey with you, you know, in a loving way, of course. But when you dig a hole like that, you just got to figure out the best way out. And for me, where I benefited was I had a law degree and I was a lawyer and creditors could not touch the ownership interest in my law firm because it was tied to my license. So, through bankruptcy lawyers and all that stuff, I got educated on that and gave me the strategy to get through that situation and come out on the other end, which was one of the reasons I sold the interest of the law firm back to the partners, because that allowed me to have a little bit of a stream of income there in 2012, 13 and 14, while I got the credit card processing company going and getting these other things going. So there was, if there was, a silver lining, it was that fact, but it was still still pretty embarrassing financially and pretty embarrassing as a professional to really go through that over a three or four year period. Chris: You got to be hard but, like I said, I mean now that you've come through it, you know you can certainly appreciate the opportunities you have today and know that. You know I certainly probably learned some lessons of what to not do, going forward right. Jerry: Absolutely, I would say. The one lesson you learn in that scenario is you become a lot more frugal with your financial decisions and you know, especially in the banking industry, like one thing I'm proud of with that properties is we've never bought a bar to dollar. We got zero debt, and so those that's a probably a direct result of what I went through, you know, 15 years ago was I don't want to do another business where I got a bunch of debt and I'm trying to get that off and make money to live off of. Chris: That's great. So you mentioned earlier I think it was a credit card processing BlueStar, where you had some dealings with Bain Capital, and obviously you're dealing with a franchise or in this current business. So let's talk a little bit about maybe what you've learned through that. I kind of relate or maybe call those you know investors, partners, strategic partners. What have you learned as kind of some of the best ways to deal with them so you keep that relationship strong and healthy? And maybe it's something you know that happened that you're like I did this or they did. You know something that happened that soured the relationship, one they got to help our clients here at the firm you know, you know find themselves in those situations all the time, and so I'm curious you know what you know, what lessons you've learned through that process? Jerry: Yeah, so I would say getting involved in. And so when we had the credit card processing company, it was pretty a pretty simple model. We were going out and you know recruiting or or you know we're trying to sell merchants, you know restaurants Anybody who ran a credit card was it was a prospective client approached by a group who had an idea of buying up these technology companies in the youth sports space. So like, if you sign your kid up for soccer, you're there's usually a form and at the end of that form, whether it be the YMCA or anywhere else, you're paying a fee for your child to play that on that soccer team. So the model we had was take the credit card processing that we had built our own API and those types of things and bake it into a technology and go buy these companies. And interestingly, it was about how do you flip the model from a EBITDA and a multiple perspective. So these tech companies that weren't that large of companies because they were kind of geographically located, running different types of youth sports camps or whatnot, they weren't sophisticated enough and they were usually outsourcing their credit card processing to stripe or squares or something like that. So we would acquire these companies and bake in our own processing and from an ownership perspective, then that would change the multiple for maybe two times to 12 times because you have that reoccurring revenue stream coming into your business model. I literally probably learned more over that. First, 12 to 20 per month as we were acquiring these companies, doing due diligence on them, and I was the chief legal officer of the company, so I was in charge of all the due diligence. So we acquired 20 something companies and I bet I did due diligence on about 300 over two years. But it was really cool because I got to see what investors and power players in the venture capital market, how they looked at things and it's there's not a lot of emotion, it's numbers on paper and it's how do we make, how do we do this to this group of businesses, and then how do we sell it and make money. All about the return on investment, right. Chris: Exactly so. It's a. Jerry: It's very cutthroat which some businesses are, some aren't, but it was a great learning experience. I'd like to say I probably learned more in that two to three years Dealing with those big VC firms and listening to those meetings and kind of running point on due diligence than I probably learned in any other aspect of my life. Now, that's so, but that's so. Chris: Let's turn it back a little bit to app properties specifically. I know you've recently launched a new sports and entertainment division Tell us about that. What's going on behind that and what are you trying to accomplish so in the real estate brokerage? Jerry: world. There's different ways to market yourself right, and a lot of that boils down to your experience of your agent portfolio, and so some real estate brokerages are residential, some may just be commercial, but on our side we have, we've accumulated some agents that allowed us to create these divisions because of their experience levels. So land and ranch is one division, and then sports and entertainment is another division, and basically there's some criteria that we've put in place before an agent can say they're part of that team or that division dealing with professional athletes or celebrities on a number of occasions, some of the qualifications, but essentially, when somebody's moving like a professional athlete or a celebrity, there's a lot of sensitivity to that, or there's a lot of urgency, there's a lot more moving pieces, and so that specific division has agents who are, you know, experts in helping that transaction or that client Get from point A to B and solve a lot of problems along the way how to move their cars, how to move their kids into new schools, you know everything that comes along with kind of that type of transaction, as opposed to someone just buying a house and selling a house. So are we going to see? Chris: Super Bowl ads anytime soon, if I can at homecom I could afford it. Jerry: No, that's the goal is. We're really good because of how the clients affiliate network has come into play for us. I don't know if we mentioned this before the call or on the call, but you know our corporate partner ended up buying the Christie's affiliate network, which is a network of independently owned brokerages around the world. I think we have 900 offices in 54 countries, about 35,000 agents, and the reason Christie's the auction house, christie's the family who's owned that brand and that company for two hundred years. They sold the app properties because of the technology and we've been for two years bringing a worldwide global powerhouse network together into the technology to share referrals and data and information, and so that's been one of the one of the real keys to some credibility for us. Very cool. Chris: I think you just launched something else, maybe in the last week. Developer services Tell us about that. Jerry: So so again, we all know there's developers out here but we're not sure there's developers out here building multifamily building, you know, developing neighborhoods, multi-use, and so for a brokerage our size to have the ability to provide those services was kind of hard. So we ended up meeting a group of people out of Austin who came from Storybill and for those listeners who've heard about Storybill, that's a multi-billion dollar developer who went, ran out of money last summer. But we ended up negotiating their entire creative team to come over to Christie, our Christie's, and create this development services division. So starting with the chief marketing officer all the way down to their website development team, their on-site sales, so we've got a team of about 12 of superstars and they really fell in love with the Christie's brand to kind of move from Storybill into our umbrella, to kind of push those services out. So that'll be a huge win for us. Chris: So, as you sit there running all this, what is it that kind of triggers for you that this is an opportunity that makes sense, because not everybody can see that, and so there are things you're looking for. How do you go about making that decision and taking on the risk? Jerry: Yeah, so risk is a little less scary in our business because most everybody who works for our brokerage is a 1099 contractor. So we really have a pretty lean machine when it comes to we're running this right now with about seven full-time employees, three offices, so you got overhead from an office space perspective, but really you're kind of it's kind of a lean business model, which is one of the things that attracted me to it. And then obviously you have to have the people to be able to promote these different levels of services. So I think the thing that's been lucky for us is one our relationship and our network in Dallas to help get it started. And then obviously the people we've been able to add at such a young infancy of a company have given us the credibility and the numbers are reflecting that. Chris: Gotcha. So before I don't want to wrap this up without talking a little bit just about you and your leadership style, let's talk. You know, how would you describe your leadership style? How do you think that's evolved over time based on the scars and other lessons learned? Jerry: You know you work at a law firm, so you know running a law firm is you got a lot of smart people, a lot of egos, a lot of staff, a lot of overhead, and so I learned a lot about you know the operational side of a business in that seat. And then I think my ownership style has probably changed completely since I left the law firm. I'm a lot more interested in the well-being of my employees, a lot more sensitive to the culture. I think. When you talk about people coming to work and going home, in my mindset now I want that to be a great experience. I kind of use the word experience a lot in the last couple of years for some reason, and I think it's just. My evolution is like everything in our lives is an experience and you can make it a good one or you can make it a bad one, and so I think my leadership style is I want every experience to be a good one. At the best I can make it. Obviously you're going to have your headaches and your issues pop up, but we have the music on in our offices every day. We have happy hours on Thursdays. We built bars in both of our offices in Dallas and Frisco, and then we're putting one in our location in Austin so that we can have happy hours with our agents and our clients and our prospects. We hold a lot of events and I think our interaction with the community and the philanthropic stuff that we're doing is really cool. So I think where I've gotten is you know I'm 54 now and you know I started that law firm at 28 and I had a whole different picture in my mind at 28, right Till 35, of what life was going to be for me, and now I'm kind of trying to enjoy it a lot more. Chris: I love that man. Happy for you. You know clearly you're on the right track and couldn't agree more about how important culture is to any company. And I think I've said similar to you. I think life is about experiences. I think they're only really down to learning experiences good experiences and learning experiences as though, rather than bad, just learn from them and don't repeat them. Jerry: Yeah exactly right. Chris: So let's turn a little bit on the personal side of things and not as serious. What was your first job? Jerry: First job, I was a clerk in a law firm. Chris: Okay. Jerry: I was working in law school. Okay, my first job in high school. Like most of us, I grew up in Missouri in a small town. I had a yard. You know service with my best friend and we had our lawn mowers in the back of his truck and we mowed yards. So that was probably my first experience as a having a job. There you go, and first is an entrepreneur was leaving a 250 person firm to start a law firm with two other guys and being 28 years old and that was pretty exciting. We had metal chairs and you know fold up conference room table and laid out of the movie. Chris: Love it. Well, I can relate to the a little bit to that, but definitely relate to the mowing yards. That's what buddy of mine and I did in high school. So you know good money then I guess. Okay, personal preference, tex-mex or barbecue? Well, that's a tough one Probably barbecue. All right. And if you could, take a 30 day sabbatical. Where would you go? What would you do? Jerry: You know, this is my two sons who are a senior and sophomore at University of Texas right now. They called a year ago about this time and said, dad, we're going to go to Japan. And I was like, okay, and they got on a plane, just the two of them went to Japan for three weeks and after hearing that I kind of want to do that. Chris: How cool is that. The two of us went and did it on their own. Jerry: They did it on their own, traveled around on trains and backpack and love it. They're experienced when they told the stories and went through the pictures. I mean it's just a really cool culture. I'd like to go experience that. Chris: Okay, jerry, I can't thank you enough for taking the time to come on. It's hard to believe that you know I don't. I might add the numbers we met at SMU and, as undergraduates, went to law school together, so we had a lot of years together. So it's great to see where you are today and what you're doing. So proud of you. Jerry: Man. I appreciate that. And the same back at you. I followed you your whole career and super, super proud of you. What kind of legal person you are and lawyer and leader and everything you're about. So appreciate having me on and proud of you too, my man. Chris: All right, we'll do it again. We'll find a reason to do it again sometime soon. Awesome Sounds good. Special Guest: Jerry Mooty.

In today's episode of Building Texas Business, I speak with Curtis Hite, founder and CEO of Improving. Curtis shares his entrepreneurial journey, from starting at Raytheon to selling his first business and experiencing betrayal, fueling his passion for conscious capitalism. We talk about how Improving has consistently grown during economic downturns by prioritizing employees and culture. Curtis provides valuable insights into his leadership strategies, innovative programs for maintaining connections, and stakeholder models for partnerships. Whether you're an entrepreneur, business leader or interested in leadership, you'll gain inspiring insights on building a resilient company through conscious capitalism. SHOW HIGHLIGHTS Curtis Hite, founder and CEO of Improving, shares his entrepreneurial journey from feeling betrayed and undervalued at his previous jobs to founding a successful business that values its employees. We discuss the importance of maintaining a people-centric focus and sharing strategies for leading a successful company. The concept of conscious capitalism, which is a philosophy that Curtis and his team at Improving have strived to embed in their work culture, is explained. He shares his unique leadership style, emphasizing positivity, high energy, and inspiration. We discuss the importance of listening to the ideas of employees and how he prioritizes them in order to benefit both the business and the employees. Curtis introduces a program called Come Together, which helps build and maintain connections among employees. He describes a homegrown product called Engage, used to measure employee involvement and assign values to their contributions, a major part of their profit share is based on this. We emphasize the application of a stakeholder model in business, which is about identifying key partners and building relationships with them. The discussion touches on the importance of leading by example and inspiring with vision, reflecting on how Hype shifted to utilizing personal life books and creating a vision for his organization. The episode ends with a light-hearted conversation about Curtis' first job, barbecue preferences, and cherished family memories. LINKSShow Notes Previous Episodes About BoyarMiller GUESTS Curtis HiteAbout Curtis TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode, you will meet Curtis Hite, ceo of Improving. Curtis shares several important lessons he has learned along his entrepreneurial journey, maybe the most important being believe in yourself, but not too much, because you're part of a team. Curtis, I want to thank you for taking the time to join me on Building Texas Business. Curtis: Alright, thank you for having me here. I appreciate you including me. Chris: So let's get started by just you introducing kind of yourself, but more importantly, your company and what it's known for. Curtis: Alright, so Improving is a modern digital services company. I think what we're probably known for most, though, is our participation in leadership in the conscious business movement in the United States. Chris: That's great. What inspired you to start Improving? Curtis: There's actually a story I consider Origin story here, that's good, we're here for stories, okay. And I was working two companies ago at Raytheon. It's a very large company, over 100,000 employees. I was very ambitious as a young man and I had this idea of creating an internal consultancy at Raytheon. Had some skill sets that were fairly unique at the time with the technology transition similar to where we are with AI today but that was object programming, and so I came up with a business plan with my partner there and we presented it to the leadership. It went all the way up to Boston and when a letter came back it included. The words were the sentence tell the software we need to get back to work. Chris: Oh, okay, and so. Curtis: I kind of reflected on that. Being part of 100,000 person organization, those words were never intended. I get that for my eyes right. Right it was intended for more of the senior executives at the organization. But it kind of inspired me to say, well, wait a minute, maybe I can do something different. This is a good business plan and developed it on my own. And instead I took that out and found three partners that were already in the industry and started my first business. But that was the first business, but that's how I got started there. Okay, I kind of pushed there, and this was after four and a half years of being at this larger company. And then the second story, the origins to this one, is rooted in that company, the three partners, that there were, three partners from Raytheon, three partners from this new business, xp, and in the end, without going into a lot of the details, I felt very, maybe betrayed by one of the partners and maybe misled was the a better word Very misled and taken advantage of, and I always remembered that feeling. So take those two stories, plus one more, which was we sold that business to a French organization and we went public during the dot com days and after several years of running that business the French business, let me go and we were experiencing literally record revenues at the time and record profits. Even a majority of the profits of the group are coming out of North America, which I was responsible for. And I remember the shame that I felt in that moment and embarrassment and all the raw feelings that go with that. And there's a little bit of irony there because I might have been thinking about leaving or trying something new, but that kind of jolted me and I had something to prove. I had no intention of going back into the services business again. Yeah, I found myself with something to prove, creating a new services company. That was fueled out of shame, and some people may like that. Chris: Well, essentially you say it that way because my sense is that people were really honest about it. They probably come to the same conclusion you just did and did years ago. Is it maybe some shame or embarrassment that fueled them to prove something wrong and got them going? I don't think there's anything wrong with that. Curtis: Yeah, I'm not going to say there's anything wrong, because shame, if channeled properly, can be a great motivator. Chris: It's not the healthiest of feelings, I get that Right, but it does create a high degree of motivation or denotation, depending on how you are built, how you let it handle or affect you right. Curtis: Right. And so my partner, rick, in this business he actually three or four years in and we very quickly we went from 600,000 to 2 million to roughly 6.8 to 10 million in our first four years and he was worried that I would lose the motivation right, and that really didn't happen. It shifted and motivation came from a different place. But in those early years. Chris: I remember the earlier events and what can I learn when shake this company and I didn't want to mislead anybody, Right. Curtis: From lesson from. Lesson two yeah, I didn't want to feel like a number, anybody that would feel like a number. I was 139662. Chris: That was my number at the large company and that's what you would give that number instead of your name. Curtis: Right, and I felt a little treated that way when it's tell that software, we need to get back to work Right. And so when we formed the company, culture was a very important and perhaps one of, I think, our greatest accomplishments is that we've been named to over 100 best places to work. We've been number one here in Houston, led by Devlin Wells. We've been number one in Dallas, we've been number one in Texas, we've number one in Ohio, and it's not about being number one because in almost all of our offices were recognized, but it's just really about the executives at the company caring about the employees. Chris: Right the way they feel valued. Curtis: Right and that's what I'm genuinely carrying and valuing the employees, although it's not all about the employees all the time either. It's this careful balance. Chris: Sure, Well, if they don't feel valued, you're not going to win awards like that, right? Because they pull into your organization to really try to get a feel for the pulse and what's really going on. Well, thank you for sharing the origins because to me there's so much learning in that and in each entrepreneur's story there's different things that cause inspiration, from ideas and knowledge to emotions and feelings. What I gather from yours is there's kind of a series of three different setbacks, if you will, that you learn from in different ways An idea being disregarded by a large corporation hear those stories all the time. Partner issues in a business and learning from that. Hear that, represent and guide people through those issues all the time, and then this kind of the shock of being let go when you thought you were doing everything right. So I think it's a really cool, well-rounded story. So when did you talk about starting improving with your partner? What year was that? Give us a reference in time. Curtis: The very end of two things. Chris: Okay, so, wow. So you were a few years into that company. You were talking about the success over four years. You had economic crash in 08, but you were thriving through that. Curtis: Right, we actually built the company in the Great Recession and we grew every year through that environment. In fact, we've grown every year in our history, so we've never had a year. Some years it's small, a few percentage points. Other years it's big growth, but that really it's core of one of our values, which I call involvement, or which we call involvement, and that our success is a consequence of our collective involvement and leaning on each other, no matter what the conditions are good times, bad times. So, yeah, really have a big team and I really believe that. Chris: Yeah, so you've then managed at least through a couple of big downtimes. You talked about the Great Recession. Obviously, we had a global pandemic. What are some of the maybe lessons learned that you could share about how you kept focused to allow the business to continue to grow even though the world around you is, like you know, in chaos? Curtis: The first thing is remembering your team. Sometimes, as entrepreneurs, it's easy to become self-reliant, sizing your own role in this and maybe even disregarding the roles of others. So I highly encourage people and I had that lesson early on that I don't have tendencies to do that. In fact, I know deep down the exact opposite is true and pull the team together and what are we going to do in these crises or these downtimes? What are some of the ideas? So that also lets you know you're not alone. It's a good point. A lot of business owners, including myself, I often feel alone. Chris: Sure. Curtis: But I'm reminded that when I ask for help or I'm a little bit vulnerable, then I'm not alone. I'd simply feel alone, often because of the own barriers that I put up for myself, and that would be the number one thing I would remember in any of these downtimes. The second is to remain focused on what is most important, and that's unfortunately sometimes that's keeping a business alive and being not only an active member but considered a leader in conscious capitalism movement. People sometimes misinterpret that means we can't do layoffs. We can't because we're conscious business. How those are contradictory. They're not contradictory. Sometimes we have to make the decisions to keep a business healthy and unfortunately, when you care about the employees, yet at the same time we have to make decisions because you care about the business and the longevity of the employees. It requires difficult decisions. Don't be afraid to make them, but make them with a caring heart. Chris: Right, but I wanna talk more about the conscious capitalism movement. But I think you hit on something that's very important Not losing sight. At the end of the day, you're kind of responsible for a healthy, thriving business. Does it mean you're not gonna face hard decisions that affect people's lives? But the other thing I think I've learned and I'm curious if it's been your experience is, when you're faced with those hard decisions, the sooner that you can make them and not rashly but with good information the better off everyone involved is the employees affected, the company, yourself as a leader and moving through that process. Curtis: That's true. In my career I've had to do layoffs three times. Okay, one was during the dot-com bust and Enron was our largest client. We built their software. Let's not, we don't need to visit that story anymore. It wasn't us but we built the software. And then the second was during COVID was such a rapid decrease, people pulling back in business and services, just a lot of fear in the industry. And then the most recent one was some restructuring that we had to do this year. Chris: Okay. Curtis: In a weaker and very what I call volatile economy, and they're never easy and I know they're imagined by people that are affected, as this is easy but they're not. But we can't be afraid and I learned from I was forced into it with Enron All night. 40% of our business went away in a single day. Covid was the same thing. Chris: Sure. Curtis: Right, we had business units that lost 65% of their business in three weeks and when you look at that, you're forced into very expedient decisions, but it slowed down enough to make the good decisions. Right, and don't be afraid because you're gonna get negative pushback, but treat people with respect and treat people with care, because these are real people that have real lives and it's a very sad thing. Chris: It is. It is, and in other words I'd add there, treat people with dignity. So it is Absolutely. It is not an easy thing to have to go through as the leader making those decisions. So let's talk a little bit about the conscious capitalism movement, because you talked about it and referred to it twice. I was fortunate enough I shared with you, before we started recording, to speak at one of their events. I think what that is all about is just so wonderful for the business world. Share a little bit about how you and improving have been involved in that. Curtis: I got invited in 2009 and I mentioned earlier my motivation was kind of shame when we're trying to survive and build the business. But about three and a half years in, I got invited by a good friend that I still do business with and friends today, to this CEO summit in Austin and it was a phenomenal event and it was really shifting in my motivation. The keynote speaker there really had a statement at the beginning of his presentation that landed with me and it was that, outside of sales professionals, it professionals have the worst perception among CEOs and I got really defensive because we're an IT company and I'm thinking in my head and I'm journaling instead of listening to the presentation and I kind of realized our own business. Wait a second. Our industry has earned some of that, not all of it, and whether it's perception or reality, we have to own it. And that is when I actually shifted the. My own motivation was to change and shift that perception and not feel victimized by it, but to really turn that into energy on how we change that as an organization. So I was inspired by that event, by the people at the event John Mackie of Whole Foods, who originated the Tip Kindle container store, doug Rao of Trader Joe's these are really great leaders inside these businesses and I got inspired by them, plus that message and I wanted to help the organization. So, through helping the organization, the local chapters speaking on it quite frequently, not being ashamed to be a capitalist but knowing that capitalism can be used for something even greater than the good it already does, is becoming the foundation of our business. I call it the philosophy of our guiding principles. Chris: Yeah, I love that. So, taking that, how does that, or how has it and how does it continue to shape and influence the culture at improving? Curtis: Well, the first, a year later, when I was with my partner at a conference or seminar that was being taught by Stephen coming on trust, I kind of had the epiphany that the reason why we had the perception was because the CEOs didn't trust their IT organizations or partners a lot of the time. So we refold our value to include this concept of trust, and I consider three of our values are identity, but one of our values, building trust, is our ambition, and so this combination of changing this perception by focusing on trust has reshaped our business for the next decade. 70 percent of our employees participate in trust pods every week, voluntarily. They don't have to trust pod is a group of five to 15 individuals talking about these 13 trust behaviors, how they're going to use them in their daily lives with their clients, our stakeholders right, but the biggest effect is how it affects you outside of business, how it affects your relationships at home and with your friends. But this is a relentless pursuit when you think that 70 percent of our employees voluntarily join these groups and talk about building trust every week. Chris: That's. That's amazing what I guess I'm, what I'm assuming occurs in the through the participation of these trust pods, is almost a blending of work and work life and family or personal life, and there is allowing for a bridge, which to me is so important, because I think it's a mistake when people think I'm going to drop who I am as a person or what goes on in a personal life when I step in the office and vice versa, because there's a, to me, a natural blend. It's like let's just acknowledge that it's there, but how can we help them coexist? Curtis: I completely agree. Different conversation, different presentation. But I really don't believe in the concept of work life balance because it really suggests there's one or the other right. They're not connected in any way. I love many of the premises behind it, but I'm a proponent of an integral life. Yes, work is part of your life and family's part of your life, and health, and maybe faith and or learning right, everybody has the areas of their life that they prioritize, but this is a and work is almost in everybody's life. So how do we integrate these and these trust pods become a significant way of integrating and we help right. At least I like to think, and I often get this feedback that the people who participate in these trust pods with the intent of applying it at work benefit even more at home yeah, I can see that. Chris: So You're a software company let's talk about. I mean just saying that, as it is to me, infers innovation. So what are some of the things that you do as the CEO to help encourage and instill the employees at improving, to be innovative, to act innovative, because with some of that, you know you have to create a safe environment and allow for failure. So what are some of the things that you have done or are doing there to improving, to help foster that? Curtis: I referred to one of our values before, that our success is the consequence of our collective involvement, and I've referred to trust. One of the trust behaviors is to listen first and really combining those two things to try to be innovative, to gather ideas right. As a CEO, you also have to be mindful that you're going to get a lot of good ideas from your employees when you ask, but you can rarely execute on them all right. So at any given time there's probably 100 things on the money put in quotes. The world's be doing right Well, but we can only do three or four of them. So I really try to make an effort to listen, have our other executives at the company listen, try to bubble up some of the most important ideas, but also represent what's important to the business and where the important ideas to our employees overlap with the important ideas to the business are those that we take, because sometimes they don't always overlap right. Employees may want something or the business may want something. That doesn't overlap. So that's a way that we prioritize, but I would say, of the ideas, of the programs we have in place, of the initiatives, we have something called come together. That is a phenomenal gathering and creating connection. The vast majority, 90% don't come from me, they come from the company. Yeah, and it's just listening and finding the good and finding the value is often probably and letting your own ego. You don't have to be. This is for the entrepreneurs up there. You don't have to be the source of all the good ideas. In fact, I would encourage you to be take more pride on identifying the good ideas than being the source of the good ideas. Chris: There's a lot of satisfaction, I think, when you can get to that point of being proud of someone you hired, that maybe you helped train or develop or created an environment where they could be trained, developed, create their own opportunities and reward them for the ideas that they come up with right Absolutely the whole new level of satisfaction. Curtis: It is. Chris: Freeze you up as the leader to do so many more things if the pressure of all the good ideas is off your shoulders. Curtis: That's right, or all the accolades is off of mine or other executives. We actually have a homegrown product. That's, I believe it's part of our competitive advantage. It's called engage, but it's about measuring this involvement that I've talked about. Employees get to enter in things that they are doing to benefit the company, often while benefiting themselves, and it tracks these things and even assigns values to them so that when they do this, they kind of know how they're participating and how they are adding value. A major part of our profit share is based on that. Chris: Oh wow, that's right. Yeah, well, as you know, too right, if you incentivize the behavior, you're likely to get people to behave in that way. So if you incentivize something like that, yeah they're. I imagine the engagement is really strong. Curtis: It is for two reasons. The engage creates visibility. So, as the CEO of a 1600 person organization, how do I get visibility to what people are doing? I have detailed visibility into what people I look at this so they often get accolades. So people that are seeking kind of affirmation and things like that's their reward for something like this. Those that might be more utilitarian and might be more motivated by money there's a money component to it for those people, but not everybody's motivated in one way, so we try to create a mixture. Chris: I like that. So changing the subject a little bit, but still to building a company, driving it to success. You have to work outside your organization with other stakeholders or surrounding yourself with a strong team. You know external professionals. What are some of the things that you have done to identify key partners, build and maintain those relationships that have benefited, I guess, are allowed for improving, to grow, to the company it is today? Curtis: You use a very important word for me, which is a stakeholder. Here we're big proponents of a stakeholder model, not just a shareholder model, and it's very important, I believe, to make sure, like you would your own employees that all of the stakeholders have a certain alignment with your values and your ethos. You're never going to get perfect alignment because these organizations have their differences, which are wonderful, but you should kind of tell those that align similarly and those that don't. So, when we look at suppliers, what are the suppliers that have a similar set of core values? How do they treat right their own suppliers? Because we treat our suppliers better than our own customers treat us right. Chris: Very important. Sure. Curtis: How are they treating their own suppliers? When we look at partners, right, a lot of partners out there are looking at it. What's in it for me? And despite the rhetoric of us, you can sift through that, because as a partnership, are they sometimes willing to go first? Do we go first? Right, have you conscious capitalism? The movement this way? It's a partnership, but we were going first all of the time, without resentment, right, right. Yet in the long game, that ends up paying, even though that was not our purpose. So looking for this alignment becomes key, just like you would with an employee. Chris: Makes sense. It makes us. I like the treat the suppliers better than the customers, because without those suppliers you can't serve your customers. Curtis: No, right? Well, I'm not saying we treat our customers worse than our suppliers. I said that we treat our suppliers better than our customers treat us. Chris: Oh, that's right yeah. Curtis: Because we give the, we try to treat our suppliers as if they were a customer. Chris: Yeah, Makes sense. We like said they're integral to you delivering on your promise. Curtis: Very. Chris: Let's talk a little bit about leadership style. How would you describe your leadership style and maybe I'm probably pretty certain based on this conversation how you would describe it today versus maybe 15 years ago, and maybe some of the things that occurred to cause or help you evolve to where you are today? Curtis: I would describe myself as very positive, high energy. I genuinely care about people and I believe and this isn't hubris, I think many people would agree that I'll rely on inspiration too and I think I'm fairly inspiring in the right circles, both one-on-one and at least at a larger level. But when I look at some of the lessons, how that inspiration has evolved over time is very important and it's kind of very different. When I was younger I tended to rely on kind of leading by example, and if I did everything, then people would be inspired and follow. And that works to some degree and that's a common source of inspiration for people Like oh my gosh, look how hard Curtis is working. And right, he really cares about the business. I might do the same thing, but I do believe that only goes so far. Chris: It's kind of like the command model, and I think even Jim Collins talks about it. You can only get a company so far if it's the charge up the hill type of leader. Right, you can be successful, but to a point. Curtis: And to a point and I switched to trying to inspire with vision, the vision of what we could be, the vision maybe of what I personally can be. And I started with my own personal life books and creating vision for myself, but switched that to the organization inspired by a leadership group, training, staying out of Dallas and to even put together a 10-year vision for the business. And so today we have a 10-year vision, we have three-year visions, we have one-year vision. These are all written, but I tend to be able to see things and see the good in things, and that's one thing. That's why I sit on positive. So that's I see the good and can inspire around the good versus the negative or polarizing concepts in our world today. Chris: What I like about that because I can identify with that is that positive attitude is kind of how to interpret what you're saying. Is that you're in control of that. Right, you can control whether you're really going to bring up positive mindset to whatever the circumstance is or not, and you choose to say I'm going to look for the positive and then try to be inspirational about what we can do in this circumstance, and I think that's effective leadership right. Curtis: Positivity is a choice. Chris: Yes, right. Curtis: And whether it's in our personal life or our professional life, we can, in almost any circumstance, choose to find something of gratitude in the circumstance. There are things I get it that we it's too hard to find and I'm not diminishing those, but for most things in people's lives and that becomes a choice. I've also found, and for anybody listening to this, think of your three favorite managers, leaders you ever worked for. Would any of your favorites ever be described as negative? I've asked this more than 1000 times and outside somebody hearing this and trying to prove me wrong, nobody, ever, not a single person, has ever said yes, their favorite was negative. It is something of the most effective leaders. Positivity is one of what we have found to be the six most common traits. Chris: It didn't surprise me at all. It didn't surprise me at all. So let's kind of just to wrap up this conversation. What I always like to ask guests to do is we've got an audience of aspiring entrepreneurs, or maybe just started our own business. What are one or two nuggets of you know? My guess, takeaways that you would say, hey, if you're out there doing this or thinking about it, if you don't do anything else, do at least this. One or two, two things, or maybe avoid X and learn from my mistake. Anything that you can draw upon in your experience of you know. Two, I guess, two companies, three companies now that you could share. Curtis: First I would say believe in yourself, but not too much, and remember, remember deeply in your heart that you're part of a team and while the pack maybe nothing without the wolf, you have to remember that the wolf is also nothing without the pack and these things come aligned. So it's a team effort and very early on to and this is a radical idea I shared 87% of the company, and this was not just me, this was my partner coming alongside saying let's do so. My partner and I combined had about 23% of the company voting units, so we could be voted off the island at any time. Interesting that is sharing in the success of the company and that's one of our tenants today of creating a good work environment that we really did share. From an equity perspective, you may not have to share that much, okay, but it worked for us and I'm not and I'm not going to complain. But what I found most commonly, the most owners that we've found true owners in any business has been six and we've talked to hundreds of businesses. Yet we have hundreds of them and we're a privately held company. Chris: Yeah, no, that's impressive and definitely putting your money where your mouth is right about trusting the collective group to be successful, because they'll benefit from it as much as you will. Curtis: And then they. We found people have stayed, they've benefited and they're inspired often, yeah, harder towards a collective goal. Chris: That's great. That's great advice. Yes, thank you for that. Thank you. So on the personal side, we'll lighten up the mood a little bit. So what was your first job? Curtis: Oh, first job was mowing lawns because I got in trouble as a kid. Don't want to share that full story, except me and my brother putting some napalm burn some people's tires, goodness only, and I ended up mowing lawns for a long time to prefer to buy the tires back and all of that. Chris: Oh, that sounds like that. Yeah, there's a deeper story there, for sure. Okay, Tex-Max or barbecue. What do you prefer? Curtis: Barbecue. Chris: Okay, no hesitation there. I like it. Curtis: Love barbecue. Chris: And then last question if you could take a 30 day sabbatical, where would you go and what would you do? Curtis: Wow, I don't know where I'd go, but I know who I'd go with and I would take my two kids, Colin and. Chris: Autumn Awesome, that's great. No, no better people spend time with right that's right, all right. Curtis, thank you for sharing your story and being so open about what you've done through your career, the setbacks, the successes, and what you're doing now to build, improving, to the amazing company it is. Curtis: Thank you so much for having me today.

Removing friction, taking control of user data, and enhancing customer engagement throughout the funnel are necessary steps to increase game margins and retain valuable players. However, the app store duopoly can put a block in the road, restricting access to players in growing markets, charging high transaction fees, and limiting commerce capabilities. This week's guest, Xsolla, clears those obstacles. Xsolla is a game commerce platform that helps devs distribute their games directly to players, bypassing the oversaturated app stores and putting the power back in the hands of creators. Chris Hewish, President and Interim CEO of Xsolla, takes centre stage in this episode to tell devs about the company's innovative solutions that maximise player LTV, give companies increased control of their data, and provide fully customisable, alternative monetisation tools that don't interrupt gameplay and can increase revenue per paying user by 8X.  CHAPTER TIMESTAMPS 0:10 - Intro 02:45 - What does Xsolla do? 05:39 - A new era of game distribution 09:06 - Is it more cost-effective to ditch the app stores?  14:40 - The Digital Markets Act 16:46 - Giving developers more control over what they create 21:23 - How does a web shop increase your revenue? 26:15 - A headless checkout 28:20 - Accelerate XR and Xsolla Mall 33:34 - Favourite games Q&A with Chris * * * * * * * * * * * * * * *  ** Let's Connect **

Finding that secret sauce can lead to success, but it's not always easy to find. In this episode of the Class E Podcast, we talked with Chris Sexton, founder of the barbecue catering company, Sexton's Smoke-N-Grill. From learning countless lessons in the Greenville Starts program to dealing with personal health concerns, Sexton discusses the future of his company, how he has become more appreciative of his skills, and the importance of keeping priorities straight as an entrepreneur. Guest: Chris Sexton Facebook: https://www.facebook.com/sextonsmokingrill Host: Mary Sturgill Producer: Isabella Martinez '24   TRANSCRIPT:  MARY: Hi there, everyone. Welcome to this episode of the Class E Podcast. You know, this is the podcast that is brought to you through a partnership between the Hill Institute for Innovation and Entrepreneurship and the Communication Studies Department here at Furman University.  Today's episode is part of the everyday entrepreneur series in which we talk to entrepreneurs who have graduated from our GVL Starts program. And the reason that we're doing that is we want you to hear their stories and be inspired by them wherever they are in the process of their venture. So today we have a very special guest, Chris Sexton, who is the owner of Sexton Smoke-N-Grill, and a new venture that he's calling Mr. Sauce It Up. Chris, welcome to the show.  CHRIS: Thank you for having me. Thank you for having me.  MARY: Chris, I'm so happy that you were able to join us today because one - I'm gonna look right into the camera for the YouTube people - Chris' food is amazing. Now when I was in, you know, I was a broadcaster for 20 years, and when I was in Texas, the broadcasters and you know different people in the community, they call us celebrities or whatever, but we had to judge barbecue competitions. So I've judged many a barbecue competition in my life. And Chris' is by far the best of any that I have done and it all boils down to the sauce, which I imagine is where the Mr. Sauce It Up came from.  CHRIS: That is exactly where Mr. Sauce came from. I've created a new sauce using fruit, alcohol, and just a wide imagination to come up with different sauces. We've got about 10 to 15 sauces that we do.  MARY: Yeah.  CHRIS: All incorporating fruits and alcohol like I said. Like you can take Hennessy bourbon… MARY: Don't give your whole secret away.  CHRIS: No, everything's not coming, but we've got great stuff coming.  MARY: We don't want people to copy it. And you will want to once you taste this, you'll want to try to redo this at home. Tell us about how you got started with this. Because you're in finance.  CHRIS: I'm in finance. So to be honest with you, from working in finance, I've always had a passion for cooking. I started cooking when I was like 14 years old working at a little restaurant in Greer with legendary Peggy Davis. She owns Peggy's Diner in Greer. Started working with her, handing out trays… and I kind of fell in love with that whole environment of cooking, creating. Did that all the way through high school… worked at McDonald's. But the sauce and the cooking came from truly talking on the phone with a guy from Mississippi on the phone about a car deal.  MARY: Oh, wow. CHRIS:  And he asked me what I was doing for Thanksgiving. I told him I was going to try fried turkey. He said you need to smoke it.  MARY: Yeah.  CHRIS: And that day, I smoked a duck, a turkey and a…a duck, a turkey, and a Boston butt.  MARY: Wow.  CHRIS: And they all came out great.  MARY: Yeah. On your first time. CHRIS: On my first time, it came out great. Not perfect, but great. MARY: Right.   CHRIS: But it was addictive. It was like it was something that…it's what I needed at that point in time to slow me down and give me some perspective. MARY: Yeah.  CHRIS: And from there it's just kind of bloomed and grown from there.  MARY: Yeah. What inspired you? Was it just the conversation with him or have you always… I mean, you've kind of always been a little a foodie. CHRIS: A foodie.  MARY: I mean, I consider you a foodie.  CHRIS: So what really inspired me is the process.  MARY: Yeah. CHRIS: I fell in love with it. And I'm a person that loves serving people. So getting to feed people, seeing smiles on their face, people honestly patting your back saying this is the best barbecue I've ever had.  MARY: And there are some smiles when they eat your stuff.  CHRIS: And it's encouraging. So the sauce idea actually came… I made a dish, not gonna say what dish it is, and my mom tried it and when she got done, she says “man, this would be good on some chicken wings.” MARY: Yeah.  CHRIS: And so me being who I am, it took me like three years… I sat there and thought about it and one day while I was at work, all my great ideas come on the clock… So I was sitting there one day and I'm like bingo. I figured out how to do it, I tried it, and I kind of took it off from there.  MARY: Yeah.  CHRIS: And that's… the biggest thing about my barbecue is it's different. MARY: Yeah. It totally is.  CHRIS: And I refuse to do what everybody else does. And my goal with my business is to create a new space in a traditional market.  MARY: Yeah.  CHRIS: When you go to restaurants and you go places… that's the other thing that inspired me…I'm tired of eating vinegar based, tomato based, mustard based barbecue sauces. You know, I want something different and so that's what we've done. MARY: So you have…how many sauces did you say now?   CHRIS: Got around 10 or 15 sauces. MARY: Yeah.  CHRIS: The newest…the newest sauce that I'm working on would be a Carolina white sauce. Carolina is known for that fruit flavor for peaches and things of that nature.  MARY: Right.  CHRIS: So imagine taking your traditional yum yum sauce mixed in with a little bit of fruit.  MARY: Oh yeah.  CHRIS: And we're working on that and actually combining the smoked brisket and pulled pork with fried rice with that yum yum sauce.  MARY: Oh my gosh. My mouth is watering.   CHRIS: So, yeah. Look for us on Tik Tok soon. MARY: Yeah, there you go. When we were in the… we were in Greenville Starts cohort together, and the first time I tasted Chris's sauce, I was like, “Chris, you need to call this the best damn sauce ever.”  CHRIS: That is actually the slogan. “The best damn sauce you've ever had.”  MARY: Yeah. Yeah. I love it. CHRIS: I tell people… I'm trying to be humble, but when you have something that's different, you have to let people know.  MARY: Exactly.  CHRIS: And this is when you taste it, it just… it kind of shocks you because you're not… you're thinking barbecue sauce.  MARY: Totally.  CHRIS: But it kind of just catches you… you're like what is this?  MARY: Yeah.  CHRIS: And it just kind of sucks you in.  MARY:  Well, and I think you just said it correct. You're taking a space that is so kind of entrenched in kind of the flavors that are there. And you're creating something new with the idea of barbecue. And I love that. Can you talk us through the process of creating this business because I guess you started with the smoking first and then the sauces and then where are you… how, you know…do you have a website? Do you have a restaurant? How are you coming together?   CHRIS: What we're doing now is… So this is how I initially started out. I was at my desk at Ford one day having a conversation with someone that asked me about catering.  MARY:Yeah.  CHRIS: So I hopped online, in between calls, looking at what I had to do to get started so I went online, I got my EIN…and kind of got in touch with state and got everything going. MARY: Yeah. CHRIS: That was in 2016. So for the last three years off and on, I've done a lot of catering. A lot of on site. My biggest thing is on site grilling. MARY: Yeah. CHRIS: I put on quite a show when I grill.  MARY: I mean you can tell with his personality. You're the entertainment and the food.  CHRIS: So yeah, if you're looking for an entertainer and a grill master, I'm your guy. So we… that's my big thing is I travel, I take my grill, I like to set up shop.  MARY: Yeah.  CHRIS: And I also work with… I've been working… I had been working before I took my current job with the church during the Wednesday night Bible studies. I'm big on… like I said my dad is a Baptist preacher.  MARY: Right. CHRIS: So we grew up in the country and all I know is fellowship and eating. I've probably eaten in every county in the state.  MARY: Yeah. CHRIS: Every, every type of food you can have, but those experiences is what inspired me. But long story short, the business idea and the model came from just three years of having to stop and go because working back and forth, and now learning how to balance time, family, and everything. The Mr. Sauce It Up will give me the opportunity to kind of work and service people and enjoy it and also make my first big shine through Mr. Sauce It Up.  MARY: Yeah. So I want to talk a little bit about… because entrepreneurial, you know, ventures are, it's a journey, right? And I know we all have setbacks, and I know that you've had some setbacks, including a health setback for a while that kind of made everything go on pause. So how are you doing now? And let's talk about the setbacks and how you overcame them.  CHRIS: Oh, wow. So it's crazy the night that we had our finale. Our, you know, our big pitch.  MARY: Yeah.  CHRIS: I found out I had a nodule on my thyroid that they had to go in and remove. They thought it was small, but it ended up being like the size of a baseball. MARY: Wow. CHRIS: So it sat on my chest and it kind of impacted me. Dealing with things like that… it impacts…your thyroid is your gas and keeps you going. MARY: Yeah, yeah.  CHRIS: So for like the last three years, I've ran on nothing but adrenaline and you didn't know it. So it's taken me a little… little bit of time to adjust to being normal and not having that excess energy and just you know being actually knowing what it feels like to be tired and having to take a nap. MARY: Right. CHRIS: So for the last six, you know, part of that I ran on you know pretty much adrenaline because the thyroid and I were back balanced. Kind of and it… but it gave me an opportunity to really sit back and refocus and re-  kind of gave me a bigger hunger for what I want to do. I've looked at food trucks, and things like that, but a crazy and a funny fact about me is I've had 22 wrecks in my lifetime.  MARY: 22 wrecks? CHRIS: 22 automobile accidents.  MARY: Oh my goodness, Chris. CHRIS: So me driving a food truck probably nobody around here wants.  MARY: They don't mix.  CHRIS: That's not a good mix so I'm in the process of trying to find a building either…. I would prefer Greenville, but the Spartanburg area is also something I'm open to… to certainly barbecue out of. But until then, I'm gonna let myself and also cakes and sweet potato pies…  MARY: Yeah. Oh my god. Sweet potato pies.  CHRIS: …kind of feed my business and my picture while I kind of work my nine to five and do your day in and day out thing.  MARY: Yeah. CHRIS: The struggle. You know, being an entrepreneur… it takes a… you got to have a little bit of crazy in you to be an entrepreneur. But the biggest thing you have to have to be an entrepreneur is being resilient.  MARY: Yes. CHRIS: You never know what obstacles are gonna come your way. I never expected and never thought I was sick MARY: Right. You had no idea.  CHRIS: I had no idea. You know, and even through it, you got to, you know, one of the mottos I live off of is fake it till you make it.  MARY: Right.  CHRIS: You got to go into every day, no matter what's going on, with a smile on your face, press through. And you kind of put it behind you and live in that moment because you never know life can be taken from you at any given moment. So you got to enjoy it no matter what's going on. And that's what's kind of helped me evolve and get to the point that I'm at now. And for me, I've learned you know, when things are going… when things are going at their best is when things…your biggest hurdles are going to come. MARY: Yeah.  CHRIS: For me, I spent all last year partnering with people and creating a lot of partnerships I kind of had to give up. So to kind of reinvent myself and roll back out and rebrand as Mr. Sauce It Up, it's going to be really exciting and I think it's the right way and path to go. The biggest thing I can tell other entrepreneurs is don't be stubborn.  MARY: Yeah.  CHRIS: For a whole course, through Greenville Starts, everybody told me, “it's the sauce, it's the sauce, it's the sauce.”  MARY: Yeah. CHRIS: And I love cooking. I love grilling.  MARY: Yeah.  CHRIS: And a couple of weeks ago… I'd say a couple of months ago, it finally dawned on me “Hey, you've got a product that nobody else can do.” MARY: Right. CHRIS: This is your…this is your headline and this is your angle. I'll still grill and barbecue and do barbecue and whatnot. But…I have a gift that I gotta give the world.   MARY: Right. That's your foot in the door -  think the barbecue, but the sauce is so scalable. I mean it gives me goosebumps just thinking about where you could go and seeing this on grocery store shelves. I mean it really does. CHRIS: That's my ultimate goal. My ultimate goal is to… MARY: I mean I literally just got goosebumps.  CHRIS: We've got here in Greenville…we've got we've got the Duke's manufacturing. I want to have something similar to that here just pumping out sauce so hopefully when you're getting you know your Chick fil A… go to McDonald's get a sauce packet, and you'll see my pretty face on it. MARY: I love it. I love it. And you said some really good things about there in that comment about being resilient and not being stubborn. And I think being willing to go with the flow because I know you were in talks about a space right when you got sick. And so every… I mean literally everything went on hold.  CHRIS: So with the space…this is another thing that when in the restaurant business, it's a risky business… MARY: It is.  CHRIS: For me, the biggest thing is finding people that want to invest and that will roll the dice on a restaurant. MARY: And that's true for all restaurant owners.  CHRIS: That's been the biggest challenge, but the buildings I looked at have been highly competitive.  MARY: Yeah.  CHRIS: I looked at a property in Duncan… was looking at property in Duncan and somebody came in at the last minute and outbid me by like 30 grand.  MARY: Right. Wow.  CHRIS: And being in finance and being the underwriter you… the risk… I'm very careful if that's the risk I take and I evaluate it making sure I'm making solid decisions.  MARY: And you understand that risk.  CHRIS: Yeah, because being in business for yourself, is a risk alone. MARY: Absolutely. CHRIS: You don't want your business upside down and trying to make back money that you may not be able to get back. That's not a wise move so we kind of backed off a bit. And it's been a blessing because like I said had I got into it then, gotten sick, we would have been in a worse situation. So thankfully, we got into a position where we're able to press pause and my true belief is that when my opportunity and my time is there, it's gonna happen but until then we're just gonna keep doing what we have to do.  MARY: One hundred percent. One hundred percent. So what's been the most rewarding thing about starting this venture for you? CHRIS: Networking and meeting new people.  MARY: Yeah.  CHRIS: And to be honest with you, the other thing people don't know about me is I'm kind of shy.  MARY: I don't believe that for a minute. Because the first night we were in Greenville Starts together, I mean, we clicked, obviously but…but yeah, no. But you, probably like me, I have to overcome it when I'm with people. Once I get there, I'm fine.  CHRIS: So I guess you can say my shyness comes out different. When I get nervous and get shy, it's like lights on, like camera on, game on, let's go. So you never really know it. So I embrace it. And being able to… this has taught me how to fight through that and how it really… I guess having a good time meeting new people and the biggest thing I think I'd say is just learn. Being an entrepreneur has taught me so much and it has stretched my limits. And so when I was younger, I was a hothead. MARY: I believe that.  CHRIS: Something happened… something happened and I'm, you know, fired up. MARY:  Right. CHRIS: So for instance, a couple of weeks ago, my first time back out and I go to leave and my grill catches a flat tire.  MARY: Oh, no. Yeah.  CHRIS: And the old me would have been saying Sunday School words and throwing stuff and all upset. We just pressed pause and regrouped and it has made me grow and develop patience. And understand that some things you cannot control. If you can't control it, you just move on.  MARY: I would think that this entrepreneurial process that you're on, and that health scare, that major health scare, probably both had something to do with that kind of, okay, it does no good to get upset about this stuff, just deal with it one thing at a time. CHRIS: Well there's another factor in there also. I've got a grandson now.  MARY: Oh yes, that's true. Happy Grandfather.  CHRIS: So, being a grand dad, it kind of…I would say the moment I took my daughter to the hospital.  MARY: Yeah.  CHRIS: Got the call. I had to take her to the hospital. That's when life changed.  MARY: Yeah.  CHRIS: We just kind of… I don't know it's something about having a grandchild that you can give back to them.  MARY: Right.  CHRIS: It kind of changes you. At the same time, it just shows your new appreciation for life. So all of that within the three month period, it really has slowed me down… made me appreciate life even more. But at the same time, it's made me a fighter. It's really made me a fighter and made me...  MARY: Yeah, because you want to be around for him. CHRIS: Yeah, to be honest with you, this whole get up, I've thought about for the last four years.  MARY: Yeah, this is what it's gonna look like. CHRIS: Yeah. And going through that experience gave me the courage to kind of step out of the shell and put it out there and move forward because what's the worst thing that can happen? Somebody will laugh at you? MARY: Right. Exactly.  CHRIS: You know at the end of the day, this is who I am.  MARY: And who cares? If they're laughing at you, they're looking at you?  CHRIS: They're looking at you. They're going to remember.  MARY: Right.  CHRIS: This is who I am. A little country guy from South Carolina just trying to sell some good barbecue and sauce.  MARY: Yeah, I love it. Chris, I love it. So we were, like I said we were in the Greenville cohort, Greenville starts cohort together, and for those of you may not know that's like an eight week program where the participants could expose everything from, you know, fundraising, capital to legal issues and things that of course, you're not an expert in everything, right? And so we learned so much to marketing. I mean, you name it, we touched on it in that class. What were some of the takeaways from that that you are implementing now? Almost a year later.   CHRIS: Want to hear a good story? MARY: Yeah always.  CHRIS: It kind of goes with the question you asked me previously about my experience.  MARY: Yeah.  CHRIS: Do you remember the night that we wrote the breakup letter?  MARY: Yes. We had to write a breakup letter to our business. And you know, you're the second person to bring this up in these conversations, but his breakup letter was amazing. But go ahead.  CHRIS: I lived my breakup letter this year. And that night, the night that we had read that letter out loud and share that experience…  MARY: Yeah.   CHRIS: I lived it this year. And going through it and living it and seeing your dreams kind of, let's just say be taken away.  MARY: Yeah, yeah.  CHRIS: It makes you appreciate your gifts and it makes you appreciate what you did. So, without Greenville Starts, I probably wouldn't have pushed through this year. I probably would have gave up and just gone back to working the nine to five and just you know enjoy life but my experience with Greenville Starts and having to, you know, go through a made breakup with something that you love and then having to go through it actually, it kind of gave you…I can go back and I can remember some of the speeches that the speakers gave. I will say it gave me motivation and courage and more than anything else it taught me that I'm not a know it all. I've worked in the banking industry for years as a banker and on the other side of the fence, telling people no to loans and being actually on the opposite end of it - trying to be approved, trying to get all your documents together gives you a whole new appreciation for what people on the other side go through. We've been on both sides. I have an appreciation for both now. But I will say that Greenville Starts… it gave me the courage to bounce back and gave me that fight and it prepared me for the hurdles that were ahead. So if anybody in Greenville County has a business idea and they feel like they can make it, but their confidence is an issue, I would definitely recommend Greenville Starts. We have the all-American, the GOAT, the great, the best hair, Brian Davis. He just…has a way of inspiring…inspiring you. Like just…any of our cohorts, I think about you guys and where you're at and I see your successes and it motivates you. You see other people being successful and that pushes you on.  MARY: One hundred percent. Which is the whole reason we do this podcast is to share your all's stories with the public so that we can encourage other people to go ahead and follow their dreams and create their ventures, you know, and I mean, you talk about Greenville Starts being an inspiration, you're an inspiration to, I know our entire cohort.  CHRIS: I appreciate it. I appreciate it. I think, you know, God puts you in a certain place at a certain time. And I think I feel like that was a perfect time because like going into it, I'll be honest with you toward the end of class I kind of felt like something was off. It drained me. It drained me. It put me… I don't like talking about this aspect of it, but it impacted my mental health.  MARY: Yeah. CHRIS: It gave me some anxiety and put me in a depressive state and it you know, that's not me. MARY: Right. CHRIS: One hundred miles per hour, 100 days a week.  MARY: Yeah.  CHRIS: So at the end of the class, it was like okay, what we got going on? And you guys really pushed us through. It's like a family. It's not just like a class. It's not just like a group of people. It feels like family and a cheerleader group.  MARY: Yeah. CHRIS: I've coached football, played football. I love sports and I love that team aspect. And that's what it felt like. Each week it wasn't a competition against each other. It was a way that we can push each other…push each other to make each other better. It's been a year and a half now. And when you can go back and recall specific conversations and specifics in a needed time, that's when you know it had an impact on you. That's what Greenville Starts said to me.  MARY: Yeah. CHRIS: It put a lot of information in this encyclopedia up here.  MARY: Yeah. I love that. I love that. What advice do you have to other entrepreneurs that you… either from Greenville Starts or just your personal experience?  CHRIS: I'm going to steal one from Ted Lasso.  MARY: Okay.  CHRIS: The great Ted Lasso. You got to believe. And what he also says…that's number one is believe.You got to believe in yourself. You got to believe in the process and you got to trust, you know, that the good Lord put you in a position he gave you whatever gifts that you have for a reason. And you have to follow the plan in your process. When things get hard, you got to go harder.  MARY: Yeah.  CHRIS: And when things get easy, you got to kind of scratch your head and say, why is that so easy and know that something's coming. MARY: Right. Be prepared.  CHRIS: Be prepared because something's around the corner. The other thing is, I'm a Florida State fan. And the reason I'm a Florida State fan is because of…He talked about a lot about what you do when people aren't watching.  MARY: Yes.  CHRIS: And as an entrepreneur… it's what you're doing behind the scenes and when people aren't watching is what's going to make you successful. You know, the… you know, I cook a brisket 26 hours for it to be gone in 30 minutes.  MARY: Right.  CHRIS: So it's what I do behind the scenes and the effort and what people don't see is what makes you a great entrepreneur and a great… and great at what you do. And the last is something I learned from a guy named Tom Leopard back in 2012. Your priorities. As an entrepreneur, you have to have your priorities in order. It's got to be your faith, your family, and your fortune. If those three get out of whack at any point in time, it's time to step back, reevaluate, and bring them back in line and then things will start flowing so greatly. So always remember your faith, your family, and then you're fortune and as long as those three are aligned, you can always be successful and bounce back.  MARY: I love that. The three F's.  CHRIS: The three F's.  MARY: I love it. So you brought some… before we let you go, you brought some goodies for us. So, boy, I wish people…I wish we had smellivision because that cake smells so good. Oh my gosh. So Chris, what do we have here? This is one of the cakes that you do.  CHRIS: This is my spin on a…You lived in Kentucky?  MARY: I did not live in Kentucky.  CHRIS: I don't know why I thought you lived in Kentucky. So, this is my take on a Kentucky butter cake.  MARY: Okay.  CHRIS: So I call it a Carolina butter cake.  MARY: Yeah.  CHRIS: It's a pound cake with some secret flavors.  MARY: Okay.  CHRIS: As all things as Mr. Sauce It Up does, we also do cake glazes.  MARY: Yeah.  CHRIS: So this has a pineapple. No, I'm sorry…a peach mango rum glaze to it.  MARY: Yeah. Oh my goodness. This is going to be so good.  CHRIS: Mixed in butter. Something I came up with. I am the king of taking a recipe and turning it into my own. MARY: Right.  CHRIS: So, that's what I do the best. I don't… You know, if I go out to eat I'm probably going to take two… two combos, two meals and turn it into one.  MARY: And put them together.  CHRIS: So this is kind of what I've done with this and created my own flavor, but I feel pretty confident, I'm willing to bet you a $1 to your paycheck that you've never had a flavor like this.  MARY: All right, let's see it.  CHRIS: Let's see. Let me pull out my Dexter knife.  MARY: He's going to pull out his Dexter knife. Oh yeah, that's a Dexter knife. All right. All right. All right, let's cut into this sucker. So remind me again what the glaze is?  CHRIS: This is a peach mango with a hint of rum.  MARY: Okay.  CHRIS: And some other stuff that I can't really share with you at the time. I'll share with you at the time.  MARY: Right let's go. Cheers.  CHRIS: Cheers.  MARY: Oh my gosh.  CHRIS: Mmm. Mama where you at? Come on over here, get smacked.  MARY: That is so good. Did you say mama come on over here, get smacked?  CHRIS: Come on over. Come on over.  MARY: Oh yeah. So, we're going to have to change that phrase, well or add to it…the best damn sauce…the best damn glaze…because this is good stuff.  CHRIS: Thank you so much. Thank you so much.  MARY: Oh my goodness. Alright. So again, we'll have the links to how you get in touch with Chris wherever we're posting this podcast, both on YouTube and all of our podcast channels. Just look under the copy, the body copy. And you'll see that there because you… if you are having an event, you want to hire Chris to cater that event. Again, it's the entertainment and food. You can't beat that. CHRIS: Let me tell you.  MARY: Yeah.  CHRIS: I didn't mean to interrupt, but this cake is good.  MARY: It does taste good.  CHRIS: It tastes good. I'm a pound cake foodie and I think I've found something here.  MARY: I think you have too.  CHRIS: Not to brag, but yeah.  MARY: I think…I can't put it down. I got to finish eating so I can say the rest of the show so I can close the show out. Oh my gosh. So good. Alright. How do people get in touch with you if they want to get some sauce or they want you to cater an event?  CHRIS: Cater an event. You can find me on Facebook - Chris Sexton or Sexton's Smoke-N- Grill. Also on Instagram, it's Chris Sexton or Sexton's Smoke-N-Grill. Email me at sextonssmokengrill@gmail.com. www.sextonssmokengrill.com. And that's just Sexton's, Smoke, the letter “n”, grill.com. Or you can call me 864-680-4629. We got the sauces.  MARY: Alright, Chris, thank you so much.  CHRIS: Thank you. Anytime. Anytime.  MARY: So remember, if someone you know is an entrepreneur or has an idea, Greenville Starts is a great place for them to get started or if they're somewhere in the process along the way and they just need that little extra “umph” to learn things that they don't necessarily know, then that's a great place. So, in order to get into the next cohort, all you have to do is Google Greenville Starts and Furman and it should be the very first link that pops up and get yourself on that list.  The other thing I wanted to remind everybody of is that we have the Paladin Pitch competition, which if you are a Furman student, you can win $10,000 for your venture. That's coming up in April, but you have to participate in some pitch competitions before that. So, contact the Hill Institute, get your pitch to them and start working and then from all those pitches throughout the year, they'll choose the finalists to pitch in April. So be thinking about that, be brainstorming. If you want to do something, now is the time to do it. So, that does it for this episode of the Class E Podcast. I'm your host Mary Sturgilll. Remember this podcast is brought to you through a partnership between the Hill Institute for Innovation and Entrepreneurship and the Communication Studies Department here at Furman University. It is produced by student producers, Kayla Patterson and Eliza Polich, a true example of the Furman Advantage. And remember, you can get this podcast two ways now - you can listen to it wherever you listen to your podcast, we also have a YouTube channel where you can watch it and you can see this beautiful cake that we just ate and see us eating it. And we also.. follow us on Tik Tok if you're on Tik Tok because we just started a brand new Tik Tok channel and you'll see a lot of the outtakes and a lot of cool stuff on behind the scenes stuff on that Tik Tok channel. Until next time everybody, dream big.    

Today's Building Texas Business Podcast episode finds us chatting with Robert Grosz, President and COO of the tech company WorldVue. Robert shares insights into how WorldVue has sustained success for decades through strong customer relationships and a responsibility-centered culture. He details their customer-centric approach and innovation fostering, revealing lessons learned navigating the pandemic with a dedication to service and constructive dialogue. Robert also opens up about transitions into leadership, emphasizing quick decisions, balancing loyalty with progress, and his thoughtful vision for a blended family-exploration sabbatical. From navigating disagreements to keeping pace with industry shifts, Robert offers a compelling view of resilient leadership. SHOW HIGHLIGHTS Robert Grosz, the President and COO of WorldVue, discusses how the company drives growth through strong customer relationships and a company culture rooted in responsibility. He highlights the importance of fostering innovation, creativity, and relevance in the ever-changing tech landscape to stay competitive. We discuss WorldVue's response to the pandemic, emphasizing the importance of their company culture, which includes responsibility, dedication to customer service, and the importance of constructive dialogue. He talks about his transition into a leadership role at WorldVue, emphasizing the importance of quick decision-making and his philosophy on loyalty. Robert shares his proposition for a 30-day sabbatical, and his appreciation for the dynamic beauty of Texas. The episode touches on building relationships and driving growth,We discuss how WorldVue has been successful for 50 years by solving problems, befriending customers, and adding value to their lives. Building a strong company culture is discussed, with Robert explaining how WorldVue managed to successfully navigate the pandemic thanks to its dedication to customer service and focus on responsibility. Building trust and success in leadership is also covered, with Robert emphasizing the importance of making decisions fast and how loyalty can be an adversary to that philosophy. Robert shares his vision for a 30-day sabbatical, which includes spending the first two weeks at home with family and the last two weeks exploring the dynamic beauty of Texas. Finally, We discuss Roberts approach to navigating leadership disagreements, sharing a key lesson learned from past experiences that resulted in lost opportunities. LINKSShow Notes Previous Episodes About BoyarMiller GUESTS Robert GroszAbout Robert TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode you'll meet Robert Grosz, president and Chief Operating Officer of WorldVue. Robert shares how WorldVue focuses on building a culture of responsibility by being a service-oriented company to its customers in order to drive growth. Robert:, I want to thank you for agreeing to come on Building Texas Business. It's a pleasure to meet you. Robert: Chris, it's great to meet you as well. Chris: Let's get started by just telling the audience about WorldVue and what it's known for. Robert: Chris, have you ever had a friend that is really good at something, whether it's fixing cars or technology, programming your TV, things like that? Chris: It's a friend that you can count on. Robert: It's their best friend. Sure, they go above and beyond. If you've got a problem, you know you can come to them. They respond quickly and they give it their all. Even if they don't know about the solution, they give it their all and they help you and they add value to your life and you build that friendship. That's what we strive for at WorldVue. WorldVue is a company that's been in business for almost 50 years now, houston-based. Our customers are hotels and our expertise is technology. So if a hotel brand, a hotel owner, an individual hotel has a problem with technology, we want them to come to us because we want to be their best friend forever and add value to their lives. So what we're known for is solving problems for hotels, befriending them, building relationships with them and just being part of that industry, being part of the hospitality business. Chris:And that's what's made us successful for 50 years. That's great. I love how it's so ingrained that it's about relationships and even using the analogy of best friend, what inspired you to get involved with WorldVue? What inspired this company to get to where it is today? Robert: Yeah, so they've been along a lot longer than I've been with them. Chris: Sure, I don't look that. You started a company. I started when I was one. Robert:No, no, that's started long before. It's a family business. It's still a family business. The founder still comes to work. He's usually the first one there and the last one to leave. I'm very, very engaged but of course the business has changed a lot over the years. I've known the company for the last 17 years. I actually was with Dish Network. Dish Network is where WorldVue gets their programming, their content, the TV content and some of their technology and I got to know them as a supplier, vendor, got to know the people. I fell in love with the people, fell in love with the company, the culture. The time came where they were kind of pivoting and it's kind of the next generation of WorldVue and we're building this company as a legacy business to last for the next 10 generations and they needed someone with my skillset, my expertise, to help lead them into that. And that's kind of how I got to know WorldVue and got to be involved with WorldVue. Now I'm the president and chief operating officer of the company and I've got a great team around us and teamwork I'm sure we're going to talk about teamwork and people are very, very important and kind of fulfilling our mission. So yeah, that's the origin story of how I got involved with WorldVue. Chris: Okay, that's great. So technology company means evolution and innovation have to be in the fabric of the company. So talk to us a little bit about what you do in your role to foster creativity, innovation, to keep WorldVue relevant in its industry. Robert: Yeah, sure, and relevance. I'm glad you said that word. Relevance is our key growth driver. So you know we've got two growth drivers One's relevance, which is all about product, it's all about the technology that we're out there evangelizing, designing and supporting and really becoming experts at, and with that relevance drives market share growth and getting into more and more and more hotel properties. We currently serve 7000 properties in the US, and now we're expanding internationally. But we're a product driven company because that's our expertise. You know, we want to be the best friend to our clients. That's kind of why we exist. But the what we do is the technology, and we will use technology from leading providers that are off the shelf, you know some big brands that everyone's heard of before, like LG and Cisco. You know brands like that, but what we'll do is we'll take those and we'll integrate them. So integration is kind of what we do best and it's kind of our secret sauce is how do you integrate big, big brands like an Oracle with a LG which does interim entertainment and TV technology? That's our secret sauce. Chris: So the integration. Robert: We're the glue between big technologies and we do it very well. And again, if you lean back on the why you actually want to develop this relationship to add value to your customers and we want your customer to be your best friend. That's kind of what we're doing. So it is related to the technology. We like to say we're a service company that just happens to do technology. We're not a technology company that tries to do service. That's one of our big differentiators. Chris: I would imagine that's a meaningful difference in mindset when you go to the hiring process and building your team to have that servant service oriented mindset be the lead, primary thing you're looking for. What are some of the things you're you do to make sure you're hiring the right people that fit that mindset? Robert: Yeah, yeah, yeah surrounding yourself with people better than you is one of our mantras at any level of the company, and I think if you, just if you, champion that mantra, you know constantly looking for people that do things a little bit better than you, whether it's a specific skill or an attitude, and I think attitude is something you can't really teach. Attitude is something that you carry with you as a human being in your existence, is your WorldVue, which is one of the reasons for the name world. Chris: Gotcha, that makes sense is. Robert: You've got to have that. You've got to have your head on straight as it relates to how do you interact with others, how you act with it, with a team, how you help build the team, how you pull in the same direction to achieve a goal, and those things are very important. We can hire people that are incredibly intelligent, incredibly book smart, have done amazing things and we do but but if, if you don't hire for the attitude and you don't hire for the teamwork, you're going to end up failing, and that's really what we look for there's some tools you have in place so that in that process, the people doing the interviews, whatever it is, and however you go about that, that help you identify or get a bead on the attitude that the candidate has. Yeah, so so we developed our own tools and we, of course, use off the shelf tools, personality assessments and things like that. But, we developed a tool that we called chirp. It's an acronym C, h, I, r, p coachable, humble, intelligent, responsive and persistent. So what we do is, when we're talking to someone, we try to bounce those, those, those challenges, those dynamics off of the candidate to see if they're open to actually learning and becoming a better person. Chris: And if you don't have the C, the coachable. Robert: It's going to be hard for you to be part of the team. Sure Because regardless of what you know, even the smartest person on earth, there's still something for them to learn and they have to be open minded about absorbing that and taking some direction and realizing the experience of others. So coachable humble humility is important. It's related to coachable Intelligence. Isn't book smart, it's more emotional intelligence. It's no one what to say when to say it. Being quick on your feet, having that mindset about who you actually are as a person and how you interrelate to each other, and then how you actually consult problems related to a specific tactical technology, that's intelligence. Chris: Responsive you know. Robert: When the phone rings, you answer it. When an email comes in, you respond to it, you don't let it dwindle. Right and persistence. Persistence is that hunger and that energy, right. Persistence is, you know, knowing that there's a goal, knowing that it's going to be tough to get to that goal, if it's worth pursuing and fighting for it. You know so. Together is the chirp. If you look at our logo, there's a wonderful sparrow icon, which is the chirp, which is a bird, so it all ties together. Chris: Okay. So how do you then take this service oriented mindset you hired using chirp, which I love the acronym. How do you then take that into action and actually go about building these relationships to where your customers become your best friends? How do you connect those dots? Robert: Yeah, so I mean it's about engagement with the customer on their turf right. The world revolves around the customer, doesn't revolve around us as individuals or as a company. So you go to where they are. You go to where the relevance factor is high to them, whether it's a trade show event or it's their office, whether it's charities that they might sponsor and support that are worthwhile getting involved with you. Try to make it about a personal relationship, and that's where our best customers and our best employees thrive is when you can truly make it about the individual. That's very, very important to us. We get on their turf and we try to understand who they are as a person. We're not just checking a box. If we check a box, we become a commodity. When we become a commodity, then the margins are rode, financial performance isn't there and we don't exist Right. So we've got to make it about that personalization. We've got to make it about the customer. Chris: Very good. So let's talk a little bit about how the company has maybe managed over these last few years. I would think, given what we experienced in 2020 and coming in a few years out of that there was, your customers, at least, had probably suffered some downturns in their business, which probably translated to you. What are some of the things you did to help manage the company through those tough times? Robert: Sure, yeah Well, the hospitality industry in general and a lot of industries, but especially the hospitality industry. When people stopped traveling for business, they stopped traveling for personal. They didn't go on vacation. We had a lot of our hotels closed down. Some of our hotels stayed open for first response medical personnel, things like that and they did okay. Some very limited service hotels that don't really exist for that business traveler but they exist just because they need a bed to rent Actually did okay. They thrived, they had good occupancy. We as a company were fortunate. We managed, not by laying people off and cutting back, but we managed by committing and recommitting to our employees. So we had no layoffs because of COVID. We took a kind of unique philosophy to the pandemic and that period of time two, three year period of time where we got back in the office as soon as we could and we did that in a safe way. So there was social distancing and making sure that everything was clean and being aware to the health of all of our employees and respecting individual wishes, but we encourage people to get back in the office in October of 2020. And we've been back since, and we do that because we think that people communicate best in person. It's probably one of the reasons you have us all here to have a podcast, as opposed to doing it virtually. Absolutely Is that personal connection. You can't put your finger on it, but it's important. So I think that that action was a cultural move and I think it's had it's paid dividends for us. I hope it's paid dividends for our employees and I think we'll continue with that mindset. We were there to help our customers, so we were making sure, from a commercial perspective, that we could give them as much relief as possible. We were there to help them turn up their properties, turn down their properties using all kinds of technologies. So there's a lot of different technology out there that a hotel uses. And we were there for them, in all fronts. Chris: That's great. I can totally identify with that thought process, that mindset. We took the same approach in 2020, got people back in in May of 2020, doing the same thing making sure the workplace was safe, but with the view that we work better together. It does foster a healthy culture. I think it makes us better in who we are and in our work and how we can serve our clients and customers. And, to your point, I'm pretty adamant that these podcasts although we've done a few via Zoom because we had to 90, I mean there's I don't need all fingers on one hand, they've almost all been in person, because you just can't replace the dynamic when you're together. So you touched on it. I want to go down this trail with you. And that's culture. How would you make, describe the culture at WorldVue and what are some of the things that you have done to build and foster that culture? Robert: Sure, so we have a culture of responsibility. We're responsible to each other as much as we're responsible to our customers and we have a promise that we make, which is we deliver every time, no exception. And that is as relevant for the guy in the office next to you as it is to your customer, which could be a couple thousand miles away. Right, you know, we deliver every time, no exception. So if someone needs something, we strive to deliver that right. We strive to deliver on the promise. Sometimes it's not easy, oftentimes it's not easy, but it takes a lot of energy and a lot of focus, and I think everyone knows that. But that promise in the company from, you know, from the, the, the, the newest call center rep, all the way to the top they all try to kind of pull that direction. That creates that culture of rowing in the same direction. And that is very, very important. Because if you've got a company that's rowing in multiple directions, it's going to be, it's going to be problematic, it's going to be expensive, the trust is going to be violated, you're not going to be able to move quickly and address customer needs, you're not going to look at the dynamic of what customers can offer in the marketplace and turn quickly to address that it's. It's really core to to who we are as a company, as as individuals. Chris: So what do you do as the president, chief operating officer, low leader, to show up so that people understand that you live the culture, you can enforce that culture. What are some of the things you do to reinforce that every day? Robert: Yeah, so you've got to lead from the front. It's all about attitude. You can't come in all slouched over. You've got to be on point and you've got to do it authentically. It can't be fake, right? And that's a challenge sometimes. Chris: For sure. Robert: And you've got to have your focus. You've got to have your eye on the prize, if you will. Communication is critical, so routine, touch-based meetings. I don't like to have long meetings that consume people's time or people attend the meeting to be attending the meeting. I want there to be a purpose and a reason. I want there to be lots of dialogue. Constructive criticism. Constructive differences make everything special and you can't just kind of dominate. You've got to listen to the different opinions. Chris: Ask more questions. Robert: Ask more questions. We like to say listen 10 times more than people are talking, and you've got to lead by example. If you don't do that yourself as an individual, again something's wrong and everyone sees it and everyone knows it. Chris: So I asked most guests about setbacks or failures and we learned sometimes much more by those. Is there a situation or experience you can think about as a leader where it didn't go as you hoped or it was a failure or setback in a decision or strategy, but you learned from it and the learning from that has made you better today than you were before. Yeah, absolutely. Robert: I mean I've got lots of setbacks and failures, but I think one big example would be if there is a disagreement between leaders and they're not seeing eye to eye and they don't address it quickly, it can create division and that division creates distraction and the distraction creates lost opportunities. And we've dealt with that over the last few years. We've had some disagreements on the direction we needed to go and the solution was coming in the room together, fixing it, getting it on the same page, having the confidence and the buy-in at the most inner level as a person, as an individual, and making the team more cohesive. So you can go from cohesive to a failure very quickly if you don't pay attention to that dynamic. So that was one of big lessons learned. There are others where you bring individuals into the company based upon their experience and their pedigree and you throw them into our mix and they just don't dance our dance and they create a bunch of disruption and you've got to move fast there. It's tough letting people go. It always is tough letting people go, but oftentimes it's good for them as much as it's good for the company, because they're not comfortable in their shoes. That's tough to be a person. When you're not comfortable in your shoes, it's tough to live a life. Chris: Yeah, you touched on something there that I think everyone that I've interviewed in these podcast agree. The biggest lesson learned maybe in that difficult time when someone's not fitting is making that decision faster than you feel like you probably want to, because the person that's not fitting in your organization will be better off because it's just not a good fit and they'll find the place they fit better and your organization will be better because that person that's not fitting is going to be a distraction. It potentially could erode culture and you're just always better off moving faster, even though it'd feel right in your gut sometimes. That's right. You're affecting human lives. Robert: Yeah, and loyalty, by the way is the adversary to that philosophy. Chris: Right, so we all want to be loyal to people. Robert: I think good people are loyal, but you have to have the vision, the foresight, the clarity to understand where there's loyalty and then there's a bad fit, a poor fit. And if there's a poor fit then the best move is always make it a better fit. So that's very important. Chris: As WorldVue has grown, what have you done to build a team around you and let go of some of the things that maybe you used to do more on a day-to-day basis and learn to make us trust and let go yeah, trust is a key word. Robert: So finding people better than you at things, making sure that they're the right fit and then trusting that they're going to get the job done, and sitting back and delegating some responsibilities that you may have you may think that you need to do to them or to their teams, and then watching it grow. And it's very easy to delegate to somebody, but it's difficult to give them enough rope where they're going to actually lead or fail. If they fail, then you can step back in and you can fix it and you can delegate to someone else. You could coach them, but if you've got good people around you I mean if you've got good people that are pulling in the same direction they will self-adjust, they will succeed because they want to reach the same goal that you want to reach. So in some ways it can be very, very simple and easy. Oftentimes it doesn't feel that way when you're doing it, so that's an interesting dynamic. Chris: It really is. The other thing I was going to ask you about, excuse me, is you kind of had an interesting experience in that. I guess I'm talking about transition, succession from founder of company that's still around, as you mentioned in the beginning, but you stepping in to the leadership role as president, chief operating officer maybe talk to us, because there's some listeners out there maybe doing that or or that's in their near future. Let's talk a little bit about what were some of the challenges of bridging that transition gap as you took over as the president of the company. Robert: Yeah, I think, from my personal story, it's about building trust and having integrity as well as having a deep level of respect. If someone founds a company that's been around for almost 50 years, I look up to them. I don't care what that company is. I mean, they've done something that a lot of people have never experienced or will never experience, and I've got to give them tons of credit for that and have utmost respect for that effort. But making that person or that group of people trust you and inspiring them to let you lead is a significant, significant initiative that you've got to have a lot of purpose, a lot of focus on, and that's kind of the most important part, I think, is to to build a relationship. Build that relationship, build the trust, be authentic, have integrity. They will then see that you can lead and take what they've done to the next level and hopefully that will benefit their family and families for generations to come, because that's the ultimate outcome. It's not building to flip it, it's not make a fast buck. In fact, the bucks have nothing to do with it. It's about the purpose. It's about what you deliver value to society, to your customers. It's about what you want to do. That's why that analogy to a friend a best friend is really good at something. I think that's a very good focus for us to have, and I think that if you can generate thousands and thousands of friends throughout the world that all have that need, you've got a successful business that's providing college educations, food on the table, happiness, travel, fun for families, countless families. That's really exciting. That's kind of the passion. Chris: Did you have any challenges as that transition, where the people that used to report directly to the founder maybe weren't coming to you at first, and how did you manage that? Robert: I would be lying to say that that doesn't still exist. It does. It's just a challenge that you have to acknowledge and you have to kind of embrace. I get it. Like I said, the respect level that I have for the founder, the founding family, is so high that I would expect that legacy employees that have been around for a long time. Look at that with the same level of respect. Chris: So you don't take offense to it, oh you can't take offense to it. Robert: It's an eagle driven thing. Chris: Yeah, well, it sounds like that attitude that you bring to it is consistent with the culture, that you're the mindset of the right attitude and that the company's got everyone going in the same direction. Yeah, that's right. So it's not easy running a company the scale and size that you do. What are some of the things that you've done personally to try to have a very successful business life, but also very successful and fulfilling personal life? Robert: Sure, yeah, I mean, I've got four children, twin three-year-olds, a seven-year-old and a 22-year-old and a wonderful wife at home and you know you can't lose focus on what they need and what they want. You can't lose focus on being at home. Right, home is where the heart is. Home provides all kinds of emotional support and you know that's kind of been my exercise routine is making sure that I can maintain a healthy home, which you know. There's this concept of balance that I haven't figured out yet Sure like everyone has their own definition right. Yeah, but because of technology you can be in one location and have a FaceTime call with someone else and you at least can, you know, make sure you're there from a voice and a conversation standpoint. But it's not easy. For sure, but it is definitely worth living for, it's worth striving towards, and you know I value the family component of my life tremendously and I'm hoping that that lends itself to the mission of where we are, the direction we're headed as a company. Out that comes off, and you know I try to treat the folks around me that are closest to me in the office like family as well, and I get a lot of practice. Chris: That's good, that's great, great attitude about it. So what do you see on the horizon? What's next for WorldVue? Where do you see the near future taking you? Robert: Well, our friends are getting larger and larger. We're getting more of them. We are expanding internationally. So we just formed entities in the UK and the EU and Dubai, as well as, I believe, in Singapore and Mexico City. So, we've got a strategy to expand what we do globally, which is going to be very, very exciting. It's going to be very, very difficult. The challenge is exciting, though, and the great people around me and our teams are all excited and enthusiastic about that. But, from just growing business and sticking to our knitting in terms of domestic growth. We've got great relationships with hotel brands. There are multiple. The environment of hospitality is multidimensional and very fascinating to me at least. Where you've got a brand presence, you've got real estate owners, you've got operators and then you've got, of course, guests and the occupants of the property and you've got to serve all four of those groups in a special way and make sure that you're coming through for them. And so we've done a pretty good job at all of those levels. We're excited about some of our brand relationships that are growing and we're becoming more of their best friend. They have other friends. Sure You're their best friend. So the growth plan with product competencies as one lever and market share expansion as the other lever, is what's going to take us forward, and we'd like to be five times larger than what we are in the next five years. Chris: Oh, it's aggressive, it's aggressive. I was going to ask you what's driving that growth? Robert: It's demand. The demand that there's so much technology out there. Technology has become this kind of ambiguous word, right. Sure when it could be hard technology, like a wireless access point or a TV or an ethernet switch or a door lock, or it could be a software right. The software is kind of the glue that makes that hardware valuable, and the software on each of those individual devices is unique. And the key is how do you integrate those softwares together to create an amazing experience, whether it's for a guest, for a hotel associate, the housekeeper or for the owner of the property? In terms of value creation through stronger profitability, there's opportunities to leverage technology to not only solve problems but create opportunities. We think that's where the real demand is going to come from. We just have to be there to be their best friend make it all work and when they have a problem, come to us. Chris: Be that trusted friend. Robert: Be the trusted friend, trusted advisor. Chris: So what advice would you give to someone who aspires to be a business leader or entrepreneur, based on your experience, Create a focus, like create something you really want to achieve. Robert: Start at the end, like what do you want your life to look like and what do you see doing that really is a passion for you. Leave all the other stuff out of that equation, leave the money out of that equation, leave the location out of that equation. But focus with the end in mind, in terms of how you'd like to live to, and then build backwards from there, like what does it take to get there? Create a roadmap for yourself. I know, very early on in life I saw the movie Wall Street and this is on silly, but I loved business after that. I don't know why I don't know what it was, maybe it was the acting, I don't know but I wanted to be a businessman, I wanted to be in business and then I lived my life. I got to college. I was lucky enough to run into some very influential professors. One of them happened to be a real estate guy. He was doing commercial real estate development and exposed me to a company called Equity Group Investments which is based in Chicago. I grew up in Wisconsin, based in Chicago. A guy named Sam Zell who just passed away this last year. And Sam was an iconic entrepreneur, a builder of businesses all along the real estate kind of foundational area, and I decided I wanted to work for Sam Zell. So I graduated college, moved to Chicago, no job, started originating mortgages 100% commission straight out of school and just pursued Sam's company, got involved with Equity Residential, which was his apartment rate, got in the flow of that company, developed this love of technology. I've always had a love of technology, applied technology to real estate early on in the early 90s, kind of made a name for myself, and then that took me to where I am today, which is real estate technology, the scene between the two, solving problems and then being someone's best friend. Chris: There's value there. Robert: And that's kind of how what. I would advise so, start with the end of mind. Chris: Okay, I love that Great story, so let's turn to a little lighter subjects. What was your first job? Robert: First job was? That's a great question. First job I worked in a warehouse and I was moving things around a warehouse after school and I was 14, 15 years old. Like no technology involved in that there was like a tow motor, a tow motor and a truck and a dock. But you know, and really exposed myself to an interesting lifestyle, you know, the people who work in warehouses are pretty salt of the earth and you know, boy, you sweat it in that job right, and then you know. But probably my most interesting job and the one that I was at the least or the shortest amount of time was. I joined a roofing crew in a summer in college and I was on that job for a total of four hours. Chris: And. Robert: I had blisters and bloody hands in that first morning. It was a commercial three-story roof, pitched roof, asphalt, you know, shingles and those guys. I've never seen someone work as hard as them and I couldn't do it. I just couldn't do it. So I went to work as a teller after that. Chris: Okay. Robert: Two weeks later, a bank teller. Chris: Okay, okay, well, so you mentioned you grew up in Wisconsin. Yeah, Been in Houston a while now, so, being newer to Houston and Texas, what do you prefer Tex-Mex or barbecue? Robert: Oh, barbecue. I love the quality of the food meats you know the taste. I think it's good that there's a competition between barbecue to see who's best. I love like playing that game. Chris: It's a good experience as well, there's so many good options. Last week, in fact, someone was visiting Houston, so we've heard all about Texas barbecue. Where do you recommend we go? And I was stumped. Tell me kind of what you like or what you want, because it depends. That's great. So if you could take a 30-day sabbatical, where would you go and what would you do? Robert: Yeah, so that's easy. I spend the first two weeks at home just being at home. You know being a dad being, you know being a husband. I think that's very, very important, boy, that would be a good vacation. Chris: Yeah. Robert: And then maybe the last two weeks I'd stay here in Texas. I go to Hill Country. Yeah, there's so many great places in Texas. It's like a whole different country really. Chris: Sure. Robert: You could go to Dallas and spend some time downtown Dallas doing some fun stuff. You could stay here in Houston and experience all kinds of interesting stuff. Or you could go to Austin, go to Hill Country. It's just the dynamic is incredible. Chris: Couldn't agree more, so I'd stay here close to home. I travel enough. Okay, fair enough, fair enough. Well, Robert:, thank you again for agreeing to be a guest. I loved hearing your story and what you're doing at World View and the team that you all have there. So thanks again. Robert: Absolutely, it's been a pleasure. Thank you, Chris. Special Guest: Robert Grosz.

Listen in today's episode as entrepreneur extraordinaire Mark Walker shares Direct Digital Holdings journey. Mark reveals how laser-focusing on people, processes and credibility grew revenues from $6M to $120M in just five years. His insights on genuine networking and understanding capital raising are invaluable. We also explore leveraging AI for personalized ads and how concentrating on small wins propels growth. Mark's servant leadership style emphasizes collaboration in decision-making. Transitioning from private to public, Mark outlines assembling experienced boards through professional connections. Continuous learning, reading and informed networking develop strong leadership. This glimpse into Mark's exemplary journey offers a treasure trove of strategies for success. SHOW HIGHLIGHTS Mark Walker, the co-founder and CEO of Direct Digital Holdings, emphasizes the importance of people, processes, and credibility in scaling a business from $6 million to $120 million in revenue within five years. He explains that adopting an "it's okay to fail" mindset and involving every team member in the hiring process can lead to a more efficient and collaborative team. The unique sales strategy of Direct Digital Holdings is shared, which involves dividing their sales groups into hunters and farmers, contributing to their remarkable growth. We discuss the significance of focusing on small wins and leveraging AI for personalized ads in accelerating business growth. He mentions that his leadership style is rooted in servant leadership, emphasizing collaboration in decision-making. Walker explains his strategy for assembling a board of directors to transition a company from private to public, highlighting the advantages of collaborating with law and accounting firms to recruit experienced board members. He stresses the importance of continuous learning, networking, and staying informed in maintaining effective leadership. Walker reveals his love for Gatlin's Barbecue and his dream of taking a 30-day sabbatical in Asheville, North Carolina. He explains that maintaining a genuine network of connections before needing something is a valuable tool for success. Walker also shares the importance of a company culture based on integrity, service to each other, and accountability. LINKSShow Notes Previous Episodes About BoyarMiller GUESTS Mark WalkerAbout Mark TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode, you will meet Mark Walker, co-founder and CEO at Direct Digital Holdings. Mark shares his views on how the importance of focusing on people and processes will help accelerate and manage the growth of your company. Mark, I want to thank you for being here today and being a guest on our podcast. Mark: Yeah, thank you for having us. Chris: So let's just get started by you telling us, tell us, direct Digital Holdings. What is that company? What are you known for? Mark: Yeah, very simply, direct Digital Holdings. What we do is we help companies buy and sell media and we leverage technology to do it. We have a buy side platform where we actually work with roughly about 250 different clients all across the United States, focused on the middle market, and when we look at the middle market, there are companies that are five to 500 million in revenue and we help them purchase media in order to drive our way of performance for their company. The second half of our business is Colossus SP, which is a supply side platform, and that side of the business we help publishers such as USA Today, gannett, hearst, brands of that Nature actually sell media in an automatic or programmatic way throughout the digital ecosystem, and so we work with about 26,000 publications, helping them sell media online and that's everything from digital banner ads to CTV, ot, streaming audio ads and help them generate revenue for their publications and for their websites. Chris: That's great. So what was your inspiration to start this company and grow it to where it is today? Mark: Yeah, absolutely. My business partner and I. We actually worked on another publisher, ebony Media, and while we were at Ebony we saw how the value chain of the programmatic ecosystem and media buying was changing. We saw that publishers were having difficulty specifically multicultural publishers were having difficulty getting connected into the programmatic ecosystem because their websites were too small and typically the larger players in the marketplace would want to work with publications that had 10 million unique visitors Well, anyone less than that. They didn't think it was worth their time giving them the technical expertise, know how, wherewithal, to connect into the programmatic ecosystem and purchase media automatically. So we saw the opportunity to buy two nascent platforms. One was Huddle Masses, which was the initial buy side platform. The other one was Colossus, which was the sell side platform. We put them together underneath one brand direct digital holdings and we started off with roughly about $6 million in revenue, and this year we're projected to grow to about 120 million in top line revenue over the course of these five years, and we've been really blessed and honored that many clients and partners have decided to work with us over this time. Chris: Yeah, I get a meant remarkable growth. Let's talk about a little bit. So this is your first stint at being an entrepreneur. Mark: Yeah, absolutely. Yeah it's myself and my business partner, Keith Smith. It's our first time really stepping into the role of operator. Previously I worked at startups. That's really where I first got my digital expertise and worked at Deloitte, worked at NRG Energy here in town and then also at Ebony Media. So all the while I've been working in the digital space, but this is my first entree into entrepreneurial space, really around the digital platform. Chris: So what were some of the lessons that you've learned, starting basically your own company and taking on that leadership role where everything you know, the buck stops with you? Maybe explain to our listeners, maybe, some of the things that that you've learned along that journey. Mark: Yeah, you know, I would kind of frame it up into three different categories. Chris: One one. Mark: It was about building up credibility in the marketplace. Having a good name, having a good reputation, having a network that you could lean on, I can tell you has been categorically valuable. That network is what I've leaned on for board members, what I've leaned on for contacts, relationships all throughout my career and really it's been 20 years of building up relationships that has come to fruition through this organization. Chris: That's number one. Mark: The second was really building up the credibility as well as the connections, but really the credibility of learning a craft and an expertise. That's been the second thing. And staying inside of the digital space and having 20 years of experience, it just kind of gives you secondhand knowledge of how things are gonna operate and how digital operates and flows. And then the third piece is understanding how to raise capital and put capital into the ecosystem. My business partner he came from private equity, worked on Wall Street and so he had the expertise and really brought that to bear, and so really it's been the culmination of those three things that we made a good partnership in bringing all three of those together. That's actually allowed us to have the success that we've had today. Chris: Yeah, it makes sense. I mean you can't, I think, overemphasize the importance of building really good relationships throughout your career, because you never know what you're gonna need to lean on them. Mark: No, that's exactly right. Yeah, my buddy, he gave me a saying a long time ago. He said network before you need something, and so I kind of lived by that ethos and I thought it was actually a good way of thinking about relationships. And usually if you do something good or nice for someone, even though you don't know how it's gonna come back to you, nine times out of 10, it always comes back when you need it, and that's really has been the story of our career and also our experience working with direct digital holdings. Chris: Yeah, I like that Network before you need something which said in other ways be genuine, right, build relationships in a genuine way, and then, yeah, it's always nice to help people out, and then if you do that from a point of genuineness, then it gets returned. It always gets returned somehow. So let's talk a little about your growth. I mean 6 million to 120. What are some of the things you feel like you and your co-founding partner have done to help kind of manage that growth, Because sometimes rapid growth can destroy a company. Anything that you can kind of share with us, that you think you all have kind of put into place to kind of manage this growth so that it's a healthy growth and that the company is sustainable. Mark: Yeah, absolutely, you know. It was really, you know, going from 6 million to roughly we did. God took about 30 million through an acquisition and so that was a good push for us and then, from that 30 million, really the next trunch from 30 to 90, which is what we did last year we really started working on processes. I can't stress enough in my experience back at Deloitte as well as with NRG really emphasize the importance of process people. You can't grow without people and you can't grow in an organized fashion without processes. And so we internally have been focused for the last two years really building up the processes and bringing new people into the organization to work specific tasks you think about when we look at organizations inside of us, inside of our organization. Part of the training had incorporated is you look at the functional first. Remove all the bodies, just think about the functions that need to be executed, think about the KPIs and the accountability, and then you start assigning the right person for the right role within those functions and understanding that each leader can only manage roughly four or five people effectively. So, we've definitely have had an emphasis and a focus on people, processes and accountability in KPIs inside of our organization. And that's really has led us really to take it from 30 to 90 million. And then we're putting more processes in, more what we call our third and fourth layer of employees inside the organization for us to really take that growth from the 90 to the 120, hopefully from 120 and beyond. Chris: That's great. So totally agree process and people, especially people, are the most important right. You can't no chance of achieving that kind of growth without good people. So what are you doing? And I don't know, how's your employee head count grown when you were at the six and even maybe the 30 to now? How many people are we talking about? Mark: Yeah, so back when we were at six we had probably eight, nine people total. Today we're at 85. So definitely like 12x growth from where we started off. The good thing is we've hired a significant amount of people with experience, a wealth of experience inside of the industry. So that really cuts down on the learning curve. And then the next piece is giving people the distance and direction where we're trying to go, and give them the guide rails. We'll let them figure it out. The thing I try to say internally is if I had to tell you how to do your job, then one of us is not doing their job effectively. So my goal is to hire people who understand and aren't afraid to fail. Put them inside of a structure, give them the distance and the direction of the resources that they need to try to accomplish a task and hopefully, get out the way and try to remove boulders when necessary. That's been kind of our leadership philosophy inside the organization and we think we empower our employees to actually accomplish a task that we put in front of them and hopefully we can celebrate at the end of the year for them achieving it. Most of the times nine times out of ten they actually outperform. So we think if we set up the right structure, giving them the right resources to help, them and then giving them the proper distance and direction and get out of the way. usually that's an effective way If you hire the right people, for them to be effective in their jobs. Chris: I like that. So, going with the people theme, you got to get them in the right seat, give them direction. What are you doing there at Direct Digital to foster a culture and so that people want to stay? Let's talk a little bit about that. Mark: Yeah, the culture that we really try to foster is one based on integrity. So if you're going to say something, follow up and do it. If you don't do it, take account of it before it. That's number one we try to foster that. We also foster service to each other, and that's the biggest one. My job as a leader is really to be of service to the employees, so take it serious to try to provide service to them and getting them what they need in order for them to execute effectively, and so we try to instill that inside of our leadership team and view it as it's not you doing what I say. It's about you enrolling in what we're trying to accomplish, and then let me help you get there. And so, even though we give big goals to our employees, we feel like it's all of our jobs to own that goal. And so I'm right there making phone calls. I still go on sale pitches. Last night, I had a client dinner we're still out here boots on the ground and if I'm not the number one salesperson trying to help generate sales and leads for the team, then I feel like I'm not doing my job. So that's kind of how we think about it. And when we try to hire employees, the word we termed as we want strategic doers. I like that. Yeah, we don't. We, you know, we're very deliberate that, especially in the growth phase that we're in, I need a strategic doer, someone who can be strategic but someone who doesn't mind rolling up their sleeves and getting dirty and running a report or making a sales call or generating leads. We need everybody doing it and then if you do effective job, then hire more resources underneath it. You can start moving into the strategic role. Yeah, Every employee starts off that way. We think it's a bit of an effective way for us to grow. Chris: Kind of that mindset of do what it takes to get the job done. Yep, well, it sounds like you know a lot of collaboration to kind of a team, teamwork, team, teammate mentality. Yeah, but you talked about you know just your hiring process, anything that you guys were doing there. Do you think they're somewhat innovative in how you go about the hiring process to make sure you're getting the right people? And maybe any challenges you faced in the last few years, given the environment and the economy? Mark: Yeah, when we come to the hiring, what we adopt as our philosophy is everybody touches them. So if the team is going to interview, if the person is going to be working on team, everybody on team has a say. Everybody on team has veto authority. And then the one thing I try to remind the leaders is the problem is going to be the problem. So if one person identifies a weakness, another person identifies a weakness, then that's probably the weakness in that person and it's not going to change. So then you have to ask yourself the tougher question Is that weakness detrimental in this role, or is that something that can be covered up or managed? And so that philosophy has been very instrumental in us being effective and we've been very. When we have our debriefs after we interview someone, everyone comes together. One person feels like I don't think they're going to be a good fit or I don't feel comfortable working with them. Then that's a no across the board. So very rarely have we made a decision that the collective wasn't comfortable with that person coming into the organization. Maybe it's my old fraternal approach to things, pledging a fraternity, and my business partner he actually played football at UT, but feel like a team and a collaborative approach is always the best way to try to find the best candidates and make sure you can protect the culture of the organization. Chris: Yeah, no, I couldn't agree more. I think that you've got that cohesiveness. You just can't put a price on it. And one person you hear it a lot in sports right, but a bad apple in the locker room or can destroy a good team, or quite the opposite. Maybe not a group of the best stars, but they get along. They can play above their natural ability. Mark: Yeah, absolutely. Chris: And. Mark: I love that yeah. Chris: So let's talk about a setback that maybe you've encountered in the last since starting at the company. Explain, maybe a setback you've encountered, what you did to overcome that, maybe what the learning was and how it's made you or the company better. Yeah, absolutely. Mark: You know, in moving and growing this fast, sometimes you miss processes and you know the way that we view it. One person didn't miss a process. We all missed the process. So for us you know, we've done that before where you know you have might be a process set up to protect the organization and you missed it. Sometimes you got to go in and everybody has to rally around and say, okay, guys, let's figure out what happened. There's no fault to be assigned, but really what it is. Let's figure out where did the process break down and we're all collectively accountable. So, that's really the approach we've taken, what I think it actually helped us. It actually helped us Really identify are there any other holes that we have in the organization we need to plug up? You know, you know what you know, but you don't know what you don't need. You don't always know what you don't know Right, and so it's that piece that, unfortunately, usually errors get pointed out and that's the correction that you have to go in place. But we try to take an attitude of it's no one's fault, it's all of our problem, let's all own it, let's take accountability for it, let's fix it. Chris: I'd have to believe that helps foster that it's okay to fail type of mentality you talked about earlier. Right, that if everyone's kind of you feel like everyone, that's your coworkers are in it with you, then you're more likely to take that risk, knowing that failure is not going to point fingers at you as a result. Mark: Absolutely, and that usually usually helps, because if everyone's in there with you together, then you're okay. You know you got coverage. Chris: Yeah. Mark: So that's the best benefit that you have. Chris: Switching subjects a little bit, let's just when you think about what you guys are doing and both sides of your business, anything kind of innovative that you all employed, that you think has really helped the trajectory of the company and this growth you've seen. Mark: Yeah, I would say a couple things. One, we bifurcated our sales groups, so we have lead generation and then we have our sales closers. That has been instrumental. Let the hunters be the hunters, let the farmers be the farmers and let them both work collectively together. That has been instrumental to help us grow. Specifically on our buy side business, we've been growing solid 10-20% year over year. That's a tougher business to grow but the level of growth that we've been able to see has been very effective for us. Very proud of what we've been able to accomplish on that piece On the sell side of our business, which has been growing 100-200% year over year we've been able to really foster an environment where a lot of companies will go in and try to get the big whale. We play a lot of small ball inside of the game, so a lot of fruit what I call was low hanging fruit had gotten left by our competitors. We called, we made calls, not to the highest level person, to the lowest level person, told them to test out our platform and, sure enough, we were able to grow that business that way. Our business leader was very innovative on that approach, calling what we call fingers on keyboards those are the decision makers, the day-to-day decision makers to get them to try out our platform and through those efforts we were able to grow effectively. So sometimes, especially when talking to other entrepreneurs, sometimes look for the slow hanging fruit. Don't try to hit the home run, try to hit the single. The single will get you on base and that gets you actually in the game. That's kind of the strategy we've taken. Chris: I think that's great advice for some of our listeners out there that maybe trying to grow their company they just started is. You know, you don't always have to hit the home run of the Grand Slam right, you can start small and let that momentum build. What about AI? How do you see AI playing into your business model and what changes do you think are going to be coming down your path where you may need to make some adjustments? Mark: Yeah, no good question. When it comes to AI, I think what you're going to start saying is it's definitely been around for some time, or some level of machine learning has been around for some time. We think of it in two different counts. We think of behind the house and then in front of the house. Behind the house, that's the stuff that you really don't see, but that's really inside of the processes. That's stuff that we're taking advantage of right now. We're taking advantage of a lot of different algorithms. We're incorporating AI into different pieces of it. You won't be able to see it, touch it, feel it, but it's actually making our systems run much more, our technology run much more efficiently. On the back end, that, I think, has been around for a while and we're definitely in that space and moving more advantageously in that space. Behind the house. In front of the house is where I think all the excitement is actually coming with AI. The fact that you can do words with image imagery, natural language, learning, things of that nature I think we're going to start seeing in the next two years is a personalization of ads. Right now, you do a lot of ads. You might come up with 16, 17, 20 different recipes, trying to hit different segments. I think you're going to see a lot more personalization. On the data side, we have a significant amount of personalization of understanding what people like, what they dislike, their behavioral, demographic, psychographics all that information is already there. Now you're going to start seeing the creative reflect that, because creating new recipes of ads is going to be a lot easier leveraging AI technology than when you don't have AI technology. You have a human who has to replicate 20 different ads of the same idea. I think that's really the next evolution that you're going to see. I think that's going to be the exciting part coming to our space in probably the next two years. Chris: Wow, that'll be before you know it. Mark: Yeah, it'll probably be here sooner than later. Chris: Yeah, let's talk a little bit about leadership. How would you describe your leadership style? Mark: I think it's more of a. As I said before, I try to serve all of my team members. On the personal, we all think of more of it as a collaborative approach. We think of each other as a work family. We try to foster that type of environment of a work family. If you go to our office space, there are offices, but the main area, about 3,000 square feet, looks like a house. It looks like a kitchen, has a TV, has couches. We try to foster a work family environment. We want kids up there. We ask employees bring your kids. We have X-pots for them to play. It needs to be a collaborative approach because we spend probably more time at work than we do at home. Chris: Yeah, no question, right, so you might as well enjoy it while you're there. Mark: The other way that I would say is my leadership style is I try to really believe in trying to be a servant leader, so every problem is my problem. If my team has a problem, it's my problem. I try to own it. I try to help people solve through it and work with them and try to hold them accountable for the result. But no one's held accountable on their own. We're all accountable, so everyone pitches in to try to help out. So that's what we try to do with the environment, that we try to foster Type of leadership style that we have. My team probably would say I get into the weeds a little too much. Sometimes you can't help it right. Chris: Yeah, but I enjoy getting started. I get that. I get that there's some value, as long as you can regulate it to your team, seeing you willing to get in and get dirty get your fingernails dirty from time to time, right, and they're like, okay, you are in this with us, yeah, let's talk about. So. You've got your co-founder, keith Smith. How do the two of you manage the leadership roles in the company to be aligned and kind of maybe not contradict one another or step on each other's toes? Mark: Yeah, so the way we operate Function is we both bring two different experiences and we actually did bring two different personalities to the equation my business partner, keith. He's definitely more on the finance side. So when it comes to the finance, when it comes to the administrator, when it comes to the legal, he owns that, that's, he takes the leadership piece on that and I'm more than happy to step out of the way. All those pieces we got to do refies. We're going through the IPO process. He definitely took the lead on how to get that whole structure and organizing. Yeah, that expertise and experience for that. Chris: When it comes to the operational side. Mark: that's the piece that I bring more of my leadership style to, and so we meet in the middle. So when those two come together we meet in the middle. So it's really kind of clear lines in how we are structured. When it comes to investors, he takes the lead on talking to investors and stuff like that. If they need to hear from the operator, then I step in and have those kind of conversations. Chris: But that's pretty much how we structure the organization and it works well that way, so clearly delineated roles and responsibilities, and then everyone in the organization understands that as well, how it shapes up. Mark: Yeah, and then personality wise we make a good match, because I'm probably more of the passionate one, he's probably more of the sub dude one, so we meet in the middle that way. Chris: Okay, yeah, that sounds like a great team. The results speak for itself. What about mentors? Any mentors you've had along the way? That kind of help get you to where you are, shape your leadership philosophies, your work ethic, etc. Mark: Oh, absolutely, I had a thousand. You know a lot of them Some of them have been independent entrepreneurs. I call them my own personal board of directors. Reach out to a lot of them one-on-one to have conversations with them and get feedback and thought. Some of my mentors and leaders actually have joined the board, okay, and they're on our board of directors, and so definitely get a lot of leadership and good guidance from our board of directors, very happy with what they provide and the expertise that they deliver. And then they definitely help shape the organization and also give me and challenge me to think through different either opportunities or also different risks that are out there. So definitely got the board, got my independent individual board of directors as well. Of friends that I actually call on that I've known for 20 plus years. Some are in the industry, some are outside the industry, but they haven't been shaped by all of them. Chris: Let's talk a little bit about that. You know the board and board composition, etc. When did you and Keith decide to form a board of directors? Was it right out of the start or was it as the company was evolving and growing? Mark: Yeah, so we started our when we were from 2018 to 2022, we were actually privately held, so we're probably I'll do as myself, keith and we had a third business partner who we ended up buying out, so we made up the constitute the board and, trust me, it was 100 times easier as a private company yeah. Because you look at Keith and I look at him and say what do you want to do? Chris: Yeah, Right, which is typically how the small, privately held entrepreneur starts out. Right Exactly. Mark: Yeah, and just kind of kind of keeping moving. When we ended up deciding to go public, we had to actually form a public board, and so then we had to start recruiting people with actually board experience and expertise and you know some level of ground toss and all that. And that's when you know, we had to start tapping into our own connections, our own network. Our lead director we worked at Deloitte. We both worked at Deloitte, didn't know each other at that time but we knew mutual people and mutual friends and so we recruited her to come on the board as our lead director. She's been absolutely phenomenal. But really thought through, what did we need to help us grow to the next level? So we knew we needed technologists. We knew we needed someone with finance background and a strong experience and accounting around audit committee. Then we knew we needed someone with industry expertise, specifically from the agency side. So we're very strategic about who we brought on the board, why we brought them on the board and what value we were really looking to get in expertise. So you know, my advice on performing a board is really to think through. Don't think about where you are today, but really think about where you're trying to go tomorrow and try to bring the people who have that experience and expertise to come on the board. Now I will say for us to recruit one of those members, best place to go is your law firm and your accounting firm. They know good people. They know people they probably worked with on other boards. My first piece of advice go to your attorneys and go to your accountants and see if they know of anyone who might be a good board member. That's how we started our recommendation process, yeah. Chris: And I think you're right in picking those disciplines that you have again as a mentor or resource to bounce ideas off of, get direction from. Yeah, and you don't have to be a public company, a privately held company trying to grow can that entrepreneur can benefit from those resources. Mark: Absolutely Firmly believe that and then build the right culture even inside the board. You want to collaborate on board who can think through problems collectively and come to a solution. Chris: Yeah, what about? You know we all, we all try to continue to learn and grow. What are some of the things you do to kind of keep yourself sharp, to keep learning, to be that servant leader? You know the type of person that you want to emulate in the company. Mark: Yeah, a couple things. One definitely mentorship. So you know, one of the pieces of advice I give is get into a CEO group, because everybody has problems. Chris: Right, then you can learn from other people's problems before they become yours. Mark: Before they become yours. You're like, let me take note of that problem. That's number one. But I would also say you know I read a lot. Yeah, every morning I'm reading, every afternoon I'm reading, I subscribe to God knows how many publications. So you really try to absorb information and I have to say you have to get out of the ivory tower and get out on the street. Yeah, I'm a firm believer in, you know, hearing kind of the qualitative information. To me, if it's in the news, it's already too late. It's really the qualitative information that you get from networks that really kind of give you insight on where the trends are going. So I always try to keep my ear to the street. By getting out and meeting with people and taking people to watch, I get a lot of good information that way. Chris: These are great pieces of advice as far as how to kind of stay in tune with things, and I think you're right. These days there's some great publications, you know I think Bloomberg does since two meals a day, one in the morning, one in the evening, and all that where news is coming at you fast. Mark: It's coming at you and you gotta be on it every day, For sure You're absolutely right. Chris: Before we change subjects, one or two things that you would say to some of our listeners that are trying to start, or maybe just start, a new company about here. If you're about to embark on this journey to pursue a passion on your own or with a couple partners, here are one or two things that I think you should absolutely do or consider doing, as you kind of embark on that wisdom there. Mark: You know, the one piece of advice I would give is be all in Like entrepreneurship. I will just say two things. One, it's not for the faint of heart, but you gotta be all in. And so I think there is something about failure and success. The risk of failure will drive you to success. But if you kinda have one foot in and I'm still doing my job, but I wanna do this then you're not wanting to be an entrepreneur. You either gotta be all in, ready to risk it all, or you don't. That's probably the one piece of advice I would give Pretty much everyone. And if you're not in the position to get yourself in the position to and then go all in, Don't think you can do it half in, half out. It won't work. Chris: That's great, great advice actually, and very true. It's funny that's a pretty consistent theme of the guest I've had. Is that all in mentality? And the second is it's not for the faint of heart. Mark: Right. Chris: So just know there's gonna be tough times and you just gotta muscle through it. So let's go a little bit on the personal side. What was your first job? Mark: First job in high school was a sacker at Randalls. I used to sack groceries when I turned 16, over off of Jones Road and, yeah, you made good money. If I came home with $40 after a cycle, I was pretty happy. Chris: Yeah, and in the hot Texas heat. Oh absolutely, yeah, okay, so your native Texan. I always ask all my guests you prefer Tex-Mex or barbecue? Mark: Barbecue hands down Gavils barbecue. Chris: Oh, okay, there we go, no hesitation, and applaud for Gatlins. I love it. It's pretty good stuff. They've gotten a lot more competition now, but Gavils gonna win, yeah. So let me ask you this so if you could take a 30 day sabbatical not that you would, if you could where would you go? What would you do? Mark: If I could take a 30 day sabbatical I would probably. You know, I really wouldn't mind going to Asheville, north Carolina, getting out in the mountains and enjoy some of that, especially in the fall I'd be out there all day Just out in the woods and hanging out. Chris: It's a beautiful area. Oh God, it's gorgeous. Yeah, it's got a sketch right out there. Well, mark, I wanna thank you again for coming on. Congratulations to you and Keith on what you've built and are continuing to build. Love hearing your story and the insights you shared. Mark: Yeah, absolutely, absolutely. Pleasure being here. I appreciate your time and thank you for having us. Special Guest: Mark Walker.

This week we call out the following:The Supreme CourtThe PGATrump's espionage! Indictment time please!Racist violent neighbors & the Cops that protect themJan6 Domestic terrorist & Second City alumnus Jay JohnstonAnd we celebrate:Chief Justice Roberts "flip flop" on voting rights - YASSSSSSS!!!The departure of Chuck Todd(pronounced Tahh)The firing of Chris "Let's let Trump run the show" Licht at CNNAND ALL OF YOU FOR BEING ON THE SIDE OF JUSTICE, DIVERSITY, EQUITY AND INCLUSION!!!! Please check out HRC.Org on all the ways you can help create safe spaces for LGBTQIA youth & us all! Trans rights are human rights!!! The Final Word on all things Political and Pop Cultural. Comedic duo Frangela makes "Real News. REAL FUNNY!" Your positive "Back Up AND Black Up!" here to inspire you to #RESIST!Do you want to hear more Idiots of the Week?? Become a Frangela patron at Patreon.com and get three exclusive Micro Idiot podcasts each week as our thank you for your support.Frangela swag available at https://www.zazzle.com/store/frangela! Book a personalized video shout-out from Frangela at Cameo.com/frangeladuo.

Stories in this episode: - Bus Stop Buddies Turned Creeps, by Amanda (0:48) - Midday Park Stalker, by Anonymous (14:54) - The Man in the Silver Mercedes, by Sick Cookie (19:41) - Chris, by Emily (29:05) Extended Patreon Content: - He Said My Tail Light Was Out, by Alicia - The Unknown Man Inside My House, by Alexandria - Horror in Hawaii, by Courtney - Almost Kidnapped While Pregnant, by Andrea - Potential Employer Turned Stalker by Barrett - The Sandwich Man, by Kelly Due to periodic changes in ad placement, time-stamps are are estimates.  All of the stories you've heard this week were narrated and produced with the permission of their respective authors. Let's Not Meet: A True Horror Podcast is not associated with Reddit or any other message boards online. To submit your story to the show, send it to letsnotmeetstories@gmail.com.   Get access to extended, ad-free episodes of Let's Not Meet: A True Horror Podcast with bonus stories every week at a higher bitrate along with a bunch of other great exclusive material and merch at patreon.com/letsnotmeetpodcast. This podcast would not be possible to continue at this rate without the help of the support of the legendary LNM Patrons. Come join the family! Check out the other Cryptic County podcasts like Odd Trails, Welcome to Paradise (It Sucks), and the Old Time Radiocast at CrypticCountyPodcasts.com or wherever you get your podcasts! Go to HelloFresh.com/lnm50 and use code lnm50 for 50% off, plus your first box ships free! Check out the Vessi Cloudburst and other styles at vessi.com/MEET. Use code MEET for 15% off your order. Free shipping for CA, US, AU, JP, TW, KR, SGP.  - Facebook - https://www.facebook.com/groups/433173970399259/  - Website - https://letsnotmeetpodcast.com  - Patreon - https://patreon.com/letsnotmeetpodcast  - Instagram - https://www.instagram.com/letsnotmeetcast/  - Twitch - https://twitch.tv/crypticcounty  

Natural disaster movies, anyone? It's what Steph's been into, and Chris has THOUGHTS on the drilling in Armageddon. Additionally, a chat around RuboCop RSpec rules happens, and they answer a listener's question, "how do you get acquainted with a new code base?" This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. Greenland (https://www.imdb.com/title/tt7737786/) Geostorm (https://www.imdb.com/title/tt1981128/) San Andreas (https://www.imdb.com/title/tt2126355/) Armageddon (https://www.imdb.com/title/tt0120591/) This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. Flaky tests slow everyone down, break your flow, and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start? BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. So I've been watching more movies lately. So evenings aren't always great; I don't always feel good being around 33 weeks pregnant now. Evenings I can be just kind of exhausted from the day, and I just need to chill and prop my feet up and all that good stuff. And I've been really drawn to natural disaster like end-of-the-world-type movies, and I'm not sure what that says about me. But it's my truth; it's where I'm at. [chuckles] I watched Greenland recently, which I really enjoyed. I feel like they ended it well. I won't share any spoilers, but I feel like they ended it well. And they didn't take an easy shortcut out that I kind of thought that they might do, so that one was enjoyable. Geostorm, I watched that one just last night. San Andreas, I feel like that's one that I also watched recently. So yeah, that's what's new in my world, you know, your typical natural disaster end-of-the-world flicks. That's my new evening hobby. CHRIS: I feel like I haven't heard of any of the three that you just listed, which is wild to me because this is a category that I find enthralling. STEPH: Well, definitely start with Greenland. I feel like that one was the better of the three that I just mentioned. I don't know Geostorm or San Andreas which one you would prefer there. I feel like they're probably on par with each other in terms of like you're there for entertainment. We're not there to judge and be hypercritical of a storyline. You're there purely for the visual effects and for the ride. CHRIS: Gotcha. Interesting. So quick question then, since this seems like the category you're interested in, Armageddon or Deep Impact? STEPH: Ooh, I'm going to have to walk through the differences because I always get those mixed up. Armageddon is where they take Bruce Willis up to an asteroid, and they have to drill and drop a nuke, right? CHRIS: They sure do. STEPH: [laughs] And then what's Deep Impact about? I guess the fact that I know Armageddon better means I'm favoring that one. I can't place what...how does Deep Impact go? CHRIS: Deep Impact is just there's an asteroid coming, and it's the story and what the people do. So it's got less...it doesn't have the same pop. I believe Armageddon was a Michael Bay movie. And so it's got that Michael Bay special bit of something on it. But the interesting thing is they came out the same year; I want to say. It's one of those like Burger King and McDonald's being right next door to each other. It's like, what are you doing there? Why are you...like, asteroid devastation movies two of you at the same time, really? But yeah, Armageddon is the correct answer. Deep Impact is like a fine movie, but Armageddon is like, all right, we're going to have a movie about asteroids. Let's really go for it. Blow it out. Why not? STEPH: Yeah, I'm with you. Armageddon definitely sticks out in my memory, so I'd vote that one. Also, for your other question that you didn't ask, but you kind of implicitly asked, I'm going to go McDonald's because Burger King fries are trash, and also, McDonald's has better ice cream cones. CHRIS: Okay, so McDonald's fries. Oh no, I was thinking Wendy's, get a frosty from there, and then you make that combination because the frostys are great. STEPH: Oh yeah, that's a good combo. CHRIS: And you need the french fries to go with it, but then it's a third option that I'm introducing. Also, this wasn't a question, but I want to loop back briefly to Armageddon because it's an important piece of cinema. There's a really great...like it's DVD commentary, and it's Ben Affleck talking with Michael Bay about, "Hey, so in the movie, the premise is that the only way to possibly get this done is to train a bunch of oil drillers to be astronauts. Did we consider it all just having some astronauts learn to do oil drilling?" And Michael Bay's response is not safe for radio is how I would describe it. But it's very humorous hearing Ben Affleck describe Michael Bay responding to that. STEPH: I think they addressed that in the movie, though. They mentioned like, we're going to train them, but they're like, no, drilling is such an art and a science. There's no way. We don't have time to teach these astronauts how to drill. So instead, it's easier to teach them to be astronauts. CHRIS: Right. That is what they say in the movie. STEPH: [laughs] Okay. CHRIS: But just spending a minute teasing that one apart is like, being an astronaut is easy. You just sit in the spaceship, and it goes, boom. [laughs] It's like; actually, there's a little bit more to being an astronaut. Yes, drilling is very subtle science and art fusion. But the idea that being an astronaut [laughs] is just like, just push the go-to space button, then you go to space. STEPH: The training montage is definitely better if we get to watch people learn how to be astronauts than if we watch people learn how to drill. [laughs] So that might have also played a role. CHRIS: No question, it is the correct cinematic choice. But whether or not it's the true answer...say we were actually faced with this problem, I don't know that this is exactly how it would play out. STEPH: I think we should A/B test it. We'll have one group train to be drill experts and one group train to be astronauts, and we'll send them both up. CHRIS: This is smart. That's the way you got to do it. The one other thing that I'm going to go...you know what really grinds my gears? In the movie Armageddon, they have this robotic vehicle thing, the armadillo; I believe it's called. I know more than I thought I would remember about this movie. [chuckles] Anyway, continuing on, the armadillo, the vehicle that they use to do the drilling, has the drill arm on it that extends out and drills down into the asteroid. And it has gears on the end of it. It has three gears specifically. And the first gear is intermeshed with the second gear, which is intermeshed with the third gear, which is intermeshed with the first gear, so imagine which direction the first gear is turning, then imagine the second gear turning, then imagine the third gear turning. They can't. It's a physically impossible object. One tries to turn clockwise, and the other one is trying to go counterclockwise, and they're intermeshed. So the whole thing would just cease up. It just doesn't work. I've looked at it a bunch of times, and I want to just be wrong about this. I want to be like; I don't know what's going on. But I think the gears on the drilling machine just fundamentally at a very simple mechanical level cannot work. And again, if you're going to do it, really go for it, Michael Bay. I kind of like that, and I really hate it at the same time. STEPH: I have never noticed this. I'm intrigued. You know what? Maybe Armageddon will be the movie of choice tonight. [chuckles] Maybe that's what I'm going to watch. And I'm going to wait for the armadillo to come out so I can evaluate the gears. And I'm highly amused that this is the thing that grinds your gears are the gears on the armadillo. CHRIS: Yeah. I was a young child at the time, and I remember I actually went to Disney World, and I saw they had the prop vehicle there. And I just kind of looked up at it, and I was like, no, that's not how gears work. I may have been naive and wrong as a child, and now I've just anchored this memory deep within me. In a similar way, so I had a moment while traveling; actually, that reminded me of something that I said on a recent podcast episode where I was talking about names and pronunciation. And I was like, yeah, sometimes people ask me how to pronounce my name. And I can't imagine any variation. That was the thing I was just wrong about because 'Toomay' is a perfectly reasonable pronunciation of my name that I didn't even think... I was just so anchored to the one truth that I know in the world that my name is Toomey. And that's the only possible way anyone could pronounce it. Nope, totally wrong. So maybe the gears in Armageddon actually work really, really well, and maybe I'm just wrong. I'm willing to be wrong on the internet, which I believe is the name of the first episode that we recorded with you formally as a co-host. [chuckles] So yeah. STEPH: Yeah, that sounds true. So you're going to change the intro? It's now going to be like, and I'm Chris 'Toomay'. CHRIS: I might change it each time I come up with a new subtle pronunciation. We'll see. So far, I've got two that I know of. I can't imagine a third, but I was wrong about one. So maybe I'm wrong about two. STEPH: It would be fun to see who pays attention. As someone who deeply values pronouncing someone's name correctly, oh my goodness, that would stress me out to hear someone keep pronouncing their name differently. Or I would be like, okay, they're having fun, and they don't mind how it gets pronounced. I can't remember if we've talked about this on air but early on, I pronounced my last name differently for like one of the first episodes that we recorded. So it's 'Vicceri,' but it could also be 'Viccari'. And I've defaulted at times to saying 'Viccari' because people can spell that. It seems more natural. They understand it's V-I-C-C-A-R-I. But if I say 'Vicceri', then people want to add two Rs, or they want a Y. I don't know why it just seems to have a difference. And so then I was like, nope, I said it wrong. I need to say it right. It's 'Vicceri' even if it's more challenging for people. And I think Chad Pytel had just walked in at that moment when I was saying that to you that I had said my name differently. And he's like, "You can't do that." And I'm like, "Well, I did it. It's already out there in the world." [laughs] But also, I'm one of those people that's like, Viccari, 'Vicceri' I will accept either. In a slightly different topic and something that's going on in my world, there was a small win today with a client team that I really appreciated where someone brought up the conversation around the RuboCop RSpec rules and how RuboCop was fussing at them because they had too many lines in their test example. And so they're like, well, they're like, I feel like I'm competing, or I'm working against RuboCop. RuboCop wants me to shorten my test example lines, but yet, I'm not sure what else to do about it. And someone's like, "Well, you could extract more into before blocks and to lets and to helpers or things like that to then shorten the test. They're like, "But that does also work against readability of the test if you do that." So then there was a nice, short conversation around well, then we really need more flexibility. We shouldn't let the RuboCop metrics drive us in this particular decision when we really want to optimize for readability. And so then it was a discussion of okay, well, how much flexibility do we add to it? And I was like, "Well, what if we just got rid of it? Because I don't think there's an ideal length for how long your test should be. And I'd rather empower test authors to use all the space that they need to show their test setup and even lean into duplication before they extract things because this codebase has far more dry tests than they do duplication concerns. So I'd rather lean into the duplication at this point." And the others that happened to be in that conversation were like, "Yep, that sounds good." So then that person issued a PR that then removed the check for that particular; how long are the examples? And it was lovely. It was just like a nice, quick win and a wonderful discussion that someone had brought up. CHRIS: Ooh, I like that. That sounds like a great conversation that hit on why do we have this? What are the trade-offs? Let's actually remove it. And it's also nice that you got to that place. I've seen a lot of folks have a lot of opinions in the past in this space. And opinions can be tricky to work around, and just deeply, deeply entrenched opinions is the thing that I find interesting. And I think I'm increasingly in the space of those sort of, thou shalt not type linter rules are not ideal in my mind. I want true correctness checks that really tell some truth about the codebase. Like, we still don't have RuboCop on our project at Sagewell. I think that's true. Yeah, that's true. We have ESLint, but it's very minimal, what we have configured. And they more are in the what we deem to be true correctness checks, although that is a little bit of a blurry line there. But I really liked that idea. We turn on formatters. They just do the thing. We're not allowed to discuss the formatting, with the exception of that time that everybody snuck in and switched my 80-line length to a 120-line length, but I don't care. I'm obviously not still bitter about it. [chuckles] And then we've got a very minimal linting layer on top of that. But like TypeScript, I care deeply, and I think I've talked in previous episodes where I'm like, dial up the strictness to 14 because TypeScript tends to tell me more truths I find, even though I have to jump through some hoops to be like TypeScript, I know that this is fine, but I can't prove it. And TypeScript makes me prove it, which I appreciate about it. I also really liked the way you referred to RSpec's feedback to you was that RSpec was fussing at you. That was great. I like that. I'm going to internalize that. Whenever a linter or type system or anything like that when they tell me no, I'm going to be like, stop fussing, nope, nope. [chuckles] STEPH: I don't remember saying that, but I'm going to trust you that that's what I said. That's just my true southern self coming through on the mic, fussing, and then go get a biscuit, and it'll just be a delightful day. CHRIS: So if I give RuboCop a biscuit, it will stop fussing at me, potentially? STEPH: No, the biscuit is just for you. You get fussed at; you go get a biscuit. It makes you feel better, and then you deal with the fussing. CHRIS: Sold. STEPH: Fussing and cussing, [laughs] that's most of my work life lately, fussing and cussing. [laughs] CHRIS: And occasional biscuits, I hope. STEPH: And occasional biscuits. You got it. But that's what's new in my world. What's going on in your world? CHRIS: Let's see. In my world, it's a short week so far. So recording on Wednesday, Monday was a holiday. And I was out all last week, which very much enjoyed my vacation. It was lovely. Went over to Europe, hung out there for a bit, some time in Paris, some time in Amsterdam, precious little time on a computer, which is very rare for me. So it was very enjoyable. But yeah, back now trying to just get back into the swing of things. Thankfully, this turned out to be a really great time to step away from the work for a little while because we're still in this calm before the storm but in a good way is how I would describe it. We have a major facet of the Sagewell platform that we are in the planning modes for right now. But we need to get a couple of different considerations, pick a partner vendor, et cetera, that sort of thing. So right now, we're not really in a position to break ground on what we know will be a very large body of work. We're also not taking on anything else too big. We're using this time to shore up a lot of different things. As an example, one of the fun things that we've done in this period of time is we have a lot of webhooks in the app, like a lot of webhooks coming into the app, just due to the fact that we're an integration of a lot of services under the hood. And we have a pattern for how we interact with and process, so we actually persist the webhook data when they come in. And then we have a background job that processes and watch our pattern to make sure we're not losing anything and the ability to verify against our local version, and the remote version, a bunch of different things. Because turns out webhooks are critical to how our app works. And so that's something that we really want to take very seriously and build out how we work with that. I think we have eight different webhook integrations right now; maybe it's more. It's a lot. And with those, we've implemented the same pattern now eight times; I want to say. And in squinting at it from a distance, we're like; it is indeed identically the same pattern in all eight cases or with the tiniest little variation in one of them. And so we've now accepted like, okay, that's true. So the next one of them that we introduced, we opted to do it in a generic way. So we introduced the abstraction with the next iteration of this thing. And now we're in a position...we're very happy with what we ended up with there. It's like the best of all of the other versions of it. And now, the plan will be to slowly migrate each of the existing ones to be no longer a unique special version of webhook processing but use the generic webhook processing pattern that we have in the app. So that's nice. I feel good about how long we waited as well because it's like, we have webhooks. Let's introduce the webhook framework to rule them all within our app. It's like, no, wait until you see. Check and make sure they are, in fact, the same and not just incidental duplication. STEPH: I appreciate that so much. That's awesome. That sounds like a wonderful use of that in-between state that you're in where you still got to make progress but also introduce some refactoring and a new concept. And I also appreciate how long you waited because that's one of those areas where I've just learned, like, just wait. It's not going to hurt you. Just embrace the duplication and then make sure it's the right thing. Because even if you have to go in and update it in a couple of places, okay, sure, that feels a little tedious, but it feels very safe too. If it doesn't feel safe...I could talk myself back and forth on this one. If it doesn't feel safe, that's a different discussion. But if you're going through and you have to update something in a couple of different places, that's quick. And sure, you had to repeat yourself a little bit, but that's fine. Versus if you have two or three of something and you're like, oh, I immediately must extract. That's probably going to cause more pain than it's worth at this point. CHRIS: Yeah, exactly, exactly that. And we did get to that place where we were starting to feel a tiny bit of pain. We had a surprising bit of behavior that when we looked at it, we were like, oh, that's interesting, because of how we implemented the webhook pattern, this is happening. And so then we went to fix it, but we were like, oh, it would actually be really nice to have this fixed across everything. We've had conversations about other refinements, enhancements, et cetera; that we could do in this space. That, again, would be really nice to be able to do holistically across all of the different webhook integration things that we have. And so it feels like we waited the right amount of time. But then we also started to...we're trying to be very responsive to the pressure that the system is pushing back on us. As an aside, the crispy Brussels snack hour and the crispy Brussels work lunch continue to be utterly fantastic ways in which we work. For anyone that is unfamiliar or hasn't listened to episodes where I rambled about those nonsense phrases that I just said, they're basically just structured time where the engineering team at Sagewell looks at and discusses higher-level architecture, refactoring, developer experience, those sort of things that don't really belong on the core product board. So we have a separate place to organize them, to gather them. And then also, we have a session where we vote on them, decide which ones feel important to take on but try and make sure we're being intentional about how much of that work we're taking on relative to how much of core product work and try and keep sort of a good ratio in between the two. And thus far, that's been really fantastic and continues to be, I think, really effective. And also the sort of thing that just keeps the developer team really happy. So it's like, I'm happy to work in this system because we know we have a way to change it and improve it where there's pain. STEPH: I like the idea of this being a game show where it's like refactor island, and everybody gets together and gets to vote which refactor stays or gets booted off the island. I'm also going to go back and qualify something I said a moment ago, where if something feels safe in terms of duplication, where it starts to feel unsafe is if there's like an area that you forgot to update because you didn't realize it's duplicated in several areas and then that causes you pain. Then that's one of those areas where I'll start to say, "Okay, let's rethink the duplication and look to dry this up." CHRIS: Yep, indeed. It's definitely like a correction early on in my career and overcorrection back and trying to find that happy medium place. But as an aside, just throwing this out there, so webhooks are an interesting space. I wish it were a more commoditized offering of platforms. Every vendor that we're integrating with that does webhooks does it slightly differently. It's like, "Oh, do you folks have retries?" They're like, "No." It's like, oh, what do you mean no? I would love it if you had retries because, I don't know, we might have some reason to not receive one of them. And there's polling, and there are lots of different variations. But the one thing that I'm surprised by is that webhook signing I don't feel like people take it serious enough. It is a case where it's not a huge security vulnerability in your app. But I was reading someone who is a security analyst at one point. And they were describing sort of, I've done tons of in-the-code audits of security practices, and here are the things that I see. And so it's the normal like OWASP Top 10 Cross-Site Request Forgery, and SQL injection, and all that kind of stuff. But one of the other ones he highlighted is so often he finds webhooks that are not verified in any way. So it's just like anyone can post data into the system. And if you post it in the right shape, the system's going to do some stuff. And there's no way for the external system to enforce that you properly validate and verify a webhook coming in, verify that payload. It's an extra thing where you do the checksum math and whatnot and take the signature header. I've seen somewhere they just don't provide it. And it's like, what do you mean you don't provide it? You must provide it, please. So it's either have an API key so that we have some way to verify that you are who you say you are or add a signature, and then we'll calculate it. And it's a little bit of a dance, and everybody does it different, but whatever. But the cases where they just don't have it, I'm like, I'm sorry, what now? You're going to say whom? But yeah, then it's our job to definitely implement that. So this is just a notice out there to anyone that's listening. If you got a bunch of webhook handling code in your app, maybe spot-check that you're actually verifying the payloads because it's possible that you're not. And that's a weird, very open hole in the side of your application. STEPH: That's a really great point. I have not worked with webhooks recently. And in the past, I can't recall if that's something that I've really looked at closely. So I'm glad you shared that. CHRIS: It's such an easy thing to skip. Like, it's one of those things that there's no way to enforce it. And so, I'd be interested in a survey that can't be done because this is all proprietary data. But what percentage of webhook integrations are unverified? Is it 50%? Is it 10%? Is it 100%? It's definitely not 100. But it's somewhere in there that I find interesting. It's not a terribly exploitable vulnerability because you have to have deep knowledge of the system. In order to take advantage of it, you need to know what endpoint to hit to, what shape of data to send because otherwise, you're probably just going to cause an error or get a bunch of 404s. But like, it's, I don't know, it's discoverable. And yeah, it's an interesting one. So I will hop off my webhook soapbox now, but that's a thought. MIDROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half. So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! CHRIS: But now that I'm off my soapbox, I believe we have a topic that was suggested. Do you want to provide a little bit of context here, Steph? STEPH: Yeah, I'd love to. So this came up when I was having a conversation with another thoughtboter. And given that we change projects fairly frequently, on the Boost team, we typically change projects around every six months. They asked a really thoughtful question that was "How do you get acquainted with a new codebase? So given that you're changing projects so often, what are some of the tips and tricks for ways that you've learned to then quickly get up to speed with a new codebase?" Because, frankly, that is one of the thoughtbot superpowers is that we are really good at onboarding each other and then also getting up to speed with a new team, and their processes, and their codebase. So I have a couple of ideas, and then I'd love to hear some of your thoughts as well. So I'll dive in with a couple. So the first one, this one's frankly my favorite. Like day one, if there's a team where I'm joining and they have someone that can walk me through the application from the users' perspective, maybe it's someone that's in sales, or maybe it's someone on the product team, maybe it's a recording that they've already done for other people, but that's my first and favorite way to get to know an application. I really want to know what are users experience as they're going through this app? That will help me focus on the more critical areas of the application based on usage. So if that's available, that's fabulous. I'm also going to tailor a lot of this more to like a Rails app since that's typically the type of project that I'm onboarding to. So the other types of questions that I like to find answers to are just like, what's my top-level structure? Like to look through the app and see how are things organized? Chris, you've mentioned in a previous episode where you have your client structure that then highlights all the third-party clients that you're working with. Are we using engines in the app? Is there anything that seems a bit more unique to that application that I'm going to want to brush up on or look into? What's the test coverage like? Do they have something that's already highlighting how much test coverage they have? If not, is there something that then I can run locally that will then show me that test coverage? I also really like to look at the routes file. That's one of my other favorite places because that also is very similar to getting an overview of the product. I get to see more from the user perspective. What are the common resources that people are going to, and what are the domain topics that I'm working with in this new application? I've got a couple more, but I'm going to pause there and see how you get acquainted with a new app. CHRIS: Well, unsurprisingly, I agree with all of those. We're still searching for that dare to disagree beyond Pop-Tarts and IPAs situation. To reiterate or to emphasize some of the points you made, the sales demo thing? I absolutely love that one because, yes, absolutely. What's the most customer-centric point of view that I can have? Can I then login to a staging version of the site so I can poke around and hopefully not break anything or move real money or anything like that? But understanding why is this thing, not in code, but in actual practical, observable, intractable software? Beyond that, your point about the routes, absolutely, that's one of my go-to's, although the routes there often is so much in the routes, and it's like some of those may actually be unused. So a corollary to the routes where available if there's an APM tool like Scout, or New Relic, or something like that, taking a look at that and seeing what are the heavily trafficked endpoints within this app? I like to think about it as the entry points into this codebase. So the routes file enumerates all of them, but some of them matter, and some of them don't. And so, an APM tool can actually tell you which are the ones that are seeing a ton of traffic. That's a really interesting question for me. Similarly, if we're on Heroku, I might look is there a scheduler? And if so, what are the tasks that are running in the background? That's another entry point into the app. And so I like to think about it from that idea of entry points. If it's not on Heroku, and then there's some other system, like, I've used Cronic. I think it's Cronic, Whenever the Cron thing. Whenever, that's what it is, the Whenever gem that allows you to implement that, but it's in a file within the codebase, which as an aside, I really love that that's committed and expressive in the code. Then that's another interesting one to see. If it's more exotic than that, I may have to chase it down or ask someone, but I'll try and find what are all of the entry points and which are the ones that matter the most? I can drill down from there and see, okay, what code then supports these entry points into the application? I want to give an answer that also includes something like, oh, I do fancy static analysis in the codebase, and I do a churn versus complexity graph, and I start to...but I never do that, if we're being honest. The thing that I do is after that initial cursory scan of the landscape, I try and work on something that is relatively through the layers of the app, so not like, oh, I'll fix the text in a button. But like, give me something weird and ideally, let me pair with someone and then try and move through the layers of the app. So okay, here's our UI. We're rendering in this way. The controllers are integrated in this way, et cetera. This is our database. Try and get through all the layers if possible to try and get as holistic of a view of how the application works. The other thing that I think is really interesting about what you just said is you're like, I'm going to give some answers that are somewhat specific to a Rails app. And that totally makes sense to me because I know how to answer this in the context of a Rails app because those organizational patterns are so useful that I can hop into different Rails apps. And I've certainly seen ones that I'm like, this is odd and unfamiliar to me, but most of them are so much more discoverable because of that consistency. Whereas I have worked on a number of React apps, and every single one I come into, I'm like, okay, wait, what are we doing? How are we doing state management? What's the routing like? Are we server-side rendering, are we not? And it is a thing that...I see that community really moving in the direction of finding the meta frameworks that stitch the pieces together and provide more organizational structure and answer more of the questions out of the box. But it continues to be something that I absolutely love about Rails is that Rails answers so many of the questions for me. New people joining the team are like, oh, it's a Rails app, cool. I know how to Rails, and we get to run with that. And so that's more of a pitch for Rails than an answer to the question, but it is a thing that I felt in answering this question. [laughs] But yeah, those are some thoughts. But interested, it sounds like you had some more as well. I would love to hear what else was in your mind when you were thinking about this. STEPH: I do. And I want to highlight you said some really wonderful things. One that really stuck out to me that I had not considered is using Scout APM to look at heavily-trafficked endpoints. I have that on my list in regards as something that I want to know what's my error tracking, observability. Like, if I break something or if you give me a bug ticket to work on, what am I going to use? How am I going to understand what's going wrong? But I hadn't thought of it in terms of seeing which endpoints are heavily used. So I really liked that one. I also liked how you highlighted that you wish you'd do something fancy around doing a churn versus complexity kind of graph because I thought of that too. I was like, oh, that would be such a nice answer. But the truth is I also don't do that. I think it's all those things. I think it would be fun to make it easy. So I do that with new applications. But I agree; I typically more just dive in like, hey, give me a ticket. Let me go from there. I might do some simple command-line checking. So, for example, if I want to look through app models, let's find out which model is the largest. I may look for that to see do we have a God object or something like that? So I may look there. I just want to know how long are some of these files? But I also don't use a particular tool for that churn versus complexity. CHRIS: I think you hit the nail on the head with like, I wish that were easier or more in our toolset. But here on The Bike Shed, we tell the truth. And that is aspirational code flexing that we do not yet have. But I agree, that would be a really nice way to explore exactly what you're describing of, like, who are the God models? I'll definitely do that check, but not some of the more subtle and sophisticated show me the change over time of all these...like nah, that's not what I'm doing, much as I would like to be able to answer that way. STEPH: But it also feels like one of those areas like, it would be nice, but I would be intrigued to see how much I use that. That might be a nice anecdote to have. But I find the diving into the codebase to be more fruitful because I guess it depends on what I'm really looking at. Am I looking to see how complicated of a codebase this is? Because then I need to give more of a high-level review to someone to say how long I think it's going to take for me to work on a particular feature or before I'm joining a team, like, who do I think are good teammates that would then enjoy working on this application? That feels like a very different question to me versus the I'm already part of the team. I'm here. We're going to have complexity and churn. So I can just learn some of that over time. I don't have to know that upfront. Although it may be nice to just know at a high level, say like, okay, if I pick up a ticket, and then I look at that churn and complexity, to be like, okay, my ticket falls right smack-dab in the middle of that. So it's going to be a fun first week. That could be a fun fact. But otherwise, I'm not sure. I mean, yeah, I'd be intrigued to see how much it helps me. One other place that I do browse is I go to the gem file. I'm just always curious, what do people have in their tool bag? I want to see are there any gems that have been pulled in that are helping the team process some deprecated behavior? So something that's been pulled out of Rails but then pulled into a separate gem. So then that way, they don't have to upgrade just yet, or they can upgrade but then still keep some of that existing old deprecated behavior. That kind of stuff is interesting to me. And also, you called it earlier pairing. That's my other favorite way. I want to hear how people talk about the codebase, how they navigate. What are they frustrated by? What brings them joy? All of that is really helpful too. I think that covers all the ways that I immediately will go to when getting acquainted with a new codebase. CHRIS: I think that covers most of what I have in mind, although the question is framed in an interesting way that I think really speaks to the consultant mindset. How do I get acquainted with a new codebase? But if you take the question and flip it around sort of 180 degrees, I think the question can be reframed as how does an organization help people onboard into a codebase? And so everything we just described are like, here's what I do, here's how I would go about it, and pairing starts to get to collaboration. I think we've talked in a number of episodes about our thoughts on onboarding and being intentional with that, pairing people up. A lot of things we described it's like, it's ideal actually if the organization is pushing this. And you and I both worked as consultants for long enough that we're really in the mindset of like, all right, let's assume I'm just showing up. There's no one else there. They give me a laptop and no documentation and no other humans I'm allowed to talk to. How do I figure this out and get the next feature out to production? And ideally, it's something slightly better than that that we experience, but we're ready for whatever it is. Versus, most people are working within the context of an organization for a longer period of time. And most organizations should be thinking about it from the perspective of how do I help the new hires come into this codebase and become effective as quickly as possible? And so I think a lot of what we said can just be flipped around and said from the other way, like, pair them up, put them on a feature early, give them a walkthrough of the codebase, give them a sales-centric demo. Yeah, I feel equally about those things when said from the other side, but I do want to emphasize that this shouldn't be you're out there in the middle of the jungle with only a machete, and you got to figure out this codebase. Ideally, the organization is actually like, no, no, we'll help you. It's ours, so we know it. We can help you find the weird stuff. STEPH: That's a really nice distinction, though, because you're right; I hadn't really thought about this. I was thinking about this from more of the perspective of you're out in the jungle with a machete, minus we did mention pairing in there [laughs] and maybe a demo. I was approaching it more from you're isolated or more solo and then getting accustomed to the codebase versus if you have more people to lean on. But then that also makes me think of all the other processes that I didn't mention that I would include in that onboarding that you're speaking of, of like, how does this team work in terms of where do I push my code? What hooks are going to run? And then what do I wait for? How many people need to review my code? There are all those process-y questions that I think would ideally be included on the onboarding. But that has happened before, I mean, where we've joined projects, and it's been like, okay, good luck. Let us know if you need anything. And so then you do need those machete skills to then start hacking away. [laughs] CHRIS: We've been burned before. STEPH: They come in handy. [laughs] So when you are in that situation, and there's a comet that's coming to destroy earth, and there's a Rails application that is preventing this big doomsday, the question is, do you take astronauts and train them to be Rails experts, or do you take Rails developers and train them to be astronauts? I think that's the big question. CHRIS: What would Michael Bay do? STEPH: On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Chris is getting ready to travel, and of course, Sagewell started the day with an incident, a situation, if you will... Steph talks books perfect for vacations and feels sufficiently scarred regarding still working with moving fixtures over to FactoryBot. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Back to Basics: Boolean Expressions (https://thoughtbot.com/blog/back-to-basics-booleans) Sarah Drasner tweet (https://twitter.com/sarah_edo/status/1538998936933122048) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: All right, I am now officially recording as well. Let me make sure my microphone is in front of my face. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: What's new in my world? Today is an interesting day. We are recording on a Friday, which is not normal for us, was normal for a long time and then stopped, but now it's back to being normal. But it's the morning, which is confusing. Also, I am traveling this evening. I leave on a flight going to Europe. So I'm going to do a red-eye, that whole thing. So I got a lot to pack into today, literally packing being one of those things. And then this morning, because obviously, this is the way the world should play out, we started the day with an incident at Sagewell, a situation. Some code had gotten out there that was doing some stuff that we didn't want it to do. And so we had to sort of call in the dev team. And we all huddled together and tried to figure it out. Thankfully, it was a series of edge cases. It was sort of one of those perfect storms. So when this edge case happens in this context, then a bad thing could happen. Luckily, we were able to review the logs; nothing bad happened. While I'm unhappy that we had this situation play out... basically, it was a caching thing, just to throw that out there. Caching turns out to be very hard. And the particular way it played out could have manifested in behavior that would have been not good in our system, or an admin would have inadvertently done something that would have been incorrect. But on the positive side, we have an incident review process that we've been slowly incubating within the team. One of our team members introduced it to us, and then we've been using it on a few different cases. And it's really great to just have a structured process. I think it's one of those things that will grow over time. It's a very simple; what's the timeline of what happened? What's the story as to why it happened and why it wasn't caught earlier? What are the actions that we're going to take? And then what's the appendix? What's the data that we have around it? And so it's really great to just have that structure to work within. And then similarly, as far as I can tell, the first even observable instance of this behavior in our system was yesterday morning. We saw it, started to respond to it, saw one more. We were able to chase it down in the logs. Overall, the combination of the alerting that we have in Sentry and the way in which we respond to the alerting in Sentry, which I think is probably the most critical part. Datadog is our log metrics tool right now. So we're able to go through Datadog, and we have Lograge configured to add more detail to our log lines. And so we're able to see a very robust story of exactly what happened and ask the question, did anything actually bad happen? Or was it just possible that something bad could happen? And it turns out just possible. Nothing actually happened. We were able to determine that. We were even able to get a more detailed picture of who were all the users who potentially could have been impacted. Again, I don't think there was any impact. But all total, it was both a very stressful process, especially as I'm about to go on vacation. It's like, oh cool, start to the day where I'm trying to wrap up things, and instead, we're going to spend a couple of hours chasing down an incident. But that said, these things will happen. The way in which we were able to respond, the alerting and observability that we had in place make me feel good. STEPH: I like the incident structure that you just laid out. That sounds really nice in clarifying what happened when it happened in the logs. And the fact that you're able to go through and confirm if anything really bad happened or not is really nice. And I was also just debating this is one of those things, right? Right when you're about to go on vacation, that's when something's going to break. And that's like, is that good or bad? Is it good that I was here to take care of it right before, or is it bad? Because I'd really like to not be here to take care of it. [laughs] You may have mixed feelings. I have mixed feelings. CHRIS: I think I'm happy. Unsurprisingly, this exists in one of the most complex parts of our codebase. And it involves caching. And I remember when we introduced the caching, I looked at it, and I was like, hmm, we have a performance hotspot that involves us making a lot of requests to an external system. And so we thought about it a little bit, and we were like, well, if we do a little bit of caching here, we can actually reduce that down from seven calls down to one over external HTTP. And so okay, that seems to make sense. We had a pull request. We did a formal review. And even I looked at the pull request where this was introduced initially, and my comments on it were like, yep, this all looks good. Makes sense to me. But it's caching-related. So let's be very careful and look very closely at it and determine if there's anything, but it's so hard to know. And in fact, the code that actually was at play here was introduced a month ago. And interestingly, the observable side effect only occurred in the past two days, which we find very surprising. But again, it's this weird like, if A happens and then within a short period after that B happens...and so it's not quite a race condition. But it was something where a lot of stuff had to happen in a short span of time for this to actually manifest. And so, again, we were able to look through the logs and see all of the instances where it could have happened and then what did happen. Everything was fine, but yeah, it was interesting. I feel actually good to have seen it. And I think we've cleared everything up related to it and been very proactive in our response to it so that all feels good. And also, this is the sort of thing we've done this a few times now where we've had what I would call lesser incidents. There was no customer-facing impact to this. Similarly, previous incidents, we've had no or very minimal customer-facing impact. So at one point, we had a situation where we weren't processing our background jobs for a little while. So we eventually caught up and did everything we needed to. It just meant that something may not have happened in as timely a fashion as necessary. But there were no deep ramifications to that. But in each of those cases, we've pushed ourselves to go through the incident process to make sure that we're building the muscle as a team to like, actually, when the bad one comes, we want to be ready. We want to have done a couple of fire drills first. And so partly, I viewed this as that because again, there was smoke, but no fire is how we would describe it. STEPH: Nice. And that also makes sense to me how you were saying y'all introduced this about a month ago, but you were just now seeing that observable side effect. I feel like that's also how it goes. Like, you implement, especially with caching, some performance improvement, and then you immediately see that. And it's like, yay, this is wonderful. And then it's not til sometime passes that then you get that perfect storm of user interactions that then trigger some flow that you didn't consider or realize that could create an issue with that caching behavior. So yeah, that resonates. That seems right. All caching problems usually take about a month or two when you've just forgotten about what you've done. And then you have to go back in. CHRIS: Yep. Yep, yep, yep. So now we've done the obvious thing, which is we've removed every cache from the system whatsoever. There are no caches anymore because it turns out we just can't be trusted with caches in any form whatsoever. ActiveRecord, we turned off caching, Redis we threw it out. No, I'm kidding. We still have lots of caching in the app. But, man, caching is so hard. STEPH: I would love if that's in the project README where it says, "We can't be trusted with caches. No caches allowed." [laughs] CHRIS: Yeah, we have not gone all the way to forbid caching within the application. It's a trade-off. But this does have that you get those scars over time. You have that incident that happens, and then forever you're like, no, no, no, we can't do X. And I feel like I'm just a collection of those. Again, I think we've talked about this in previous episodes. But consulting for as long as I did, I saw a lot of stuff. And a lot of it was not great. And so I basically just look at everything, and I'm like, urgh, no, this will be hard to maintain. This is going to go wrong. That's going to blow up someday. And so, I'm having to work on trying to be a little more positive in my development work. But I do like that I have that inclination to be very cautious, be very pessimistic, assume the worst. I think it leads to safer code in general. There was actually a tweet by Sarah Drasner that was really wonderful. And it's basically a conversation between her and another developer. It's a pretend conversation. But it's like, "But why don't you like higher-order components?" And then it's Squints. "Well, in the summer of 2018, something bad happened, Takes a long drag of a cigarette. something very bad." It's just written so well and captures the ethos just perfectly. Like, sit down. Let me tell you a tale of the time in 2018. [laughs] So I'll include a link to that in the show notes because she actually wrote it so well too. It's got like scene direction within a tweet and really fantastic stuff. But yeah, we'll allow some caching to continue within the app. STEPH: That's amazing. So I was just thinking where you're talking about being more pessimistic versus optimistic. And there's an interesting nuance there for me because there's a difference in like if someone's pessimistic where if someone just brings up an idea and someone's like, "Nope, like, that's just not going to work," and they just always shoot it down, that level of being pessimistic is too much. And it's just going to prevent the team from having a collaborative and experimental environment. But always asking the question of like, well, what's the worst that could happen? And what are the things that we should mitigate for? And what are the things that are probably so unlikely that we should just wait and see if that happens and then address it? That feels like a really nice balance. So it's not just leaning into saying no to everything. But sure, let's consider all the really bad things that could happen, make a plan for those, but still move forward with trying things out. And I realized I do this in my own life, like when someone asks me a question around if there's something that we want to do that's a bit kind of risky. And the first thing I always think of is like, well, what's the worst that could happen? And I think that has confused people that I immediately go there because they think that I'm immediately saying no to the idea. And so I have to explain like, no, no, no. I'm very intrigued, very interested. I just have to think through what's the worst that can happen. And if I'm okay with that, then I feel better about accepting it. But my emotional state, I have to think through what's the worst and then go from there. CHRIS: Wow, it's a very bottom-up approach for your life planning there. [chuckles] STEPH: Yep, I think that's, you know, it's from being a developer for so long. It has impacted now how I make other decisions. Good or bad? Who knows? Yeah, it turns out being a developer has leaked into my personal life. I've got leaky abstractions over here. So, good or bad? Who knows? CHRIS: Leaky abstractions all the way down. Yeah, circling back to, like, I don't think I'm pessimistic per se. The way that I see this playing out often is there will be a discussion of an architectural approach, or there's a PR that goes up. And my reaction isn't no, or this has a known failure point; it is more of uh, this makes me uncomfortable. And it's that like; I can't even say exactly why, and that's what makes it so difficult. And I think this is a place that can be really complicated for communication, particularly between developers who have been around for a little bit longer and have done this sort of thing and have gathered these battle scars and developers who are a bit newer. Having that conversation and being like, um, I can't say exactly why. I can tell you some weird stories. I might not even remember the stories. Some of it just feeds into just like, does this code make me uncomfortable? Or does this code make me happy? And I tend towards wildly explicit code for these reasons. I want to make it as clear as possible and match as close as possible to the words that we're saying because I know that the bugs hide in the weird corners of our code. So I try and have as few corners. Make very rounded rooms of code is a weird analogy that doesn't play, but here we go. That's what I do on this show is I make weird analogies. Actually, we were working on some code that was dealing with branching conditional things. So we had a record which has a boolean value on it. So we've got true or false, and then we've got two states, and then we've gotten an enum with three states. So all total, we have six possible states. But as we were going through this conversation, I was pairing with another developer on the team. And I was like, something feels weird here. And I actually invoked the name of Joël Quenneville because much of the data structure thought that I had here I associate with work that Joël has done around Maybe and things like that. And then also, my suggestion was let's build a truth table because that seems like a fun way to manage this and look at it and see what's true. Because I know that there are spots on this two-by-three grid that should never happen. So let's name that and then put that in the code. We couldn't quite get it to map into the data type, like into that Boolean in the enum. Because it's possible to get into those states, but we never should. And therefore, we should alert and handle that and understand, like, how did this even happen? This should never happen. And so we ended up taking what was a larger method body with some of the logic in it and collapsing it down to very explicitly enumerate the branches of the conditional and then feed out to a method. Like, call a method that had a very explicit name to say, okay, if it's true and we're in this enum state, then it's bad, alert bad. And then the other case like, handle the good case. And I was very happy with what we refactored down to because this is another one of those very complex parts of our code. Critical infrastructure-y is how I would describe it. And so, in my mind, it was worth the I'm going to go with pathological refactoring that we got to there. But yes, I was channeling Joël in that moment. I'm very happy to have had many conversations with him that help me think through these things. STEPH: That's awesome. Yeah, those truth tables can be so helpful. There's a particular article that, of course, Joël has written that then describes how a truth table works and ways that you can implement it into your habits. It's called Back to Basics: Boolean Expressions. I will be sure to include a link in the show notes. CHRIS: But yeah, I think that summarizes my day and probably the next couple of days as I prepare for an adventure over to Europe and chat about developer spidey sense. But yeah, what's new in your world? STEPH: Yeah, that's a big day. There's a lot going on. Well, I actually want to circle back because you mentioned that you're packing and you're going on this trip. And I'm curious, do you have any books queued up for vacation? CHRIS: I do, yeah. I'm currently reading Elantris by Brandon Sanderson. Folks might be aware of his work from the highest-funded Kickstarter of all time, which was absurd. Did you see this happen? STEPH: I don't think so, uh-uh. CHRIS: He did this fun, cheeky little Kickstarter. The video was sort of a fake around...oh, it almost sounded like he might be retiring or something like that. And then he's like, JK, I wrote five new books. And so the Kickstarter was for those books with different tiered packages and whatnot. I think he got just the right viral coefficient going on. And apologies for the spoiler if anyone's not seen the video, but it's been out there for a while. So he wrote some books, and that's what the Kickstarter is for. You get some books. You sort of join a book club, and you'll get one a quarter. A million dollars seems like that will be a bunch for that. That'd be great. If he raised a million dollars, that'd be amazing. $40 million four-zero million dollars. [laughs] I'm just watching it play out in real-time as well. It just skyrocketed up. The video, I think, was structured just right. He got it onto the...it was on Reddit and Twitter and just bouncing around, and people were sharing it. And just everything about it seemed to go perfectly. And yes, the highest-funded Kickstarter of all time, I believe, certainly within the publishing world. But yeah, Brandon Sanderson, prolific author, and his stuff ends up just being kind of light and fun. And so I was reading Elantris for that. It's been a little bit slower to pick up than I would like. So I'm now in the latter half. I'm hoping it'll go a little bit more quickly and be...I'm just kind of looking for a fun read, some fantasy thing to go on an adventure. But as the next book, I downloaded a second one just to make sure I'm covered. I have a book by John Scalzi, who's a sci-fi, fantasy, more on the sci-fi end of the spectrum. And I've read some of his other stuff and enjoyed it. And this particular book has a very consistent set of reviews. I've read the reviews a few times. And everybody who reviews it is just like, "This isn't the greatest book I've ever read, but man was it a fun ride." Or "Yeah, no, best book? No. Fun book? Yes." And just like, "This book was a fun ride. This was great." And I was like, perfect. That is exactly what I'm looking for on a European vacation. The book is called The Kaiju Preservation Society, which also plays on monsters, Pacific Rim Godzilla. Kaiju, I think, is the word for that category of giant dinosaur-like monster. And so it's the Kaiju Preservation Society, which, I don't know, means some stuff, and I'm going to go on a fun adventure. So yeah, those are my books. STEPH: Nice. I've got one that I'm reading right now. It's called Clementine: The Life of Mrs. Winston Churchill, written by Sonia Purnell. And Sonia Purnell tends to focus on female historical figures. And so it's historical fiction, which is a sweet spot for me. The only thing I'm debating on is because I'm realizing as I'm reading through it, I'm questioning, okay, well, what's real and what's not? Because I don't want to be that person that's like, did you know? And then, I quote this fictional fact about somebody that was made up for the novel. [laughs] So I'm realizing that maybe historical fiction is fun, but then I'm having to fact-check all the things because then I'm just curious. I'm like, oh, did this really happen, or how did it go down? So it's been pretty good so far. But then it makes me wish that historical fiction novels had at the back of them they're like, these are all the events that were real versus some of the stuff that we fictionalized or added a little flair to. I'm in that interesting space. I also like how you highlighted that you chose a fun book. I was having a conversation with a colleague recently about downtime. And like, do you consume more tech during downtime? Like, are you actively looking for technical blog posts or technical books to read or podcasts, things like that? And I was like, I don't. My downtime is for fun. Like, I want it to be all the things that are not tech. Maybe some tech sneaks in there here and there, but for the most part, I definitely prioritize stuff that's fun over more technical content in my spare time, which has taken me a little while to not feel guilty about. Earlier in my career, I definitely felt like I should be crunching technical content all the time. And now I'm just like, nope, this is a job. I'm very thankful that I really enjoy my job, but it's still a job. CHRIS: It is an interesting aspect of the world that we work in where that's even a question. In my previous life as a mechanical engineer, the idea that I would go home and read about mechanical engineering...I could attend a conference, but I would do that for very particular reasons and not because, like, oh, it's fun. I'll go meet my friends. For me, this was a big reason that I moved into tech because I am one of those folks who will, like, I will probably watch a video about Remix in particular because that's my new thing that I like to play around with and think about. But it needs to be a particular shape of thing I've found. It needs to be exploratory, puzzle-y. Fun code, reading, learning work that I do needs to be separated from my work-work in a certain way. Otherwise, then it feels like work, then it is sort of a drudgery. But yeah, my brain just seems to really like the puzzle of programming and trying to build things. And being able to come into a world where people share as much as they do blogs and conference talks and all of that is utterly fantastic. But it is a double-edged sword because I 100% agree that the ability to disconnect to, like, work a nine-to-five and then go home at the end of the day. Yeah, go home, you know, because you remember when we went to an office and then we would go home afterwards? I have to commute every once in a while into the city and -- STEPH: You mean go downstairs or go to another room? That's what you mean? [laughs] CHRIS: I used to commute every day, and it took a lot of time. And now when I do it, I feel that so viscerally because I'm like, it's just a lot easier to just walk to my office in my house. But yes, I 100% I'm aligned to that like, yeah, no, you're done with work for the day, walk away. That's that. And learning a new technology or things like that, that's part of the job. There shouldn't be the expectation that that just happens. There's continuing education in every other field. It's like, oh, we'll pay for your master's degree so you can go learn a thing. That's the norm in every other...not in every other industry but many, many, many industries. And yet the nature of our world the accessibility of it is one of the most wonderful things about it. But it can be a double-edged sword in that if there are the expectations that, oh yeah, and then, of course, you're going to go home and have side projects and be learning things. Like, no, that is an unreasonable expectation, and we got to cut that off. But then again, I do do that. So I'm saying two things at the same time, and that's always complicated. STEPH: But I agree with what you're saying because you're basically respecting both sides. If people enjoy this as a hobby, more power to you.; that's great. This is what you enjoy doing. If you don't want to do this as a hobby and respect it as a job, then that's also great too. There can be both sides, and no side should feel guilty or judged for whichever path that they pursue. And I absolutely agree, if there are new skills that you need to learn for a job, then there should be time that's carved out during your work hours that then you get to focus on those new skills. It shouldn't be an expectation that then you're going to work all day and then spend your evening hours learning something else. And same for interviews; there shouldn't be a field that says, "Hey, what are your side projects?" Or at least that should not be an important part of the interview. There should be an alternative to be like, "Or what work code do you want to talk about?" Or something else that's more in that nine-to-five window that you want to talk about. That way, there's a balance between like, sure, if you have something that you want to talk about on the side, great, but if not, then let's focus on something that you've done during your actual work hours because that's more realistic. CHRIS: I do think there's an interesting aspect at play because the world of development moves so rapidly and because it's constantly changing. And to frame it differently, I don't think we've got this thing figured out. And so many people lament how quickly it changes and that there's a new framework every other week. And there's a bit of churn that is perhaps unnecessary. But at the same time, I do not feel like as a community, as a working population, that we're like, yeah, got it, crushed it. We know how to make great software, no question about it. It's going to be awesome. We're going to be able to maintain it for forever, don't even worry about it. New feature? We can get that in there. They're actually still pretty rare. So we need to be learning, and evolving, and exploring new techniques. I think the amount of thinking is probably good mostly in the development world. But organizations have to make space for that with their teams. And thoughtbot obviously does that with investment days. That's just such a wonderful structure that embraces that reality and also brings happiness, and it's just a pleasant way to work. And frankly, my team does not have that right now. We do the crispy Brussels snack hour, which also now has a corresponding crispy Brussels work lunch, which is one week we think about it, and the next week we do the thing. We're trying to make space for that. But even that is still more intentional and purposeful and less exploratory and learning. And so it's an interesting trade-off. I deeply believe in this thing, and also, the team that I'm leading isn't doing it right now. Granted, we're an early-stage startup. We got to build a bunch of stuff. I think that's fine for right now. But it is a thing that...again, I'm saying two things at the same time, always fun. STEPH: Well, and there might be a nice incremental approach to this as well. So thoughtbot has the entire day, and maybe it's less than a full day. So perhaps it's just there's an hour or two hours or something like that where you start to introduce some of that self-improvement time and then blossom out from there. Because yeah, I understand that not all teams may feel like they have the space for that. But then I agree with everything else you said that it really does improve team morale and gives people a space to then be able to get to explore some of those questions that they had earlier. So then they don't feel like they have to then dedicate some weekend time or off hours' time to then look into a question. And I admit, I'm totally guilty too. I am that person that then I've worked extra hours, but it's because, like you said, if there's a puzzle that my brain is stuck on and I just feel the need to get through it. But then I look at that as am I doing this because I want to? Yes. Okay, then as long as I'm happy and I don't feel like this is increasing any concern around burnout, then I don't worry about it. MIDROLL AD: Debugging errors can be a developer's worst nightmare… but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! Circling back to your original question about what's going on in my world, and you mentioned scarring earlier. I feel sufficiently scarred [laughs] in regards to still working with moving fixtures over to FactoryBot. This week has really confirmed that fixtures don't trigger a lot of the callbacks, the model callbacks that exist. And so this really means that you can just create bad data that your application doesn't actually allow your application to create. So there are tests that are exercising behavior that should never exist. And then porting that over to FactoryBot then highlights that because then as soon as I move that record over and then try to create it or do something with it, then the app, the test, do the right thing and let me know saying no, no, no, we've added validations. You can't do that anymore. That has been grinding my gears in terms of trying to then translate. Because then I have to really dive into the code to understand it. And the goal here is to stay as high level as possible and not have to dive in too much. But then that means that I do have to dive in and understand more. So this has frankly just been one of those times in my career where you just kind of have to slog through the work. It's important work to be done. It'll be great once it's done. But it's a painful process. And the best way that I've found to make it more enjoyable is to be in heavy communication with Joël, who's on the project with me, just so if we get stuck on something, then we can chat with each other. And then also there's one file that's particularly gnarly. And so we moved over one test. We were successful, and which felt great because then we could at least document like, okay, when we come back to this, at least we have one example that highlights the wonkiness that we ran into. But we've decided, okay, we're done with that file. We're going to take a break. There's a lot there, but we're going to move on and give ourselves a break and do some of the easier ones, and then we'll circle back to the harder one. Which was, I think, just a bit of bad luck in terms of, like, as we're going down the list, that happened to be like the gnarliest one, and it was like the first one that Joël picked up. And so I'm going through a couple of files, and Joël is like, "What? [laughs] How are you making progress?" And we realize it's just because that file, in particular, is very hard to find all the mystery guests and then to move everything over. Finding a positive note through all of the cruft, I will say this is helping with some of my code sleuthing skills. So as I am running into these problems and then looking for mystery guests, I'm noticing ways that I can then, as quickly as possible, try to triage and identify as to why one test doesn't match another test. Some of it is more specific to the application setup, so it won't be as applicable to future projects. But then some other areas have been really helpful. Like, I'm using caller a lot more to understand, like, I know this is getting called, but I don't know who's calling you. So I can put in a line that basically outputs like, show me your stack traces to how you got here. So that's been really nice as well. So it has improved some of my code sleuthing skills and also my spidey sense in terms of it's typically mystery guests. Like when a test isn't passing, it's because fixtures are creating extra data that are getting pulled in when there are queries that are being run. But they're not explicitly referenced in the test setup itself. So that's typically then where I start is looking for what record looks relevant to this test that I haven't pulled over to my test setup. CHRIS: I appreciate you finding the silver lining, the positive bit of this. Because as you're describing, the work that you're doing sounds like I think you use the word slog, which seems like a very accurate term. But sometimes we have to do that sometimes for a variety of reasons. We end up either having to introduce new code or fix old code, but this is sometimes the work. And this is something that I think you and I share about this show is we get to show all sides of the work. And the work can be glamorous and new. And oh, I've got this greenfield app that I'm building, and it's wonderful. Look at the architecture. And I know in the moment that I'm building someone else's legacy code three years from now. [laughs] And so telling the other side of the story and providing that rounded point of view, because like, yeah, this is all part of it. Again, I don't believe that this is a solved problem, building robust software that we can maintain. And so yeah, you're doing the good work in there. And I thank you for sharing it with us. STEPH: Thanks. Just don't use fixtures in your test, I beg of you. Please don't do that to the legacy code that you're writing for future developers. [laughs] That is my one request. CHRIS: And I will maybe add on to that, sparingly use callbacks. Maybe don't use them at all, and certainly don't use the combination because, my goodness, that'll lead you into some fun times. But yeah, just two small recommendations there. STEPH: Oh, there's something else I wanted to share. I saw that Slack added a new audio feature that allows you to record the pronunciation of your name, which is the feature that I was so excited about when we added it to our internal tool called Hub at thoughtbot. And now Slack has it on their profile so that way you can upload the pronunciation. And then anyone looking at your profile can then listen to how to pronounce your name. There are a couple of other features that they released, I think just in June, so about a month ago from the recording of today. [laughs] That's weird to say, but here we are. So I'll include a link in the show notes so folks can see that feature in addition to others, but I'm super excited. CHRIS: Oh, that is nice. I also like all right, so Slack now has it. Hub now has it. But I don't have access to Hub anymore. And I don't have access to every Slack in the world yet. But here's my suggestion. All right, everybody, stick with me here. I want you to own a domain. I want you to have a personal site on it. And I want the personal site to include the pronunciation of your name. I get that that's a big ask. And I get that there are other platforms that are calling to you, and you may be writing on those. But you know what? Just stand up a little site, just a little place on the internet that you own. And if it includes the pronunciation of your name, I will be forever grateful. STEPH: I like this idea. I initially was taking your idea and immediately running with it as you were speaking it because then I wondered if everyone had their own YouTube channel. But I don't know how hard it is to create a YouTube channel. I am not a YouTube channeler, so I don't know what that looks like. [laughs] But not everybody will know how to purchase a domain. So that might be another approach. CHRIS: I think it's pretty easy to do a YouTube channel. I'm conflating a couple of things. This is my basket of beliefs about people on the internet, but I kind of think everybody should own their own little slice of the internet. And so totally, YouTube is a place where the people make some stuff, make videos, put them on YouTube, absolutely. But ideally, you own something. I see a lot of people that are on YouTube, and that's it, and so their entire audience lives on YouTube. And if YouTube someday decides to change or remove them or say Medium as an example, Medium actually, I think, does a more interesting version of this where your identity kind of gets subsumed into Medium. And I really think everybody should just have their own little, tiny slice of the internet that's there. It has their name that they own that no platform can decide; hey, we've shifted, and now your stuff is gone. Cool URIs don't change as they say, and that's what I want. And then yeah, if you can have the pronunciation of your name on there, that's extra nice. Although I say that, and I don't know that I would do it because my name feels very obvious. One day someone was like, "Oh, how do you pronounce your last name?" I forget if I actually replied with the pronunciation. Or if I was like, "I need to know what options you're considering. I'm so interested because I've really only got the one." Maybe I'm anchored. Maybe I'm biased. [chuckles] I've been doing this for a while. But I really cannot think of another pronunciation of my name. STEPH: You might hear another one that you really like, and you need to pivot. CHRIS: Oh gosh. STEPH: That's the point where you start pronouncing your name differently. CHRIS: Wow, that would be a lot. And then, I could have a change log on my personal site where people can see this is the pronunciation, and this is what the pronunciation used to be. STEPH: [laughs] I like this idea. I also like this idea that everybody has their own slice of internet land. I like this encouragement that you're providing for everyone. On a slightly different note, there's a blog post that I'm really excited to talk about. It's written by Eric Bailey, who's a former thoughtboter. It's called The Optics of Pair Programming. And given how much pair programming that I'm doing, especially with Joël on the current project, it was a really wonderful read. And it also helped me think about pairing from a different perspective because we do have a very strong pairing culture at thoughtbot. So there's a lot of nuance, especially social nuances that can go along with when you invite someone to pair with you that I had not considered until I read this wonderful post by Eric. And we'll be sure to include a link in the show notes. But to provide an overview, essentially, Eric shares that given coming from thoughtbot where we do have a very open approach to pairing where pairing sessions are voluntary and then also last as long as the problem will last...but then when you're at a new company, you could experience pushback if you're inviting someone to pair and then to consider why that pushback may exist. And some of the high-level areas that Eric highlighted are power dynamics, assessment, privacy, and learning styles. So to dive into each of some of those, there's a power dynamics of it's important to consider who's offering to pair. So if I've joined a team as a consultant, there may be a power dynamic there that someone is feeling where their team is paying for my time. So they may feel like they can't say no if I offered to pair. They feel like they need to say yes to the invitation, even if they don't really want to. Or probably a more classic example would be like, what if your boss wants to pair or someone that's just more senior than you? Then it could leave you feeling like, well, I can't say no to this person, can I? Which yes, you totally can say no to that person, but it may leave you in a place where you feel like you can't. And so, it puts you in this sort of uncomfortable and powerless position. The other one is assessment, so offering to pair with someone could feel like you are implying that you want to assess their skills or that you're implying that they're not up to the task and therefore they need your help. So then that could also place someone in an uncomfortable position. There's also privacy. So someone who isn't confident may not want someone to observe their behavior or observe how they're working. It could make them feel really anxious, which then I love that Eric points this out. Ironically, pairing is really good at addressing that lack of confidence because then you get to see how other people work through their problems or how they think, or they may also have some anxiety. Or it just helps you become more comfortable in talking and thinking through with other people. So that one is a tough one where it's hard to get over that initial hurdle. But actually, the more you pair, then the less anxious you'll feel when you pair. And then there's also learning styles because pairing really involves a lot of deep thinking but in our personal time. And it can be hard to balance both of those, and it's just not as effective for some people. So I know that even as much as I really enjoy pairing, I just need to sit with code on my own sometimes. I need to think about it. I need to run it; I need to look at it. So it's really nice to talk with someone. But then I also need that alone time to then just think through it on my own because I can't have that same deep focus if I'm also worried about how the other person is experiencing that session because then my mental energy is going towards them. So that covers a number of the social nuances that can be included or running through someone's mind when you extend an invitation to them to pair. And it really resonated with me the areas that Eric highlights in this blog post. He also talks about a couple of strategies, which I'd love to dive into as well. But I'm going to pause here and see what thoughts you have. CHRIS: Yeah, I love this post. And it got me thinking about pairing and the broader human backdrop of all of the processes and workflows that we have. Everything he highlighted about pairing feels true. Although similar to you and to Eric, I've worked in a context where pairing was a very natural, very regular part of the work and sort of from the very top-down. And so everyone pairing between developers of any different level or developers and designers or really anyone in the...it was just such a part of how we worked that no one really questioned it or at least not after the first couple of weeks. I imagine joining thoughtbot those first weeks; you're like, oh God. As I shared, I think in the previous episode that we recorded, my pairing interview was with Joe Ferris, the CTO of thoughtbot, [laughs] writing a book about good and bad code. And I was like, I don't know what anything is here but very quickly getting over that hurdle. And having that normalizing experience was actually really great, and then have been comfortable with it since. But the idea that there are so many different social dynamics at play feels true. And then as I think about other things, like stand-up is one that I think of as this very simple this is a way to communicate where we're at. And where necessary or where useful, allow people to interject or step in to say, "Oh, let me help you get unblocked there or whatever it is." But so often, I see stand-up being a ritual about demonstrating that you are, in fact, doing work, which is like, here's what I did yesterday. I don't know if it's useful. Then mention that you're working on this project. But the enumeration of look, obviously, work was done by me. You can see it; here are the receipts. It's very much this social dynamic at play. And retro is another one where like, if retro is very much owned by one voice and not a place that change actually happens where people feel safe airing their opinions or their concerns, then it's going to be a terrible experience. But if you can structure it and enforce that it is a space that we can have a conversation, that everyone's voice is welcome and that real change happens as a result of, then it's a magical tool for making sure we're doing the right things. But always behind these are the people, and feelings, and the psychology at play. And so this was just such an interesting post to read and ruminate on that a little bit more. STEPH: Yeah, I agree, especially with a comment that you made about those daily syncs where I really just want to focus on today and what you have that you're blocked on. So it's a really nice update in case there are any cross-collaboration opportunities. That's really what I'm looking for in a daily update. And so I appreciate when people don't go through a laundry list of what they did yesterday because it's like, that's great. But then, like you said, it's just like you're trying to prove here's what I've done, and I trust you; you're working. So just let me know what you're doing today, friend. So Eric does a wonderful job of also including some strategies for ways that then you can address some of these concerns and then how there may be some extra anxiety that's increased when you're inviting somebody to pair. There are some wonderful strategies. I'll let folks read through the blog post itself. There are a couple in particular that came to mind for me because I was then self-assessing how do I tend to approach pairing with someone? And some ways that I want them to feel very comfortable with that experience. And there's a couple. There's one where I recognize that I need to build trust with each person. I can't just go on to a team and expect everyone to know that I have good intentions and that I'm going to do my best to be a fun, helpful pairing partner, and that it's not a zone of judgment. And that has to be cultivated with each person. Because especially as a consultant, if I'm joining a team, the people who hired me are not necessarily the people that I'm working with. It's someone that's probably in leadership or management that has then brought on thoughtbot. And so then the people that I'm working with they don't know me, and they don't know what my pairing style is going to be. So looking for ways to build trust with each person and then also inviting them or asking for help myself. So there's a bit of vulnerability that has to be shown to build trust with someone to say," Hey, I'm stuck on a problem. I would love a second set of eyes. Would you be willing to help me out with this?" So then that way, they're coming in to help me initially versus I'm going in and saying, "Hey, can I help you?" I have found that to be an effective strategy. And there's one that I do really want to talk about, and that's not everyone is going to pair well together. Like, you may find someone who always leaves you feeling just stressed or demoralized. And while it's important to consider your role and why that's true, that does not mean it's your fault and necessarily your problem to fix. So similar to having to manage up, you may need to coach the person that you're pairing with in ways that help you feel comfortable pairing. But if they don't listen to your requests and implement any of that feedback, then just don't pair with that person. That is a very fine option to recognize people that are not receptive to your needs and, therefore, not someone that you need to then force into being a great pairing buddy. And I emphasize that last one because it took me a little while to become comfortable with that and accepting that it wasn't my fault that I wasn't having a great pairing session with people. Similar to when I'm learning from someone that if someone is explaining something to me and they're making me feel inadequate while they're explaining it to me, that's not necessarily my fault. Like, I used to internalize that as like, oh, I just can't get this. But I am now a very staunch believer in if you can't explain it to me in a way that I understand, then that's probably more on you than on me. And that has also taken me time to just really accept and embrace. But once you do, it is so freeing to realize that if someone's explaining a concept and you're still not getting it, it's like, hey, how can we try harder together versus you just making me try harder? CHRIS: I like that right there of like, if I don't understand this, it may actually be you, not me, or something to that effect. Let's get that on a bumper sticker and put that in The Bike Shed store so that everybody can buy it and put it on their cars or at least just us. But yeah, that starting from the bottom sometimes it's just not going to work great. There are even...I think what you're describing sounds a little more complicated, individuals who are personally not great at communicating or pairing or things like that. And that's going to happen. We're going to run into folks that...pairing is communication. That's just the core of it, and some folks, that may not be their strongest suit. But I think there's another category of just like different working styles. And whereas I might...judge is such a heavy word, but I'm going to use it. I might judge someone who is not doing a great job at communicating to someone else, or understanding their point of view, or striving to do that, or taking feedback. Like, those are not great things. Whereas there may just be two different development styles or backgrounds, or there are other reasons that actually they may be not an ideal fit. That said, I have definitely found that in almost every variation of pairing, I've seen work at some point. Like, when I was very early on in my career pairing with folks that are very senior, I didn't get most of it, but I got some stuff. And then folks that are very much on the same level or folks that have a deep knowledge in framework, code base language, whatever and folks that are new to it but have a different set of experiences. Basically, every version of that, I found that pairing is actually an incredibly powerful technique for knowledge sharing, for collaboration, for all of that. So although there are rare cases where there might be some misalignment, in general, I think pairing can work. I do think you hit on something earlier of there are certain folks that are more private thinkers, is how I would describe it, where thinking out loud is complicated for them. I'm very much someone who talks. That's how I figure out what I think is I say stuff. And I'm like, oh, I agree with what I just said. That's good. But I find I actually struggle. There's something I think of...maybe I'm just a loudmouth is what I'm hearing as I say it, but that is how I process things. Other folks, that is not true. Other folks, it's quite internal, and actually trying to vocalize that or trying to share the thought process as they're going may be uncomfortable. And I think that's perfectly reasonable and something that we should recognize and make space for. And so pairing should not be forced upon a team or an individual because there are just different mindsets, different ways of thinking that we need to account for. But again, the vast majority of cases...I've seen plenty of cases where it's someone's like, "I don't like to pair. That's not my thing." And it's actually that they've had bad experiences. And then when they find a space that feels safe or they see the pattern demonstrated in a way that is collegial, and useful, and friendly, then they're like, oh, actually, I thought I didn't like pairing. I thought I didn't like retro. I thought I didn't like stand-up. But actually, all of these things can be good. STEPH: Yeah, absolutely. It's a skill like anything else. You need to see value in it. And if you haven't seen value in it yet or if it's always made you anxious and uncomfortable, then it's something that you're going to avoid as much as possible until someone can provide a valuable, positive experience around how it can go. I'm going to pull back the curtains just a little bit on our recording and share because you've mentioned that you are very much you think out loud, and that's how you decide that you agree with yourself. And I think already at least twice while we've been recording this episode, I have started to say something, and I'm like, no, wait, I don't agree with that and have backed myself up. CHRIS: [laughs] STEPH: And I'm like, no, I just thought through it; I'm going to cancel it out, [laughs] and then moved in a different direction. So I, too, seem to be someone that I start to say things, and I'm like, oh, wait, I don't actually agree with what I just said [laughs], so let's remove that. CHRIS: Yep. You've described it as Michael Scott-ing on a handful of different episodes or maybe things that were cut from episodes. But where you start a sentence and then you're like, I don't know where I was going to end up there. I hoped I'd figure it out by the end, but then I did not get there. And yeah, I think we've all experienced that at various times. STEPH: That's some of my favorite advice from you is where you've been like, just lean into it, just see where it goes. Finish it out. We can always take it out later. [laughs] Because I stop myself because I immediately start editing what I'm trying to say and you're like, "No, no, just finish it, and then we'll see what happens." That's been fun. CHRIS: This is how you find out what you think. You say it out loud, and then you're like, never mind. That was ridic – STEPH: [laughs] CHRIS: I do. Actually, now I'm thinking back, and I have plenty of those where I'll say a thing, and I'm like, nope, never mind, send that one back. [chuckles] As an aside, so we do this thing where we host a podcast, and we get to talk. But we're both now describing the pattern where we'll start to say something, and we'll be like no, no, no, actually, not that. And I think, dear listeners out there, you probably don't hear any of this, the vast majority of it, because we have wonderful editors behind the scenes, Thom Obarski for many years, and now Mandy Moore, who's been with us for a while. And so once again, thank you so much to the editor team that allows us to, I think, again, feel safe in this conversation that we can say whatever feels true and then know that we'll be able to switch that around. So thank you so much to the editors who help us out and make us sound better than we are. STEPH: Yeah, that has made a big difference in my capabilities to podcast. If we were doing this live, ooh goodness, this might be a whole different, weird show. [laughs] CHRIS: I mean, the same is true for code, right? I deeply value the ability to make an absolute mess in my local editor and have nine different commits that eventually I throw two out. And then I revert that file, and then eventually, the PR that I put up that's my Instagram selfie. That's like, I carefully curated this, but what's behind the scenes it's just a pile of trash. So yeah, the ability to separate the creation and the editing that's a meaningful thing to have in life. STEPH: Oh, I can't unsee that now. [laughs] A pull request is now the equivalent of that curated Instagram selfie. That is beautiful. [laughs] CHRIS: To be clear, I don't think I've ever taken an Instagram selfie. But I get the idea, and I felt like it was an analogy that would work. Again, I try out analogies on this show, and many of them do not stick. But I think that one is all right. STEPH: It might even go back to pairing because then you've got help in taking that picture. So hey, you're making a mess with somebody until you get that right perfect thing, and then you push it up for the world to see. So safe spaces for all the activities, I think that's the takeaway. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph has an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. Chris got to do something exciting this week using dry-monads. Success or failure? This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. Bartender (https://www.macbartender.com/) dry-rb - dry-monads v1.0 - Pattern matching (https://dry-rb.org/gems/dry-monads/1.0/pattern-matching/) alfred-workflows (https://github.com/tupleapp/alfred-workflows/blob/master/scripts/online_users.rb) Raycast (https://www.raycast.com/) ruby-science (https://github.com/thoughtbot/ruby-science) Inertia.js (https://inertiajs.com/) Remix (https://remix.run/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. Flaky tests slow everyone down, break your flow, and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start? BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. STEPH: What type of bird is the strongest bird? CHRIS: I don't know. STEPH: A crane. [laughter] STEPH: You're welcome. And on that note, shall we wrap up? CHRIS: Let's wrap up. [laughter] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris, I saw a good movie I'd like to tell you about. It was just over the weekend. It's called The Duke, and it's based on a real story. I should ask, have you seen it? Have you heard of this movie called The Duke? CHRIS: I don't think so. STEPH: Okay, cool. It's a true story, and it's based on an individual named Kempton Bunton who then stole a particular portrait, a Goya portrait; if you know your artist, I do not. But he stole a Goya portrait and then essentially held at ransom because he was a big advocate that the BBC News channel should be free for people that are living on a pension or that are war veterans because then they're not able to afford that fee. But then, if you take the BBC channel away from them, it disconnects them from society. And it's a very good movie. I highly recommend it. So I really enjoyed watching that over the weekend. CHRIS: All right. Excellent recommendation. We will, of course, add that to the show notes mostly so that I can find it again later. STEPH: On a more technical note, I have a small update, or it's more of a question. It's an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. This has been quite a journey that Joël and I have been on for a while now. And we're making progress, but we're realizing that we're spending like 95% of our time in the test setup and porting that over, specifically because we're mapping fixture data over to FactoryBot, and we're just realizing that's really painful. It's taking up a lot of time to do that. And initially, when I realized we were just doing that, we hadn't even really talked about it, but we were moving it over to FactoryBot. I was like, oh, cool. We'll get to delete all these fixtures because there are around 208 files of them. And so that felt like a really good additional accomplishment to migrating the test over. But now that we realize how much time we're spending migrating the data over for that test setup, we've reevaluated, and I shared with Joël in the Slack channel. I was like, crap. I was like, I have a bad idea, and I can't not say it now because it's crossed my mind. And my bad idea was what if we stopped porting over fixtures to FactoryBot and then we just added the fixtures to a directory that RSpec would look so then we can rely on those fixtures? And then that way, we're literally then ideally just copying over from Test::Unit over to RSpec. But it does mean a couple of things. Well, one, it means that we're now running those fixtures at the beginning of RSpec test. We're introducing another pattern of where these tests are already using FactoryBot, but now they have fixtures at the top, and then we won't get to delete the fixtures. So we had a conversation around how to manage and mitigate some of those concerns. And we're still in that exploratory. We're going to test it out and see if this really speeds us up referencing the fixtures. The question that's wrapped up in this is there's something different between how fixtures generate data and how factories generate data. So I've run into this a couple of times now where I moved data over to just call a factory. But then I was hitting these callbacks or after-save-hooks or weird things that were then preventing me from creating the record, even though fixtures was creating them just fine. And then Joël pointed out today that he was running into something similar where there were private methods that were getting called. And there were all sorts of additional code that was getting run with factories versus fixtures. And I don't have an answer. Like, I haven't looked into this. And it's frankly intentional because I was trying hard to not dive into understanding the mechanics. We really want to get through this. But now I'm starting to ponder a little more as to what is different with fixtures and factories? And I liked that factories is running these callbacks; that feels correct. But I'm surprised that fixtures doesn't, or at least that's the experience that I'm having. So there's some funkiness there that I'd like to explore. I'll be honest; I don't know if I'm going to. But if anybody happens to know what that funkiness is or why fixtures and factories are different in that regard, I would be very intrigued because, at some point, I might look into it just because I would like to know. CHRIS: Oh, that is interesting. I have not really worked with fixtures much at all. I've lived a factory life myself, and thus that's where almost all of my experience is. I'm not super surprised if this ends up being the case, like, the idea that fixtures are just some data that gets shoveled into the database directly as opposed to FactoryBot going through the model layer. And so it's sort of like that difference. But I don't know that for certain. That sounds like what this is and makes sense conceptually. But I think this is what you were saying like, that also kind of pushes me more in the direction of factories because it's like, oh, they're now representative. They're using our model layer, where we're defining certain truths. And I don't love callbacks as a mechanism. But if your app has them, then getting data that is representative is useful in tests. Like one of the things I add whenever I'm working with FactoryBot is the FactoryBot lint rake task RSpec thing that basically just says, "Are your factories valid?" which I think is a great baseline to have. Because you may add a migration that adds a default constraint or something like that to the database that suddenly all your factories are invalid, and it's breaking tests, but you don't know it. Like subtly, you change it, and it doesn't actually break a test, but then it's harder later. So that idea of just having more correctness baked in is always nice, especially when it can be automated like that, so definitely a fan of that. But yeah, interested if you do figure out the distinction. I do like your take, though, of like, but also, maybe I just won't figure this out. Maybe this isn't worth figuring it out. Although you were in the interesting spot of, you could just port the fixtures over and then be done and call the larger body of work done. But it's done in sort of a half-complete way, so it's an interesting trade-off space. I'm also interested to hear where you end up on that. STEPH: Yeah, it's a tough trade-off. It's one that we don't feel great about. But then it's also recognizing what's the true value of what we're trying to deliver? And it also comes down to the idea of churn versus complexity. And I feel like we are porting over existing complexity and even adding a smidge, not actual complexity but adding a smidge of indirection in terms that when someone sees this file, they're going to see a mixed-use of fixtures and factories, and that doesn't feel good. And so we've already talked about adding a giant comment above fixtures that just is very honest and says, "Hey, these were ported over. Please don't mimic this. But this is some legacy tests that we have brought over. And we haven't migrated the fixtures over to use factories." And then, in regards to the churn versus complexity, this code isn't likely to get touched like these tests. We really just need them to keep running and keep validating scenarios. But it's not likely that someone's going to come in here and really need to manage these anytime soon. At least, this is what I'm telling myself to make me feel better about it. So there's also that idea of yes, we are porting this over. This is also how they already exist. So if someone did need to manage these tests, then going to Test::Unit, they would have the same experience that they're going to have in RSpec. So that's really the crux of it is that we're not improving that experience. We're just moving it over and then trying to communicate that; yes, we have muddied the waters a little bit by introducing this other pattern. So we're going to find a way to communicate why we've introduced this other pattern, but that way, we can stay focused on actually porting things over to RSpec. As for the factories versus fixtures, I feel like you're onto something in terms of it's just skipping that model layer. And that's why a lot of that functionality isn't getting run. And I do appreciate the accuracy of factories. I'd much rather know is my data representative of real data that can get created in the world? And right now, it feels like some of the fixtures aren't. Like, how they're getting created seemed to bypass really important checks and validations, and that is wrong. That's not what we want to have in our test is, where we're creating data that then the rest of the application can't truly create. But that's another problem for another day. So that's an update on a trade-off that we have made in regards to the testing journey that we are on. What's going on in your world? CHRIS: Well, we got to do something exciting this week. I was working on some code. This is using dry-monads, the dry-rb space. So we have these result objects that we use pretty pervasively throughout the app, and often, we're in a controller. We run one of these command objects. So it's create user, and create user actually encompasses a ton of logic in our app, and that object returns a result. So it's either a success or a failure. And if it's a success, it'll be a success with that new user wrapped up inside of it, or if it's a failure, it's a specific error message. Actually, different structured error messages in different ways, some that would be pushed to the form, some that would be a flash message. There are actually fun, different things that we do there. But in the controller, when we interact with those result objects, typically what we'll do is we'll say result equals create user dot run, (result=createuser.run) and then pass it whatever data it needs. And then on the next line, we'll say results dot either, (results.either), which is a method on these result objects. It's on both the success and failure so you can treat them the same. And then you pass what ends up being a lambda or a stabby proc, or I forget what they are. But one of those sort of inline function type things in Ruby that always feel kind of weird. But you pass one of those, and you actually pass two of them, one for the success case and one for the failure case. And so in the success case, we redirect back with a notice of congratulations, your user was created. Or, in the failure case, we potentially do a flash message of an alert, or we send the errors down, or whatever it ends up being. But it allows us to handle both of those cases. But it's always been syntactically terrible, is how I would describe it. It's, yeah, I'm just going to leave it at that. We are now living in a wonderful, new world. This has been something that I've wanted to try for a while. But I finally realized we're actually on Ruby 2.7, and so thus, we have access to pattern matching in Ruby. So I get to take it for a spin for the first time, realizing that we were already on the correct version. And in particular, dry-monads has a page in their docs specific to how we can take advantage of pattern matching with the result objects that they provide us. There's nothing specific in the library as far as I understand it. This is just them showing a bunch of examples of how one might want to do it if they're working with these result objects. But it's really great because it gives the ability to interact with, you know, success is typically going to be a singular case. There's one success branch to this whole logic, but there are like seven different ways it can fail. And that's the whole idea as to why we use these command objects and the whole Railway Oriented Programming and that whole thing which I have...what is this word? [laughs] I feel like I should know it. It's a positive rant. I have raved; that is how our users kindly pointed that out to us. I have raved about the Railway Oriented Programming that allows us to do. But it's that idea that they're actually, you know, there's one happy path, and there are seven distinct failure modes, seven unhappy paths. And now, using pattern matching, we actually get a really expressive, readable, useful way to destructure each of those distinct failures to work with the particular bits of data that we need. So it was a very happy day, and I got to explore it. This is, again, a feature of Ruby, not a feature of dry-monads. But dry-monads just happens to embrace it and work really well with it. So that was awesome. STEPH: That is awesome. I've seen one or two; I don't know, I've seen a couple of tweets where people are like, yeah, Ruby pattern matching. I haven't found a way to use it. So I'm excited that you just shared a way that you found to use it. I'm also worried what it says about our developer culture that we know the word rant so well, but rave, we always have to reach back into our memory to be like, what's that positive word or something that we like? [laughs] CHRIS: And especially here on The Bike Shed, where we try to gravitate towards the positive. But yeah, it's an interesting point that you make. STEPH: We're a bunch of ranters. It's what we do, pranting ranters. I don't know why we're pranting. [laughs] CHRIS: Because it's that exciting. That's what it is. Actually, there was an interesting thing as we were playing around with the pattern matching code, just poking around in the console session with it, and it prints out a deprecation warning. It's like, warning: this is an experimental feature. Do not use it, be careful. But in the back of my head, I was like, I actually know how this whole thing plays out, Ruby 2.7, and I assure you, it's going to be fine. I have been to the future, at least I'm pretty sure. I think the version that is in Ruby 2.7 did end up getting adopted basically as it stands. And so, I think there is also a setting to turn off that deprecation warning. I haven't done it yet, but I mostly just enjoyed the conversation that I had with this deprecation message of like, listen, I've been to the future, and it's great. Well, it's complicated, but specific to this pattern matching [laughs] in Ruby 3+ versions, it went awesome. And I'm really excited about that future that we now live in. STEPH: I wish we had that for so many more things in our life [laughs] of like, here's a warning, and it's like, no, no, I've seen the future. It's all right. Or you're totally right; I should avoid and back out of this now. CHRIS: If only we could know how the things would play out, you know. But yeah, so pattern matching, very cool. I'll include a link in the show notes to the particular page in the dry-monads docs. But there are also other cool things on the internet. In an unrelated but also cool thing that I found this week, we use Tuple a lot within our organization for pair programming. For anyone who's not familiar with it, it's a really wonderful piece of technology that allows you to pair program pretty seamlessly, better video quality, all of those nice things that we want. But I found there was just the tiniest bit of friction in starting a Tuple call. I know I want to pair with this person. And I have to go up and click on the little menu bar, and then I have to find their name, then I have to click a button. That's just too much. That's not how...I want to live my life at the keyboard. I have a thing called Bartender, which is a little menu bar manager utility app that will collapse down and hide the icons. But it's also got a nice, little hotkey accessible pop-up window that allows me to filter down and open one of the menu bar pop-out menus. But unfortunately, when that happens, the Tuple window isn't interactive at that point. I can't use the arrow keys to go up and down. And so I was like, oh, man, I wonder if there's like an Alfred workflow for this. And it turns out indeed there is actually managed by the kind folks at Tuple themselves. So I was able to find that, install it; it's great. I have it now. I can use that. So that was a nice little upgrade to my workflow. I can just type like TC space and then start typing out the person's name, and then hit enter, and it will start a call immediately. And it doesn't actually make me more productive, but it makes me happier. And some days, that's what matters. STEPH: That's always so impressive to me when that happens where you're like, oh, I need a thing. And then you went through the saga that you just went through. And then the people who manage the application have already gotten there ahead of you, and they're like, don't worry, we've created this for you. That's one of those just beautiful moments of like, wow, y'all have really thought this through on a bunch of different levels and got there before me. CHRIS: It's somewhat unsurprising in this case because it's a very developer-centric organization, and Ben's background being a thoughtbot developer and Alfred user, I'm almost certain. Although I've seen folks talking about Raycast, which is the new hotness on the quick launcher world. I started eons ago in Quicksilver, and then I moved to Alfred, I don't know, ten years ago. I don't know what time it is anymore. But I've been in Alfred land for a while, but Raycast seems very cool. Just as an aside, I have not allowed myself... [laughs] this is another one of those like; I do not have permission to go explore this new tool yet because I don't think it will actually make me more productive, although it could make me happier. So... STEPH: I haven't heard of that one, Raycast. I'm literally adding it to the show notes right now as a way so you can find The Duke later, and I can find Raycast later [chuckles] and take a look at it and check it out. Although I really haven't embraced the whole Alfred workflow. I've seen people really enjoy it and just rave about it and how wonderful it is. But I haven't really leaned into that part of the world; I don't know why. I haven't set any hard and fast rules for myself where I can't play around with these technologies, but I haven't taken the time to do it either. CHRIS: You've also not found yourself writing thousands of lines of Vimscript because you thought that was a good idea. So you don't need as many guardrails it would seem. That's my guess. STEPH: This is true. CHRIS: Whereas I need to be intentional [laughs] with how I structure my interaction with my dev tools. STEPH: Instead, I'm just porting over fixtures from one place to another. [laughs] That's the weird space that I'm living in instead. [laughs] CHRIS: But you're getting paid for that. No one paid me for the Vimscript I wrote. [laughter] STEPH: That's fair. Speaking around process-y things, there's something that's been on my mind that Valeria, another thoughtboter, suggested around how we structure our meetings and the default timing that we have for meetings. So Thursdays are my team-focused day. And it's the day where I have a lot of one on ones. And I realized that I've scheduled them back to back, which is problematic because then I have zero break in between them, which I'm less concerned about that because then I can go for an hour or something and not have a break. And I'm not worried about that part. But it does mean that if one of those discussions happens to go over just even for like two or three minutes, then it means that someone else is waiting for me in those two to three minutes. And that feels unacceptable to me. So Valeria brought up a really good idea where I think it's only with the Google Meet paid version. I could be wrong there. But I think with the paid version of it that then you can set the new default for how long a meeting is going to last. So instead of having it default to 30 minutes, have it default to 25 minutes. So then, that way, you do have that five-minute buffer. So if you do go over just like two or three minutes with someone, you've still got like two minutes to then hop to the next call, and nobody's waiting for you. Or if you want those five minutes to then grab some water or something like that. So we haven't implemented it just yet because then there's discussion around is this a new practice that we want everybody to move to? Because I mean, if just one person does it, it doesn't work. You really need everybody to buy into the concept of we're now defaulting to 25 versus 30-minute meetings. So I'll have to let you know how that goes. But I'm intrigued to try it out because I think that would be very helpful for me. Although there's a part of me that then feels bad because it's like, well, if I have 30 minutes to chat with somebody, but now I'm reducing it to 25 minutes each time, I didn't love that I'm taking time away from our discussion. But that still feels like a better outcome than making somebody wait for three to five minutes if something else goes over. So have you ever run into something like that? How do you manage back-to-back meetings? Do you intentionally schedule a break in between or? CHRIS: I do try to give myself some buffer time. I stack meetings but not so much so that they're just back to back. So I'll stack them like Wednesdays are a meeting-heavy day for me. That's intentional just to be like, all right, I know that my day is going to get chopped up. So let's just really lean into that, chop the heck out of Wednesday afternoons, and then the rest of the week can hopefully have slightly longer deep work-type sessions. And, yeah, in general, I try and have like a little gap in between them. But often what I'll do for that is I'll stagger the start of the next meeting to be rather than on the hour or the half-hour, I start it on the 15th minute. And so then it's sort of I now have these little 15-minute gaps in my workflow, which is enough time to do one or two small things or to go get a drink or whatever it is or if things do run over. Like, again, I feel what you're saying of like, I don't necessarily want to constrain a meeting. Or I also don't necessarily want to go into the habit of often over-running. I think it's good to be intentional. Start meetings on time, end meetings on time. If there's a great conversation that's happening, maybe there's another follow-up meeting that should happen or something like that. But for as nonsensical of a human as I believe myself to be, I am rather rigid about meetings. I try very hard to be on time. I try very hard to wrap them up on time to make sure I go to the next one. And so with that, the 15-minute staggering is what I've found works for me. STEPH: Yeah, that makes sense. One-on-ones feels special to me because I wholeheartedly agree with being very diligent about like, hey, this is our meeting time. Let's do a time check. Someone says that at the end, and then that way, everybody can move on. But one on ones are, there's more open discussion space, and I hate cutting people off, especially because it might not be until the last 15 minutes that you really got into the meat of the conversation. Or you really got somewhere that's a little bit more personal or things that you want to talk about. So if someone's like, "Yeah, let me tell you about my life goals," and you're like, "Oh, no, wait, sorry. We're out of time." That feels terrible and tragic to do. So I struggle with that part of it. CHRIS: I will say actually, on that note, I'm now thinking through, but I believe this to be true. Everyone that reports to me I have a 45-minute one-on-one with, and then my CEO I set up the one-on-one. So I also made that one a 45-minute one-on-one. And that has worked out really well. Typically, I try and structure it and reiterate this from time to time of, like, hey, this is your space, not mine. So let's have whatever conversation fits in here. And it's fine if we don't need to use the whole time, but I want to make sure that we have it and that we protect it. Because I often find much like retro, I don't know; I think everything's fine. And then suddenly the conversation starts, and you're like, you know what? Actually, I'm really concerned now that you mentioned it. And you need that sort of empty space that then the reality sort of pop up into. And so with one on one, I try and make sure that there is that space, but I'm fine with being like, we can cut this short. We can move on from one-on-one topics to more of status updates; let's talk about the work. But I want to make sure that we lead with is there anything deeper, any concerns, anything you want to talk through? And sort of having the space and time for that. STEPH: I like that. And I also think it speaks more directly to the problem I'm having because I'm saying that we keep running over a couple of minutes, and so someone else is waiting. So rather than shorten it, which is where I'm already feeling some pain...although I still think that's a good idea to have a default of 25-minute meetings so then that way, there is a break versus the full 30. So if people want to have back-to-back meetings, they still have a little bit of time in between. But for one on ones specifically, upping it to 45 minutes feels nice because then you've got that 15-minute buffer likely. I mean, maybe you schedule a meeting, but, I don't know, that's funky. But likely, you've got a 15-minute buffer until your next one. And then that's also an area that I feel comfortable in sharing with folks and saying, "Hey, I've booked this whole 45 minutes. But if we don't need the whole time, that's fine." I'm comfortable saying, "Hey, we can end early, and you can get more of your time back to focus on some other areas." It's more the cutting someone off when they're talking because I have to hop to the next thing. I absolutely hate that feeling. So thanks, I think I'll give that a go. I think I'll try actually bumping it up to 45 minutes, presuming that other people like that strategy too, since they're opting in [laughs] to the 45 minutes structure. But that sounds like a nice solution. CHRIS: Well yeah, happy to share it. Actually, one interesting thing that I'm realizing, having been a manager at thoughtbot and then now being a manager within Sagewell, the nature of the interactions are very different. With thoughtbot, I was often on other projects. I was not working with my team day to day in any real capacity. So it was once every two weeks, I would have this moment to reconnect with them. And there was some amount of just catching up. Ideally, not like status update, low-level sort of thing, but sort of just like hey, what have you been working on? What have you been struggling with? What have you been enjoying? There was more like I needed bigger space, I would say for that, or it's not surprising to me that you're bumping into 30 minutes not being quite long enough. Whereas regularly, in the one on ones that I have now, we end up cutting them short or shifting out of true one-on-one mode into more general conversation and chatting about Raycast or other tools or whatever it is because we are working together daily. And we're pairing very regularly, and we're all on the same project and all sorts of in sync and know what's going on. And we're having retro together. We have plenty of places to have the conversation. So the one-on-one again, still, I keep the same cadence and the same time structure just because I want to make sure we have the space for any day that we really need that. But in general, we don't. Whereas when I was at thoughtbot, it was all the more necessary. And I think for folks listening; I could imagine if you're in a team lead position and if you're working very closely with folks, then you may be on the one side of things versus if you're a little bit more at a distance from the work that they're doing day to day. That's probably an interesting question to ask, and think about how you want to structure it. STEPH: Yeah, I think that's an excellent point. Because you're right; I don't see these individuals. We may not have really gotten to interact, except for our daily syncs outside of that. So then yeah, there's always like a good first 10 minutes of where we're just chatting about life and catching up on how things are going before then we dive into some other things. So I think that's a really good point. Cool, solving management problems on the mic. I dig it. In slightly different news, I've joined a book club, which I'm excited about. This book club is about Ruby. It's specifically reading the book Ruby Science, which is a book that was written and published by thoughtbot. And it requires zero homework, which is my favorite type of book club. Because I have found I always want to be part of book clubs. I'm always interested in them, but then I'm not great at budgeting the time to make sure I read everything I'm supposed to read. And so then it comes time for folks to get together. And I'm like, well, I didn't do my homework, so I can't join it. But for this one, it's being led by Joël, and the goal is that you don't have to do the homework. And they're just really short sections. So whoever's in charge of leading that particular session of the book club they're going to provide an overview of what's covered in whatever the reading material that we're supposed to read, whatever topic we're covering that day. They're going to provide an overview of it, an example of it, so then we can all talk about it together. So if you read it, that's wonderful. You're a bit ahead and could even join the meeting like five minutes late. Or, if you haven't read it, then you could join and then get that update. So I'm very excited about it. And this was one of those books that I'd forgotten that thoughtbot had written, and it's one that I've never read. And it's public for anybody that's interested in it. So to cover a little bit of details about it, so it talks about code smells, ways to refactor code, and then also common patterns that you can use to solve some issues. So there's a lot of really just great content that's in it. And I'll be sure to include a link in the show notes for anyone else that's interested. CHRIS: And again, to reiterate, this book is free at this point. Previously, in the past, it was available for purchase. But at one point a number of years ago, thoughtbot set all of the books free. And so now that along with a handful of other books like...what's Edward's DNS book? Domain Name Sanity, I believe, is Edward's book name that Edward Loveall wrote when he was not a thoughtboter, [laughs] and then later joined as a thoughtboter, and then we made the book free. But on the specific topic of Ruby Science, that is a book that I will never forget. And the reason I will never forget it is that book was written by the one and only CTO Joe Ferris, who is an incredibly talented developer. And when I was interviewing with thoughtbot, I got down to the final day, which is a pairing session. You do a morning pairing session with one thoughtbot developer, and you do an afternoon pairing session with another thoughtbot developer. So in the morning, I was working with someone on actually a patch to Rails which was pretty cool. I'd never really done that, so that was exciting. And that went fine with the exception that I kept turning on Caps Lock on their keyboard because I was used to Caps Lock being CTRL, and then Vim was going real weird for me. But otherwise, that went really well. But then, in the afternoon, I was paired with the one and only CTO Joe Ferris, who was writing the book Ruby Science at that time. And the nature of the book is like, here's a code sample, and then here's that code sample improved, just a lot of sort of side-by-side comparisons of code. And I forget the exact way that this went, but I just remember being terrified because Joe would put some code up on the screen and be like, "What do you think?" And I was like, oh, is this the good code or the bad code? I feel like I should know. I do not know. I'm not sure. It worked out fine, I guess. I made it through. But I just remember being so terrified at that point. I was just like, oh no, this is how it ends for me. It's been a good run. STEPH: [laughs] CHRIS: I made it this far. I would have loved to work for this nice thoughtbot company, but here we are. But yeah, I made it through. [laughs] STEPH: There are so many layers to that too where it's like, well if I say it's terrible, are you going to be offended? Like, how's this going to go for me if I speak my truths? Or what am I going to miss? Yeah, that seems very interesting (I kind of like it.) but also a terrifying pairing session. CHRIS: I think it went well because I think the code...I'd been following thoughtbot's work, and I knew who Joe was and had heard him on podcasts and things. And I kind of knew roughly where things were, and I was like, that code looks messy. And so I think I mostly got it right, but just the openness of the question of like, what do you think? I was like, oh God. [laughs] So yeah, that book will always be in my memories, is how I would describe it. STEPH: Well, I'm glad it worked out so we could be here today recording a podcast together. [laughs] CHRIS: Recording a podcast together. Now that I say all that, though, it's been a long time since I've read the book. So maybe I'll take a revisit. And definitely interested to hear more about your book club and how that goes. But shifting ever so slightly (I don't have a lot to say on this topic.) but there's a new framework technology thing out there that has caught my attention. And this hasn't happened for a while, so it's kind of novel for me. So I tend to try and keep my eye on where is the sort of trend of web development going? And I found Inertia a while ago, and I've been very, very happy with that as sort of this is the default answer as to how I build websites. To be clear, Inertia is still the answer as to how I build websites. I love Inertia. I love what it represents. But I'm seeing some stuff that's really interesting that is different. Specifically, Remix.run is the thing that I'm seeing. I mentioned it, I think, in the last episode talking about there was some stuff that they were doing with data loading and async versus synchronous, and do you wait on it or? They had built some really nice levers and trade-offs into the framework. And there's a really great talk that Ryan Florence, one of the creators of Remix.run, gave about that and showed what they were building. I've been exploring it a little bit more in-depth now. And there is some really, really interesting stuff in Remix. In particular, it's a meta-framework, I think, is the nonsense phrase that we use to describe it. But it's built on top of React. That won't be true for forever. I think it's actually they would say it's more built on top of React Router. But it is very similar to Next.js for folks that have seen that. But it's got a little bit more thought around data loading. How do we change data? How do we revalidate data after? There's a ton of stuff that, having worked in many React client-side API-heavy apps that there's so much pain, cache invalidation. How do you think about the cache? When do you fetch from the network? How do you avoid showing 19 different loading spinners on the page? And Remix as a framework has some really, I think, robust and well-thought-out answers to a lot of that. So I am super-duper intrigued by what they're doing over there. There's a particular video that I think shows off what Remix represents really well. It's Ryan Florence, that same individual, the creator of Remix, building just a newsletter signup page. But he goes through like, let's start from the bare bones, simplest thing. It's just an input, and a form submits to the server. That's it. And so we're starting from web 2.0, long, long ago, sort of ideas, and then he gradually enhances it with animations and transitions and error states. And even at the end, goes through an accessibility audit using the screen reader to say, "Look, Remix helps you get really close because you're just using web fundamentals." But then goes a couple of steps further and actually makes it work really, really well for a screen reader. And, yeah, overall, I'm just super impressed by the project, really, really intrigued by the work that they're doing. And frankly, I see a couple of different projects that are sort of in this space. So yeah, again, very early but excited. STEPH: On their website...I'm checking it out as you're walking me through it, and on their website, they have "Say goodbye to Spinnageddon." And that's very cute. [laughs] CHRIS: There's some fundamental stuff that I think we've just kind of as a web community, we made some trade-offs that I personally really don't like. And that idea of just spinners everywhere just sending down a ball of application logic and a giant JavaScript file turning it on on someone's computer. And then immediately, it has to fetch back to the server. There are just trade-offs there that are not great. I love that Remix is sort of flipping that around. I will say, just to sort of couch the excitement that I'm expressing right now, that Remix exists in a certain place. It helps with building complex UIs. But it doesn't have anything in the data layer. So you have to bring your own data layer and figure out what that means. We have ActiveRecord within Rails, and it's deeply integrated. And so you would need to bring a Prisma or some other database connection or whatever it is. And it also doesn't have more sort of full-featured framework things. Like with Rails, it's very easy to get started with a background job system. Remix has no answer to that because they're like, no, no, this is what we're doing over here. But similarly, security is probably the one that concerns me the most. There's an open conversation in their discussion portal about CSRF protection and a back and forth of whether or not Remix should have that out of the box or not. And there are trade-offs because there are different adapters that you can use for auth. And each would require their own CSRF mitigation. But to me, that is the sort of thing that I would want a framework to have. Or I'd be interested in a framework that continues to build on top of Remix that adds in background jobs and databases and all that kind of stuff as a complete solution, something more akin to a Rails or a Laravel where it's like, here we go. This is everything. But again, having some of these more advanced concepts and patterns to build really, really delightful UIs without having to change out the fundamental way that you're building things. STEPH: Interesting. Yeah, I think you've answered a couple of questions that I had about it. I am curious as to how it fits into your current tech stack. So you've mentioned that you're excited and that it's helpful. But given that you already have Rails, and Inertia, and Svelte, does it plug and play with the other libraries or the other frameworks that you have? Are you going to have to replace something to then take advantage of Remix? What does that roadmap look like? CHRIS: Oh yeah, I don't expect to be using Remix anytime soon. I'm just keeping an eye on it. I think it would be a pretty fundamental shift because it ends up being the server layer. So it would replace Rails. It would replace the Inertia within the stack that I'm using. This is why as I started, I was like, Inertia is still my answer. Because Inertia integrates really well with Rails and allows me to do the sort of it's not progressive enhancement, but it's like, I want fancy UI, and I don't want to give up on Rails. And so, Inertia is a great answer for that. Remix does not quite fit in the same way. Remix will own all of the request-response lifecycle. And so, if I were to use it, I would need to build out the rest of that myself. So I would need to figure out the data layer. I would need to figure out other things. I wouldn't be using Rails. I'm sure there's a way to shoehorn the technologies together, but I think it sort of architecturally would be misaligned. And so my sense is that folks out there are building...they're sort of piecing together parts of the stack to fill out the rest. And Remix is a really fantastic controller and view from their down experience and routing layer. So it's routing, controller, view I would say Remix has a really great answer to, but it doesn't have as much of the other stuff. Whereas in my case, Inertia and Rails come together and give me a great answer to the whole story. STEPH: Got it. Okay, that's super helpful. CHRIS: But yeah, again, I'm in very much the exploratory phase. I'm super intrigued by a lot of what I've seen of it and also just sort of the mindset, the ethos of the project as it were. That sounds fancy as I say it, but it's what I mean. I think they want to build from web fundamentals and then enhance the experience on top of that, and I think that's a really great way to go. It means that links will work. It means that routing and URLs will work by default. It means that you won't have loading spinner Armageddon, and these are core fundamentals that I believe make for good websites and web applications. So super interested to see where they go with it. But again, for me, I'm still very much in the Rails Inertia camp. Certainly, I mean, I've built Sagewell on top of it, so I'm going to be hanging out with it for a while, but also, it would still be my answer if I were starting something new right now. I'm just really intrigued by there's a new example out there in the world, this Remix thing that's pushing the envelope in a way that I think is really great. But with that, my now…what was that? My second or my third rave? Also called the positive rant, as we call it. But yeah, I think on that note, what do you think? Should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll :: Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy. The Bike Shed: 328: Terrible Simplicity (https://www.bikeshed.fm/328) When To Fetch: Remixing React Router - Ryan Florence (https://www.youtube.com/watch?v=95B8mnhzoCM) Virtual Event - Save Time & Money with Discovery Sprints (https://thoughtbot.com/events/save-time-money-with-discovery) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: thoughtbot's next virtual event "Save Time & Money with Discovery Sprints" is coming up on June 17th, from 2 - 3 PM Eastern. It's a discussion with team members from product management, design and development. From a developer perspective, topics will include how to plan a product's architecture, both the MVP and future version, how to lead a tech spikes into integrations and conduct a build vs buy reviews of third party providers. Head to thoughtbot.com/events to register, the event is June 17th 2 - 3 PM ET. Even if you can't make it, registering will get you on the list for the recording. CHRIS: We're the second-best. We're the second-best. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: I'm very happy to report that I picked up a treat from the store recently. So while I was in Boston and we were hanging out in person, we talked about Pop-Tarts because that always comes up as a debate, as it should. And then also Toaster Strudels came up, so I now have a package of Toaster Strudels, and those are legit. Pop-Tart or Toaster Strudel, I am team Toaster Strudel, which I know you're going to ask me about icing and if I put it on there, so go ahead. I'm going to pause. [laughs] CHRIS: It sounds like I don't even need to say anything. But yes, inquiring minds want to know. STEPH: I think that's also my very defensive response because yes, I put icing on my Toaster Strudel. CHRIS: How interesting. [laughs] STEPH: But it feels like a whole different class of pastry. So I'm very defensive about my stance on Pop-Tarts with no icing put Strudel with icing. CHRIS: A whole different class of pastry. Got it. Noted. Understood. So did you travel? Like, were these in your luggage that you flew back with? STEPH: [laughs] Oh no. They would be all gooey and melty. No, we bought them when we got back to North Carolina. Oh, that'd be a pro move; just pack little individual Strudels as your airplane snack. Ooh, I might start doing that now. That sounds like a great airplane snack. CHRIS: You got to be careful though if the icing, you know, if it's pressurized from ground level and then you get up there, and it explodes. And you gotta be careful. Or is it the reverse? It's lower pressure up in the plane. So it might explode. STEPH: [laughs] Either way, it might explode. CHRIS: Well, yeah. If you somehow buy a packet of icing that is sky icing that is at that pressure, and you bring it down, then...but if you take it up and down, I think it's fine. If you open it at the top, you might be in danger. If you open icing under the ocean, I think nothing's going to happen. So these are the ranges that we're playing with. STEPH: I will be very careful sky icing and probably pack two so that way I have a backup just in case. So if one explodes, we'll be like, all right, now I know what I'm working with and be more prepared for the next one. CHRIS: That's just smart. STEPH: I try to make smart travel decisions, Toaster Strudels on the go. Aside from travel treats and sky icing, I have some news regarding Planet Argon, who is a Ruby on Rails consultancy regarding their latest published this year's Ruby on Rails community survey results. And so they list a lot of fabulous different topics in there. And one of them includes a learning section that highlights most listened to podcasts in the Ruby on Rails community as well as blogs and some other resources. And Bike Shed is listed as the second most listened to podcast in the Ruby on Rails community, so whoo, golf clap. CHRIS: Fantastic. STEPH: And in addition to that, the thoughtbot blog got a really nice shout-out. So the thoughtbot blog is in the number two spot for the most visited blogs in the community. In the first spot is Ruby Weekly, which is like, you know, okay, that feels fair, that feels good. So it's really exciting for the thoughtbot blog because a lot of people work really hard on curating and creating that content. So that's wonderful that so many people are enjoying it. And then I should also highlight that for the podcast in first place is Remote Ruby, so congrats to Chris, Jason, and Andrew for grabbing that number one spot. And Brittany Martin, host of the Ruby on Rails Podcast, along with Brian Mariani, Jemma Issroff, and Nick Schwaderer, are in the number three spot. And some people say that Ruby is losing steam but look at all that content and all those highly ranked podcasts. I mean, we like Ruby so much we're spending time recording ourselves talking about it. So I say long live Ruby, long live Rails. CHRIS: Yes. Long live Ruby indeed. And yeah, it's definitely an honor to be on the list and to be amongst such other wonderful shows. Certainly big fans of the work of those other podcasts. We even did a joint adventure with them at one point, and that was a really wonderful experience, so yeah, honored to be on the list alongside them. And to have folks out there in the world listening to our tech talk and nonsense always nice to hear. STEPH: Yeah. You and I show up and say lots of silly things and technical things into the podcast. The true heroes are the ones that went and voted. So thank you to everybody who voted. That's greatly appreciated. It's really nice feedback. Because we get listener responses and questions, and those are wonderful because it lets us know that people are listening. But I have to say that having the survey results is also really nice. It lets us know people like the show. Oh, but I did go back and look at some of the previous stats because then I was like, huh, so I'm paying attention. I looked at this year's, and I was like, I wonder what last year's was or the year before that. And I think this survey comes out every two years because I didn't see one for 2021. But I did find the survey results for 2020, which we were in the number one spot for 2020, and Remote Ruby was in the second spot. So I feel like now we've got a really nice, healthy podcasting war situation going on to see who can grab the first spot. We've got two years, everybody, to see who [laughs] grabs the number one spot. That's a lot of prep time for a competition. CHRIS: Yeah, I feel like we should be like, I don't know, planning elaborate pranks on them or something like that now. Is that where this is at? It's something like that, I think. STEPH: I think so. I think this is where you put like sky frosting inside someone's suitcase, and that's the type of prank that you play. [laughs] CHRIS: The best of pranks. STEPH: We'll definitely put together a little task force. And we'll start thinking of pranks that we all need to start playing on each other for the podcasting wars that we're entering for the next few years. But anywho, what's going on in your world? CHRIS: Let's see, what's going on in my world? A fun thing happened recently. I had a chance to reflect back on some architectural choices that we've made in the Sagewell platform. And one of those specific choices is how we've approached building our native mobile apps. We made what some listeners may remember is an interesting set of choices. In particular, in Episode 328, which we'll include a link to in the show notes, I shared with you the approach that we're doing, which is basically like, Inertia is great, web user great. We like the web as a platform. What if we were to wrap it in a native shell and find this interesting and somewhat unique hybrid trade-off point? And so, at that point, we were building it. We had most of it built out, and things were going quite well. I think we maybe had the iOS app in the store and the Android app approaching the store or something like that. At this point, both apps have been released to the store, so they are live. Production users are signing in. It's wonderful. But I had a moment in the past couple of weeks to reassess or look at that set of choices and evaluate it. And thankfully, I'm happy with the choices that we've made. So that's good. But to get into the specifics, there were two things that happened that really, really framed the choice that we made, so one was we introduced a major new feature. We basically overhauled the first-run experience, the onboarding that users experience, and added a new, pretty fundamental facet to the platform. It's a bunch of new screens, and flows, and error states, and all of this complexity. And in the process, we iterated on it a bunch. Like, first, it looked like this, and then we changed the order of the screens and switched out the error messages, and et cetera, et cetera. And I'll be honest, we never even thought about the mobile apps. It just wasn't even a consideration. And interestingly, we did as a final check before going fully live and releasing this out to the full production audience; we did spot check it in the mobile apps, and it didn't work. But it didn't work for a very specific, boring, technical reason that we were able to resolve. It has to do with iframes and WebViews and embedded something, something. And we had to set a flag. Thankfully, it was solvable without a deploy of the native mobile apps. And otherwise, we never thought about the native apps. Specifically, we were able to add this fundamental set of features to our platform. And they just worked in native mobile. And they were the same as they roughly are if you're on a mobile WebView or if you're on a desktop web, you know, slightly different in terms of form factor. But the functionality was all the same. And critically, the error states and the edge cases and the flow, there's so much to think about when you're adding a nontrivial feature to an app. And the fact that we didn't have to consider it really spoke to the choice that we made here. And again, to name it, the choice that we made is we're basically just reusing the same WebViews, the same Rails controllers, and the same what are Svelte components under the hood but the same essentially view layer as well. And we are wrapping that in a native iOS. It's a Swift application shell, and on Android, it's a Kotlin application shell. But under the hood, it's the same web stuff. And that was really great. We just got these new features. And you know what? If we have to rip that whole set of functionality out, again, we won't need to deploy. We won't need to rethink it. Or, if we want to subtly tweak it, we can do that. If we want to think about feature flags or analytics, or error states or error reporting, all of this just naturally falls out of the approach that we took. And that was really wonderful. STEPH: That's super nice. I also love this saga of like, you made a choice, and then you're coming back to revisit and share how it's going. So as someone who's never done this before, in regards of wrapping an application in the manner that you have and then publishing it and distributing it that way, what does that process look like? Is this one of those like you run a command, and literally, it's going to wrap the application and then make it hostable on the different mobile app stores? Or what's that? Am I oversimplifying the process? What does that look like? CHRIS: I think there are a lot of platforms or frameworks I think would probably be the better word like Capacitor is something that comes to mind or Ionic or Expo. There are a handful of them that are a little more fully featured in what they provide. So you just point us at your React Views and whatnot, and we'll wrap that up, and it'll be great. But those are for, I may be overgeneralizing here, but my understanding is those are for more heavy client-side bundles that are talking to a common API. And so you're basically taking your same rich client-side application and bundling that up for reuse on the native app, the native app platforms. And so I think those do have some release to the store sort of thing. In our case, we went a little bit further with that integration wrapper thing that we built. So that is a thing that we maintain. We have a Sagewell iOS repo and a Sagewell Android repo. There's a bunch of Swift and Kotlin code, respectively, in each of them, and we deploy to the stores manually. We're doing that whole process. But critically, the code that is in each of those repositories is just the bridge glue code that says, oh, when this Inertia navigation event happens, I'm going to push a WebView to the navigation stack. And that's what that is. I'm going to render the tab bar of buttons at the bottom with the navigation elements that I get from the server. But it's very much server-driven UI, is the way that I would describe it. And it's wrapping WebViews versus actually having the whole client bundle wrapped up in the thing. It's unfortunately subtle to try and talk through on the radio, but yeah. [laughs] STEPH: You're doing great; this is helping. So if there's a change that you want to make, you go to the Rails application, and you make that change. And then do you need to update anything on that iOS repo? It sounds like you don't, which then you don't have to push a new update to the store. CHRIS: Correct. For the vast majority of things, we do not need to make any changes. It's very rare for us to deploy the iOS or the Android app is a different way to put it or to push new releases to the store. It happens we may want to add a new feature to the sort of bridge layer that we built, but increasingly, those are rare. And now it's basically like, yeah, we're just wrapping those WebViews, and it's going great. And again, to name it, it's a trade-off. It's an intentional trade-off that we've made. We're never going to have the richest, most deep platform integration, smooth experience. We are making a small trade-off on that front. But given where we're at as an organization, given how early we are, how much iteration and change, we chose an architecture that optimizes for that change. And so again, like what you just said, yeah, I can...you know how it's really nice to be able to deploy six times a day on a web app, and that's a very straightforward thing to do? It is not so straightforward in the native mobile world. And so, we now have afforded ourselves the ability to do that. But critically, and this is the fun part in my mind, have the trade-offs in the controls. So if we were just like, it's just a WebView, and that's it, and we put it in the stores, and we're done, that is too far of an extreme in my mind. I think the performance trade-offs, the experience trade-offs, it wouldn't feel like a native app like in a deep way, in a problematic way. And so as an example, we have a navigation bar at the top of our app, particularly on iOS, that is native iOS navigation. And we have a tab bar at the bottom, which is native tab UI element. I forget actually what it's called, but it's those elements. And we hide the web application navigation when we're in the mobile context. So we actually swap those out and say, like, let's actually promote these to formal native functionality. We also, within our UI on the web, have a persistent button in the top right corner of your screen that says, "Need help? Reach out to your retirement advocate." who is the person that you get to work with. You can send questions, et cetera, et cetera. It's this little help sidebar drawer thing that pops out. And we have that as a persistent HTML button in the top corner of the web frame. But when we're on native, we push that up as a distinct element in the native UI section. And then again, the bridge that I'm talking about allows for bi-directional communication between the JavaScript side and the native side or the native side and the JavaScript side. And so it's those sorts of pieces that have now afforded us all of the freedom to tinker, and we don't need to re-release where we're like, oh, we want to add a new weird button that does a thing in the WebView when you click on a button outside the WebView. We now just have that built-in. STEPH: Yeah, I really like the flexibility that you're describing. When you promoted those elements to be more native-friendly so, like the navigation or the footer or the little get help chat, is that something that then your team implemented in like the iOS or the Kotlin repo? Okay, I see you nodding, but other people can't see that, so...[laughs] CHRIS: Yeah. I was going to also say the words, but yes, those are now implemented as native parts. So the thing that we built isn't purely agnostic decoupled. It is Sagewell-specific; a lot of it is low-level. Like, let's say we want to wrap an Inertia app in a native mobile wrapper. Like, 90% of the code in it is that, but then there are little bits that are like, and put a button up there. And that button is the Sagewell button. And so it's not entirely decoupled from us. But it mostly is this agnostic bridge to connect things together. STEPH: Yeah, the way you're describing it sounds really nice in terms of you're able to get out the app quickly and have a mobile app quickly that works on both platforms, and then you're still able to deploy changes without having to push that. That was always my biggest mental, or emotional hurdle with the idea of mobile development was the concept of that you really had to batch everything together and then submit it for review and approval and then get it released. And then you got to hope people then upgrade and get the newest version. And it just felt like such a process, not that I ever did much of it. This was all just even watching like the mobile team and all the work that they had to do. And I had sympathy pains for them. But the fact that this approach allows you to avoid a lot of that but still have some nice, customized, more native elements. Yeah, I'm basically just recapping everything you said because I like all of it. CHRIS: Well, thank you, friend. Like I said, I've really enjoyed it, and similar to you, I'm addicted to the feedback loop of the web. It's beautiful. I can deploy ten times or however many I want. Anytime I want, I can push out a new version. And that ability to iterate, to test, to explore, to tweak, to not have to do as much formal testing upfront because I'm terrified that if a bug sneaks out, then, it'll take me two weeks to address it; it just is so, so freeing. And so to give that up moving into a native context. Perhaps I'm fighting too hard to hold on to my dream of the ability to rapidly iterate. But I really do believe in that and especially for where we're at as an organization right now. But, and a critical but here, again, it's a trade-off like anything else. And recently, I happened to be out about in the town, and I decided, oh, you know what? Let me open up the app. Let me see what it's like. And I wasn't on great internet. And so I open the app, and it loads because, you know, it's a native app, so it pops up. But then the thing that actually happened is a loading spinner in the middle of the screen and sort of a gray nothing for a little while until the server request to fetch the necessary UI elements to render the login screen appeared. And that experience was not great. In particular, that experience is core to the experience of using the app every single time. Every time you use it, you're going to have a bad time because we're re-downloading that UI element. And there's caching, and there's things that could happen there to help with that. But fundamentally, that experience is going to be a pretty common one. It's the first thing that you experience when you're opening the app. And so I noticed that and I chatted with the team, and I was like, hey, I feel like this is actually something that fixing this I think would really fundamentally move us along that spectrum of like, we've definitely made some trade-offs here. But overall, it feels snappy and like a native app. And so, we opted to prioritize work on a native login screen for both platforms. This also allows us to more deeply integrate. So particularly, we're going to get biometric logins like fingerprints or face scans, or whatever it is. But critically, it's that experience of like, I open the Sagewell native app on my iOS phone, and then it loads immediately. And then I show it my face like we do these days, and then it opens up and shows me everything that I want to see inside of it. And it's that first-run experience that feels worth the extra effort and the constraints. Because now that it's native mobile, that means in order to change it, we have to do a deploy, not a deploy, release; that's what they call it in the native world. [laughs] You can tell I'm well-versed in this ecosystem. But yeah, we're now choosing that trade-off. And what I really liked about this sort of set of things like the feature that we were able to just accidentally get for free on native because that's how this thing is built. And then likewise, the choice to opt into a fully native login screen like having that lever, having that control over I'm going to optimize for iteration generally, but where it's important, we want to optimize for performance and experience. And now we have this little slider that we can go back and forth. And frankly, we could choose to screen by screen just slowly replace everything in the app with true native WebViews backed by APIs. And we could Ship of Theseus style replace every element of the app with true native mobile things until none of the old bridge code exists. And our users, in theory, would never know. Having that flexibility is really nice given the trade-off and the choice that we've made. STEPH: You said a word there that I missed. You said ship something style. CHRIS: Ship of Theseus. STEPH: What is that? CHRIS: It's like an old biblical story, I want to say, but it's basically the idea of, like, you have the ship. And then some boards start to rot out, so replace those boards. And then the mast breaks, you replace the mast. And slowly, you've replaced every element on the ship. Is it still the same ship at that point? And so it's sort of a philosophical question. So if we replace every single view in this app with a native view, is it still the same map? Philosophers will philosophize about it forever, but whatever. As long as we get to keep iterating and shipping software, then I'm happy. STEPH: [laughs] Y'all philosophize. That's that word, right? CHRIS: Yeah. STEPH: And do your philosopher thing. We'll just keep building and shipping. CHRIS: I don't know if I pronounced it right. It's like either Theseus or Theseus, and I'm sure I said the wrong one. And now that I've said the other, I'm sure both of them are wrong somehow. It's like a USB where there's up and down, and yet somehow it takes three tries. So anyway, I may have mispronounced it, and I may be misattributing it, but that's the idea I was going for. STEPH: Well, given I wasn't even familiar with the word until just now, I'm going to give both pronunciations a thumbs up. I also really like how you decided that for the login screen, that's the area that you don't want people to wait because I agree if you're opening an application or opening...maybe it's the first time, maybe it's the 100th time. Who knows? But that feels important. Like, that needs to be snappy. I need to know it's responsive. And it builds trust from the minute that I clicked on that application. And if it takes a long time, I just immediately I'm like, what are y'all doing? Are y'all real? Do you know what you're doing over there? So I like how you focused on that experience. But then once I log in, like if something is slow to log me in, I will make up excuses for the application all day where I'm like, well, you know, maybe it's my connection. It's fine. I can wait for the next screen to load. That feels more reasonable. And it doesn't undermine my trust nearly as much as when I first click on the app. So that feels like a really nice trade-off as well, or at least a nice area that you've improved while still having those other trade-offs and benefits that you mentioned. CHRIS: To highlight it, you used a phrase there which I really liked. Like, it's building trust. If something's a little bit off in that first run experience every single time, then it kind of puts a question in the back of your head, maybe not even consciously. But you're just kind of looking at it, and you're like, what are you doing there? What are you up to, friend? Humans say to the apps they use on their phone. That's normal, right? When you talk... But to name it, we've also done a round of performance work throughout the app. And so there are a couple of layers to it. But it was work that we had planned for a while, but we kept deferring. But now that we're seeing more usage of the native apps, the native apps experience the same surface area of performance stuff but all the more so because they may be on degraded network connections, et cetera. And so this is another example where this whole thing kind of pays off. The performance work that we did affects everything. It affects the web. It's the same under the hood. It's let's reduce the network requests that we're making in the payloads that we're sending, particularly the network requests to upstream things, so like the banking partner that we're using and those APIs, like, collating all the data to then render the screen. Because of Inertia, we only have a single sort of back and forth conversation via the API as opposed to I think it's pretty common to have like seven different APIs and four different spinners on the screen. We're not doing that, none of that on my watch. [chuckles] But we minimize the background calls to the other parties that we're integrating with. And then, we reduce the payload of data that we're sending on each request. And each of those were like, we had to think about things and tweak and poke, but again it's uniform. So mobile web has that now, desktop web has that now. Android, iOS, they all just inherited it sort of that just happened one day without a deploy or release, without a release of either of the native mobile apps. We did deploy to the web to make that happen, but that's easy. I can do that a bunch of times a day. One last thing I want to share as we're on this topic of trade-offs and levers, there was a really great conference talk that I watched recently, which was Ryan Florence of remix.run also React Router fame if you're familiar with him from that. But he was talking about the most recent version of Remix, which is their meta framework on top of React. But they've done some really interesting stuff around processing data, fetching data, when and how to sequence that. And again, that thing that I talked about of nine different loading spinners on the screen, Remix is taking a very different approach but is targeting that same thing of like, that's not great for user experience. Cumulative layout shift being the actual number that you can monitor for this. But in that talk, there are features that they've added to Remix as a framework where you can just decide, like, do we wait for this or do we not? Do we make sure we have all of the data, or do we say, you know what? Actually, this is going to be below the fold. So it's okay to defer loading this until after we send down the first payload. And then we'll kick in, and we'll do it from the client-side. But it's this wonderful feature of the framework that they're adding in where there's basically just a keyword that you can add to sort of toggle that behavior. And again, it's this idea of like trade-offs. Are we okay with more layout shift, or are we okay with more waiting? Which is it that we're going to optimize for? And I really love that idea of putting that power very simply in the hands of the developers to make those trade-off decisions and optimize over time for what's important. So we'll share a link to that talk in the show notes as well. But it was very much in the same space of like, how do I have the power to decide and to change my mind over time? That's what I want. But yeah, with that, I think that's enough of me updating on the mobile app. I'll continue to share as new things happen. But again, I'm at this point very happy with where we're at. So yeah, it's been fun. But yeah, what else is up in your world? STEPH: I have a dear Gerrit message that I wrote earlier, so I want to share that with you. Gerrit is the system that we're using for when we push up code changes that then manages very similar in the competitive space of like GitHub and GitLab, and Bitbucket. And so the team that I'm working with we are using Gerrit. And Gerrit and I, you know, we get along for the most part. We've managed to have a working relationship. [chuckles] But this week, I wrote my dear Gerrit letter is that I really miss being able to tell a story with my commit messages. That is the biggest pain that I'm feeling right now. So for anyone that's less familiar or if you already are familiar with Gerrit, each change that Gerrit shows represents a single commit that's under review. And each change is identified by a Change-Id. So the basic concept of Gerrit is that you only have one commit per review. So if you were to translate that to GitHub terminology, every pull request is only going to have one commit, and so you really can't push up multiple. And so, where that has been causing me the most pain is I miss being able to tell a story. So like even simple stories that are like, hey, I removed something that's not used. I love separating that type of stuff into its own commit just so then people can see that as they're going through review. Now, before I merge, I'm likely to squash, and that doesn't feel important that it needs to be its own commit. That's really just for the reviewer so they can follow along for the changes. But the other one, I can slowly get over that one. Because essentially, the way I get around that is then when I do push up my code for review, is I then go through my change request, and then I just add comments. So I will highlight that line and say, "Hey, I'm removing this because it's not in use." And so, I found a workaround for that one. But the one I haven't found a workaround for is that I don't push up my local work very often because I love having lots of local, tiny, green commits so that way I can know the progress that I'm at. I know where I'm headed. Also, I have a safe space to roll back to, but then that means that I may have five or six commits that I have locally, but I haven't pushed up somewhere. And that is bothering me more and more hour by hour the more I think about it that I can't push stuff up because it makes me nervous. Because, I mean, usually, at least by the end of the day, I push everything up, so it's stored somewhere. And I don't have to worry about that work disappearing. Now I am working on a dev machine. So there is that aspect of it's technically...it's not even on my local machine. It is stored somewhere that I should still be able to access. CHRIS: What's a dev machine? The way you're saying it, it sounds like it's a virtual machine, not like a laptop. But what's a dev machine? STEPH: Good question. So the dev machine is a remote server or remote machine that then I am accessing, and then that's where I'm performing. That's where I'm writing all of my work. And then that's also kind of the benefit is everything is not local; it's controlled by the team. So then that also means that other teams, other individuals can help set up these environments for future developers. So then you have that consistency across everyone's working with the same Rails version, or gems, or has access to the same tools. So in that sense, my work isn't just on my laptop because then that would really worry me because then I've got nowhere...it's not backed up anywhere. So at least it is somewhere it's being stored that then could be accessed by someone. So actually, now, as I'm talking this through, that does help alleviate my concern about this a bit. [laughs] But I still miss it; I still miss being able to just push up my work and then have multiple commits. And I looked into it because I was like, well, maybe I'm misunderstanding something about Gerrit, and there's a way around this. And that's still always a chance. But from the research that I've done, it doesn't seem to be. And there are actually two very fiery takes that I saw that I have to share because they made me laugh. When I was Googling, the question of like, "Can I push up multiple commits to one single Gerrit CR? Or is there just a way to, like, can I have this concept of like a branch and then I have many commits, but then I turn it into one CR? Whatever the world would give me. What do they have? [laughs] I'm laughing just looking at this now. One of the responses was, have you tried squashing your commits into one commit? And I was like, [laughs] "Yeah, that's not what I had in mind, but sure." And then the other one, this is the more fiery take. They were very defensive about Gerrit, and they wrote that "People who don't like Gerrit usually just hack shit together. They cut corners and love squashing commits or throwing away history. And those people hate Gerrit. Developers who care love it. It's definitely possible and easy to produce agile software." And I just...that made me laugh. I was like, cool, I'm a developer that cuts corners and loves squashing commits. [laughs] CHRIS: So you don't care is what that take says. STEPH: I'm a developer who does not care. CHRIS: You know, Steph, I've worked with you for a while. And I've been looking for the opportunity to have this hard conversation with you. But I just wish you cared a little more about the software that you're writing, about the people that you're working with, about the commits that you're authoring. I just see it in every facet of your work. You just don't care. To be very clear for anyone listening at home, that is the deepest of sarcasm that I can make. Steph cares so very much. It's one of the things that I really enjoy about you. STEPH: I mean, we had the episode about toxic traits. This would have been the perfect time to confront me about my lack of caring about software and the processes that we have. So winding down on that saga, it seems to be the answer is no, friend; I cannot push up multiple commits. Oh, I tried to hack it. I am someone that tries to hack shit together because I tried to get around it just to see what would happen. [laughs] Because the docs had suggested that each change is identified by a Change-Id. And I was like, hmm, so what if there were two commits that had the same Change-Id, would Gerrit treat those as patch sets? Because right now, when you push up a change, you can see all the different patch sets, so that's nice. So that's a nice feature of Gerrit as you can see the history of, like, someone pushed up this change. They took in some feedback. They pushed up a new change. And so that history is there for each push that someone has provided. And I wondered maybe if they had the same Change-Id that then the patch sets would show the first commit and then the second commit. And so I manually altered the commits two of them to reference the same Change-Id. And I have to say, Gerrit was on to me because they gave me a very nice error message that said, "Same Change-Id and multiple changes. Squash the commits with the same Change-Ids or ensure Change-Ids are unique for each commit. And I thought, dang, Gerrit, you saw me coming. [laughs] So that didn't work either. I'm still in a world of where I now wait. I wait until I'm ready for someone to review stuff, and I have to squash everything, and then I go comment on my CRs to help out reviewers. CHRIS: I really like the emotional backdrop that you provided here where you're spending a minute; you're like, you know what? Maybe it's me. And there's the classic Seymour Skinner principle from The Simpsons. Am I out of touch? No, it's the children who are wrong. [laughs] And I liked that you took us on a whole tour of that. You're like, maybe it's me. I'll maybe read up. Nope, nope. So yeah, that's rough. There's a really interesting thing of tools constraining you. And then sometimes being like, I'm just going to yield control and back away and accept this thing that doesn't feel right to me. Like, Prettier does a bunch of stuff that I really don't like. It shapes code in a way, and I'm just like, no, that's not...nope, you know what? I've chosen to never care about this again. And there's so much utility in that choice. And so I've had that work out really well. Like with Prettier, that's a great example whereby yielding control over to this tool and just saying, you know what? Whatever you produce, that is our format; I don't care. And we're not going to talk about it, and that's that. That's been really useful for myself and for the teams that I'm on to just all kind of adopt that mindset and be like, yeah, no, it may not be what I would choose but whatever. And then we have nice formatted code; it's great. It happens automatically, love it. But then there are those times where I'm like; I tried to do that because I've had success with that mindset of being like, I know my natural thing is to try and micromanage and control every little bit of this code. But remember that time where it worked out really well for me to be like, I don't care, I'm just going to not care about this thing? And I try to not care about some stuff, which it sounds like that's what you're doing right here. [laughs] And you're like, I tried to not care, but I care. I care so much. And now you're in that [chuckles] complicated space. So I feel for you, Steph. I'm sorry you're in that complicated space of caring so much and not being able to turn that off [laughs] nor configure the software to do the thing you want. STEPH: I appreciate it. I should also share that the team that I'm working with they also don't love this. Like, they don't love Gerrit. So when I shared in the Slack channel my dear Gerrit message, they're both like, "Yeah, we feel you. [laughs] Like, we're in the same spot," which was also helpful because I just wanted to validate like, this is the pain I'm feeling. Is someone else doing something clever or different that I just don't know about? And so that was very helpful for them to say, "Nope, we feel you. We're in the same spot. And this is just the state that we're in." I think they have started transitioning some other repos over to GitLab and have several repos in Gitlab, but this one is still currently using Gerrit. So they very much commiserate with some of the things that I'm feeling and understand. And this does feel like one of those areas where I do care deeply. And frankly, this is one of those spaces that I do care about, but it's also like, I can work around it. There are some reasonable things that I can do, and it's fine as we just talked through. Like, the fact that my commits are not just locally on my machine already makes me feel better now that I've really processed that. So there are lower risks. It is more of just like a workflow. It's just, you know, it's crushing my work vibe. CHRIS: Harshing your buzz. STEPH: In the great words of Queen Elsa, I gotta let it go. This is the thing I'm letting go. So that's kind of what's going on in my world. What else is going on in your world? CHRIS: Well, first and foremost, fantastic reference and segue. I really liked that. But yeah, let's see, [laughs] what else is going on in my world? We had an interesting thing happen last week. So we had an outage on the platform last week. And then we had an incident review today, so a formal sort of post-mortem incident review. There are a couple of different names that folks have given to these. But this is a practice that we want to build within our engineering culture is when stuff goes wrong, we want to make sure that we have meaningful conversations around to try to address the root causes. Ideally, blameless is a word that gets used often in this context. And I've heard folks sort of take either side of that. Like, it's critical that it's blameless so that it doesn't feel like it's an attack. But also, like, I don't know, if one person did something, we should say that. So finding that gentle middle ground of having honest, real conversations but in a context of safety. Like, we're all going to make mistakes. We're all going to ship bugs; let's be clear about that. And so it's okay to sort of...anyway, that's about the process. We had an outage. The specific outage was that we have introduced a new process. This is a Sidekiq process to work off a specific queue. So we wanted that to have discrete treatment. That had been running, and then it stopped running; we still don't know why. So we never got to the root-root cause. Well, we know what the mechanism was, which was the dyno count for that process was at zero. And so, eventually, we found a bunch of jobs backed up in the Sidekiq admin. We're like, that's weird. And then, we went over to Heroku's configuration dashboard. And we saw, huh, that's weird. There are zero dynos processing this. That wasn't true yesterday. But unfortunately, Heroku doesn't log or have an audit trail around changes to those process counts. It's just not available. So that's unfortunate. And then the actual question of like, how did this happen? It probably had to be someone on the team. So there is like, someone did a thing. But that is almost immaterial because, again, people are going to do things, bugs will get shipped, et cetera. So the conversation very quickly turned to observability and understanding. I think we've done a pretty good job of instrumenting error reporting and being quite responsive to that, making sure the signal-to-noise ratio is very actionable. So if we see a bug or a Sentry alert come through, we're able to triage that pretty quickly, act on it where it is a real bug, understand where it's a bit of noise in the system, that sort of thing. But in this case, there were no errors. There was no Sentry. There was nothing; there was the absence of something. And so it was this really interesting case of that's where observability, I think, can really come in and help. So the idea of what can we do here? Well, we can monitor the count of jobs backed up in Sidekiq queue. That's one option. We could do some threshold alerting around the throughput of processed events coming from this other backend. There are a bunch of different ways, but it basically pushed us in the direction of doubling down and reinforcing the foundation of our observability within the platform. So we're just kicking that mini-project off now, but it is something we're like, yeah, we feel like we could add some here. In particular, we recently added Datadog to the stack. So we now have Datadog to aggregate our logs and ideally do some metric analysis, those sort of things, build some dashboards, et cetera. I haven't explored Datadog much thus far. But my sense is they've got the whiz-bang things that we need here. But yeah, it was an interesting outage. That wasn't fun. The incident conversation was actually a good conversation as a team. And then the outcome of like, how do we double down on observability? I'm actually quite excited for. STEPH: This is a fun moment for me because I have either joined teams that didn't have Datadog or have any of that sort of observability built into their system or that sort of dashboard that people go to. Or I've joined teams, and they already have it, and then nobody or people rarely look at it. And so I'm always intrigued between like what's that catalyst that then sparked a team to then go ahead and add this? And so I'm excited to hear you're in that moment of like, we need more observability. How do we go about this? And as soon as you said Datadog, I was like, yeah, that sounds nice because then it sounds like a place that you can check on to make sure that everything is still running. But then there's still also that manual process where I'm presuming unless there's something else you have in mind. There's still that manual process of someone has to check the dashboard; someone then has to understand if there's no count, no squiggly lines, that's a bad thing and to raise a concern. So I'm intrigued with my own initial reaction of, like, yeah, that sounds great. But now I'm also thinking about it still adds a lot of...the responsibility is still on a human to think of this thing and to go check it. Versus if there's something that gets sent to someone to alert you and say like, "Hey, this queue hasn't been processed in 48 hours. There may be a concern that actually feels nicer." It feels safer. CHRIS: Oh yeah, definitely. I think observability is this category of tools and workflows and whatnot. But I think what you're describing of proactive alerting that's the ideal. And so it would be wonderful if I never had to look at any of these tools ever. And I just knew if I got, let's say, it's PagerDuty connected up whatever, and I got a push notification from PagerDuty saying, "Hey, go look at this thing." That's all I ever need to think about. It's like, well, I haven't gotten a PagerDuty in a while, so everything must be fine, and having a deep trust in that. Similar to like, if we have a great test suite and it's green, I feel confident deploying the sort of absence of an alert being the thing that I can trust. But right now, we're early enough in this journey that I think what we need to do is stand up a bunch of these different graphs and charts and metric analysis and aggregations and whatnot, and then start to squint at it for a while and be like, which of these would I be really concerned if it started to wibble? And then you can figure the alerting around said wibble rate. And that's the dream. That's where we want to get to, but I think we've got to crawl, walk, run on this. So it'll be an adventure. This is very much the like; we're starting a thing. I'll tell you about it more when we've done it. But what you're describing is exactly what we want to get to. STEPH: I love wibble rate. That's my new measurement I'm going to start using for everything. It's funny, as you're bringing this up, it's making me think about the past week that Joël Quenneville and I have had with our client work. Because a somewhat similar situation came up in regards where something happened, and something was broken. And it seemed it was hard to define exactly what moment caused that to break and what was going on. But it had a big impact on the team because it essentially meant none of the bills were going through. And so that's a big situation when you got 100-plus people that are pushing up code and expecting some of the build processes to run. But it was one of those that the more we dug into it, the more it seemed very rare that it would happen. So, in this case, as a sort of a juxtaposition to your scenario, we actually took the opposite approach of where we're like; this is rare. But we did load up a lot of contexts. Actually, I was thinking back to the advice that you gave me in a previous episode where I was talking about at what point do you dig in versus try to stay at surface level? And this was one of those, like, we've spent a couple of days on getting context for this and understanding. So it felt really important and worthwhile to then invest a little bit more time to then document it. But then we still went with the simplest approach of like, this is weird. It shouldn't happen again. We think we understand it but then let's add a little bit of documentation or wiki page around like, hey, if you do run into this, here are some steps that will fix everything. And then, if you need to use this, let somebody know because this is so odd it shouldn't happen. So we took that approach in this case where we didn't increase the observability. It was more like we provided a fire extinguisher very close to the location in case it happens. And so that way, it's there should the need arise, but we're hoping it just never gets used. We're also in the process of changing how a lot of that logic works. So we didn't really want to optimize for observability into a system that is actively being changed because it should look very different in upcoming months. But overall, I love the conversations that you bring about observability, and I'm excited to hear about what wibble rates you decide to add to your Datadog dashboard. CHRIS: There's a delicate art and science to the selection of the wibble rates. So I will certainly report back as we get into that work. But with that, shall we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph and Chris are recording together! Like, in the same room, physically together. Chris talks about slowly evolving the architecture in an app they're working on and settling on directory structure. Steph's still working on migrating unit tests over to RSpec. They answer a listener question: "As senior-level developers, how do you set goals to ensure that you keep growing?" This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. Faking External Services In Tests With Adapters (https://thoughtbot.com/blog/faking-external-services-in-tests-with-adapters) Testing Third-Party Interactions (https://thoughtbot.com/blog/testing-third-party-interactions) Jen Dary - On Future Goals (https://www.beplucky.com/on-future-goals/) Charity Majors - The Engineer Manager Pedulum (https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) Charity Majors Bike Shed Episode (https://www.bikeshed.fm/302) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: What is new in my world? Actually, this episode feels different. There's something different about it. I can't quite put my finger on it. I think it may be that we're actually physically in the same room recording for the first time in two years and a little bit more, which is wild. STEPH: I can't believe it's been that long. I feel like it wasn't that long ago that we were in The Bike Shed...oh, I said The Bike Shed studio. I'm being very biased. Our recording studio [laughs] is the more proper description for it. Yeah, two and a half years. And we tried to make this happen a couple of months ago when I was visiting Boston, and then it just didn't work out. But today, we made it. CHRIS: Today, we made it. Here we are. So hopefully, the audio sounds great, and we get all that more richness in conversation because of the physical in-person manner. We're trying it out. It'll be fun. But let's see, to the normal tech talk and nonsense, what's new in my world? So we've been slowly evolving the architecture in the app that we're working on. And we settled on something that I kind of like, so I wanted to talk about it, directory structure, probably the most interesting topic in the world. I think there's some good stuff in here. So we have the normal stuff. There are app models, app controllers, all those; those make sense. We have app jobs which right now, I would say, is in a state of flux. We're in the sad place where some things are application records, and some things are Sidekiq workers. We have made the decision to consolidate everything onto Sidekiq workers, which is just strictly more powerful as to the direction we're going to go. But for right now, I'm not super happy with the state of app jobs, but whatever, we have that. But the things that I like so we have app commands; I've talked about app commands before. Those are command objects. They use dry-rb do notation, and they allow us to sequence a bunch of things that all may fail, and we can process them all in a much more reasonable way. It's been really interesting exploring that, building on it, introducing it to new developers who haven't worked in that mode before. And everyone who's come into the project has both picked it up very quickly and enjoyed it, and found it to be a nice expressive mode. So app commands very happy with that. App queries is another one that we have. We've talked about this before, query objects. I know we're a big fan. [laughs] I got a golf clap across the room here, which I could see live in person. It was amazing. I could feel the wind wafting across the room from the golf clap. [chuckles] But yeah, query objects, they're fantastic. They take a relation, they return a relation, but they allow us to build more complex queries outside of our models. The new one, here we go. So this stuff would all normally fall into app services, which services don't mean anything. So we do not have an app services directory in our application. But the new one that we have is app clients. So these are all of our HTTP clients wrapping external third parties that we're interacting with. But with each of them, we've taken a particular structure, a particular approach. So for each of them, we're using the adapter pattern. There's a blog post on the Giant Robots blog that I can point to that sort of speaks to the adapter pattern that we're using here. But basically, in production mode, there is an HTTP backend that actually makes the real requests and does all that stuff. And in test mode, there is a test backend for each of these clients that allows us to build up a pretty representative fake, and so we're faking it up before the HTTP layer. But we found that that's a good trade-off for us. And then we can say, like, if this fake backend gets a request to /users, then we can respond in whatever way that we want. And overall, we found that pattern to be really fantastic. We've been very happy with it. So it's one more thing. All of them were just gathering in-app models. And so it was only very recently that we said no, no, these deserve their own name. They are a pattern. We've repeated this pattern a bunch. We like this pattern. We want to even embrace this pattern more, so long live app clients. STEPH: I love it. I love app clients. It's been a while since I've been on a project that had that directory. But there was a greenfield project that I was working on. I think it might have been I was working with Boston.rb and working on giving them a new site or something like that and introduced app clients. And what you just said is perfect in terms of you've identified a pattern, and then you captured that and gave it its own directory to say, "Hey, this is our pattern. We've established it, and we really like it." That sounds awesome. It's also really nice as someone who's new to a codebase; if I jump in and if I look at app clients, I can immediately see what are the third parties that we're working with? And that feels really nice. So yeah, that sounds great. I'm into it. CHRIS: Yeah, I think it really was the question of like, is this a pattern we want to embrace and highlight within the codebase, or is this sort of a duplication but irrelevant like not really that important? And we decided no, this is a thing that matters. We currently have 17 of these clients, so 17 different third-party external things that we're integrating with. So for someone who doesn't really like service-oriented architecture, I do seem to have found myself in a place. But here we are, you know, we do what we have to with what we're given. But yes, 17 and growing our app clients. STEPH: That is a lot. [laughs] My eyes widened a bit when you said 17. I'm curious because you highlighted that app services that's not really a thing. Like, it doesn't mean anything. It doesn't have the same meaning of the app queries directory or app commands or app clients where it's like, this is a pattern we've identified, and named, and want to propagate. For app services, I agree; it's that junk drawer. But I guess in some ways...well, I'm going to say something, and then I'm going to decide how I feel about it. That feels useful because then, if you have something but you haven't established a pattern for it, you need a place for it to go. It still needs to live somewhere. And you don't necessarily want to put it in app models. So I'm curious, where do you put stuff that doesn't have an established pattern yet? CHRIS: It's a good question. I think it's probably app models is our current answer. Like, these are things that model stuff. And I'm a big believer in the it doesn't need to be an application record-backed object to go on app models. But slowly, we've been taking stuff out. I think it'd be very common for what we talk about as query objects to just be methods in the respective application record. So the user record, as a great example, has all of these methods for doing any sort of query that you might want to do. And I'm a fan of extracting that out into this very specific place called app queries. Commands are now another thing that I think very typically would fall into the app services place. Jobs naming that is something different. Clients we've got serializers is another one that we have at the top level, so those are four. We use Blueprinter within the app. And again, it's sort of weird. We don't really have an API. We're using Inertia. So we are still serializing to JSON across the boundary. And we found it was useful to encapsulate that. And so we have serializers as a directory, but they just do that. We do have policies. We're using Pundit for authorization, so that's another one that we have. But yeah, I think the junk drawerness probably most goes to app models. But at this point, more and more, I feel like we have a place to put things. It's relatively clear should this be in a controller, or should this be in a query object, or should this be in a command? I think I'm finding a place of happiness that, frankly, I've been searching for for a long time. You could say my whole life I've been searching for this contented state of I think I know where stuff goes in the app, mostly, most of the time. I'm just going to say this, and now that you've asked the excellent question of like, yeah, but no, where are you hiding some stuff? I'm going to open up models. Next week I'm going to be like, oh, I forgot about all of that nonsense. But the things that we have defined I'm very happy with. STEPH: That feels really fair for app models. Because like you said, I agree that it doesn't need to be ActiveRecord-backed to go on app models. And so, if it needs to live somewhere, do you add a junk drawer, or do you just create app models and reuse that? And I think it makes a lot of sense to repurpose app models or to let things slide in there until you can extract them and let them live there until there's a pattern that you see. CHRIS: We do. There's one more that I find hilarious, which is app lib, which my understanding...I remember at one point having one of those afternoons where I'm just like, I thought stuff works, but stuff doesn't seem to work. I thought lib was a directory in Rails apps. And it was like, oh no, now we autoload only under the app. So you should put lib under app. And I was just like, okay, whatever. So we have app lib with very little in it. [laughs] But that isn't so much a junk drawer as it is stuff that's like, this doesn't feel specific to us. This goes somewhere else. This could be extracted from the app. But I just find it funny that we have an app lib. It just seems wrong. STEPH: That feels like one of those directories that I've just accepted. Like, it's everywhere. It's like in all the apps that I work in. And so I've become very accustomed to it, and I haven't given it the same thoughtfulness that I think you have. I'm just like, yeah, it's another place to look. It's another place to go find some stuff. And then if I'm adding to it, yeah, I don't think I've been as thoughtful about it. But that makes sense that it's kind of silly that we have it, and that becomes like the junk drawer. If you're not careful with it, that's where you stick things. CHRIS: I appreciate you're describing my point of view as thoughtfulness. I feel like I may actually be burdened with historical knowledge here because I worked on Rails apps long, long ago when lib didn't go in-app, and now it does. And I'm like, wait a minute, but like, no, no, it's fine. These are the libraries within your app. I can tell that story. So, again, thank you for saying that I was being thoughtful. I think I was just being persnickety, and get off my lawn is probably where I was at. STEPH: Oh, full persnicketiness. Ooh, that's tough to say. [laughs] CHRIS: But yeah, I just wanted to share that little summary, particularly the app clients is an interesting one. And again, I'll share the adapter pattern blog post because I think it's worked really well for us. And it's allowed us to slowly build up a more robust test suite. And so now our feature specs do a very good job of simulating the reality of the world while also dealing with the fact that we have these 17 external situations that we have to interact with. And so, how do you balance that VCR versus other things? We've talked about this a bunch of times on different episodes. But app clients has worked great with the adapter pattern, so once more, rounding out our organizational approach. But yeah, that's what's up in my world. What's up in your world? STEPH: So I have a small update to give. But before I do, you just made me think of something in regards to that article that talks about the adapter pattern. And there's also another article that's by Joël Quenneville that's testing third-party interactions. And he made me reflect on a time where I was giving the RSpec course, and we were talking about different ways to test third-party interactions. And there are a couple of different ways that are mentioned in this article. There are stub methods on adapter, stub HTTP request, stub request to fake adapter, and stub HTTP request to fake service. All that sounds like a lot. But if you read through the article, then it gives an example of each one. But I've found it really helpful that if you're in a space that you still don't feel great about testing third-party interactions and you're not sure which approach to take; if you work with one API and apply all four different strategies, it really helps cement how to work through that process and the different benefits of each approach and the trade-offs. And we did that during the RSpec course, and I found it really helpful just from the teacher perspective to go through each one. And there were some great questions and discussions that came out of it. So I wanted to put that plug out there in the world that if you're struggling testing third-party interactions, we'll include a link to this article. But I think that's a really solid way to build a great foundation of, like, I know how to test a third-party app. Let me choose which strategy that I want to use. Circling back to what's going on in my world, I am still working on migrating unit tests over to RSpec. It's a thing. It's part of the work that I do. [laughs] I can't say it's particularly enjoyable, but it will have a positive payoff. And along that journey, I've learned some things or rediscovered some things. One of them is read expectations very carefully. So when I was migrating a test over to RSpec, I read it as where we expected a record to exist. The test was actually testing that a record did not exist. And so I probably spent an hour understanding, going through the code being like, why isn't this record getting created like I expect it to? And I finally went back, and I took a break, and I went back. And I was like, oh, crap, I read the expectation wrong. So read expectations very carefully. The other one...this one's not learned, but it is reinforced. Mystery Guests are awful. So as I've been porting over the behavior over to RSpec, the other tests are using fixtures, and I'm moving that over to use factorybot instead. And at first, I was trying to be minimal with the data that I was bringing over. That failed pretty spectacularly. So I have learned now that I have to go and copy everything that's in the fixtures, and then I move it over to factorybot. And it's painful, but at least then I'm doing that thing that we talked about before where I'm trying to load as little context as possible for each test. But then once I do have a green test, I'm going back through it, and I'm like, okay, we probably don't care about when you were created. We probably don't care when you're updated because every field is set for every single record. So I am going back and then playing a game of if I remove this line, does the test still pass? And if I remove that line, does the test still pass? And so far, that has been painful, but it does have the benefit of then I'm removing some of the setup. So Mystery Guests are very painful. I've also discovered that custom error messages can be tricky because I brought over some tests. And some of these, I'm realizing, are more user error than anything else. Anywho, I added one of the custom error messages that you can add, and I added it over to RSpec. But I had written an incorrect, invalid statement in RSpec where I was looking...I was expecting for a record to exist. But I was using the find by instead of where. So you can call exist on the ActiveRecord relation but not on the actual record that gets returned. But I had the custom error message that was popping up and saying, "Oh, your record wasn't found," and I just kept getting that. So I was then diving through the code to understand again why my record wasn't found. And once I removed that custom error message, I realized that it was actually because of how I'd written the RSpec assertion that was wrong because then RSpec gave me a wonderful message that was like, hey, you're trying to call exist on this record, and you can't do that. Instead, you need to call it on a relation. So I've also learned don't bring over custom error messages until you have a green test, and even then, consider if it's helpful because, frankly, the custom error message wasn't that helpful. It was very similar to what RSpec was going to tell us in general. So there was really no need to add that custom step to it. For the final bit that I've learned or the hurdle that I've been facing is that migrating tests descriptions are hard unless they map over. So RSpec has the context and then a description for it that goes with the test. Test::Unit has methods like method names instead. So it may be something like test redemption codes, and then it runs through the code. Well, as I'm trying to migrate that knowledge over to RSpec, it's not clear to me what we're testing. Okay, we're testing redemption codes. What about them? Should they pass? Should they fail? Should they change? What are they redeeming? There's very little context. So a lot of my tests are copying that method name, so I know which tests I'm focused on, and I'm bringing over. And then in the description, it's like, Steph needs help adding a test description, and then I'm pushing that up and then going to the team for help. So they can help me look through to understand, like, what is it that this test is doing? What's important about this domain? What sort of terminology should I include? And that has been working, but I didn't see that coming as part of this whole migrating stuff over. I really thought this might be a little bit more of a copypasta job. And I have learned some trickery is afoot. And it's been more complicated than I thought it was going to be. CHRIS: Well, at a minimum, I can say thank you for sharing all of your hard-learned lessons throughout this process. This does sound arduous, but hopefully, at the end of it, there will be a lot of value and a cleaned-up test suite and all of those sorts of things. But yeah, it's been an adventure you've been on. So on behalf of the people who you are sharing all of these things with, thank you. STEPH: Well, thank you. Yeah, I'm hoping this is very niche knowledge that there aren't many people in the world that are doing this exact work that this happens to be what this team needs. So yeah, it's been an adventure. I've certainly learned some things from it, and I still have more to go. So not there yet, but I'm also excited for when we can actually then delete this portion of the build process. And then also, I think, get rid of fixtures because I didn't think about that from the beginning either. But now that I'm realizing that's how those tests are working, I suspect we'll be able to delete those. And that'll be really nice because now we also have another single source of truth in factory_bot as to how valid records are being built. Mid-Roll Ad: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. Flaky tests slow everyone down, break your flow and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start? BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/ bikeshed. That's buildpulse.io/bikeshed. Pivoting just a bit, there's a listener question that I'm really excited for us to dive into. And this listener question comes from Joël Quenneville. Hey, Joël. All right, so Joël writes in, "As senior-level developers, how do you set goals to ensure that you keep growing? How do you know what are high-value areas for you to improve? How do you stay sharp? Do you just keep adding new languages to your tool belt? Do you pull back and try to dig into more theoretical concepts? Do you feel like you have enough tech skills and pivot to other things like communication or management skills? At the start of a dev career, there's an overwhelming list of things that it feels like you need to know all at once. Eventually, there comes a point where you no longer feel like you're drowning under the list of things that you need to learn. You're at least moderately competent in all the core concepts. So what's next?" This is a big, fun, scary question. I really like this question. Thank you, Joël, for sending it in because I think there's so much here that can be discussed. I can kick us off with a few thoughts. I want to first highlight one of the things that...or one of the things that resonates with me from this question is how Joël describes going through and reaching senior status how it can really feel like working through a backlog of features. So as a developer, I want to understand this particular framework, or as a developer, I want to be able to write clear and fast tests, or as a developer, I want to contribute to an open-source project. But now that that backlog is empty, you're wondering what's next on your roadmap, which is where I think that sort of big, fun scariness comes into play. So the first idea is to take a moment and embrace that success. You have probably worked really hard to get where you're at in your career. And there's nothing wrong with taking a pause and enjoying the view and just being appreciative of the fact that you are able to get your work done quickly or that you feel very confident in the work that you're doing. Growth is often very important to our careers, but I also think it's important to recognize when you've achieved certain growth and then, if you want to, just enjoy that and pause. And you're not constantly pushing yourself to the next level. I think that is a totally reasonable and healthy thing to do. The second thing that comes to mind is that you're on a Choose Your Own Adventure mode now, so you get to...I would encourage folks, once you've reached this stage, to reflect on where you're at and consider what is your dream? What are your aspirations? Maybe they're related to tech; maybe they're not. And consider where is it that you want to go next? And then, what are the concrete steps that will help you achieve those goals? So there's a really great article by Jen Dary, who's a career coach and owner of Plucky Manager Training, that describes this process. And there's a really great blog post that I'll be sure to include a link to in the show notes. But she has a couple of great questions that will then help you identify, like, what are my goals? Some of those questions are, "If I could do anything and money wasn't an object, I'd spend my time doing dot dot dot." And that doesn't necessarily mean sitting on a beach with your toes in the sand all day. I mean, it could, but then that probably just means you need a vacation. So take the vacation. And then, once you start to get bored, where does your mind start to wander? What are the things that you want to do? Where are you interested in spending your time? And then, once you have an idea of how you'd like to spend your time, you can consider what actions you could take next that will point you in that direction. There's also the benefit that by this point, you probably have an idea of the type of things that you like to do and where you like to spend your time. And so you can figure out which areas of expertise you want to invest in. So do you like more greenfield projects? Do you like architecture discussions? Do you like giving talks? Do you like teaching? Or maybe you're interested in management. I think there's also a more concrete approach that you can take that. You can just talk to your managers in your team and say, "Hey, what big, hard problems are you looking to solve? And then, you can get some inspiration from them and see if their problems align with your interests. Maybe it's not even your own team, but you can talk to other companies and see what other problems industries are trying to solve. That might be an area that then spurs some curiosity or some interest. And then, where do you feel underutilized? So with your current day-to-day, are there areas where you feel that you wish you had more responsibilities or more opportunities, but you feel like you don't have access to those opportunities? Maybe that's an area to explore as well. This feels like a wonderful coaching question in terms of you have done it; congratulations. You've reached a really great spot in your career. And so now you're figuring out that big next step. This is going to be highly customized to each person to then figuring out what it is that's going to help you feel fulfilled over the next five years, ten years, however long you want to project out. Those are some of my thoughts. How about you? What do you think? CHRIS: Well, first, those are some great thoughts. I appreciate that I get to follow them now. It's going to be a hard act to follow. But yeah, I think Joël has asked a fantastic question. And coming from Joël, I know how intentional and thoughtful a learner, and sharer, and teacher and all of these things are. So it's all the more sort of framed in that for me knowing Joël personally. I think to start, the kernel of the question is as senior developers, that's the like...or senior level developers is the way Joël phrased it, but it treats it as sort of this discrete moment in time, which I think there's maybe even something to unpack. And I think we've probably talked about this in previous episodes, but like, what does that even mean? And I think part of the story here is going from reactive where it's like, I don't know how anything works. I know a little bit. I can code some. And every day, I'm presented with new problems that I just don't understand. And I'm trying to build up that base of knowledge. Slowly, you know, you start, and it's like 95% of the time you feel like that. And slowly, the dial switches over, and maybe it's only 25% of the time you feel like that. Somewhere along that spectrum is the line of senior developer. I don't actually know where it is, but it's somewhere in there. And so I think it's that space where you can move from reactive learning things as necessitated by the work that's coming at you to I want to proactively choose the things that I want to be learning to try and expand the stuff that I know, and the ways that I can think about the work without being in direct response to a piece of work coming at me. So with that in mind, what do you do with this proactive space? And I think the way Joël frames the question, again, to what I know of Joël, he's such an intentional person. And I wouldn't be surprised if Joël is very purposeful and thinks about this and has approached it as a specific thing that he's doing. I have certainly been in more of “I'll figure it out when I get there.” I'll explore. Or actually, probably the most pointed thing that I did was I joined a consultancy. And that was a very purposeful choice early on in my career because I'm like, I think I know a little bit. I don't think I know a lot. I would like to know a lot. That seems fun. So what do I think is the best way to do that? My guess, and it turned out to be very much true, is if I join a consultancy, I'm going to see a bunch of different projects, different types of technologies, organizations, communication structure, stuff that works, stuff that doesn't work. And to be honest, I actually thought I would try out the consultancy thing for a little while, like a year or two, and then go on to my next adventure. Spoiler alert: I stayed for seven years. It was one of the best periods of my professional life. And I found it to be a much deeper well than I expected it to be. But for anyone that's looking for, like, how can I structure my career in a way that will just automatically provide the sort of novelty and space to grow? I would highly recommend a consultancy like thoughtbot. I wonder if they're hiring. STEPH: Well, yes, we are hiring. That was a perfect plug that I wasn't expecting for that to come. But yes, thoughtbot is totally hiring. We'll include a link in the show notes to all the jobs. [laughs] CHRIS: Sounds fantastic. But very sincerely, that was the best choice that I could have made and was a way to flip the situation around such that I don't have to be thinking about what I want to be learning. The learning will come to me. But even within that, I still tried to be intentional from time to time. And I would say, again, I don't have a holistic theory of how to improve. I just have some stuff that's kind of worked out well. One thing is focusing on fundamentals wherever I can, or a different way to put it is giving myself permission to spend a little bit more time whenever my work brushes up against what I would consider fundamentals. So things that are in that space are like SQL. Every time I'm working on something, I'm like, ah, I could use like a CROSS JOIN here, but I don't know what that is. Maybe I'll spend an extra 30 minutes Googling around and trying to figure out what a CROSS JOIN is. Is that a thing? Is a CROSS JOIN a real thing? I may be making it up. [laughs] A window function, I know that those are real. Maybe I'll learn what a window function is. I think a CROSS JOIN is a real thing. A LEFT OUTER JOIN that's a cool thing. And so, each time I've had that, SQL has been something that expanding my knowledge; I've continually felt like that was a good investment. Or fundamentals of HTTP, that's another one that really has served me well. With Ruby being the primary language that I program in, deeply understanding the language and the fundamentals and the semantics of it that's another place that has been a good investment. But by contrast, I would say I probably haven't gone as deep on the frameworks that I work with. So Rails is maybe a little bit different just because, like many people, I came to Ruby through Rails, and I've learned a lot of Rails. But like in JavaScript, I've worked with many different JavaScript frameworks. And I have been a little more intentional with how much time I invest into furthering my skills in them because I've seen them change and evolve enough times. And if anything, I'm trying to look for ones that are like, what if it's less about the framework and more about JavaScript and web fundamentals underneath? Thus, I've found myself in Svelte land. But I think it's that choice of trying to anchor to fundamentals wherever possible. And then I would say the other thing that's been really beneficial for me is what can I do that's wildly outside the stuff that I already know? And so probably the most pointed example I have of this is learning Elm. So I previously spent most of my career working in Ruby and JavaScript, so primarily object-oriented languages without a strong type system. And then, I was able to go over and experience this whole different paradigm way of working, way of structuring programs, feedback loop. There was so much about it that was really, really interesting. And even though I don't get to work in Elm, frankly, as much as I would want at this point or really at all, it informs everything that I do moving forward. And I think that falls out of the fact that it was so different than what I was doing. So if I were to do that again, probably the next type of language I would learn is Lisp because those are like, well, that's a whole other category of thing that I've heard about. People say some fun stuff about them, but I don't really know. So it's that fundamentals and weird stuff is how I would describe it. And by weird, I mean outside of the core base of knowledge that I have. STEPH: I love that categorization, and I'll stick with it, fundamentals and weird stuff, to stretch and grow and find some other areas. I also really like your framing, the reactive versus proactive. I think that's a really nice way to put it because so much of your career is you are just learning what your company needs you to learn, or you're learning what you need to keep progressing and to feel more competent with the types of features or the work that you're handling. And I think that's why Jen Dary's blog post resonates with me so much because it's probably...up until now, a lot of someone's career, maybe not Joël's particularly, but I know probably for my career, a lot of it has been reactive in terms of what are the things that I need to learn? And so then once you reach that point of like, okay, I feel competent and reasonably good at all the things that I needed to know, where do I want to go next? And rather than focus on necessarily the plans that are laid out in front of me, I can then go wide and think about what are some of the bigger things that I want to tackle? What are the things that are meaningful to me? Because then I can now push forward to this bigger goal versus achieving a particular salary band or title or things like that. But I can focus on something else that I really want to contribute to. And there do seem to be two common paths. So once you reach that level, either you typically go into management, or you become that more like principal and then onward and upward, whatever is after principal. I don't even know what's after that, [laughs] but the titles that come after principal. So there's management, and then I've seen the other very strong contributors, so Aaron Patterson comes to mind. And I feel like those people then typically will migrate to places where they get to contribute to a language or to a framework. And I think it comes down to the idea of impact because both of those provide a greater impact. So if you go into management, you can influence and affect a team of individuals, and you can increase the value created by that team. Then you've likely exceeded the value that you would have created as your own individual contributor. Or, if you contribute to a language or a framework, then your technical decisions impact a larger community. So I think that would be another good thing to reflect on is what type of impact am I looking for? What type of communities do I want to have a positive impact on? And that may spur some inspiration around where you want to go next, the things that you want to focus on. CHRIS: Yeah, I think one of the things we're picking up in that that Joël mentioned in his question is the idea of there is the individual contributor path. But then there's also the management path, which is the typical sort of that's the progression. And I think, for one, naming that the individual contributor path and the idea of going to principal dev and those sorts of outcomes is a fantastic path in and of itself. I think often it's like, well, you know, you go along for a certain amount of time, and then you become a manager. It's like, those are actually distinctly different things. And people have different levels of interest and aptitude in them, and I think recognizing that is critically important. And so, not expecting that management just comes after individual contributor is an important thing. The other thing I'll say is Charity Majors, who we had on the podcast a bit back, has a wonderful blog post about the pendulum swing called The Engineer/Manager Pendulum. And so in it, she talks about folks that have taken an exploration over into manager land and then come back to the individual contributor path or vice versa sort of being able to move between them, treating them as two potentially parallel career tracks but ones that we can move between. And her assertion is that often folks that are particularly strong have spent some time in both camps because then you gain this empathy, this understanding of what's the whole picture? How are we doing all of this? How do we think about communication, et cetera? So, again, to name it, like, I think it's totally fine to stay on one of those tracks to really know which of those tracks speaks to you or to even move between them a little bit and to explore it and to find out what's true. So we'll include a link to that in the show notes. And we'll also include a link to the previous episode a while back when we had Charity on. But yeah, those I think are some critical thoughts as well because those are different areas that we can grow as developers and expand on our impact within the team. And so, we want to make sure we have those options on the table as well. STEPH: Absolutely. I love where teams will support individuals to feel comfortable shifting between experiences like that because it does make you a more well-rounded contributor to that product team, not just as an engineer, but then you will also understand what everybody else is working on and be able to have more meaningful conversations with them about the company goals and then the type of work that's being done. So yeah, I love it. If you're in a place that you can maybe fail a little bit, hopefully not in a too painful way, but you can take a risk and say, "Hey, I want to try something and see if I like it," then I think that's wonderful. And take the risk and see how it goes. And just know that you have an exit strategy should you decide that you don't like that work or that type of work isn't for you. But at least now you know a little bit more about yourself. Overall, I want to respond directly to something that Joël highlighted around how do you know what are high-value areas for you to improve? And I think there are two definitions there because you can either let the people around you and your team define that high value for you, and maybe that really resonates with you, and it's something that you enjoy. And so you can go to your manager and say, "Hey, what are some high-value areas where I can make an impact for the team?" Or it could be very personal. And what are the high-value areas for you? Maybe there's a particular industry that you want to work on. Maybe you want to hit the public speaking circuit. And so you define more intrinsically what are those high-value areas for you? And I think that's a good place to start collecting feedback and start looking at what's high value for you personally and then what's high value to the company and see if there's any overlap there. With that, I think we've covered a good variety of things to explore and then highlighted some of the different ways that you and I have also considered this question. I think it's a fabulous question. Also, I think it's one, even if you're not at that senior level, to ask this question. Like, go ahead and start asking it early and often and revisit your answers and see how they change. I think that would be a really powerful habit to establish early in your career and then could help guide you along, and then you can reflect on some of your earlier choices. So, Joël, thank you so much for that question. STEPH: On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! Page transitions Overview (https://youtu.be/JCJUPJ_zDQ4) Using yield_self for composable ActiveRecord relations (https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations) A Case for Query Objects in Rails (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) Customer.io (https://customer.io/) Turning the database inside-out with Apache Samza | Confluent (https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/) Datomic (https://www.datomic.com/) About CRDTs • Conflict-free Replicated Data Types (https://crdt.tech/) Apache Kafka (https://kafka.apache.org/) Resilient Management | A book for new managers in tech (https://resilient-management.com/) Mixpanel: Product Analytics for Mobile, Web, & More (https://mixpanel.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're -- STEPH: Oh, I have golden roads, yes. [laughter] CHRIS: You might should inform that you've got golden roads, yeah. STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that. CHRIS: [laughs] STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it? [laughter] CHRIS: Do you want to fight? STEPH: Yeah, are we going to fight? CHRIS: I might could fight you. STEPH: I might could. I might should. [laughter] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari. But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming. CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others? STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those. CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody. STEPH: Oh, I'm behind. CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it. STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie. CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene. [laughter] STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is. CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs] STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five. CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie. STEPH: Yeah, that would be death by Top Gun. CHRIS: But not the normal way, the different, indirect death by Top Gun. STEPH: I don't know what the normal way is. [laughs] CHRIS: Like getting shot down by a Top Gun pilot. [laughter] STEPH: Yeah, that makes sense. [laughs] CHRIS: You know, the dogfighting in the plane. STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note. And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec. And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things. But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name. Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up. But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over? How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never. CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles] STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup. CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior's phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here... I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise. And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal. But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it. STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it. And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do. CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing. STEPH: Cool. Well, that's a huge help to me. What's going on in your world? CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well." So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at. But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty. One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there. And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this. STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I? [laughter] CHRIS: What am I actually? STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating. CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly. There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me. Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures. STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool. CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures. And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through. So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting. STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs] CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs] STEPH: No, raving. I will never forget now, raving. [laughs] CHRIS: So, I mean, we've done this before. STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends." [laughter] CHRIS: Actually, we got a handful of emails on that. [laughter] STEPH: Did you know the English language? CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs] But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it. But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake. Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph? STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know. CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still. [laughter] STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters. So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it. So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there. And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it. But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods. So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by. And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this? CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic. And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can. The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before. STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process. Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time. CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that. STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world? CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing. Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event. And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy. As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set. So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either. There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream. So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that. And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together. STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world. And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next? CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application. So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit. But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there. There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It's like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this. But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out. STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again? While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world? CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me. We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it. But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it. STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next. But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user. That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle. CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event. And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event. And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying. STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product. CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls. Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them. STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important. CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you? STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that. But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else. So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans' core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing. The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles] So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together. What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this? And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management. So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes. CHRIS: That was just the first chapter? STEPH: Yeah, that was just the first chapter. CHRIS: My goodness. STEPH: And I shortened it drastically. [laughs] CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true. STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life. But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs] But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through. CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true. STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows? CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it. STEPH: Agreed. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

We've got a tricycle anniversary!

Chris came up with a mnemonic device: Fn-Delete – for when he really wants to delete something and is also thinking about password complexity requirements, which leads to an exciting discussion around security theater. Steph talks about the upcoming RailsConf and the not-in-person option for virtual attendees. She also gives a shoutout to the Ruby Weekly newsletter for being awesome. NIST Password Standards (https://specopssoft.com/blog/nist-password-standards/) 3 ActiveRecord Mistakes That Slow Down Rails Apps: Count, Where and Present (https://www.speedshop.co/2019/01/10/three-activerecord-mistakes.html) Difference between count, length and size in an association with ActiveRecord (https://bhserna.com/count-size-length-active-record.html) Ruby Weekly (https://rubyweekly.com/) Railsconf 2022 (https://railsconf.org/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. You know, each time I do that, I can't resist the urge to say happy Friday, but then I realize people aren't listening on a Friday. So happy day to anyone that's listening. What's new in your world, friend? CHRIS: I'm going to be honest; you threw me for a loop there. [laughs] I think it was the most recent episode where we talked about my very specific...[laughs] it's a lovely Friday, that's true. There's sun and clouds. Those are true things. But yeah, what's new in my world? [laughs] I can do this. I can focus. I got this. Actually, I have one thing. So this is going to be, I'm going to say vaguely selfish, but I have this thing that I've been trying to commit into my brain for a long time, and I just can't get it to stick. So today, I came up with like a mnemonic device for it. And I'm going to share it on The Bike Shed because maybe it'll be useful for other people. And then hopefully, in quote, unquote, "teaching it," I will deeply learn it. So the thing that happens in my world is occasionally, I want to delete a URL from Chrome's autocomplete. To be more specific, because it's easier for people to run away with that idea, it's The Weather Channel. I do not like weather.com. I try to type weather often, and I just want Google to show me the little, very quick pop-up thing there. I don't want any ads. I don't want to deal with that. But somehow, often, weather.com ends up in my results. I somehow accidentally click on it. It just gets auto-populated, and then that's the first thing that happens whenever I type weather into the Omnibox in Chrome. And I get unhappy, and I deal with it for a while, then eventually I'm like, you know what? I'm deleting it. I'm getting it out of there. And then I try and remember whatever magical key combination it is that allows you to delete an entry from the drop-down list there. And I know it's a weird combination of like, Command-Shift-Alt-Delete, Backspace, something. And every single time, it's the same. I'm like, I know it's weird, but let me try this one. How about that one? How about that one? I feel like I try every possible combination. It's like when you try and plug in a USB drive, and you're like, well, it's this way. No, it's the other way. Well, there are only two options, and I've already tried two things. How can I not have gotten it yet? But I got it now. Okay, so on a Mac specifically, the key sequence is Shift-Function-Delete. So the way I'm going to remember this is Function is abbreviated on the keyboard as Fn. So that can be like I'm swearing, like, I'm very angry about this. And then Shift is the way to uppercase something like you're shouting. So I just really need to Fn-Delete this. So that's how I'm going to remember it. Now I've shared it with everyone else, and hopefully, some other folks can get utility out of that. But really, I hope that I remember it now that I've tried to boil it down to a memorable thing. STEPH: [laughs] It's definitely memorable. I'm now going to remember just that I need to Fn-Delete this. And I'm not going to remember what it all is tied to. [laughs] CHRIS: That is the power of a mnemonic device. Yeah. STEPH: Like, I know this is useful in some way, but I can't remember what it is. But yeah, that's wonderful. I love it. That's something that I haven't had to do in a long time, and I hadn't thought about. I need to do that more. Because you're right, especially changing projects or things like that, there are just some URLs that I don't need cached anymore; I don't want auto-completed. So yeah, okay. I just need to Fn-Delete it. I'll remember it. Here we go. I'm speaking this into the universe, so it'll be true. CHRIS: Just Fn-Delete it. STEPH: Your bit about the USB and always getting it wrong, you get it 50-50 [laughs] by getting it wrong, resonates so deeply with me and my capability with directions where I am just terrible whether I have to go right or left. My inner compass is going to get it wrong. And I've even tried to trick myself where I'm like, okay, I know I'm always wrong. So what if I do the opposite of what Stephanie would do? And it's still somehow wrong. [laughs] CHRIS: Somehow, your brain compensates and is like, oh, I know that we're going to do that. So let's...yeah, it's amazing the way these things happen. STEPH: Yep. I don't understand it. I've tried to trick the software, but I haven't figured out the right way. I should probably just learn and get better at directions. But here we are. Here we are. CHRIS: You just loosely referred to the software, but I think you're referring to the Steph software when you say that. STEPH: Yes. Oh yeah, Steph software totally. You got it. [laughs] CHRIS: Gotcha. Cool. Glad that I checked in on that because that's great. But shifting gears to something a little bit deeper in the technical space, this past week, we've been thinking about passwords within our organization at Sagewell. And we're trying to decide what we want to do. We had an initial card that came through and actually got most of the way to implemented to dial up our password strictness requirements. And as I saw that come through, I was like, oh, wait, actually, I would love to talk about this. And so we had the work that was coming through the PR that had been opened was a pretty traditional set of let's introduce some requirements on our passwords for complexity, so let's make it longer. We're going from; I think six was the default that Devise shipped with, so we're increasing that to, I think it was eight. And then let's say that it needs a number, and a special character, and an uppercase letter or something like that. I've recently read the NIST rules, so the National Institute of Standards and Technology, I think, is what they are. But they're the ones who define a set of rules around this or guidelines. But I think they are...I don't know if they are laws or what at this point. But they tell you, "This is what you should and shouldn't do." And I know that the password complexity stuff is on the don't do that list these days. So I was like, this is interesting, and then I wanted to follow through. Interestingly, right now, I've got the Trello boards up for The Bike Shed right now. But as a result, I can't look at the linked Trello card that is on the workboards because they're in different accounts. And Trello really has made my life more difficult than I wanted. But I'm going to pull this up elsewhere. So let's see. So NIST stuff, just to talk through that, we can include a link in the show notes to a nice summary. But what are the NIST password requirements? Eight character minimum, that's great. Change passwords only if there is evidence of a compromise. Screen new passwords against a list of known compromised passwords. That's a really interesting one. Skip password hints, limit the number of failed authentication attempts. These all sound great to me. The maximum password length should be at least 64 characters, so don't constrain how much someone can put in. If they want to have a very long password, let them go for it. Don't have any sort of required rotation. Allow copy and pasting or functionality that allows for password managers. And allow the use of all printable ASCII characters as well as all Unicode characters, including emojis. And that one really caught my attention. I was like, that sounds fun. I wish I could look at all the passwords in our database. I obviously can't because they're salted and encrypted, and hashed, and all those sorts of things where I'm like, I wonder if anybody's using emojis. I'm pretty sure we would just support it. But I'm kind of intrigued. STEPH: You said something in that list that caught my attention, and I just want to see if I heard it correctly. So you said only offer change password if compromised? Does that mean I can't just change my password if I want to? CHRIS: Sorry. Yeah, I think the phrasing here might be a little bit odd. So it's essentially a different way to phrase this requirement is don't require rotation of passwords every six or whatever months. Forgotten password that's still a reasonable thing to have in your application, probably a necessity in most applications. But don't auto-rotate passwords, so don't say, "Your password has expired after six months." STEPH: Got it. Okay, cool. That makes sense. Then the emojis, oh no, it's like, I mean, I use a password manager now, and thanks to several years ago where he shamed me into using one. Thank you. That was great. [laughs] CHRIS: I hope it was friendly shame, but yeah. STEPH: Yes, it was friendly; kind shame if that sounds like a weird sentence to say. But yes, it was a very positive change. And I can't go back now that I have a password manager in my life. Because yeah, now I'm thinking like, if I had emojis, I'd be like, oh great, now I have to think about how I was feeling at the time that then I introduced a new password. Was I happy? Was I angry? Is it a poop emoji? Is unicorn? What is it? [laughs] So that feels complicated and novel. You also mentioned on that list that going for more complexity in terms of you have to have uppercase; you have to have a particular symbol, things like that are not on the recommended list. And I didn't know that. I'm so accustomed to that being requirements for passwords and the idea of how we create something that is secure and less easy to guess or to essentially hack. So I'm curious about that one if you know any more details about it as to why that's not the standard anymore. CHRIS: Yeah, I think I have some ideas around it. My understanding is mostly that introducing the password complexity requirements while intended to prevent people from using very common things like names or their user name or things like that, it's like, no, no, no, you can't because we've now constrained the system in that way. It tends in practice to lead to people having a variety of passwords that they forget all the time, and then they're using the forgotten password flow more often. And it basically, for human and behavior reasons, increases the threat surface area because it means that they're not able to use...say someone has a password scheme in mind where it's like, well, my passwords are, you know, it's this common base, and then some number of things specific to the site. It's like, oh no, no, we require three special characters, so it's like they can't do their thing. And now they have to write it down on a Post-it Note because they're not going to remember it otherwise. Or there are a variety of ways in which those complexity requirements lead to behavior that's actually less useful. STEPH: Okay, so it's the Post-it Note threat vector that we have to be worried about. [laughs] CHRIS: Which is a very real threat factor. STEPH: I believe it. [laughs] Yes, I know people that keep lists of passwords on paper near their desk. [laughs] This is a thing. CHRIS: Yep, yep, yep. The other thing that's interesting is, as you think about it, password complexity requirements technically reduce the overall combinatoric space that the passwords can exist in. Because imagine that you're a password hacker, and you're like, I have no idea what this password is. All I have is an encrypted hashed salted value, and I'm trying to crack it. And so you know the algorithm, you know how many passes, you know potentially the salt because often that is available. I think it has to be available now that I think about that out loud. But so you've got all these pieces, and you're like, I don't know, now it's time to guess. So what's a good guess of a password? And so if you know the minimum number of characters is eight and, the maximum is 12 because that actually happens on a lot of systems, that's actually not a huge combinatoric space. And then if you say, oh, and it has to have a number, and it has to have an uppercase letter, and it has to have a special character, you're just reducing the number of possible options in that space. And so, although this is more like a mathematical thing, but in my mind, I'm like, yeah, wait, that actually makes things less secure because now there are fewer passwords to check because they don't meet the complexity requirements. So you don't even have to try them if you're trying to brute-force crack a password. STEPH: Yeah, you make a really good point that I hadn't really thought about because I've definitely seen those sites that, yeah, constrain you in terms of like, has to have a minimum, has to have a maximum, and I hadn't really considered the fact that they are constraining it and then reducing the values that it could be. I am curious, though, because then it doesn't feel right to have no limit in terms of, like, you don't want people then just spamming your sign up and then putting something awful in there that has a ridiculous length. So do you have any thoughts on that and providing some sort of length requirement or length maximum? CHRIS: Yeah, I think the idea is don't prevent someone who wants to put in a long passphrase, like, let them do that. But there is, the NIST guidelines specifically say 64 characters. Devise out of the box is 128, I believe. I don't think we tweaked that, and that's what we're at right now. So you can write an old-style tweet and that can be your password if that's what you want to do. But there is an upper limit to that. So there is a reasonable upper limit, but it should be very permissive to anyone who's like, I want to crank it up. STEPH: Cool. Cool. Yeah, I just wanted to validate that; yeah, having an upper bound is still important. CHRIS: Yeah, definitely. Important...it's more for implementation and our database having a reasonable size and those sorts of things. Although at the end of the day, the thing that we saw is the encrypted password. So I don't know if bcrypt would run slower on a giant body of text versus a couple of characters; that might be the impact. So it would be speed as opposed to storage space because you always end up with a fixed-length hash of the same length, as far as I understand it. But yeah, it's interesting little trade-offs like that where the complexity requirements do a good job of forcing people to not use very obvious things like password. Password does not fit nearly any complexity requirements. But we're going to try and deal with that in a different way. We don't want to try and prevent you from using password by saying you must use an uppercase letter and a special character and things that make real passwords harder as well. But it is an interesting trade-off because, technically, you're making the crackability easier. So it gets into the human and the technical and the interplay between them. Thinking about it somewhat differently as well, there's all this stuff about you should salt your passwords, then you should hash them. You should run them through a good password hashing algorithm. So we're using bcrypt right now because I believe that's the default that Devise ships with. I've heard good things about Argon2; I think is the name of the new cool kid on the block in terms of password hashing. That whole world is very interesting to me, but at the end of the day, we can just go with Devise's defaults, and I'll feel pretty good about that and have a reasonable cost factor. Those all seem like smart things. But then, as we start to think about the complexity requirements and especially as we start to interact with an audience like Sagewell's demographics where we're working with seniors who are perhaps less tech native, less familiar, we want to reduce the complexity there in terms of them thinking of and remembering their passwords. And so, rather than having those complexity requirements, which I think can do a good job but still make stuff harder, and how do you communicate the failure modes, et cetera, et cetera, we're switching it. And the things that we're introducing are we have increased the minimum length, so we're up to eight characters now, which is NIST's low-end recommended, so it's between 8 and 128 characters. We are capturing anytime a I forgot password reset attempt happens and the outcome of it. So we're storing those now in the database, and we're showing them to the admins. So our admin team can see if password reset attempts have happened and if they were successful. That feels like good information to keep around. Technically, we could get it from the logs, but that's deeply hidden away and only really accessible to the developers. So we're now surfacing that information because it feels like a particularly pertinent thing for us. We've introduced Rack::Attack. So we're throttling those attempts, and if someone tries to just brute force through that credential stuffing, as the terminology goes, we will lock them out so either based on IP address or the account that they're trying to log into. We also have Devise's lockable module enabled. So if someone tries to log in a bunch of times and fails, their account will go into a locked state, and then an admin can unlock it. But it gives us a little more control there. So a bunch of those are already in place. The new one, this is the one that I'm most excited about, is we're going to introduce Have I Been Pwned? And so, they have an API. We can hit it. It's a really interesting model as to how do we ask if a password has been compromised without giving them the password? And it turns out there's this fun sort of cryptographic handshake thing that happens. K-anonymity is apparently the mechanism or the underpinning technology or idea. Anyway, it's super cool; I'm excited to build it. It's going to be fun. But the idea there is rather than saying, "Don't use a password that might not be secure," it's, "Hey, we actually definitively know that your password has been cracked and is available in plaintext on the internet, so we're not going to let you use that one." STEPH: And that's part of the signup flow as to where you would catch that? CHRIS: So we're going to introduce on both signup and sign-in because a password can be compromised after a user signs up for our system. So we want to have it at any point. Obviously, we do not keep their plaintext password, so we can't do this retroactively. We can only do it at the point in time that they are either signing up or signing in because that's when we do have access to the password. We otherwise throw it away and keep only the hashed value. But we'll probably introduce it at both points. And the interesting thing is communicating this failure mode is really tricky. Like, "Hey, your password is cracked, not like here, not on our site, no, we're fine. Well, you should probably change your password. So here's what it means, there's actually this database that's called Have I Been Pwned? Don't worry; it's good, though. It's P-W-N-E-D. But that's fine." That's too many words to put on a page. I can't even say it here in a podcast. And so what we're likely to do initially is instrument it such that our admin team will get a notification and can see that a user's password has been compromised. At that point, we will reach out to them and then, using the magic of human conversation, try and actually communicate that and help them understand the ramifications, what they should do, et cetera. Longer-term, we may find a way to build up an FAQ page that describes it and then say, "Feel free to reach out if you have questions." But we want to start with the higher touch approach, so that's where we're at. STEPH: I love it. I love that you dove into how to explain this to people as well because I was just thinking, like, this is complicated, and you're going to freak people out in panic. But you want them to take action but not panic. Well, I don't know, maybe they should panic a little bit. [laughs] CHRIS: They should panic just the right amount. STEPH: Right.[laughs] So I like the starting with the more manual process of reaching out to people because then you can find out more, like, how did people react to this? What kind of questions did they ask? And then collect that data and then turn that into an FAQ page. Just, well done. CHRIS: We haven't quite done it yet. But I am very happy with the collection of ideas that we've come to here. We have a security firm that we're working with as well. And so I had my weekly meeting with them, and I was like, "Oh yeah, we also thought about passwords a bunch, and here's what we came up with." And I was very happy that they were like, "Yeah, that sounds like a good set." I was like, "Cool. All right, I feel good." I'm very happy that we're getting to do this. And there's an interesting sort of interplay between security theater and real security. And security theater, just to explain the phrase if anyone's unfamiliar with it, is things that look like security, so, you know, big green lock up in the top-left corner of the URL bar. That actually doesn't mean anything historically or now. But it really looks like it's very secure, right? Or password complexity requirements make you think, oh, this must be a very secure site. But for reasons, that actually doesn't necessarily prove that at all. And so we tried to find the balance of what are the things that obviously demonstrate our considerations around security to the user? At the end of the day, what are the things that actually will help protect our users? That's what I really care about. But occasionally, you got to play the security theater game. Every other financial institution on the internet kind of looks and feels a certain way in how they deal with passwords. And so will a user look at our seemingly laxer requirements or laxer approach to passwords and judge us for that and consider us less secure despite the fact that behind the scenes look at all the fun stuff we're doing for you? But it's an interesting question and interesting trade-off that we're going to have to spend time with. We may end up with the complexity requirements despite the fact that I would really rather we didn't. But it may be the sort of thing that there is not a good way to communicate the thought and decision-making process that led us to where we're at and the other things that we're doing. And so we're like, fine, we just got to put them in and try and do a great job and make that as usable of an experience as possible because usability is, I think, one of the things that suffers there. You didn't do one of the things on the list, or like, it's green for each of the ones that you did, but it's red for the one that you didn't. And your password and your password confirmation don't match, and you can't paste...it's very easy to make this wildly complex for users. STEPH: Security theater is a phrase that I don't think I've used, but the way you're describing it, I really like. And I have a solution for you: underneath the password where you have "We don't partake in security theater, and we don't have all the other fancy requirements that you may have seen floating around the internet and here's why," and then just drop a link to the episode. And, you know, people can come here and listen. It'll totally be great. It won't annoy anyone at all. [laughs] CHRIS: And it'll start, and they'll hear me yelling about Fn-Delete that weather.com URL. [laughter] STEPH: Okay, maybe fast forward then to the part about -- CHRIS: Drop them to the timestamp. That makes sense. Yep. Yep. STEPH: Mm-hmm. Mm-hmm. [laughs] CHRIS: I like it. I think that's what we should do, yeah. Most features on the app should have a link to a Bike Shed episode. That feels true. STEPH: Excellent Easter egg. I'm into it. But yeah, I like all the thoughtfulness that y'all have put into this because I haven't had to think about passwords in this level of detail. And then also, yeah, switching over to when things start to change and start to move away, you're right; there's still that we need to help people then become comfortable with this new way and let them know that this is just as secure if not more secure. But then there's already been that standard that has been set for your expectations, and then how do you help people along that path? So yeah, seems like y'all have a lot of really great thoughtfulness going into it. CHRIS: Well, thank you. Yeah, it's frankly been a lot of fun. I really like thinking in this space. It's a fun sort of almost hobby that happens to align very well with my profession sort of thing. Actually, oh, I have one other idea that we're not going to do, but this is something that I've had in the back of my mind for a long time. So when we use bcrypt or Devise uses bcrypt under the hood, one of the things that it configures is the cost factor, which I believe is just the number of times that the password plus the salts and whatnot is run through the bcrypt algorithm. The idea there is you want it to be computationally difficult, and so by doing it multiple times, you increase that difficulty. But what I'd love is instead of thinking of it in terms of an arbitrary cost factor which I think is 12, like, I don't know what 12 means. I want to know it, in terms of dollars, how much would it cost to, like dollars and cents, to crack a password. Because, in theory, you can distribute this across any number of EC2 instances that you spin up. The idea of cracking a password that's a very map-reducible type problem. So let's assume that you can infinitely scale up compute on-demand; how much would it cost in dollars to break this password? And I feel like there's an answer. Like, I want that number to be like a million dollars. But as EC2 costs go down over time, I want to hold that line. I want to be like, a million dollars is the line that we want to have. And so, as EC2 prices go down, we need to increase our bcrypt cost factor over time to adjust for that and maintain the million dollar per password cracking sort of high bar. That's the dream. Swapping out the cost factor is actually really difficult. I've looked into it, and you have to like double encrypt and do weird stuff. So for a bunch of reasons, I haven't done this, but I just like that idea. Let's pin this to $1 value. And then, from there, decisions naturally flow out of it. But it's so much more of a real thing. A million dollars, I know what that means; 12, I don't know what 12 means. STEPH: A million-dollar password, I like it. I feel like -- CHRIS: We named the episode. STEPH: I was going to say that's a perfect title, A Million-Dollar Password. [laughs] CHRIS: A Million-Dollar Password. But with that wonderful episode naming cap there, I think I'm done rambling about passwords. What's up in your world, Steph? STEPH: One of the things that I've been chatting with folks lately is RailsConf is coming up; it's May 17 through the 19th. And it's been sort of like that casual conversation of like, "Hey, are you going? Are you going? Who's going? It's going to be great." And as people have asked like, "Are you going?" And I'm always like, "No, I'm not going." But then I popped on to the RailsConf website today because I was just curious. I wanted to see the schedule and the talks that are being given. And I keep forgetting that there's the in-person version, but there's also the home edition. And I was like, oh, I could go, I could do this. [laughs] And I just forget that that is something that is just more common now for conferences where you can attend them virtually, and that is just really neat. So I started looking a little more closely at the talks. And I'm really excited because we have a number of thoughtboters that are giving a talk at RailsConf this year. So there's a talk being given by Fernando Perales that's called Open the Gate a Little: Strategies to Protect and Share Data. There's also a talk being given by Joël Quenneville: Your Test Suite is Making Too Many Database Calls. I'm very excited; just that one is near and dear to my heart, given the current client experiences that I'm having. And then there's another one from someone who just joined thoughtbot, Christopher "Aji" Slater, Your TDD Treasure Map. So we'll be sure to include a link to those for anyone that's curious. But it's a stellar lineup. I mean, I'm always impressed with RailsConf talks. But this one, in particular, has me very excited. Do you have any plans for RailsConf? Do you typically wait for them to come out later and then watch them, or what's your MO? CHRIS: Historically, I've tended to watch the conference recordings after the fact. I went one year. I actually met Christopher "Aji" Slater at that very RailsConf that I went to, and I believe Joël Quenneville was speaking at that one. So lots of everything old is new again. But yeah, I think I'll probably catch it after the fact in this case. I'd love to go back in person at some point because I really do like the in-person thing. I'm thrilled that there is the remote option as well. But for me personally, the hallway track and hanging out and meeting folks is a very exciting part. So that's probably the mode that I would go with in the future. But I think, for now, I'm probably just going to watch some talks as they come out. STEPH: Yeah, that's typically what I've done in the past, too, is I kind of wait for things to come out, and then I go through and make a list of the ones that I want to watch, and then, you know, I can make popcorn at home. It's delightful. I can just get cozy and have an evening of RailsConf talks. That's what normal people do on Friday nights, right? That's totally normal. [laughs] CHRIS: I mean, yeah, maybe not the popcorn part. STEPH: No popcorn? CHRIS: But not that I'm opposed to popcorn just —- STEPH: Brussels sprouts? What do you need? [laughs] CHRIS: Yeah, Brussels sprouts, that's what it is. Just sitting there eating handfuls of Brussels sprouts watching Ruby conference talks. STEPH: [laughs] CHRIS: I do love Brussels sprouts, just to throw it out there. I don't want it to be out in the ether that I don't like them. I got an air fryer, and so I can air fry Brussels sprouts. And they're delicious. I mean, I like them regardless. But that is a really fantastic way to cook them at home. So I'm a big fan. STEPH: All right, I'm moving you into the category of fancy friends, fancy friends with an air fryer. CHRIS: I wasn't already in your category of fancy friends? STEPH: [laughs] I didn't think you'd take it that way. I'm sorry to break it to you. [laughter] CHRIS: I'm actually a little hurt that I'm now in the category of fancy friends. It makes a lot of sense that I wasn't there before. So I'll just deal with...yeah, it's fine. I'm fine. STEPH: It's a weird rubric that I'm running over here. Pivoting away quickly, so I don't have to explain the categorization for fancy friends, I saw something in the Ruby Weekly Newsletter that had just come out. And it's one of those that I see surface every so often, and I feel like it's a nice reminder because I know it's something that even I tend to forget. And so I thought it'd be fun just to resurface it here. And then, we can also provide a link to the wonderful blog post that's written by Benito Serna. And it's the difference between count, length, and size and an association with ActiveRecord. So for folks that would love a refresher, so count, that's a method that's always going to perform a SQL count query. So even if the collection has already been loaded, then calling count is always going to execute a database query. So this is the one that's just like, watch out, avoid it. You're always going to hit your database when you use this one. And then next is length. And so, length loads the whole collection into memory and then returns that length to the number of items in that collection. If the collection has been loaded, then it's not going to issue a database call. And then it's just still going to use...it's going to delegate to that Ruby length method and let you know how many records are in that collection. So that one is a little bit better because then that way, if it's already loaded, at least you're not going to have a database call. And then next is the size method, which is just the one that's more highly recommended that you use because this one does have a nice safety net that is built-in because first, it's going to check if we need to perform a database call, if the records have been loaded or not. So if the collection has not been loaded, so we haven't executed a database query and stored the result, then size is going to perform a database query. Specifically, it's using that SQL count under the hood. And if the collection has been loaded, then a database call is not issued, and then going to use the Ruby length method to then return the number of records. So it just helps you prevent unnecessary database calls. And it's the reason that that one is recommended over using count, which is going to always issue a call. And then also to avoid length where you can because it's going to load the whole collection into memory, and we want to avoid that. So it was a nice refresher. I'll be sure to include a link in the show notes. But yeah, I find that I myself often forget about the difference in count and size. And so if I'm just in the console and I just want to know something, that I still reach for count. It is still a default for mine. But then, if I'm writing production code, then I will be more considered as to which one I'm using. CHRIS: I feel like this is one of those that I've struggled to lock into my head, but as you're describing it right now, I think I've got, again, another mnemonic device that we can lock on to. So I know that SQL uses the keyword count, so count that's SQL definitely. Length I know that because I use that on other stuff. And so it's size that is different and therefore special. That all seems good. Cool, locking that in my brain along with Fn-Delete. I have two things that are now firmly locked in. So you were just mentioning being in the console and working with this. And one of the things that I've noticed a lot with folks that are newer to ActiveRecord and the idea of relations and the fact that they're lazy, is that that concept is very hard to grasp when working in a console because at the console, they don't seem lazy. The minute you type out user.where some clause, and the minute you type that and hit enter in the console, Ruby is going to do its normal thing, which is like, okay, cool, I want to...I forget what it is that IRB or any of the REPLs are going to do, but it's either inspect or to_s or something like that. But it's looking for a representation that it can display in the console. And ActiveRecord relations will typically say like, "Oh, cool, you need the records now because you want to show it like an array because that's what inspect is doing under the hood." So at the console, it looks like ActiveRecord is eager and will evaluate the query the minute you type it, but that's not true. And this is a critical thing that if you can think about it in that way and the fact that ActiveRecord relations are lazy and then take advantage of it, you can chain queries, you can build them up, you can break that apart. You can compose them together. There's really magical stuff that falls out of that. But it's interesting because sort of like a Heisenberg where the minute you go to look at it in the REPL, it's like, oh, it is not lazy; it is eager. It evaluates it the minute I type the query. But that's not true; that's actually the REPL tricking you. I will often just throw a semicolon at the end of it because I'm like, I don't want to see all that noise. Just give me the relation. I want the relation, not the results of executing that query. So if you tack a semicolon at the end of the line, that tells Ruby not to print the thing, and then you're good to go from there. STEPH: That's a great pro-tip. Yeah, I've forgotten about the semicolon. And I haven't been using that in my workflow as much. So I'm so glad you mentioned that. Yeah, I'm sure that's part of the thing that's added to my confusion around this, too, or something that has just taken me a while to lock it in as to which approach I want to use for when I'm querying data or for when I need to get a particular count, or length, or size. And by using all three, I'm just confusing myself more. So I should really just stick to using size. There's also a fabulous article by Nate Berkopec that's titled Three ActiveRecord Mistakes That Slow Down Rails Apps. And he does a fabulous job of also talking about the differences of when to use size and then some of the benefits of when you might use count. The short version is that you can use count if you truly don't care about using any of those records. Like, you're not going to do anything with them. You don't need to load them, like; you truly just want to get a count. Then sure, because then you're issuing a database query, but then you're not going to then, in a view, very soon issue another database query to collect those records again. So he has some really great examples, and I'll be sure to include a link to his article as well. Speaking of Ruby tidbits and kind of how this particular article about count, length, and size came across my view earlier today, Ruby Weekly is a wonderful newsletter. And I feel like I don't know if I've given them a shout-out. They do a wonderful job. So if you haven't yet checked out Ruby Weekly, I highly recommend it. There are just always really great, interesting articles either about stuff that's a little bit more like cutting edge or things that are being released with newer versions, or they might be just really helpful tips around something that someone learned, like the difference between count, length, and size, and I really enjoy it. So I'll also be sure to include a link in the show notes for anyone that wants to check that out. They also do something that I really appreciate where when you go to their website, you have the option to subscribe, but I am terrible about subscribing to stuff. So you can still click and check out the latest issue, which I really appreciate because then, that way, I don't feel obligated to subscribe, but I can still see the content. CHRIS: Oh yeah. Ruby Weekly is fantastic. In fact, I think Peter Cooper is the person behind it, or Cooperpress as the company goes. And there is a whole slew of newsletters that they produce. So there's JavaScript Weekly, there's Ruby Weekly, there's Node Weekly, Golang Weekly, React Status, Postgres Weekly. There's a whole bunch of them. They're all equally fantastic, the same level of curation and intentional content and all those wonderful things. So I'm a big fan. I'm subscribed to a handful of them. And just because I can't go an episode without mentioning inbox zero, if you are the sort of person that likes to defend the pristine nature of your email inbox, I highly recommend Feedbin and their ability to set up a special email address that you can use to then turn it into an RSS feed because that's magical. Actually, these ones might already have an RSS feed under the hood. But yeah, RSS is still alive. It's still out there. I love it. It's great. And that ends my thoughts on that matter. STEPH: I have what I feel is a developer confession. I don't think I really appreciate RSS feeds. I know they're out there in the ether, and people love them. And I just have no emotion, no opinion attached to them. So one day, I think I need to enjoy the enrichment that is RSS feeds, or maybe I'll hate it. Who knows? I'm reserving judgment. Either way, I don't think I will. [laughs] But I don't want to box future Stephanie in. CHRIS: Gotta maintain that freedom. STEPH: On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

In this special episode of the Path to Well-Being in Law podcast to celebrate Well-Being Week in Law, Chris and Bree sit down with Institute for Well-being in Law VP of Diversity, Equity, & Inclusion Lindsay Draper. Transcript: CHRIS NEWBOLD: Hello Well-being friends and welcome to the first podcast of 2022. This is the Path To Well-Being In Law podcast, an initiative of the Institute for Well-Being in Law. I'm your co-host Chris Newbold, executive vice president of ALPS malpractice insurance. And boy, we've had a lot of fun on the podcast over the course of the last year. I think we just hit our 20th episode and, as most of our listeners know, our goal is to introduce you to thought leaders in the well-being movement doing meaningful work within the legal profession and in the process, we're really working hard to build and nurture a national network of well-being advocates intent on creating a culture shift within the profession. And as always, Bree, we have been together from the beginning. We've done all of our podcasts together. We've not had to had a guest co-host yet. So I'm certainly thankful as we begin the new year to embark on what's really the year three because I think we got started late in- BREE BUCHANAN: That's right. CHRIS: ... 2019, right? BREE: Yeah. CHRIS: And Bree, how are you doing? How were your holidays? BREE: Absolutely wonderful. And yeah, it's just amazing that we are starting our third year of the podcast and I've had so many great guests. I hope the listeners can go back and see the different really thought leaders in the well-being and law space. And the idea of trying to sort of capture what they're thinking, capture trends, and be able to share that among what we really see with the institute is a growing body of people throughout the legal profession who are really passionate about addressing these issues and promoting well-being across the board. And so, we see this as an opportunity to cross-pollinate with ideas and share what's going on. So delighted to be here again and happy new year, everybody. CHRIS: Yeah. What I'm excited about... One of the things I'm excited about is just how our movement has grown in terms of the people that have been welcomed into the movement over the course of the last year. I think that's going to really prove to be exciting from a speaker perspective, as we bring on more guests in 2022. And one of the things... Super excited to kick off 2022 with a three part series in an area that frankly is probably overdue, but something that's critically important as we've thought about where well-being ultimately goes. And that's the intersection of diversity, equity and inclusion with well-being. And so, this will mark the first of three episodes that we focus specifically on that issue because, again, I don't know that you can really differentiate one from the other. And as we all know, if you've met one lawyer, you've met one lawyer and we're all on our individual journey as human beings, right? And there are some really, I think, interesting intersections with diversity, equity and inclusion. I know that we're very excited to kick off the new year with our friend Lindsey Draper to the podcast. If you would take a couple minutes and introduce Lindsey, I know that we're just thrilled to have him as our first guest. BREE: Absolutely. And I love working with Lindsey. I think the most important thing on his bio is that he's on our board of directors. And so, Lindsey has been pulling a major laboring oar with us over the past year plus to really get the institute off the ground and running. And so, Lindsey serves on our board of directors. He is the vice president of diversity, equity and inclusion. And so, just a little bit of background for Lindsey. This is where we make him blush a little bit, but as the Milwaukee County Court Circuit Court Commissioner, he oversaw Wisconsin's adherence to the mandates of the Juvenile Justice and Delinquency Prevention Act as a state's disproportionate minority contact coordinator and compliance monitor. And that was just the day job. And then he retires and goes on to serve in a variety of leadership roles. He served as chair of the ABA standing committee on client protection, which is how I originally met Lindsey and his work in that role. He's currently the chair of the board of directors of the St. Charles Youth and Family Services in Milwaukee. He's been in the past a director at large of the National Client Protection Organization, and as a liaison to the Wisconsin Task Force on Lawyer well-being. And not just a liaison, I'm looking at his bio understates his involvement. Lindsey was really key in the efforts to get that work up and moving. So, Lindsey welcome today. And I'm going to start off by asking you a question we all ask all of our guests at the very beginning to talk to us about... To say hi, but then also talk to us, what are the experience in your life that may be a driver behind your passion for the work that we're doing here at the institute? And I just want to hear a little bit about that. So, Lindsey, welcome to the podcast. LINDSEY DRAPER: Well, first off, Bree and Chris, thank you very much for having me. I'm excited to be here and I want to start with... And part of why I'm excited is that I don't want anyone to miss how much the institute has made diversity, equity and inclusion a focus of the work that is done. One of the things that I recall from the first moment that I was asked about possibly serving in the role of vice president for DEI, one of the things I recall was at the point that I indicated that it was going to be a learning curve for me, because most of my work had been local. It had been in the state of Wisconsin. I was a government employee most of that early part of my career. And then the part that was on the national basis was with the National Client Protection Organization. I needed to learn a lot about what the well-being work involved. Obviously, I saw that the report that the task force did, I initially was the liaison from the National Client Protection Organization. And the reason I had to start with all of that talk was in the work with the National Client Protection Organization, I got the chance to see what happens when lawyers are not healthy. We were involved in trying to make good to people who trusted lawyers. And a large part of that involved clients who were people of color, people who were immigrants, people who were frankly underserved by the legal community. And as I got the chance to see who the victims were and the people who lost, I also came to understand that a number of the lawyers, who frankly messed up, weren't ill intentioned. Many of them had struggles. So, it was having had a number of years working with the standing committee on client protection, working with Wisconsin's committee, that I got the chance to see how important it is for clients that lawyers be healthy. And obviously starting with having been in law school, I've been a part of the legal community. So just watching those areas meant a lot to me. And frankly, by virtue of being African-American, I've seen what difference it makes in various places, whether it's having people in law school assume that I got in as part of an affirmative action outreach. Having people in various parts of the legal community make some assumptions over time that there were limited abilities, I guess. I got the chance to see the impact that, excuse me, underrepresented communities have in the profession and how long term micro and macro-aggressions can have impact on well-being. So, those were all of the things that contributed to why I'm so excited about being part of this. CHRIS: Great perspective. And Lindsey, as you know, diversity, equity and inclusion is such a, I think, vital issue now at the forefront of our profession and frankly, the country at the moment. And even when you go back to our originating report that served as a catalyst to the movement, it's interesting in retrospect to go back and see that there really wasn't a lot of discussion in that report about diversity, equity and inclusion. And obviously as events in society in the summer of 2020 brought this to the forefront, we really can't now put well-being and law in a silo without considering how diversity. equity and inclusion intersects that. And I'm just kind of curious in your mind, how do they intersect and how do you look at that? LINDSEY: Well, there's several pieces. And I think you start with... The question you just asked is a huge part of the answer to the question. There are a number of incredibly well-meaning people who when you point out, "By the way, this didn't get addressed or not a lot of attention got paid to this," are surprised because it didn't occur that the issue of diversity, equity, inclusion played nearly the role that it does. That I don't think a lot of times we are aware. And I frankly need to include myself in part of this discussion. Very early in the role that I had as DEI vice president, I talked with other members of the board, and after having explained what it was that I saw as the goals and after having talked about some of the paths that I would like to see the institute take, I got asked, "Lindsey, do you see this as mainly an issue for people of color?" And it was a whole matter of, "You do know that you never talked about gender in what you were saying." As time has passed, and as I have gotten more and more personally aware of how big the conversation needs to be, it's also become much more important that this not just be a matter of bringing people to the table, but also a continuing dynamic discussion of how do we make sure that the people we have brought to the table stay there, but also feel valued and included as part of the discussion? BREE: Absolutely. Yeah. And I think that it's incumbent upon all of us to pay attention to that. I think about making it where people can stay there and people feel comfortable, valued, welcome in the profession, and that's for everyone. And I also think about it. The issue in regards to particularly well-being, the issue of sustainability in that, how do you make this a profession that everybody can be a part of for a long time because... And I am presented as a white, cisgendered woman, so I have to listen a lot and try to learn, but what I hear and I can certainly understand is the incessant microaggressions that occur in our society and in our profession wears one down. Of course, it would. And it impacts that ability to stay, to work, to make this a sustainable profession for people. Is that something that you see too, Lindsey? LINDSEY: That's a very large part of the conversation. One of the things that I think gets missed sometimes in looking at how people can rise in the profession or how people can stay, is what happens. And the example that was brought to my attention by an attorney in Madison, Wisconsin, had to do with how often he walked into the courtroom, and the very first thing that got said sometimes by bailiffs, sometimes by clerks was as he approached the bench to register or sign in, was wait till your lawyer gets here. The automatic assumption, "You've got to be the defendant. You have to have a lawyer." No opportunity for anybody to learn who this person was. And that's a common experience. The reason that it came up was this was a person who was leaving the legal profession, just simply feeling, "I can't take this anymore." BREE: Wow. LINDSEY: One of the things that happens and depending... My career for the most part was in the juvenile justice system and sometime part of it in criminal justice system, but one of the things that happens there is over time, people learn who you are. If you are in a different part of the system where people don't know who you are, it becomes that much easier for people to make assumptions simply based on having seen you. That, "Oh, you must be the defendant. You must have a lawyer coming to help you out." The other part that... I know people do and say things meaning to be complimentary, but there's a point that you get tired of hearing how well spoken you are or how well you put together a brief. BREE: Oh my Lord. LINDSEY: Where people are surprised that you're competent. And if you stop to think about how over time that regularly occurring beats you down, then you understand why sometimes when you start the discussions that say, "Let's work on DEI," you have some lawyers who say, "I'm tired of educating people. Why are we not talking about making sure I'm healthy?" BREE: Absolutely. Absolutely. One of the things too, also Lindsey, I was thinking in preparation for this podcast, I'm talking to you today is when I go out and do... Because I have a day job and I do speaking on just lawyer well-being issues. And I've really tried to... Have started in the past year and a half to include some discussion on diversity, equity and inclusion. And the piece that I folded into is around kind of unpacking the eye of DEI, the inclusion piece. And the idea of that there's a tremendous amount of scientific research that for people who are excluded and there's a phrase called thwarted belongingness, that that has documented real negative mental health outcomes. And it's really striking to me to hear that. And I think there's nothing for me, personally, that I think is more painful as the idea of being excluded of being kept out of the circle of where things happen. LINDSEY: Yes. BREE: And what an incredibly painful place that is. And I just remember in an early conversation, Lindsey, you and I had, and you talked a little bit about just putting it in very real basic terms about being able to feel welcome in a space. Are you made to feel welcome? And that's a real basic phrase that any human can understand and to not have that... I mean, that just... When you talked about that, I just remembered it cracked my heart open because... And was a real just light bulb for me because I felt I got it on a feeling level. It was just really powerful. Anyway, just thinking about the idea around inclusion, exclusion, and how painful that can be and the damage it can cause over time. LINDSEY: So one of my favorite slides whenever I get the chance to do a presentation is the inclusion slide that says equity is being invited to a party. Inclusion is being asked to dance. That one of the things that's important is not only to be present because you can be present in a whole bunch of places where you're not particularly welcome, frankly, or where people don't necessarily respect what you've got to say. Being marginalized is, I think, the term that for a long time was used to describe what happens. That is that if the discussions at the meeting rarely include any opportunity for what you have to say or what you may think or how certain policies may impact, not just you, but others who have some of the same views than you over time... Well, first off, you start looking, why am I here? Because there's a point that the good salary or, I don't know, the window in your office doesn't carry nearly the weight as, "Oh good Lord. I don't want to go to work today." And so, that's an important piece. Let me go back to something though, Bree. And I want to be sure we talk about one other issue that was part of the inclusion part. And that's the piece that says we have to recognize that all of the issues, and this is part of what I was starting on when I mentioned having had the gender issue brought to my attention. When we're talking about inclusion, there are some parts that we really do see a lot more now than we always did. And for instance, the LGBTQ+ community is one that we at least recognize a bit more. Disabilities are one of the areas that we have to be careful on because part of what... Disabilities, sometimes, they're not just physical. That in the Wisconsin task force, I was reminded that some mental health issues, people who have certain diagnoses who are able to function quite well as lawyers and to be really good lawyers, but sometimes there are some assumptions that get made if in fact anyone knows that I'm being treated for the following. So, I do want to be sure that when we are having this conversation, and that's why the marginalized part of this discussion is important to me, we also recognize that we as lawyers, and frankly, we as people who are trying to be sensitive to the issue, have to be open to the fact that we still don't see everybody at times and don't see the impact of some decisions we make... The open bar, for instance, at state bar conferences is an example that I think we all think of. We sometimes forget the number of golf outings that accompany our events and the bonding time. Not everybody can go to the golf outing or not everybody has interest in it. Sometimes the lack of wanting to drink isn't just a matter of having concerns about substance abuse. Sometimes it has to do with religious reasons. Sometimes it's just health related. So, there are a lot of things that... And the reason that I say the whole well-being issue and DEI issue has to be dynamic, has to be continuous. CHRIS: Well, Lindsey, I think that's a good transition to kind of this. How do we influence leaders and all of our brethren, I guess, in the profession that if you care about well-being, you have to care about diversity, equity and inclusion? And it is about this dynamic continuousness that kind of goes hand in hand. I'd love to hear your perspective on why these are inextricably linked if we're really searching for progress. LINDSEY: Well, first of all, we have to bear in mind that lawyers have clients. We have people that we serve and many of those are people from underrepresented or diverse communities. And it's important to know the perspectives, to know the lives, to know the interest, to know the... I don't know, the well-being and what is in the best interest of the people we serve. Secondly, there's a huge amount of information and perspective that comes. That sometimes there are ways of approaching problems, ways of approaching issues, ways of looking at how do we grow as a profession, how do we improve as a profession that can be better off if we hear different voices. And I think one of the things that at times we forget is that as much as we and the profession may have succeeded because we have a certain outlook and a certain determination, we might have done better if we had included others and if we had looked to what others had to say. The notion that we are a healthy profession, but we don't take into account the well-being of some of our members is one that pretty much contributes to things like the aging of the profession. CHRIS: Let's do this. Let's take a quick break here from one of our sponsors and we're joined by Lindsey Draper out of Wisconsin. And let's take a quick break and we'll be right back. — Advertisement: Meet VERA, your firm's Virtual Ethics Risk Assessment guide developed by ALPS. VERA's purpose is to help you uncover risk management blind spots from client intake to calendaring, to cybersecurity and more. VERA: I require only your honest input to my short series of questions. I will offer you a summary of recommendations to provide course corrections if needed and to keep your firm on the right path. Generous and discreet, VERA is a free and anonymous risk management guide from ALPS to help firms like yours be their best. Visit vera@alpsinsurance.com/vera. — BREE: Welcome back everybody to our podcast. And today we have Lindsey Draper of Wisconsin who is, among many other things, the vice president of diversity, equity and inclusion on our board of directors for the institute. And so, we've been having some really meaningful conversation here in the first half, and I want to... For me, it's been really sort of an interior reflection type of comments and discussion. And I want to move a little bit externally. And so, Lindsey, have you seen out in a legal profession, diversity initiatives that you think are making an impact and any that, quite frankly, aren't? LINDSEY: Okay. So, it's possible to give you a short answer, and that would be yes, but what I want to talk about... And I've mentioned earlier that a lot of what has happened since I've been a part of, first, the task force, and then the institute has been the learning curve for me. And so, one of the pieces that I want to talk about comes from having worked with the Wisconsin task force. And that is when we started looking at who are the people who contribute to the profession and what roles they play. The reason I wanted to start with that is because wonderful work has been being done at law schools. And considering how very much law schools not only have to work with people who are under stress anyway, trying to get into the profession, worried about the fitness question that's going to get examined when they try and get admitted, worried about the interviews for placement. That if you bring to those communities also issues where they're confronted with the questions, do you really belong here? Do you fit in? That I have been just really incredibly impressed with some of the work that law schools have done to recognize that not only do we have students under stress that just as lawyers under stress sometimes resort to some ways that involve unhealthy habits. Law students do as well. And those law students have a great reluctance to ask for help. We're supposed to be the type A achiever. And to admit the need for help is to admit a weakness that most don't want to admit. So what I've seen in schools, and I got the chance to see both what, for instance, the University of Wisconsin did and what Marquette did. Marquette, actually, had a law student who had some substance abuse problems who made not only public his fight, but also the things that he did. And that same story can be replicated at a number of law schools. Some of the members of our committee are actually from law schools. So, I want to start with, I have been extremely impressed with the work that a number of law schools have, including recognizing that it would be important to bring people from those governmental entities that will decide if you get admitted to the bar to say, "You need to address what will keep you healthy. We will work with you. We want you to be a healthy lawyer." As opposed to, "We're looking for reasons to not let you in." That's such a critical message for law schools to get across early is, do not be afraid to seek help. Get it before you hurt yourself, your client, and the profession. So that would be one of the things that I think is important on a governmental area. We at the institute have the incredible benefit of having service from representative from Massachusetts. Looking at the work that they have. Looking at people who have developed not only an interest and a commitment to diversity, equity, inclusion, and well-being, but also embedded in their work. People who have this focus. So, I look to the state of Massachusetts because, frankly, a lot of what I personally have been able to learn and do came from patterning after a lot of what they did. So, there are a number of places. There are a number of states that were leaders. You can't overlook the work that Virginia did, but in looking at DEI, those would be two things. One is a huge amount of respect for law schools. Secondly, looking at states like Massachusetts. CHRIS: Lindsey, is that because of the advancements made in welcoming conversation around challenges that those individuals in law school or in states ultimately feel? I mean, is it a cultural component because, obviously, there's admission related issues as well and other areas? So, it kind of feels to me that... Again, going back to this feeling welcomed in the space of becoming a lawyer, being licensed as a lawyer, being welcomed into the courtroom, how you're perceived. It seems to go back to that notion of how we start the process is critically important to a cultural evolution that if it continues can only benefit both the profession and the way that the profession is seen. LINDSEY: So, I think my answer to that would be, again, sort of twofold. And just sort of bear in mind that there is... And I touched on it a second ago. There is no single African-American lawyer, African-American female lawyer, gay African-American female lawyer. I mean, that there are so many different parts of who people are. And one of the things that happens over the course of life is you develop sensitivities to things. And there are frankly people who look for aggression, but there are also people who recognize when it's happening. Well, if you just start with that, and then you realize that you've got a culture in the legal profession, and you've got some decisions that people have to make. And where I'm going with this is if, for instance, you have a law firm that welcomes a member of an underrepresented group into the firm and decides we want you here, and here's your case. And that person ends up getting treatment for substance abuse, for instance. Does the firm run the risk in not letting the client know? Have you shared some information you weren't supposed to share? If you don't, have you not done the right thing by your client? And then if the attorney hears or feels that he or she is being undercut, I think the normal first response is going to be because I'm African-American or because... And you think about how many different questions arise under the circumstances. That's why the commitment to the whole "D", the whole "E", and the whole "I" is critical. Because there are a lot of questions that are going to arise and a lot of decisions that are going to have to be made all the way along. You can't be human without having some things happen in your life. You're not going to be perfect your whole life. And you just need to be sure that when we take a look at the decisions that get made, they're made in a comfortable environment. CHRIS: Lindsey, as vice president of diversity, equity and inclusion for the institute, talk a little bit about... Again, it's been a journey thus far, right, in terms of including more perspectives. And I'd love for you to expand on some of the areas that you see the group kind of laying out part of its strategic plan to ensure that there again is a connectedness between these two issues that we know is real and only if we work on them in conjunction, will we see even stronger progress. LINDSEY: Well, you actually raised a significant part there when talking about the strategic plan because among the things that happens, the more people you have on a committee, the more different ideas you have, the more different areas of focus that you're going to have. But one of the things that's been really critical... And I really do have to say how proud I am to be part of the institute, and the institute has made a conscious effort to say, "We may have messed up in not looking at some things from the beginning," but we want to do that. The committee has made a big point of saying, "We can help the other parts of the institute if we know what they're doing before everybody's way down the road, if we can be part of helping frame the questions get asked." And an example of what I am discussing, one of the things the committee has said is, I've looked at the panels presenting at various entities or various programs, I don't see a whole lot of underrepresented people on these panels. Part of what the committee has is the ability to help the institute because the institute has said, "Give us some names. Help identify people who are very capable, who are very knowledgeable, but who haven't had the opportunity to show that." That's why, for instance, where you've had members who've been active in presenting conferences, they know some speakers that maybe others don't know. They know some people who've done research that maybe others haven't seen. So, not only making sure that there are diverse voices in the decisions of the institute and in the work of the institute, but also making sure that we are looking for other capable, accomplished people who can bring not just a different perspective, but also an incredible expertise to the work that we're all doing. CHRIS: Bree, you might be on mute. BREE: Oh. CHRIS: There you go. BREE: So I think we may have just found our first time when we have to edit. [inaudible 00:39:37]. CHRIS: [inaudible 00:39:39]. Let's just keep going. Let's keep going, Bree. We're good. BREE: Sorry. My voice has given out. [inaudible 00:39:47] just take a moment here. I was thinking that we would move towards sort of wrapping up just because of the time. CHRIS: Lindsey, I'd love for our final question to be just, I guess, a reflection point, right, of you've seen a lot of activity in this arena, right. We're clearly not where we need to be. Although I think in some respects we are more readily talking about some of the challenges in a much more robust way than ever before, but I'd love for you to just give your perspective on your outlook for the future. Are you optimistic? Is the tenor of the discussion moving in ways that has you excited, cautiously optimistic, fearful, right? So, I would just love for you to kind of give us as we kind of conclude this podcast, your perspective, as we think about well-being, as we think about challenges of diversity, equity and inclusion, as we see those kind of coming together, what do you think? What's your sense of where we currently stand and where we're going? LINDSEY: We have to start with, I'm incredibly optimistic. There's a part of me that's incredibly grateful that we're having this conversation, that there was a time when we were not. That as more and more people become aware that well-being, which everybody seems to be comfortable with, that's an important piece, affects different people differently, and it's important that well-being go across the board, that all lawyers be able to address well-being and the way that they address it isn't the same. We're talking about that, but more than just talking about it, the fact that there is an effort being made to identify, not just that there's a problem, but to offer steps that people can take to try and address the problem. I carefully avoided the word "solutions" because that's hard to say. Our profession is constantly evolving. There are things from left field, the pandemic, for example, that no one would anticipate that have impact on well-being of lots of people, affect some communities more than others and in different ways. So, I feel really good that we are having the discussion. I am somewhat worried that DEI is a term that sometimes people say, "Okay. We have to do that. Everybody's got to have that discussion. Everybody's got to have that committee." I worry a bit that just like the assumptions got made about affirmative action a half century ago that DEI may become the... Oh, yes. We have to have that conversation. But that's why I've been really thrilled to be part of the institute where, "No, this is not item seven on the agenda," and we'll talk about it after we get all the business of the day taken care of. That it's been something that from the very beginning, the institute has said, this is a priority. And the fact that there's an effort made to keep it there. So, be cautiously optimistic, but also really pleased that we're having the conversation and that we've been able to identify so many, very talented, valuable, committed people who are working on the area. CHRIS: Yeah. And I think that's a great way to end, I think, this podcast is again, how influential you, your committee has been at looking to shape the perspectives that are coming in to ultimately building the movement and setting the tone for the culture shift that I think that we are all yearning for, which is to make well-being a centerpiece of professional success in the profession. From my own perspective, we all have to be more sensitive to some of the challenges. And as we allocate resource bandwidth as an institute, just being mindful that... Again, going back to... If you met one lawyer, you've met one lawyer and we're all on our own individual journeys as human beings. And some of those challenges are markedly, markedly different for some relative to others. Lindsey, a heartfelt thank you for, again, your leadership, your work, your vision, your vulnerability, in terms of being able to say, "I don't know at all, but I'm certainly going to lean in with my perspectives and I'm going to learn along the way," because I know that you're in a learning journey, I'm in a learning journey, Bree's in a learning journey, right, of- BREE: Absolutely. CHRIS: ... betterment, right. Of again, having a passion for making a better profession, and one that's more responsive to not just the needs of the lawyers that compose it, but ultimately the people that we serve who depend on us to be solution makers for the betterment of society. So, Lindsey- BREE: And I just wanted to throw in here too. I really appreciate the conversations that we have. I've had multiple conversations with Lindsey and that this is an ongoing conversation, an ongoing discussion. And one that we continue to pick back up again and again and again throughout our work. And that's been a delightful aspect, Lindsey, working with you is that we can have these conversations and really honest ones. And so, thank you. Thank you for that. CHRIS: For sure. BREE: I thank you and I'm very grateful for the opportunity to be a part of the institute and its work, but also for the incredibly talented people with whom I've had the opportunity to serve. CHRIS: Yeah. And we will be back with more perspectives around this particular issue in our next couple of episodes. And again, for those of you who are new to the podcast, just some really insightful conversations with all different types of leaders of our movement in our first 20 episodes. I would encourage you to go back and look at the synopsis on our website. One of the things I'll also conclude with is, I think we will include our diversity, equity and inclusion policy that was adopted by our board of directors. Actually, our first action as a governing board. We'll post that in conjunction with this podcast as well. So, signing off. Be well out there, friends, and we will be back in a couple weeks. Thanks.  

Chris got a bike. Specifically, he bought a bike to use in a triathlon he signed up to participate in. Now he needs to name the bike, and speaking of naming things, a more technical topic that he talks about is the Crispy Brussels Snack Hour. Steph talks about Rescue Rails projects and increasing developer acceleration. They answer a listener question asking, "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?" This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Translate frustrations into professional corporate (https://twitter.com/MeanestTA/status/1509936432625897474) Learn Hotwire by Building a Forum (https://twitter.com/afomera/status/1512287468078264322) parallel_tests (https://github.com/grosser/parallel_tests) parallelsplittest (https://github.com/grosser/parallel_split_test) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Oh, but I recently learned that Robert Downey Jr. in the Marvel movies he's snacking a lot, maybe not Iron Man, but something...oh no, he's stacking a lot. And I'd read that he was snacking a lot on set, and so they just built it in to where like, sure, you can snack as your character while you're doing stuff. CHRIS: [laughs] STEPH: And I think that's so cool because I find that I am eating every time I show up to record with you. So I would like the same special star treatment as Robert Downey Jr., [laughs] and I just get to eat during each Bike Shed. [laughs] CHRIS: All right. [chuckles] My understanding is also that he was wildly the highest paid of all the actors, so I think that should also come along with this. STEPH: [laughs] CHRIS: Yeah, there's a lot that we can sort of layer on here, but it makes sense to me, and I'm fully on board. STEPH: You're an excellent agent. Thank you for fighting for my higher pay. [laughter] CHRIS: You are welcome. STEPH: What a good co-host you are. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. One of these days, I'm going to say, "I'm Chris Toomey," and then I'm just going to see how you roll with it, although now I'm ruining it, I should have just gone for it. [laughs] CHRIS: Nothing can prepare me for this despite the fact that you're telling me in this moment. In that future moment when you do it, I will still be completely knocked out of whack. Just like for anyone out there listening, the thing that Steph would normally have said instead of what [laughs] she just said was, "What's new in your world?" STEPH: [laughs] CHRIS: And I contractually require that that is the only way she starts this question to me because I get completely lost. She's like, "How are you doing?" I just overthink it, and I get lost, and then we end up in a place like this where I'm just rambling. STEPH: Every podcast contract you have from here on out must begin with hey, Chris, what's new in your world? [laughs] I will still get to that question. I just also had to tell you my future joke. I'm going to play that. Hopefully, you'll forget, and one day I will resurface. CHRIS: I can pretty much promise you that I'm going to forget it. [laughter] STEPH: Excellent. Well, to make sure I stick within the Chris Toomey contract guidelines, hey, Chris, what's new in your world? CHRIS: What's new in my world? Now I just want to spend a lot of time putting together my rider. There can be no brown M&M's in the bowl. No eye contact, please. And I can only be addressed with this one question which is, to be clear, very not true, Steph. And I always record with a video because we actually like to have human faces attached to things. Anyway, I'm going to tighten this all up. When we get to the technical segment of my world, I'm going to tell you about Crispy Brussels Snack Hour, so just throwing that out there as an idea. But before we do that, I'm going to share a fun little thing which is I bought a bike, which is exciting. It's not that exciting. People have bikes. This is exciting for me. But the associated thing that is more exciting/a little terrifying is I'm going to try and run a triathlon. I'm going to try and run, swim, and bike a triathlon as they go, specifically a sprint triathlon for anyone out there that's listening and thinking, oh wow, that sounds like a thing. The sprint is the shortest of the distances, so that's what I'm going to go for. But yeah, that's a thing that I'm thinking about in my world now. STEPH: I know next to nothing about triathlons. So what is a sprint in terms of like, what is the shortest? What does that mean? CHRIS: I think there actually maybe even shorter distances but of the common, there's sprint, Olympic. I want to say half Ironman, and then Ironman are the sequence. And an Ironman, as far as I understand it, I think it's a full marathon. It's like a century bike ride or something like that. It's an astronomical amount of everything. Whereas the sprint triathlon being the shortest, I think it's a 3.6-mile run, so a little over a 5K run, a 10-mile bike ride, and a quarter-mile swim, I want to say, something like that. But they're each scaled down to the rough equivalent of a 5K but in each of the different events. So you swim, and then you bike, and then you run. And so I'm going to try that, or at least I'm going to try to try. It's in September, and now is not September. So I have a lot of time between now and then to do some swimming, which I haven't done...like, I've swum but not in a serious way, not in an intentional way. So I got to figure out if I still know how to swim, probably get better at biking, and do a little bit of running, and it's going to be great. It's going to be a lot of fun. I'm super excited about it. Only a little terrified. STEPH: I think this is where as your co-host coach, which you have not asked me to be, where I would say something about there is no try, to mimic Yoda. [laughs] CHRIS: Yep, yep. Yep. Do or do not. Sprint or sprint not. There is no trying. Oh, were you making a try pun there? STEPH: I didn't go that far, but you just brought it home. I see where you're going. [laughs] CHRIS: This is pretty much what I do professionally is I just take words, and I roll them around until I find something else to do with them. So glad that we got there together. STEPH: Well, I'm really excited to hear about this. I don't know anyone that's trained for a triathlon. I think that's true. Yeah, I don't think I know anyone that's trained for a triathlon. So I'm curious to hear about how that goes because that sounds intense, friend. CHRIS: I think so. None of the individual segments sound that bad but stitching them all together, and I think the transitions are some of the tricky parts there. So yeah, it'll be fun. It's something I find...I used to never run; that was the thing. Like, deeply true in my head was that I'm not a runner. This is just a true fact about me. And then I ran a 5K one year for...it was like a holiday 5K fun run with friends. And every bit of the training leading up to it was awful. I did Couch to 5K. I hated it. My story in my head of I'm not a runner was proven with every single training run. Man, did I hate it. And then something magical happened on the day that I actually ran the race, and it was fun. And I was out there, and there was the energy of being in this group of people. But it was competitive and not competitive in this really interesting way. And then it ended, and we were just hanging out in a parking lot, and they gave us beer. And I was like, well, this is actually delightful. Maybe I actually like this thing. And so I've run a bunch of different races. And I've found that having a race to train for, and by train, I just mean some structured attempt at running, has been really enjoyable and useful for me. So yeah, this is just ratcheting that up a tiny bit. I've done a couple of half marathons is the high watermark so far. It's a good distance. But I don't know that a full marathon makes sense; that's a real commitment. And I'm looking to move laterally rather than just keep getting more complex in my running. So we're trying the shortest possible triathlon that I know of. STEPH: I am such a believer that exercise should be fun, so I love that. Like, I'm not a runner, but then you get around people, and it's exciting. And then there's that motivation, and then there's a fun ending with beers that totally jives with me. Because sure, I can go to the gym; I can lift weights, I can make myself exercise. There's some fun to it. But I strongly prefer anything that's more of like a sport or group exercise; that's just so much more fun. Well, super cool. Well, I'm excited. I would ask you all the details about your bike, but I know nothing. Do you want to share details about your bike? There may be other people that are interested. CHRIS: Oh yeah, my bike. I went to the bike store, and I said, "Could I have a bike, please?" And then they toured me around and showed me all the fancy...they were like, "This is our most modest entry-level bike." And then they kept walking around and showing me fancier bikes. And I was like, "Can we go back to that first one? That one seemed great." STEPH: [laughs] CHRIS: Because it got all of the checkboxes I was looking for, which is basically it's a bike. So actually, the specifics on it are it's a hybrid bike, so like a mix between road, and I don't even know the other road bikes I know of, and maybe it's trail. But I don't think it's meant for going on the trail. But for me, it'll be fine for what I'm trying to do as far as I understand it. It's technically a fitness hybrid, which I was like, oh, fancy. It's a fitness bike; look at me go. But it was basically just like, I would like a bike. General-purpose hybrid seems like the thing that makes sense. So I got a hybrid bike. And that's where I'm at. Oh, and I got a helmet because that seems like a smart move. STEPH: Nice. Yeah, the bike I own is also one of those hybrids where it's like…because when I moved to Boston...and lots of people have the road bikes, but their tires are just so skinny; it made me nervous. And so I saw one of the hybrid bikes, and I was like, that one. That looks a little more steady and secure, so I went with that one even though it's heavier. Do you have a name for your bike? Are you going to think of a name for your bike? CHRIS: I didn't, and I wasn't planning on it. But now that you've incepted me with this idea that I have to name my bike, of course, I have to name my bike. I'm going to need a couple of weeks to figure it out, though. We're going to have to get to know each other. And you know, something will become true in the universe for me to answer that question. But as of so far, no, I do not have a name for the bike. STEPH: Cool. I'll check back in. Yeah, it takes time to find that name. I feel you. CHRIS: [laughs] Yeah, don't make up a name. I have to find what's already true and then just say it out loud. Speaking of naming things and perhaps doing so in a frivolous way, as I mentioned earlier, the more technical topic that I want to talk about, oddly, is called Crispy Brussels Snack Hour. [laughs] So, within our dev team, we have started to collect together different things that don't quite belong on the product board, or at least they're a little more confusing. They're much more technical. In a lot of cases, they are...our form handling is a little rough. And it's the sort of thing that comes up a lot in pull requests where we'll say, "I feel like this could be improved." And we're like, "Yeah, but not in this pull request." And so then it's what do you do with that? Do you put a tech debt card in the product board? You and I have talked about tech debt cards plenty of times, and it's a murky topic. But we're trying within the team to make space and a way and a little bit of process around how do we think about these sorts of things? What are the pain points as a developer is working on the system? So to be clear, this isn't there is a bug because bugs we should just fix; that's my strong feeling, or we should prioritize them relative to the rest of the work. But this is a lower level. This is as a developer; I'm specifically feeling this sort of pain. And so we decided we should have a Trello board for it. And they were like, "Oh, what should we name the Trello board?" [laughs] And I decided in this moment I was like, "You know, if we're being honest, I've named everything very boring, very straight up the middle. We don't even have that many things to name. So we have zero frivolous names within our team. I think this is our opportunity. We should go with a frivolous name. Anybody have any ideas?" And someone had worked on a team previously where maybe it was a microservice or something like that was called crispy Brussels, like, crispy Brussels sprouts but just crispy Brussels. And so I was like, "Sure, something like that. That sounds great." And then they ended up naming it that which was funny, and fun, and playful in and of itself. But then we were like, "Oh, we should have a time to get together and discuss this." So we're now exploring how regularly we're going to do it. But we were like, let's have a meeting that is the dev team getting together to review that board. And we were like, "What do we call the meeting?" And so we went around a little bit, but we ended with the Crispy Brussels Snack Hour. STEPH: That's delightful. I love the idea of onboarding new people, and they just see on their calendar it's Crispy Brussels Snack Hour, come on down. [laughs] CHRIS: It's also got an emoji Brussel sprout and an emoji TV on either side of the words Crispy Brussels Snack Hour. So it's really just a fantastic little bit of frivolity in our calendars. STEPH: [laughs] That's delightful. How's that going? I don't think we've tried something like that explicitly in terms of, like you said, there are discussions we want to have, but they're not in the sprint. They're not tech debt cards that we want to create because, like you said, we've had conversations. So yeah, I'm curious how that's working for you. CHRIS: Well, so we've only had the one so far; it went quite well. We had a handful of different discussions. We were able to relatively prioritize this type of work within that. But one of the other things that we did was we had a conversation about this process, about this meeting, and the board. And whatnot. So we identified a couple of rules of the road or how we want to approach this that I think will hopefully be useful in trying to constrain this work because it's very easy to just like; nothing's ever perfect. And so this could very easily be a dumping ground for half-formed ideas that sound good but aren't necessarily worth the continued effort, that sort of thing. So the agenda for the meeting as described right now is async between meetings. Any of us can add new cards, ideally stated as problems and not solutions. So our form handling could use improvement. And then in the card, you can maybe make a suggestion of I think we could use this library or something like that. But rather than saying use this library or move to this library, we frame in terms of the problem, not necessarily the solution. And then, at the start of the meeting, any individual can champion a card so they can say, "Here's the thing that I really want everyone to know about that I've been feeling a lot of pain on." So it's a way for individuals who have added things to this to add a little bit more detail. Then using Trello as voting functionality, we each get a couple of votes, and we get to sprinkle them across different cards, and then using that now allows us collectively to prioritize based on those votes. And so the things that get voted up to the top we talk about; we prioritize some amount of work coming into the sprint. If it's actually going to turn into work, then it'll go onto the product board because ideally, it's moved from problem space to more of solution space even if the solution, the work to be done is do a spike on XYZ library or approach to form handling or whatever it is. But so ideally, it then moves on to the other board. The other thing that I felt was important is it's very easy for this to be a dumping ground for ideas. So my suggestion is at the end of the meeting, we sort by date, and we prune the oldest things. So it's like, if it's still hanging around and we haven't done it yet, and it's not getting voted up, then yes, we might feel some pain but not enough. It's not earning its place on this board. So that's my hope is we're weeding the Brussel sprouts garden that we have at the end of the meeting. That's roughly what we have now. We really only had the one, so that idea of pruning will probably come in later on. And it may be that this doesn't work out at all, and this ends up being tech debt cards that get stale and don't capture the truth. But I'm hopeful because there's definitely...there's a conversation to be had here. It's just whether or not we can make sure that conversation is useful and capturing the right amount of context and at the right points in time and all of that. STEPH: Yeah, I like it. I like the whole process you outlined. You know what it made me think of? It sounds like a technical retro, not that retros can't be technical; we bring up technical stuff all the time. But this one sounds like there was more technical discussion that was still looking for space to bring up. So the way that you mentioned that people add their thoughts, that it can be done async, and then you vote up, and then as things get stale, you remove them and focus on the things that the team voted for, that's really cool. I've never thought of having just a technical-specific retro. CHRIS: Yeah, definitely informed by retro. But again, just that slight honing the specific focus of this is just the dev team chatting about deeply dev-y things and making a little bit of space for that. I think the difficulty will be does this encourage us to work on this stuff too much? And that's the counterbalance that we have to have because this work can be critically important. But it can also be a distraction from features that we got to ship or bugs that are in the platform or other things like that. So that balancing act is something that I'm keeping in mind, but thus far, the way we structured it, I'm hopeful. And I'm interested in exploring it more, so we'll see where we get to. And I'll certainly report back as we refine the Crispy Brussels Snack Hour over time. STEPH: I feel like the opposite is true as well, where you have these types of concerns and things that you want to bring up. And even if they're on the board, once you get to sprint planning, there's a lot of context and conversation there that maybe the whole team doesn't have. It doesn't feel like the right moment to dive into this because you're trying to plan a new sprint. So then that stuff gets bumped down to the bottom or just never really discussed, or it gets archived. So I feel like the opposite is totally true, too, where you have this stuff, but then it never gets talked about because sprint planning is not the right place. So yeah, I'm really intrigued to see how that balance works out for y'all as well. CHRIS: Yeah, I think it's an exciting time, and we'll see where it goes. But like I said, I'm hopeful on it. But yeah, bikes, triathlons, and crispy Brussels, that's my world. Mid-roll Ad: Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: I have a couple of fun things that I want to share and then something that's a little more in the techie space. The first one is there's a delightful Twitter thread that caught my attention recently that I just want to share; totally not tech-related. But this person shared a thread talking about how they help everyone on their team who's older than they are, making sure that the slang that they're using is correct in its context. And so they provided some funny examples. And then, in return, they also will translate this person's frustrations into professional corporate-speak, and it's such a good thread. So if you need a good laugh, I will make sure to include a link in the show notes. The slang is really funny, but it's actually the translation of frustrations into professional corporate-speak that that's the part that resonated with me. That was really good. [laughs] CHRIS: You shared this with me outside of this conversation, and I've read through them. Listeners out there, do not sleep on this. I highly suggest reading through this thread because it is fantastic. STEPH: The other thing that I saw is Andrea Fomera, who is a Rails developer and creates a fair amount of content...I haven't been through some of that content, but I know there's content around Rails. And specifically, there is a newer course called Learn Hotwire by Building a Forum. And she has made this totally free, and I just think that is so cool. And she shared that on Twitter, so I'll be sure to include a link in that to the show notes because Hotwire is something I haven't used yet. And so I saw this free course, and I think it would be fun to dabble and go through the course. And I know there are some other people at thoughtbot that have used it and seem really happy with it or interested in using it as well. Is that something that you've used? CHRIS: I have not. I skipped over Hotwire in my adventures. I'd found Inertia and was quite happy with that. And then, in that way that, I sometimes limit the amount of things that I'm allowed to explore on the internet in hopes of actually getting some work done; I have not spent much time. But enough folks that I deeply respect are very excited about Hotwire that it remains in the like; I would love to have an afternoon just to poke around with that. So I may take a look at this, although I don't know, I'm probably still in my moratorium. I'm not allowed to look at new frameworks for a little while time period. But I hear great things. STEPH: That's fair. That's also what I've heard. I've heard great things. So yeah, I just figured I would share that in case anybody else is interested in looking for a course that they could take and also dabble at Hotwire. The other thing that's on my mind is more the type of projects that I'm really getting a lot of joy from. Because I've known about myself for a while that greenfield projects are nifty, but they're not my thing. They're not the thing that brings me a lot of joy. It's just kind of nice. You got your own space, and you're building from the ground up, cool, cool, cool. But this one, I found that the projects that I'm really starting to gravitate towards are what I've heard someone else call Rails Rescue projects. So those are the projects where they have been around for a while, or they've just been built in a way that the data modeling structure makes it really hard to implement new features. Maybe there's a lack of test coverage that makes it really risky to ship new work or to make changes. There are lots of bug reports and errors that the team is fighting with. So then that type of work comes down to where you're trying to either increase stability for the application and for users and/or you're looking to increase developer acceleration. And I really, really liked those projects. That's the type of project that I've been a part of for...I think my last couple of clients have been in that way. I don't know that they would describe it that way, that it's a Rails Rescue project. But if I can see that opportunity where I see there's a stability issue or developers are feeling a lot of pain in one area, then that's the portion of the application, the portion of the team that I'm going to gravitate towards. Or like the current work that I'm doing where we're really focused on testing and making some improvements there or reducing that pain that the team is feeling around how long CI takes to run or the flakiness because then you're having to re-verify your CI runs. I like that work. It's a bit slow and frustrating, so it does seem to require a patient person. You also have to have lots of metrics that are guiding you because you can have a lot of assumptions around I'm going to make this improvement, but it's going to take effort to get there. And it'd be great if I can validate that effort upfront. So I feel like a lot of my time is spent more around metrics, and data, and excel sheets than necessarily coding. I don't know if that's great, but it's part of the work. There's a balance there. So I just found that interesting. I don't think I would have thought this is something I was interested in until now that I've been on these projects for a while. And I've started noticing a theme where I really enjoy them. Although I realize looking back at former Stephanie days when I was going through Launch Academy and learning to code, I really thought I wanted to be in DevOps. DevOps seemed like the cool kids' corner. They knew how the internet worked. They knew what was happening. They were making it live. And I just thought it seemed really cool. For the record, it is still a cool kids' corner. But I have also learned that the work-life balance isn't great with DevOps because you just never know when you're going to be on call. And that really stood out to me as something that I didn't want to do. And I do like building some features. But essentially, it's that developer acceleration that I really liked because they were the ones that were coming and often building tools and making it easier for then people to then ship their code and get it out into the world and triage. And so I liked the fact that their users were developers versus the people using the application as much, although, I guess, technically both. But the people they were often striving to help the most was the internal team, and that resonated with me. So I guess I have eventually found my way into that space. It wasn't through DevOps, but it is now through this idea of projects that need some rescuing. CHRIS: I love that you've spent enough time now to figure out what it is that draws you in the work and the shape of projects that is meaningful to you. Interestingly, I find myself not on the opposite side of things...you know, we're always looking for a disagreement, and this isn't a disagreement, but this is a thing on which we differ a surprising amount because I do like the early-stage stuff, the new, the breaking ground, all of that exciting whatnot. But how do I not make this a more complicated statement? I appreciate that you have the point of view that you do. I think the world needs more of what you're doing than the inclination that I have, like; I want to start something bright, and fresh, and new, and I can see so much progress immediately in front of me. And this is amazing. But the hard, meaningful work like maintenance, and support, and legacy, and rescue where necessary is such a critical aspect of the work. I see this in open source so often where there are people who are like; I made an open-source project; this is great. I hacked for a bunch of weekends, and look; I made a thing. And then the support burden builds up. And open source can be this wildly undervalued thing overall. And the maintenance of open source is even more so, and you have this asymmetry between the people that are using it and don't think that their voice is one of the thousands that are out there requesting a new feature or anything like that. The handful of people that I see out there in the world that come along later in the lifespan of an open-source project and just step in to do maintenance, my goodness, is that heroic work, just quiet, necessary heroic work. And what you're describing feels sort of similar but at the project level. And I don't know; I'm sort of like silent. I'm out loud on a podcast, not silently at all judging myself because I'm like, I feel like you're doing the thing over there. That seems like a good thing. But I also like my early projects... [laughs] STEPH: I think they're...I mean, we need each other. I need you to start the code, and the applications for them to then need some help down the road [laughs] to [crosstalk 24:30]. CHRIS: But I need to do a bad enough job that we have to be rescued by you. STEPH: [laughs] CHRIS: Hey, don't you worry, friend, I'm doing a terrible...no, I think I'm doing an okay [laughter] job. Hopefully, I'm avoiding those traps, but it's hard to know when you're writing legacy code, you know. STEPH: It is hard for the reasons we were talking about earlier. Like, those technical discussions build-up, and then if you don't really have a space to then address it, then it just keeps getting sidelined until you suddenly get to this point of it's either we come to a grinding halt because we can't ship work, or we find ways to start bringing this into our process. And so that's the other part of the Rails Rescue projects is often looking at the team's process and figuring out, okay, instead of hiring consultants to come in and then try to help with this, how else can they also integrate this into their own project? So then, once thoughtbot lives, they now have ownership of this, and they can carry it forward as well. There is an aspect of this work that I'm still working on, and it comes around to the definition of work because if you go into a team or a project that's like, hey, we really need help with X. We really need help with addressing all these errors. Or we really need help improving developer happiness or getting test coverage in place. Finding out exactly how you're going to tackle that, are you going to join a team of the other developers? Like, are you looking for more of a mentorship? Like, hey, we're going to work alongside your team to then mentor them to then bring this into their own process and their own habits, so then they feel empowered to address this in the future. Are we doing this more as a triage where then we have a specific goal or two that then we're going to meet? And then once we get stuff out of this on fire state, then maybe we start pairing with other people. Or are we going to work closely with the people who are fighting fires with the bug reports and the errors? There are a bunch of different ways that you can tackle that. And I think it really helps define the success of that engagement and then your outcomes because otherwise, I feel like you can get distracted by so much. Because there's so much that's going to try to get your attention that you want to work on and fix. So you have to be very upfront about there are different areas that we can work on. Let's figure out some metrics together that we're really going after to then help define what does success look like for this first iteration of our work? And then what's the long-term plan for this work? Then how do we keep it going forward? How do we empower the team to keep this work going forward? And that's an area that I've learned just from trial and error from being part of these projects. And I'm very interested in still cultivating that skill and figuring out what's the area that we're focused on? CHRIS: There's something that you said in there that I want to hone in on, which is the idea of you've learned from going on so many of these different projects, and you're carrying forward ideas that you have. But I think more generally, there's something interesting in what you were just saying there around you've worked on a bunch of different projects at different organizations with certain things that they were great at, with certain things that they struggled with at different sizes. And you're able to bring all that experience to bear on each project. But I think also taking a step back, as you were describing, you're like, I think I've figured out what it is that I like and the type of projects that I want to do. I cannot say enough good things about working in a consultancy for a while because, my goodness, you get to try out a bunch of different stuff. And A, you get to learn a ton about how to do the work, and how to communicate, and different technologies and all of that. But you also get to figure out what it is that you might want to double down on and lean into in terms of the work. That's definitely a big part of my story. Seven years at thoughtbot, I tried a lot of different stuff, worked at a lot of different companies. And I would describe it as I found a lot of things that I didn't want. And then there's that handful of things that I really did want, and I was able to then more intentionally pursue that. So for anyone out there that's considering it, working at a consultancy is fantastic, or at least it has fantastic elements to it. It also can be complicated as you talk about finding organizations and having to, you know, if you're brought in for a certain job, but when you get there, you're like, "Ooh, I know you want me to fix bugs, but actually, I think I just need to work with your team because they're the ones writing the bugs. And why are they writing the bugs" "Well, because the salespeople are selling things, and then we have timelines." Like, we got to start at the very top of this whole pyramid and fix it. And so it can be very complicated. But there's so much that you can learn about yourself in the process, in the work, and I adored that portion of my career. STEPH: Yeah, I totally agree. Anytime someone mentions, they're like, "Oh, consultancy work. What's that like?" And I remember it was a couple of years ago I mentioned I was working for a consultancy, and they were like, "Oh, you must travel a lot." I was like, "No, [laughter] I stay put. I just work from an office in Boston." But I remember that caught me off guard because I hadn't considered that I was supposed to travel, but that makes sense that you think of consultants that travel. But when I meet people or talk to people, and they're like, "Oh, you've been at thoughtbot for five-plus years, and how's that going? And what's it like to be at a consultancy?" And exactly what you just said, it's the variety that I really like and getting to try on so many different hats and see how different teams and processes work and then identify like, oh, that worked really well for that team, or this isn't working well for that team. I have really enjoyed that. And it can be a roller coaster because you have to get really good at onboarding. You have to go through that initial phase of like; I swear I'm smart. I will get up to speed quickly, and I will learn things. But it's a period that you just have to go through with each team that you join, but you do it twice a year, maybe three times a year. And so you get comfortable with that over time. So there are definitely some challenges that then have to fit your personality and things that work for you and bring you joy. And I completely understand that it's not for everybody, just kind of I really enjoy product work, but I also really enjoy being able to move around to different teams and help folks. CHRIS: I love the idea that as a consultant, your job is to just walk through airports and high-five every Accenture billboard in it and just go up to the wall and pay your respects. But no, no, that is not our version of consulting. [laughs] STEPH: That's why I have so much time for The Bike Shed. It's because I'm just, you know, I'm in different airports high-fiving signs. And then this is my real job; Bike Shed is my real job. CHRIS: Oh, that would be fun. STEPH: [laughs] You know, I have such a fondness of Bike Shed that now something interesting has happened where someone was like, "Oh, you're bike-shedding." And they're not being mean, but they're just like, "Oh, we're totally bike-shedding," or "This is dissolving into bike-shedding." And I'm like, oh, bike-shedding, hooray. And I'm like, oh, wait, bad. [laughter] And I have to catch myself each time. CHRIS: Yeah, we've taken away a lot of the meaning. Well, I mean, have we or do we live up to it every single week? Who can say? But I, too, have a fondness for this phrase, perhaps not aligned with what it is actually meant to signify. STEPH: On a slightly different tech-related note, there is a gem that I'm really excited to check out. I saw it mentioned on the paralleltests gem, which is what helps you run your tests in parallel, and it's what we're currently using. But you can group your tests in different ways. And right now, we're using the runtime strategy where essentially then we use the output from RSpec where we know how long each file took to run. And then paralleltests will then use that data to then figure out, okay, how should I split up your test file? So then try to balance them as evenly as possible. We're at that point, though, where we've talked about tentpoles, so we have certain files that, say, take 10 minutes; other files will only take two minutes. And that balance is really throwing off our ability to then bring down the CI build time. So on paralleltests, there's reference to another gem called parallelsplit_test, where then you can run multiple test scenarios that are in one file but then split them out across different processes or different machines. And that is exactly what I want in my life right now. I haven't checked it out yet, so I feel like I'm giving a daily sync update of like, I'm going to go off and explore this thing. I will report back and see how it goes. [laughs] In the past, I usually try to say, "I've tried this thing, and this is how it went," nope, opposite today. I am sharing the thing I'm going to try, and then hopefully, it goes well. CHRIS: Well, either way, we should definitely report back. That's the truth. I like that you're leading us into this and giving us a preview. But then yeah, we'll see where we get to. That does sound like the thing you want, though. So I hope it goes well. STEPH: Yeah, we've learned at this point where we are splitting work across different machines that until we address some of those tentpole concerns, adding more machines won't help us because then a machine's going to run as long as the longest file. So we've been doing some manual work to split up those files. That's not the best, but it does help you see some results. So then, at least you know you're making progress. So now we really need to find a way to automate that because we don't want someone to have to manually figure out where are the tentpoles, split those files up, commit that, and then keep track of, like, do we have another tentpole on the horizon? We really need a gem or something to help us automate that process. So yeah, I will be happy to report back. MIDROLL AD: And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free. STEPH: Pivoting just a bit, we have a listener question. This question comes from Steve Polito. And Steve wrote in, "Longtime listener, first-time thoughboter." Yay. Yay is my addition. Anything that goes up in voice is probably my addition, [laughs] just so people know. All right, back to what Steve said. "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec? Not only does Rails provide a fully functional test suite by default," looking at you Minitest, "but it's also well-documented and even provides the ability to run system tests. Rails is built on the principle of convention over configuration. And it seems odd to me that so many developers want to override such a fundamental piece of framework." Thanks in advance, [singing] Steve Polito. Steve, I hope it's okay I sang your name [laughs] because we're here now. That is an awesome question. I'm going to give what may be less of an awesome answer which is, well, one; Steve highlights that people will then replace Minitest with RSpec. I haven't done that. I haven't actually gone into a project and said, "Okay, we need to replace your test suite and bring in RSpec instead." But if I'm starting out a project, I do have a heavy preference for RSpec, and frankly, that's just from experience. Like, that's what I was raised on, to say it in that way. [laughs] RSpec is what I know; it's what I'm used to. It's what, even when I joined thoughtbot, was just the framework that we used for all of our testing and what we focused on so heavily. So frankly, for me, it's just a really strong bias. I know it's something that I'm really good at. I know it's something that works really well. I know it's well-documented. I know it's also very accessible for other people to use. But actually replacing it on a different project, I don't think I would do that. I'd have to have a really strong reason, or maybe if we haven't actually started testing anything yet, to then replace it because that feels a bit aggressive to me. But then it just depends on the situation, I suppose. But yeah, overall, I just default to RSpec because that's what I'm accustomed to, and it's the testing framework that I know. CHRIS: Yeah, I think my answer is largely the same. It's the thing that I've worked with by far the most. Similarly, I've been on projects that were using Minitest, and therefore I used Minitest because it's definitely not worth the effort to switch. But in a lot of...well, I will say this, I've much less experience, and this may be less true over time. But there were many things that drew me to RSpec, and that continues to be interesting to me in the RSpec world. Even things as small as the assertion syntax, assertequal is the method that's, you know, this is how you do an assertion in Minitest, and it's assertequal expected, actual. That's the order of the arguments. It's expected first and then actual. That makes sense, probably with the expected, but I would get that wrong constantly. I do get that sort of thing wrong. They're just positional arguments that there's nothing about this that tells me which way to go. And so it's very easy to get failure messages that are inverted, and so it's just this tiny little thing. But with RSpec, we end up with expect and then in parentheses, the thing that we are expecting to equal the other thing, and it just reads a little more honestly. It fits within the Ruby mindset in my world. I want my code to be as expressive as possible, and Minitest feels much lower level to me. It feels more, you know, assert as a word is just...I'm not asserting. That just feels so formal. And so these are, again, to be clear, very, very small things, but they all add up. And there's a reason that we're using Ruby overall. And there's a reason that we're using Rails is this expressiveness is a big part of it for me, so I'll cling to that. I'll hold on to that as something that's true. Also, Rspec's mocking support, rspec-mocks as the library, I found to be really fantastic, and I've grown very comfortable working with it. And I know how and where to use that. I also have so much built-up knowledge, like the idea of when to use let and not use let in RSpec. It's just this deep thing that I know about. I'm sure there's an equivalent in the Minitest world, but I would have to have a different understanding in argument, and that conversation would just feel different. I think the other thing that's worth saying is this is a default for us at this point that I personally have not felt the need to reconsider. When I've worked on projects that have used Minitest, I certainly wasn't called to it. I wasn't like, oh, this seems really interesting; I'm going to lean into this more. I was like, I miss RSpec. And some of that is, again, just familiarity. But at the end of the day, we only have so much time to do things. And so, I firmly stand by my not reconsidering my testing option at this point. Like, RSpec does the things that I want. It does it really well. Critically, I'm able to build a system and write a test suite and maintain that test suite over time and have it tell me the truth as to whether or not my application should be deployed to production. That is the measure. That's the thing that I care about. I think it's maybe a little bit slower than Minitest, but I'm fine with that. I have solutions to that problem. And the thing that I care about is when the test suite is green, do I feel confident deploying? RSpec has helped me for years on that journey. And I've never questioned whether or not I should go back to the drawing board and revisit that consideration. So initially, it was probably because it was the thing that we were all using, and then that is for me why it has stuck around. And I love RSpec. I think how many episodes have we just said, "Thanks, RSpec," as a little aside? So we do love it in a deep way. STEPH: Probably not enough episodes have we said that. [laughs] Yeah, I like what you said where you haven't felt the need to switch over or to move away from RSpec. And I wonder, looking back at some of the earlier projects that I joined that were using RSpec, I don't know if maybe they chose RSpec at that time because RSpec had more of those features built-in, and Minitest was still working on those. Maybe they were parallel at the time; I'm not sure. But I like what you said about you just haven't had a need to go back and change. At this point, if I switched over to Minitest, it would definitely be a learning curve for me, which is totally fine. But yeah, I'm just happy with it, so I stick with it. And I also appreciate that idea that, yeah, unless you're new in a project, I wouldn't encourage someone to then switch over to something else unless I feel like there's just a lot of pain for some reason with the current testing setup. There has to be a reason. There has to be a drive. It can't be just a personal bias of like, I know this thing, so I want to use it. There's got to be a better reason that benefits the whole team versus just a personal preference. But overall, I think it comes down to for us; it's just a choice because it's the familiar choice. It's the one that we know. But I think Minitest and RSpec are both so widely supported. I was thinking about that convention over configuration. And yes, Rails ships with Minitest, but RSpec is so common that I don't feel like I'm breaking convention at that point. They're both so widely supported and used that I feel very comfortable going with either option. And then it's just my personal preference for RSpec. So thanks, Steve, for sending in that question. And for anyone else that has a question that you would love to share with Chris and I, you can reach us in a couple of different ways. You can reach us on Twitter via @_bikeshed. You can also go to the website, bikeshed.fm/content. We will drop some links in the show notes. But if you go there, then you can send a question or also email us directly at hosts@bikeshed.fm. And we're running a little low on listener questions, so we would love to have a listener question from you. And we would love to talk about anything that y'all want to talk about, okay, within reason, you know, triathlons, Brussel sprouts, things like that. All of that falls within the wheelhouse. CHRIS: Normal stuff. STEPH: Normal stuff, yeah. CHRIS: And to be clear, despite the fact that Steve did recently become a thoughtboter, you don't have to be a thoughtboter to send in a listener question. [laughs] In fact, it's much more common to not be a thoughtboter when sending in a listener question. But we'll take them from anybody. We're happy to chat with you. STEPH: On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases. Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Emma Bostian (https://twitter.com/EmmaBostian) Ladybug Podcast (https://www.ladybug.dev/) Gerrit (https://www.gerritcodereview.com/) Gregg Tobo the Magician (https://astonishingproductions.com/) Sean Wang - swyx - better twitter search (https://twitter.com/swyx/status/1328086859356913664) Twemex (https://twemex.app/) GitHub Pull Request File Tree Beta (https://github.blog/changelog/2022-03-16-pull-request-file-tree-beta/) Sam Zimmerman - CEO of Sagewell Financial on Giant Robots (https://www.giantrobots.fm/414) TypeScript 4.1 feature (https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/) The Bike Shed: 269: Things are Knowable (Gary Bernhardt) (https://www.bikeshed.fm/269) TSConfig Reference - Docs on every TSConfig option (https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess) Rails I18n (https://guides.rubyonrails.org/i18n.html) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard. And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well. But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful. It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience. But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too. CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this. STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on. Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it. And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it. CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that. The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang. And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well. STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden. CHRIS: It's like they're hiding it. STEPH: Yeah, one of those. [laughs] CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much. STEPH: [laughs] CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now. STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services. So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel. But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that. But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it. CHRIS: You vented a little into the yelling channel; maybe not everything, though. STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through. And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out. CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up. I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well. And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting. But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that. STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with. So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it. CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here. It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me. STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with. CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes. STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know. Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you? CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one. The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat. But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point. So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you. ... STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it. But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly. So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing. But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things. But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings. STEPH: Did you fire everybody? [laughs] CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go. The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that. STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs] CHRIS: Life's tricky, is all I'm going to say. STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better? CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it. STEPH: [laughs] CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up? And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one. STEPH: This is The Bikeshed. We can live up to that name. [laughs] CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind. But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world. But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you. STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle. I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with. CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult. STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us. CHRIS: Prant for life. That's my stance. STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic. I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate? CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript. So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is. And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array. TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array. So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer. And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad. But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this. We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice. STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on. CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct. But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life. STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice. CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct. STEPH: [laughs] That's how that song goes. CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline. But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left. STEPH: [singing] Everything you own in the box to the left. CHRIS: Thank you for doing the needful work there. STEPH: [laughs] Mid-roll Ad And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free. STEPH: I have a question for you that I'd really love to get your opinion on because I myself I'm waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this. So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone. In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test." So this goes with the idea that if you're writing tests and then you're testing text, but it's on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by. And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea. But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test? So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string. I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string. So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see. The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either. So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff? CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that. I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests. This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true. That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined. Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works? STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist. So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see. CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question. And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I've nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend. But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it. STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure. So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text? CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you. STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it. It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys. But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Chris is back from vacation and gives hiring and onboarding updates. Steph has an update about the CI slowdown and scaling CI. They tackle a listener question regarding having some fear around potential merge conflicts. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Deckset (https://www.deckset.com/) parallel_tests (https://github.com/grosser/parallel_tests) paralleltests - important line that may alter the `groupby` strategy (https://github.com/grosser/parallel_tests/blob/9bc92338e2668ca4c2df81ba79a38759fcee2300/lib/parallel_tests/cli.rb#L305) KnapsackPro (https://knapsackpro.com/) rspec-queue (https://github.com/conversation/rspec-queue) Vim Conflicted Overview (https://github.com/christoomey/vim-conflicted#overview) Mastering Git Course on Upcase (https://thoughtbot.com/upcase/mastering-git) Git Object Model (https://thoughtbot.com/upcase/videos/git-object-model) Git Object Model Operations (https://thoughtbot.com/upcase/videos/git-object-model-operations) The Opportunity Will Find You (https://thoughtbot.com/blog/the-opportunity-will-find-you) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Oh, I also have a new intro that I want to try out. This is thanks to Irmela from Twitter, where it's good morning and hooray; today is Bike Shed day. They technically said Tuesday, but we don't record on Tuesdays. So today is Bike Shed day, so happy Bike Shed day. And hey, Chris, what's new in your world? CHRIS: What is new in my world? Yeah, I loved when I saw that tweet come out. It really warmed my heart. So Tuesday, in theory, is Bike Shed day, but for you and I, Friday is Bike Shed day. It's confusing breaking the fourth wall, as I so often do. But yeah, what's new in my world? I'm back from vacation, which is the thing that I did. For listeners, well, I have been absent the previous week related to vacation and all those sorts of things. But I did what we're going to describe as a not smart thing. It wasn't intentional. The world just kind of conspired in this way. But I had two separate vacation islands that existed in my mind, and then they both kind of congealed, but as they did that, they moved towards each other, but they didn't connect. And so what I ended up with was two weeks back to back where I was out on Thursday and Friday of one week, and then I was back for Monday and Tuesday. And then I was out for Wednesday, Thursday, Friday of the following week. Protip: that's a terrible idea. It's just not enough time to sort of catch up. The whole of it was like the ramp-up to vacation and then the noise of vacation, then getting back and being like, oh, there are so many emails. Let me try and catch up on them. But also, on the very positive side, we had a new hire join the team, and so most of my focus on the days that I was in the office was around getting that new person comfortable on the team, onboarding, spending as much time as possible with them. And so, all total, it was an adventure. And again, I would strongly recommend against this. The world just kind of conspired, and suddenly these three different forces in my life came together. And this was just the shape of things. But yeah, I went on vacation, and it was great. The vacation part was great. STEPH: I will take your advice. So next time I have like two segments of PTO, I'm just going to stitch them together and just go ahead and take that whole intermittent time off. CHRIS: That probably would have been better. Again, someone new joining the team, it was very important to me to get some time with them early on, and so I opted not to do that. But yeah, the attempt to catch up in between was a completely lost effort, I would say. But I think I'm mostly caught up now, having been back in the office for about a week, so yeah. But let's see, what else has been up in my world? It's actually been a while since you and I have chatted based on the various timing and schedules and the nonsense vacation schedule that I had that you so kindly accommodated across a couple of weeks. Let's see, hiring and onboarding; the hiring went really well. We talked about that a bunch of weeks back. But now we're in the onboarding phase. And so next week will be the first week that all four of us on the engineering team are in the office together for the full week. I'm super excited to experience that. We've had different portions of it, with me being on vacation and other folks being on vacation. But now, for the first time, we're really going to feel what it's like as this team. And we're going to have our first retro as a group and all those sorts of things, so I'm very excited to do that. And thus far, all of the interactions that we've had have been really wonderful as a team. And so now it'll be the first time we're just bringing all of those various pieces together. STEPH: I just have to clarify; you said all of y'all in the office together. Do you still mean remotely? CHRIS: Oh, yes, yes, I just mean not on vacation, all present and accounted for on the internet. Remote is another interesting facet of what we're doing here and trying to figure out how to navigate that, particularly where there are some folks that are closer and can potentially get together in the city, that sort of thing, and then folks that are truly remote and making sure that we're...I'm very much of the opinion if we have anyone that's remote, we are remote team, and we must embrace async communication and really lean into that. And I think the benefits of async communication as its own consideration are so worth it. And it's one of those things that's hard to do. It requires careful, intentional thought. It requires more purposeful communication. But I think there are a lot of good things that fall out of that. It's similar to TDD in that way in my mind, like, it's not easy. It's actually quite difficult. But all the effort that I put into trying to learn how to do that has made me a better developer, I think, on all the various fronts. And I think similarly, async communication I believe in as a tool to force just better communication. And so I'm a big believer in it, and I've found a ton of benefit in remote that I'm also a big believer in that now. I, like everyone else, was forced into it as the world was, but I've really come to enjoy it a lot. And so yeah, so, no, not physically in the office, to answer your very short question with a long rambling aside. STEPH: [laughs] I like that comparison. I hadn't thought about it in that way but comparing that thoughtfulness and helpfulness of async communication and then also to TDD, where it's not easy, but the payoff is so worth it, the upfront cost of it. That is something that at thoughtbot, we've had conversations around where there are folks that really value...they want to be around people. They get energy from people, and so they want that option to be able to rent a WeWork space and maybe get together with a colleague once or twice a week, and that was supported by thoughtbot. But we also wanted to express well, if you are together, do treat everything still as a remote work environment. So let's say if you and your colleagues are on a project, but then there's a third person on that project that's remote, you still need to act like everything's remote to make sure that everyone else is still getting to participate and hear everything and be part of the conversation. So just keeping that in mind that yes, we want to support you doing your best work, and if that's around people, that's wonderful. But we are still remote-first, and communication needs to be in that fashion. Well, that's super exciting that you'll have all of the team together. That sounds like it will be wonderful to hear about and then also retros and meetings, and yeah, it sounds like you've got a fun week ahead. CHRIS: Indeed. I'm super excited to see what sort of new things come out of the new voices on the team and practices that each of the individuals have experienced at other companies that we can now fold together. The work that we've done so far has been very much inspired by thoughtbot ideas, and approaches, and workflows, and processes because that's what I brought to the table. But I'm super excited to bring in more voices and see what of that 100% stays on versus does anything change? Do we get entirely new things? So yeah, very excited about all of that. But to revisit a topic that we've talked about in the past, this week is catching up from vacation, so there's a certain amount that will constrain my work. But this was definitely another week of I did not do much coding. I'm trying to think if I did any coding this week. It's possible that the answer is no. The fact that I don't even know the answer to that is an interesting one. I still have in my mind the desire to get back to it, and I think I will. But there's so much other stuff to do. Recently, this week, there's been a lot of vendor selection and contract negotiation, which is an interesting facet of the work, but just trying to figure out, oh, we need platforms to do X, Y, and Z. And it turns out they're wildly costly and have long sales cycles. And how do you go through that, and how do you make sure that we're getting the right thing? And so that's been a big part of my work. Hiring and onboarding, again, has been a big part of it. There's also some amount of communicating back to the broader team - what are we doing? What is the product organization or the engineering team delivering? And so I'm okay at presentations, I think. I'm comfortable with giving presentations. The thing that I struggle with is finding the optimization point in preparation. I will, of my own accord, over-prepare. And that may sound a little bit like, oh, what's my greatest weakness? That I care too much. But I mean it sincerely as like, I would love to find that right amount of like, it's like an hour of preparation for a 15-minute presentation to the team. That's the right ratio. And I just hit that on the head, and it's great. But whenever I know that I need to give a larger presentation, it will distract me. And it's work that can expand to fill whatever time you give it, and so trying to thread that needle is a tricky one for me. STEPH: Yeah, I'm with you. Presentations, for me, they're one of those things that it's very stressful, anxiety-inducing; all the prep feels distracting from some of the other work that I want to do. Or maybe I'm excited about the presentation, and that is the work that I want to do. But it's not until it's done that then I'm like, oh, that was fun. That went well. This was great. It's not until after that then I feel good about it. So the lead-up to it is very stressful. And so if you can optimize that to say, well, I know exactly what this group needs, where I can cut corners, where I have to go into details, that sounds incredibly valuable. I'm curious, so this is probably a bad idea, but it's the only way I really know how to find those boundaries is you got to experiment and tweak a little bit and let yourself fail a little bit or just be very explicit with folks about this is what the presentation is, if you expected something else, let me know. Or here's what I've got, have someone to bounce ideas off of. But there's such a nicety if you can find that I'm going to try failing just a little bit and get some feedback. Or maybe it's not failing at all, but you are testing that boundary to find out did this work, or should I put more effort into this? I'm curious, do you have thoughts on that? How you're going to find that right optimization level? CHRIS: Not as specific to truly honing in on whatever the correct number is. The thing that I've been doing is I...this will sound complicated, but I wait until the last minute but a specific version of the last minute. So at most, I start working on it an hour and a half before the meeting. And these are, again, not particularly large presentations, and it's a recurring sort of thing. So it's sort of engineering talking about the work that we've done recently and trying to find the right level of detail and whatnot, so giving myself a smaller time window. I think that's enough time to tell the story and to find a meaningful way to tell the story and grab the screenshots and all of that, but it's constrained so that I don't over-optimize, over-edit, overthink. I'm using Deckset, which is a presentation tool that starts from a Markdown file. So it's just a Markdown file that I'm editing. That's great; that works really well. I do not twiddle with fonts. There's one theme that I use. It is white background with black text. That's it. And I think I've given myself deep permission to be the CTO that has a white background with black text and no transitions. I don't even go into presentation mode for it. I'm literally showing the UI of Deckset, and then just hitting the arrow to move between them. But the Chrome and the drop-down menu at the top is still visible because I want to see people's faces as I'm presenting. And I haven't figured out how to do that correctly on my computer. So I'm just presenting the window of Deckset. And I'm like, I have given myself permission to do all of those things, and that has been super helpful, actually. So that's a version of me negotiating what this means. Where I do invest the effort is trying to enumerate all of the things and then understand what is the story that I'm telling around the things and how do I get the message right for the collective audience? So, for a developer team, I would say much more nuanced technical things, for marketing folks, it would be at this end of the spectrum. I do lean on the old idea of, like, let us talk about it in the mindset of the user, so it's very much user-centric, but then some of the things that we're doing are important but invisible to the users. They're part of how we broadly build the platform that we need to, but they're completely invisible to users. And so, how do I then tell that story still with ideally a user-centric point of view? So that's where I do invest the time, and I give myself complete freedom to just grab screenshots, put black text on a white background, and then talk over it. STEPH: I love it. Because you made this comparison earlier, so now I'm thinking of a comparison of like TDD-driven presentations where it's like, what's the end goal? What's the assertion? What's the outcome that I want? And then backfilling from there. Or, in your case, you're talking about what's the story that I need to tell? What's the takeaway that I want people to have? So then you start there, and then you figure out what's the supplemental information that you need to provide to then get there. And the fact that you don't twiddle with fonts and all that stuff, I think you're already really on your way [chuckles] in terms of finding that right optimization of I need to present a clear and helpful message but not sink too much time into this CHRIS: Black text on a white background is very clear. So... STEPH: [laughs] If there are any designers listening to this, they might just be cringing to this conversation right now. [laughs] CHRIS: I actually wonder about what the...I know that dark mode is a thing that lots of folks care about. I'm thinking about the accessibility affordance of it now. I'm actually thinking through it now that I said it somewhat flippantly. I actually don't know what I'm talking about, but it was easy, and it wasn't a choice that I allowed myself to think about. So there we are. Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: In my personal world, so Tim and I are moving. We're on the move. We are transitioning from South Carolina to North Carolina. So I think I may have shared a bit of this news, but Tim has acquired his first software developer job, which is just phenomenal. It is in North Carolina. He does need to be there in person for it. So we are currently selling our South Carolina house and then moving. It's not too far. It's like three and a half hours away to where we're moving in North Carolina because we're already pretty far in North and South Carolina. So yeah, there's always another box that needs to be packed. And there's always just something else that you forget, another thing that you want to take to Goodwill or try to give to a neighbor. It's a good way to purge. I will definitely say that every time you move, it's a good time to get rid of things. CHRIS: That is a very cup half-full point of view on it, but yeah, it feels true. STEPH: [laughs] It's true. I'm a very cup half-full person. For more technical news, for more client stuff that I've been working on, so I think the last time we chatted, I was sharing that we had this mysterious CI slowdown where we were going from CI builds taking around 25 minutes to spiking to 35, sometimes 45 minutes, and I have an update there. So we found out some really great things, and we have gotten it back down to probably more about 23 minutes is where the CI is running currently. As for the actual who done it, like what caused this specific slowdown, we got to a point where we were like, we're doing so much investigative work to understand exactly what caused this that it felt less helpful because at the end of the day, we really just wanted to address the issue. And so solving the mystery of exactly what caused this started to feel less and less meaningful because we're like, well, we want to improve this anyways. So even if we found that one line or something that happened that caused this, we want a bigger solution to this type of problem because then this could happen again like, someone else maybe adds one line or something happens, and things get thrown off balance, and then suddenly, we have a slowdown, and that just takes too long to investigate. So I don't have a concrete who done it answer for the slowdown. But we've learned a couple of things; one of the things that we learned is we're using parallel_tests to then split our tests across all of the CPUs that are then running the RSpec test. And we realized that we weren't actually splitting tests based on runtime data. So there are a couple of ways that paralleltests will let you divvy up your test, and two of those ways one is file size. So you can split the files based on the size of the file, or you can use info from the runtime log. So then paralleltests can be a little bit more intelligent about like, well, I know how long these files take, so I'm going to split it based on that versus just the size of the file. And we realized that we were defaulting and using the file size instead of the runtime even though we all thought we were using runtime. And the reason for this took a bit of source code diving because looking at the README for paralleltests; it looked like as long as we're passing in a file to the runtime log path, then paralleltests is going to use that runtime data. But then there's some sneaky-sneaky in there that I'll actually link to in the show notes in case anybody's interested. But if you are setting a particular flag and don't pass in another flag, then paralleltests is going to be like, cool, I'm going to portion out your test based on file size instead of the runtime. So we fixed that, or we updated that, and that has had a significant improvement for the test being split out more evenly. So we didn't have a CPU that was taking 25 minutes while the next CPU was only taking like 17 minutes. And paralleltests also provides some really helpful data that because we have that runtime log file, we could tell how long each CPU is running and how they're getting split. So the past couple of weeks, it's heavy measure, measure, measure, take all the data, create lots of graphs, understand what's happening, and then look for ways to then fix it. So figuring out how these files or how the tests were being distributed across, we had a number of graphs that were just showing us what's actually happening. So then we could track the improvement, so that was really nice. It was the measure twice and change something once [laughs], and then we got to see the benefit from it. For scaling the CI, so we are looking on adding more machines to then process tests. That has been really interesting because we're at the point where we are adding more machines, but if we add more machines, we're not going to speed up how quickly our CI processes everything. Because we are splitting tests based on file size and not by examples, we're always going to have this effect of a tentpole. So if we have a file that takes 10 minutes, that's the fastest we're ever going to get. So Joël and I are in discussions right now of where we still really want to understand what's the fastest we can achieve just by adding another machine or two versus are we at the point that, okay, scaling horizontally and adding more machines has been helpful, but we have reached the breaking point where we actually need to divvy out the tests at a smaller scale and have a queue approach? So then that way, we can really harness the power of then we don't have one file that takes 10 minutes, and we don't have to care either. So if somebody adds a test to a file and suddenly a file goes from 12 minutes to like...well, hopefully, they added more than one test. [laughs] But let's say it goes from 10 minutes to 15 minutes; we don't want to have to manage that and understand that there's a tentpole. We just want to be able to divvy out all the examples and then have a queue approach. That's probably going to be MVP two of this, but we're still waiting that out. But it's just been really interesting to realize that scaling horizontally really only takes you so far. Like, we've added one machine, maybe one more, so then we'll have three total. And then it's like, okay, that's great, but now we need to actually address this other bigger problem. CHRIS: I know we've talked about this in previous episodes, but I'm super interested to hear as you progress into the queue approach because that's something that's been top of mind for me for a while. I don't know if we've talked about it before specifically, but Knapsack Pro is the one thing that I'm available as a service that does this. Do you have other tools that you're looking at for that, or is this still in the exploratory phase? STEPH: Knapsack is still a top contender. There's also RSpec Queue; that's another one that we have in mind. Unfortunately, I really wish paralleltests let us do this, but paralleltests just doesn't quite offer that feature. And someone in the team, I think, even reached out to the maintainer of paralleltests, and they were like, "Yep, you're totally right. We're actually more focused in making sure that this works for everybody versus has specific features." And they gave a really nice thoughtful response, which we appreciated, so at least we could confirm that paralleltests won't do exactly the thing that we need. So yeah, RSpec Queue, Knapsack, I think those are the top two that I'm familiar with. CHRIS: Gotcha. I don't know if I've seen RSpec Queue before. I'm intrigued. So actually, an interesting thing happened. While I was away on vacation, one of the folks who just joined the team as one of their first steps joining the team, noticed that our CircleCI config wasn't actually taking advantage of the parallelism that we had configured; that's on me. I turned on parallelism and then never did anything with it, which is a complete waste. And so I was super happy to come back and saw that CI, which had been creeping up to six or seven minutes, had suddenly dropped back down to two to three minutes sort of thing. I was like, this is amazing. But now I'm at the point where our RSpec suite is spreading across the different, I think, it's like four different cores that we have available, but it's not doing it as efficiently as we would like. So I'm like, oh, okay, can we dial it up to 11? But I'm intrigued; I've only looked very much in passing at RSpec Queue literally now that you've mentioned it. But Knapsack Pro exists as a different service. And so, as far as I understand, the agent that's running is going to communicate and say, "Give me another test. Give me another test." But there needs to be some external process running and managing that queue. Does RSpec Queue do that? Somebody owns the queue, right? Who owns it? Do you understand how that works? STEPH: So I was definitely familiar with this. If you'd asked me a couple of weeks ago, when I was diving heavily into the queue work before then, we transitioned more into focusing on then adding new machines; I was very up to speed on this. So I may get a couple of things wrong, but my understanding is that RSpec Queue, you're going to manage your own queue. So you bring in the gem and then use something like Redis, so then you are in charge of that. And with Knapsack, then you are using their service to manage that queue. And then they have found ways to optimize around what if you can't reach their API or something; their service is down? And making sure that that doesn't impact your CI so then you can't still run your test just because you can't reach their queue somewhere. So that's my current understanding, RSpec Queue you own it, Knapsack they're going to own it. CHRIS: Gotcha. That makes sense. That about maps to what I was expecting, and so I wonder if I could use RSpec Queue. Now I'm going to have to go research that. But it's always nice to have new things to look at on this to go at ludicrous speed. That's what I'm going for. I want to get to ludicrous speed for our CI. STEPH: I like that name. I haven't heard of that speed. I feel like I have. I feel like you've dropped that before, [laughs] like you've used that. CHRIS: I don't know; quite possibly, I have. It's a Spaceball's reference. It's a throwback to days of old. STEPH: Well, then we may be investigating RSpec Queue together. Because yeah, Joël's and I goal for this week has been very much to figure out what's our boundaries with TeamCity? What are our boundaries with horizontal scaling? And I think we're both getting to that conclusion of like, okay, this has been good, it's helpful, but we really need to look into the queue stuff if we really want to see significant progress. Also, some of the stuff we're doing because we're pushing on it, we are manually splitting files. So if there's a file that has created this tentpole that's taking 10 minutes, but we know ideally most of the other files only take six minutes, then we are splitting that file, so then we have two spec files that are associated with the same class. And then using that as a way to say, okay, what would this look like? Let's say if this were better balanced. And that's also been pushing us in the direction of like, okay, this is fun, this is informative, but it's not sustainable. We don't want to have to keep worrying about splitting these files and doing this manually and pushing us towards that queue-based approach. MIDROLL AD: And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with Mongo DB, SQL, Oracle and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30 day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial head to studio3t dot com forward slash free. That's studio dot com forward slash free. But shifting gears just a bit, we have a listener question. So this person wrote in, "I have listened and loved your podcast for many years dreaming of getting a job with people half as thoughtful and intentional as you, and finally it happened. I have my first junior dev job, and my co-workers and bosses are all super awesome. Up until now, I've been flying solo. And in my new job, I've been finding it very unsettling to resolve merge conflicts. As careful as I am to comb through the conflict and contact the other developer if needed, I feel like I am covering my eyes and crossing my fingers whenever I select the resolve conflict button. Is there some type of process or checklist I could rely on? Is it normal to have such a high fear factor with a merge conflict? Any advice or maybe just a bit of been there felt that way...?" All right. So one, that's fabulous, congratulations on the new job. That's very exciting. I think I've voiced this many times, getting your first junior dev job is so hard, and so I'm so excited when it works out for people, and they get there. And then, for the merge conflict, I have thoughts. Chris, do you want to start? Shall I start? How are you feeling? CHRIS: Why don't you start? Well, actually, I'm going to add some pre-commentary, and then I think you should lead into our actual answer. But first, I just want to say a deep thank you to this listener for sending in the question. Again, we really love getting these questions. And also, thank you for the very kind words. To be clear, listener, if you're going to send in a question, you don't have to say very kind words, but they are really wonderful to hear and especially to hear if we had any part in helping this person feel more comfortable getting into that first dev role and having an idea of what maybe a good version of that could look like. Additionally, I really love the shape of this question because it gets into the people stuff and the tech stuff, so I'm super excited about this question. Actually, both Steph you and I responded very quickly to this one. And so it really did catch our attention because I think it crosses that boundary in an interesting way that I think is sort of The Bike Shed space in the world. But to that end, you did reply first in our email chain. So I think you should start, and then I'll follow on after that. STEPH: I should also check with you. Wait, so you don't have a filter on your email that's like kind words only to The Bike Shed, and then you filter out anything that's negative? CHRIS: I have a sentiment analysis, and if it's even neutral, it gets sent straight to the trash, only purely positive. No, constructive feedback is welcome too. We would love to hear that. Well, love is a strong word. We would accept it into our inboxes and then deal with it, but yeah. STEPH: [laughs] It will be tolerated. Must require at least three hearts in all emails; just kidding. [laughs] CHRIS: Are you kidding? I'm counting them now, and I see a lot of hearts in our emails. [laughter] STEPH: Merge conflicts. So is it normal to have such a high fear factor with a merge conflict? I'm going to say absolutely. Resolving a merge conflict can be really tricky and confusing. And I think; frankly, it's something that comes with just time and practice where then you start to feel more confident. As you're resolving these, you're going to feel more comfortable with understanding what's in the branch and the code changes that you're pulling in versus something that you need to keep on your side. So I think over time, that fear will subside. But I do think it's totally normal for that to be a very scary thing that then takes practice to become accustomed to it. As for if there is some type of process or checklist, I don't know of a particular checklist, but I do have a couple of ideas. So one of the things that I do is I will often push my code to whatever management system I'm using. So if I'm using GitHub, then I'm going to push up my branch because then, at least that way, someone has a copy of my work. So if I do something and I completely botch it locally, I know I can always reset to whatever it is that I pushed up to GitHub, so then that way, I have more freedom to make mistakes and then reset from there. So that is one idea is just put it somewhere that you know is safe, so that way you now have this comfortable sandbox to then make mistakes. The other one is run the test. So hopefully, the application that you're working with has tests that you can trust; if not, that could be another conversation. But if they do have tests, then you can run those, and then hopefully, that would let you know that if you have left something in, like maybe you left a syntax error, or maybe you removed some code that you shouldn't have because you weren't sure, then those tests are going to fail, and they'll let you know that something went wrong. And you can run those while you're still in the middle of that merge conflict as long as you've addressed like...well, no, if you haven't addressed syntax errors, that's still a time that you can run it, and it's going to let you know that you haven't caught all of the issues yet. So you don't have to wait till you're done to then go ahead and run that. A couple of other ideas, practice. So go ahead and create your own merge conflicts on purpose. So this is something that I think is really helpful because it will teach you, one, what causes a merge conflict? Because now you have to figure out how to create one, and then it will help you become comfortable because you're in a completely safe place where you have made up the issue, and now you're having to resolve that, so it'll help you become more confident in reading that merge conflict message. And then last but certainly not least, grab a buddy so if you are just feeling super nervous. Anytime I'm doing something that I just feel a little nervous about, then I just ask someone like, "Hey, would you look over my shoulder? Would you pair with me while I do this?" And I have found that's incredibly helpful because it eases some of my fear. I've got someone else that is also looking through this with me. But I also find it really helpful because then it encourages that person to be like, hey, if they're ever in a spot that they need to pair, I want them to know that they can also reach out to me and have that same buddy system. I guess that's my checklist. That's the one I would create. How about you, Chris? What do you think? CHRIS: Well, first, I just want to say that basically everything you said I 100% agree with, and purposely I think was great that you actually replied to the email first and that you're saying those things first because I think everything that you said is true and is foundational. And it's sort of the approach that I would definitely recommend taking as well. My answer, then adding on to that, has to do with how I've approached learning about this space in my own career. To name it, to answer the core question, is it reasonable to be scared of this? Yes, Git is confusing. Git is deeply confusing. I absolutely love Git. I have spent a lot of time trying to understand it, and in understanding it, I've come to love it. But it's only through deep effort that I've gotten to that place. And actually, the interface, the way that we work with Git on a day-to-day basis, particularly the command line is rough. I'm going to say, what does Git checkout do? Well, it does just about everything, it turns out. That command just does all of the stuff, and that's too much. It's, frankly, the UI for Git, specifically the command-line user interface; the commands that we run to manipulate the Git history are not super intuitive. But it turns out if you pop open the hood, the object model underneath the core way that Git stores your code is actually very simple. I find it's very easy to understand, but I, unfortunately, have found that I can't understand it without dropping down to that level. And so, in my own adventures, I kind of went deep on this topic a couple of years ago, and I created a Vim plugin because obviously, that's the best way to encapsulate your knowledge about Git, and so I created a plugin called Vim Conflicted. I don't necessarily recommend the plugin. It's fine if you want to use it. I don't do a great job of maintaining my plugins at this point, to be honest. But there was a weekend where I was trying to understand the world of Git and merge conflicts in particular, and it was really sort of fighting me. And as I started to understand it better, there's a little diagram that I drew on the README that I think is probably the most interesting artifact from it. But it's this idea that there are actually four files, four versions of a given file involved in any merge conflict. And that realization shifted my thinking a good amount. And then as I started to think about that, I was like, oh, okay, and then I want to see this version of it, and this version of it, and this combination, and the diff between these two, and that was super helpful for me. More generally, I also made a course on Upcase about Git as I tried to understand it better. And there are two particular videos from the middle of the course named the Git Object Model and Object Model Operations. And again, those two videos deal with popping the hood on Git, looking inside it, and what actually is happening to your code as you perform different Git operations. One of the wonderful things about Git is it is immutable. So you're never going to destroy your Git history if you've committed. So one of the rules that I have is just always be committing, never worry about committing. If you've committed, you can always get back to that version. You would have to try very hard to destroy committed code in Git. It's the things that you do when you haven't yet committed the code that are dangerous. So commit the code, like you said, Steph, push that up to GitHub, so you have a backup of it. You will have a backup locally as well, and that's a thing that you can come to be more comfortable with. But then, from there, there's actually a lot of room to experiment and play around because there's a ton of safety in the way that Git stores the code. You do have to know how to get at it, and that's the unfortunate and tricky part. But I think, again, to sort of summarize, yes, this is confusing. Your feelings are absolutely valid and totally grounded, but it is also knowable, is what I would say. And so, hopefully, there are a couple of breadcrumbs that we've laid there in how you might go about learning about it. But yeah, find a buddy, watch a video or two, and give it a try. This is definitely a thing that you can get there but totally reasonable that your first approximation is this is confusing because it sure is. STEPH: I often forget that Git has that local copy of my code, so I'm so glad you mentioned that. And then yeah, I saw when you linked to Vim Conflicted. The diagrams are great. I had not seen these before. So yeah, I highly recommend folks take a look at those because I found those very valuable. CHRIS: In that case, it's a white background, but I allowed myself to use some colors in the little images to help differentiate the different pieces. And it's an animated diagram, so it's really a high bar for me. [laughs] STEPH: So now the question is, did you go too far? Have you over-optimized? [laughs] CHRIS: I'm going to be honest; it was a weird weekend. STEPH: [laughs] Well, I don't think you've over-optimized. I do think it's wonderful. And I think this is definitely a reference that I'll keep in mind for folks whenever they're learning about merge conflicts or just want to get more knowledgeable about them. I think these diagrams are fabulous. CHRIS: Well, thanks. Yeah, I hope...they frankly were a labor of love, and the course is three and a half hours of me rambling about Git, so hopefully, it's useful to folks. If anything, it was super useful to me because my understanding of Git was deeply crystallized in making that course. But I do hope that it's useful to other folks. And particularly those two videos that I highlighted, I think are the ones that have been most impactful for me in terms of how I think about working with Git and getting comfortable with it. STEPH: Do you still receive emails every now and then from people, or maybe they are tweets from people that are like, "Hey, I watched one of your videos and found it really helpful." I feel like I still see that every now and then where people are just commenting on like, they watched some of the content that you created for Upcase a while back, and I think that's really cool. I'm curious if you still see that. CHRIS: I do, yeah, from time to time. It is absolutely wonderful whenever I hear that. Again, listener, do not feel the need to send me anything, but it is nice when I get them. STEPH: It does seem like I'm fishing for compliments now. [laughs] CHRIS: It does seem like that. So I want to be clear that's not what's going on here. But it is nice because I do actually forget that they're out there. But a lot of the stuff that I produced for Upcase, in particular, I tried to do more timeless stuff, so like the Vim content was really about how Vim works in a deep way. And the tmux course and the Upcase course...or the tmux course, the Git course. I look back at them, and a couple of little syntactic things have changed. But I'm still like, yeah, I agree with me from six years ago or whatever it was. Oh, that's a weird number to say, and I think is honest. It's fine. I'll just be over here. [laughs] STEPH: [laughs] That's helpful to hear, though, because that's always one of my fears in creating content. It's like, I don't know, it's okay if it's more opinionated and I change my mind and disagree with my past self. But it's more like, yeah, keeping up with is this still accurate? Is this still reflective of the times? And then having to keep that stuff updated. Anywho, that's a whole big thing, content creation. CHRIS: Content creation, but there's a parallel to it that many folks will not be creating content, and I think that's a very fine and good way to go about progressing on the internet. But there's a parallel to it in learning that I think is useful. I, at this point, will typically lean in if there is something in the SQL layer that is fighting me. I have never found effort spent trying to better understand the structured query language to be wasted time. Similarly, Git is one of those tools that is just so core to the workflow that it felt very worth it to me to spend a little bit of extra time to get to a deeper level of comfort with it, and I have not regretted one minute of that. Vim and tmux are pretty similar because they're such core tools for me. But React, I would not call myself a deep expert of React. I follow some of the changes that are happening but not as deeply, and I'm not as worried about it. And if I'm like, I don't know how to do this thing, should I spend two hours learning about it or not? With frameworks and tools that have not been part of my toolset for as long, I will spend less time on them. And I think that the courses that I produced on Upcase mirror that. They're the things that I'm like; I feel very true about these things versus other stuff. Maybe it was in a weekly iteration episode or something like that. But that very much mirrors how I think about learning as well. What are the things that I'm going to continually invest in versus what are the things that I'll sort of keep an eye on from a distance but not necessarily invest as much time in? STEPH: There's a particular article that you're making me think of as we're talking about content creation and, as you mentioned, finding the things that you always find value in investing in. There's a wonderful blog post that was recently posted on the thoughtbot blog by Matheus Richard, and it's called The Opportunity Will Find You. And it made me think a lot about what you're talking about, find the things that you're excited about, find the things that you think are a good investment and just go ahead and lean into it. And it's okay if maybe that's not the thing that you're using currently at your work, but if it's something that gets you excited, then go ahead and pursue that. So in this article, for example, Matheus uses the example of learning Rust, and that's something that he's very excited about and wants to learn more about. And then there's another one where he started looking into crafting interpreters. And then that has actually led to then some fruitful work around creating custom RuboCops because then he had more knowledge around how the code is being interpreted so then he could write custom RuboCops. So yeah, plus-one to finding the things that give you energy and joy and leaning into that and investing in it. And if you share it with the world, that's fabulous, and if you don't, then keep it for yourself and enjoy it, whatever makes you happy. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph celebrates Utah's adoption day and Daylight Savings Time and troubleshoots a CI build time that had suddenly spiked for a client project using TeamCity. She also shares a minor update regarding the work that thoughtbot is doing to scale horizontally and add more machines quickly and efficiently to process more RSpec tests. Chris was alarmed by logs and unknown-unknowns and had some fun using Git down. Git bless his heart! This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. TeamCity (https://www.jetbrains.com/teamcity/) lograge (https://github.com/roidrage/lograge) Cleaning up local git branches deleted on a remote (https://www.erikschierboom.com/2020/02/17/cleaning-up-local-git-branches-deleted-on-a-remote/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. Today is Utah's adoption day. So officially, one year ago, we adopted Utah. He's about a year and a half years old now because we got him when he was around the six-month mark. So Utah, aka Raptor, which is the nickname that you gave him, and aka UD [spelling] the cutie is his other nickname...which I've forgotten, why do you call him Raptor? Why is that a name? CHRIS: Because there's a Utah Raptor. STEPH: A person? [laughs] CHRIS: No, I think it was like the fossils were found in Utah. But the Utah Raptor is a type of dinosaur. And so when I heard Utah, my brain went to Raptor, and then I dropped the Utah sort of a Cockney rhyming slang sort of thing. Shout out to Matt Sumner real quick. But yeah, Raptor. STEPH: Cool. Cool. Cool. I'm so glad I asked. Now I know. I just accepted it when you called him Raptor. I was like, sure, he can be a Raptor. [laughs] CHRIS: I feel like that says a lot about me that you were just like, okay, why not? STEPH: [laughs] CHRIS: That's different and has no apparent connection to the actual name of the creature, but that's fine. I might be a nonsense person. STEPH: Or me for accepting it. You share a lot of nonsense, and I accept a lot of nonsense. That might be our dynamic. [laughs] So it works out. CHRIS: That just may be our dynamic. STEPH: That's why I'm always so nice with the good idea, bad idea, or even terrible. [laughs] CHRIS: You're like, it's all nonsense 100% of the time, but yeah. So Utah is one year into living with you folks. So that's lovely. STEPH: Yeah, and he's growing up so well. Oh, and I've been training him for one of his latest tricks. I'm very excited because it seems to be really sinking in. So every night, we take him out for his final bathroom potty but then before we go to bed. And one night, for some reason, I started singing The Final Countdown. [singing] It's the final countdown. But I started singing it's the final potty instead. So now, when it's time to go out for the bathroom late at night, I look at him, and I start singing. And I start singing [vocalization], and it's working. He's starting to recognize that when I started singing that tune, he's like, okay, and he gets up from his comfy spot, and we go outside. And it brings me a lot of joy. CHRIS: That is perhaps the best use of Pavlovian conditioning that I've ever heard of. Also, I really appreciate that you both mentioned the final countdown but then said just in case anyone is unfamiliar with the tune, let me hum a few bars. Thank you for doing the service there. STEPH: I have been singing so much this week. I don't know if Joël Quenneville, who I've been pairing with a lot, appreciates that. Sorry, Joël. But I have been singing so much. And I think that's post-vacation vibes. That's what vacation does for you. And it helps you get back into, you know, lots of singing or at least it does for me. Let's see, what else is going on this week? So this is the week that we have DST in the USA, so Daylight Savings Time, aka summertime, where we advance our clocks so everybody...although this is going to be late. So at this point, by the time people are hearing this, you're going to have already dealt with all those bugs that have crept up. But those are creeping up this week, where people are starting to notice a lot of those flaky specs that aren't technically flaky. They're actually breaking for real reasons because they were tested in a way that shows that they're not considering that daytime boundary. CHRIS: It's as if you spend some of your time fixing flaky specs that that's where your mind goes with DST. Because I'm going, to be honest, part of what you're doing right now is telling me that this is coming up, and I didn't know. I had forgotten about that, which is very exciting, except you lose an hour asleep for this one, right? Or is it that you gain? STEPH: We're going forward. Yeah, it's fall back and then spring forward. That's how I remember it. CHRIS: Worth it. I'll take the sunshine at night. STEPH: Yeah, it's supposed to be so we have more sunshine during the daylight hours. That's the reasoning for the nonsense, the headaches. On some more technical news, when I came back from vacation, we noticed that the CI build time has suddenly spiked for the client project where previously we were averaging, I'd say, around 25-26 minutes. There's definitely a range there. But that seems to be pretty consistent. And right now, builds are taking more about 35, sometimes upwards to 45 minutes. And so it's been a bit of who done it or what caused it adventure of figuring out why, what's causing the spike. And so Joël and I have been pairing heavily on that to investigate what's going on and learned a lot of features that TeamCity offers and just diving into this particular issue. One thing that brought me joy is by looking through all the builds that are taking place on TeamCity. As I noticed, there are a number of builds that are using the RSpec selective testing that I added where if you only change a test to then we're only going to run those tests instead of the whole suite. And it was one of those changes where I thought, okay, maybe someone's going to get use out of this. Joël and I will probably get use out of this. But I'm actually seeing it about one every ten build something like that. And I'm just like, oh, this is awesome. One, people are improving tests. That's amazing. And then two, that then they're benefiting especially while we have this spike going on. So that was a suggestion from you that I appreciate because that is paying dividends. And so that brought me a lot of joy while looking into this other issue, which we haven't resolved yet. We think it has something to do with how the tests are being balanced across all the different parallelized processes. And we think that there is an imbalance that has happened. And then that's what's really throwing things off. So we can see that one particular process is taking around 26-27 minutes, but then the next process that's highest in time is only taking 17 minutes. So it's like, why is there suddenly ten more minutes that's being attributed to one process? And why is that not getting spread out? So still looking into that. That's the mystery for this week. But that's mostly what's going on in my world. What's up in your world? CHRIS: What is up in my world? I'm going to say a quite alarming thing happened this week, which was we were investigating some changes, or we were investigating some behavior where the particular portion of the system ended up in the logs, just sort of combing through. And I happened to notice this one log line that...our logs tend to be somewhat verbose. They're JSON-structured log format. I've talked about the lograge setup that we use in the past, but there's a bunch. These are long lines of JSON-structured data. But this line that caught my eye was not. It was just some text, and it said, "Unreported event: and then some other texts." And I was like, ah, what? Who didn't report which to when? I did some digging, eventually figured out that this was Sentry. Sentry was logging that it had not reported an event to us. But had we not randomly happened upon this in the logs, which is sort of a random thing to see, we would have missed this, which is scary. I mean, it was missed for a little while. And so Sentry was not reporting certain events. We had made a change, particularly to Sentry's before_send configuration. So there's a way that you can do some amount of filtering client-side or client being, in this case, our Ruby app. So that's like the client-side of Sentry, and then there's their server backend. So that would, weirdly, that's the way the client-server work in this case. But the idea is you can do some proactive filtering of being like, you know what? Rather than sending a ton of noise...because we know there's this one error that we can't stop for reasons. It's a JavaScript Chrome extension that's getting embedded in the app. That doesn't mean anything; that's just noise. Rather than even sending those over to Sentry, let's proactively filter them out. before_send is a function within the Sentry SDK that allows you to do this. But it turns out if you raise an error in there, if you happen to have introduced something that doesn't cover all the possible edge cases, then Sentry will just not let you know and will log, interestingly, that they did not report the event. I'm going to throw it out there that I would love if Sentry were to say Sentry me...that's where I put something very bad happened, and you should look at it. And they're just like, well, something pretty darn bad happened. We'll log it. Supposedly, my understanding is before_send can be used to filter out like PII or other things like that. And so their failure mode is quiet intentionally. That's my understanding as to maybe why this is true. I wish there were configuration that said, no, please fail as loudly as humanly possible. But that was terrifying. STEPH: Yeah, absolutely. I'm going to piggyback on what you just said for a minute because I was also thinking earlier and related to the sudden spike in our CI builds where I was like, it would be really nice if there's...because I suspect there's one particular change that has caused this to happen. I don't know what it is yet, but that's just my suspicion. And it would be great if when that build ran, let's say that build went from an average of 25 minutes and suddenly we have a build that took 35 minutes if TeamCity had alerted us or if something more aggressive had to happen to say like, "Hey, your team..." or maybe it's just in the logs somewhere. Okay, not in the logs somewhere more visible on the build where it's like, "Hey, your build took an extra 10 minutes compared to the average, just letting you know. I don't have a diagnosis for you, but we're just letting you know." So yeah, plus-one to getting those types of alerts out to people and notifying us when there's an average that's not being met or when things aren't getting logged like you'd expect them to. CHRIS: As part of what we were doing in the logs...like how to get to that anomaly detection place is a really interesting question in my mind. And this is a case where we were in the logs, and we wanted to instrument more things. So we have a bunch of stuff right now that goes in. It's either a warn or error log level. And the error should be pretty rare because, ideally, those are going to Sentry instead, but we still want to keep an eye on them. But we introduced a new search within log entries, which is what we're using for logging aggregation and searching. And the idea was to group all warn-level messages and to group it on the message string. So ideally, what this allows us to do is say, "Oh, we've seen 200 instances in the past two days of this new warning that we didn't see before." The difficulty is, as a human, I would see unhandled error blah as one bucket of warning, or I might want to see it that way. I might want to group it on part of the message. So it becomes really hard to find the signal in the noise on these, but at least it was a start. We now have this little graph for both warning and error-level log messages that we can see are there any new anomalies that are occurring pretty regularly? But this, again, was just this weird edge case where we were lucky to catch it. But it was very scary that it was just throwing stuff away. So the universe might have been true that our error log did get a little quiet for a little while, which was nice, but it wasn't 100%. It wasn't like we were at 10 hours, an hour, and then we went to zero. It was like some, and then we went to a lower number because we were still getting some. We were only filtering out certain ones. But yeah, it's how do you know at runtime that the system is doing the thing? This is increasingly the question that I have in my mind. But yeah, so that was the thing. We fixed it. It's fixed now. I also set up an alert in log entries to say, "If you ever see this particular phrase again unhandled or unreported," then please tell me about that post-haste. So we've got that now. STEPH: That's perfect. That's what I was about to ask us if there's a way that you could add a filter or add a warning for that anomaly detection. So that sounds great. CHRIS: I've got that now because this became a known-unknown, but there are still the unknown-unknowns, and there are so many of them. And I can't know them is my understanding of how they work. I would love to know them. I would love to pin them down and be like, "Hey, what are you doing here?" Someday maybe. But anyway, that was the thing in my world. [laughs] It was fun. It was a great little time. What else is up in your world? STEPH: I feel like you can always judge the level of fun based on how high someone's voice goes. No, it was fun. It was great. It was fun. [laughter] CHRIS: I believe that is an accurate assessment, yes. STEPH: I've caught myself doing that. I'm like, my voice is extra high, so I don't think I really mean that when I'm using the word fun. [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. I do have a small update that I can share regarding the work that we're doing to be able to scale horizontally. So we want to be able to add more machines quickly and easily so we can then process more RSpec tests. And we have discovered with TeamCity that we're pushing forward on that particular path because they have something called a composite build. And with a composite build, it's essentially your parent or your supervisor build. And then, from there, you can create other subsequent builds. So we can then say, all right, let's have multiple builds that then run the RSpec test, and then we can separate in that way. And right now, we're going about it in the hacky way because we just want a proof of concept. So we are saying specifically in this particular step, we want you to run spec models. And in this other process, we want you to run these particular tests just because we want to see how this works. And so far, the aggregation seemed great. So when you look at that composite parent build, it's showing you how each of those builds are doing. It's also reporting back the failures. It's even de-duping them. Because initially, we set it up where we were running the full test suite in parallel on both of these builds, [laughs] not what we wanted, fixed that. But it did highlight that it was de-duping the test failures. So that part was nice. So the UI seems great and seems quite very capable of doing this. Composite build seems to be the way that we can do this with TeamCity. But we're still diving into actually getting the metrics like, okay, how much is this actually going to speed us up? And what does this look like if we want to be able to scale up to say from 5 to 10 where we went from 5 machines to 10 machines? And that part doesn't feel graceful because then you have to go in and change the configuration and copy the configuration to then add a new build that then is going to process RSpec test. So other services like Buildkite make it very easy. I can't remember if it's like literally a slider or if it's a number that you enter. But you can say, "This is how many processes that I want to run," in which it would be a lot nicer for that actual scaling. Versus TeamCity, it feels far more manual and intentional where you then have to duplicate and add those settings. But it's a really good first step because, as we'd highlighted before, there's a lot of risk in moving over from an existing infrastructure to something totally new. So if we can have some wins with this approach and help out the team and reduce build time, then that gives us more grace period. So then we can assess, okay, do we really want to move over to Buildkite? What do we want to do next? What does this look like? And have further discussions. So that's a small update there. Next time I should have some more updates around actual data on how things are looking. CHRIS: Oh, cool. Yeah, I appreciate the update and definitely interested to hear how this continues to play out. This is a large project that you're undertaking and all the facets and whatnot, so yeah, super interested to hear the continued journey of the test build time reduction. Let's see, other news in my world. I've been exploring something that I'm intrigued by the idea. Let's go with that. [chuckles] That's going to be my start. I always start with these lead-ins that build things up too much. But I am finding a small tension in trying to just keep up with what the team is doing, which is a wonderful place to be. Our team is growing. We actually have someone new joining tomorrow, very exciting. But I'm trying to find the right version of I don't want to block things. I don't want all code review to have to go through me. But I do want to keep an eye on everything. I want to kind of know what we're doing collectively. And ideally, mostly, that's me being like, yep, that makes sense. We're doing that. I remember that, cool. Wait, what's this? And rarely, occasionally, there'll be a point where I'm like, oh, I want to intervene here. I want to have a conversation. I want to rethink how we're building this. And so it's moving from a place of any sort of blocking synchronous review or the necessity for that to ad hoc post-review sort of thing. And so the way that I'm trying to poke around with this, of course, I'm writing some code to do it because of me. So the two systems that we're using that seem most of interest are GitHub and Trello. And so it turns out GitHub has a wonderful search, and I can create a search that is parameterized like create a URL that jumps into a parameterized search saying, "Show me everything that was merged in the past X amount of time, " so I can say the past two days because I haven't checked it in two days. So I'll see all of the PRs that were merged, and some of them I'll have already reviewed. So I maybe could even filter further there. But for anything that I haven't seen, I'm like, oh, what was this? What was that? What was this other change? Similarly, on Trello, there's a way via the API to get all of the card update actions. And then I can filter down to say whenever a card was moved, which in our system that means...we're doing Kanban-style, so a card being moved from this column to that column that tells me that someone is progressing forward with some work. And then I can further filter down because, again, I don't really want to be blocking on this. I'm most interested in what have we done or completed in the most recent timeframe. And thus far, it's an interesting data set. And it's an interesting way to switch the problem around such that I'm not feeling...there was FOMO or organizational FOMO is perhaps how I would describe it of like, I want to try and keep an eye on stuff and make sure I'm responsive. But I'm now blocking, so I have to step away. But now I'm worried that I'm missing things. And so I'm trying to find that good middle spot. And this feels like an interesting exploration of that. STEPH: I'm intrigued when you mentioned the card moving over, so then you can tell things are progressing. And then you're answering the question of what did we do in this particular chunk of time? When you move stuff over, is there a clear sweep of we have finished this sprint, and then you have the date of that sprint at the top, and so then you essentially have a column that represents all the work that was done in that sprint? Is that an approach that you're using? Because that's the one that immediately came to mind for me when you're wondering what was accomplished during this week or two-week period? CHRIS: Interesting question. So we're not really doing sprints, or there are no real iterations. We're doing more of the I think Kanban is the way to describe it. But basically, we have a prioritized next up column. And then every day, I can say continuously, the work has the same shape, which is pick up the next most important thing, work on it, move it through the various columns. I did introduce in Trello just the idea of, like, here's a month, so we can see by month what we're doing, but that's too low granularity in my mind. I want to review it a month at a time. The whole point of this in my mind is to see stuff as it's happening vaguely in real-time but not requiring me to constantly be monitoring everything. So it gives me an opportunity at the end of the day to be like, what happened today? What do we do? But yeah, so there's no real sprint that I would couple this to because we're not really doing sprints. STEPH: Got it. Yeah, that gives me more context. I understand why you're then looking for ways as to how to answer that question of, like, what did we accomplish in this week or a particular time period? CHRIS: And to name it, this is not an intention on my part to be like, I need to control everything. I need to make all the decisions. I very much want to empower the team. And in my mind, this is actually a mechanism to empower the team. I want to give them more freedom and then have the opportunity occasionally to check back in and be like, oh, actually, there was some context that was missing here the way we did this. Let's actually unwind that, do it this other way for these reasons. But it gives me the ability to potentially have that conversation after the fact. We're trying very hard to have the tickets be as representative and complete, and well documented as possible. But that's very difficult to get to. And there are also things that I don't even know to mention. Again, I think the critical bit is this is not an attempt to make sure everything aligns with what I think; it's more I want to empower the team to move without me most of the time. And then, where there are things that potentially should have a small conversation or a redirection, then we have the ability to do that. And so, I'm trying to build that back into my workflow while basically loosening up my connection to the work in progress at any given point in time. STEPH: So you just touched on a topic that's really interesting to me or a particular space. You're doing a very kind thing where you want tickets to have lots of context so that people feel confident when they're picking up what's the action item to be done. And for someone that's new, that's incredibly helpful, and I think more important since they are new to that world. But in general, my spicy take of the moment is going to be as developers; that's part of our job. If we notice that context is missing or if we're not clear about the action item, is to think through what is it that I'm missing? Who do I reach out to? Who can I go to for help? How can I scope this work? All of that, to me, is very much part of our role. And the idea that tickets always have to be perfectly curated, which I don't think you're saying, but you're just trying to be extra helpful. But if someone were to have that expectation, I think that expectation is wrong. And I do think it is part of our work that then we help make sure that tickets are well-scoped and well-defined and have those conversations with the people creating the tickets or creating them ourselves. CHRIS: I love the clarification there, and I'm definitely in agreement with you. I don't know how picante of a take it is. I would be intrigued. Listeners, let us know. Are we breaking your mold of what things should be? But I do like the idea that it is a conversation so back and forth. And so the idea that as developers, there should just be this very clear list of things to do and you just kind of pick up a card and heads down, just get it done, I don't think that should be the mold. But I do think; ideally, the why is the most important thing that I think should be in a card. So ideally, a card should have little in terms of technical implementation notes and should have more in terms of here's the goal that we're going for, here's the problem, or here's the thing that we're trying to solve. And then maybe a suggestion of like, I think it could be an X, Y, and Z, but I'm not sure. Or we want to be able to send transactional emails, but I don't know any more than that. Our goal is to engage users. Like that last sentence, that last little bit of our goal is to engage users is a critical, critical data point, versus our goal is to solve for a regulatory and compliance issue. It's like, well, those are different. And they will lead to different solutions and different implementations and all that. So yeah, I definitely share the idea that cards don't need to be perfectly specified. And if anything, I think I'm closer to that than it probably sounded like I was. But for that reason, it's totally possible in my mind, that work will be done in a way that after the fact, I'm like, "Oh, sorry, there was a misunderstanding here. Let's revisit this work." And so, my goal is to try and stay connected and have a feedback mechanism at the end of the process. So when the work is done, be able to spot-check it rather than trying to have to watch it as it's happening or proactively define everything in excruciating detail such that exactly the right things happen all the time. So I'm moving to a place of ask forgiveness, not permission. That's the wrong analogy here. But that idea of like, we can clean it up after the fact, that's fine. And we don't need to try and prevent any sort of things, or at least that's what I'm exploring. STEPH: Yeah, I love that you highlighted having the why. I adore that when that's on a card just because I then I want to know the goal because then that's going to help me ask questions and think about scoping versus if it's like a very specific implementation, then I feel so narrowly scoped that I don't feel as confident that I can be like, okay, I know why I'm doing this versus I just feel very directed to do a thing, and that's incredibly helpful. I have also felt the pain that you're mentioning where it does feel like a ticket has all of the work clearly defined, and the goals, and the whys, and it can have everything there, but just something gets lost in the communication. And so someone implements something in a way that is how they interpreted the work versus it's not actually what the ticket or what the goal of the work was to be done. So I appreciate that where you are looking for ways to tweak things to make sure that whoever is picking up that ticket will have the same interpretation that the author intended for them to have. And then if that does happen, and things get misaligned, then you chat and figure out ways to improve it. I think that's the point that I was really thinking about, and my air quotes, "hot take," is that as developers, a big part of our job is communication, and then also sharing the knowledge that we have with other people. And so if someone is expecting that they can just always pick up work and never talk to someone, I don't know, maybe you're in the wrong business. [laughs] That's my hot take. CHRIS: I, for one, like the hot take. It is nice and ever so slightly spicy. STEPH: Thanks. Yeah, I just think communication is incredibly important. Earlier, you mentioned, I don't think we were on mic at the moment, but you mentioned something about a new Git alias. And I am very intrigued on hearing about what you've added, what it does, all the details. CHRIS: All the details, that's probably too many, but some of the details I can certainly provide. So I have two new Git aliases; one is Git gone, which is probably the heart of the whole thing. And so the background of this is I found myself pushing the green merge button on GitHub more. We've introduced some branch protection stuff, which I've talked about in previous episodes. And I dream of the day that one of my good, good friends at GitHub will give me access to the merge queue beta. Please, please, I implore thee. But in the interim, still clicking the green merge button more often than not. STEPH: Wait. I have to ask to help you in this dream. Are you forwarding these episodes to someone? You can just take a clip of you saying, "Please, please, please give me access," [chuckles] and just forwarding that or mentioning someone at GitHub or GitHub in general. CHRIS: Just leaving voicemails for people with a Bike Shed section of me begging for access to the merge queue beta? STEPH: Yeah. [laughs] CHRIS: No, I'm not. But maybe I need to up my game. You're right. [laughs] Someday, I'll get there. And that will only exacerbate this issue that I'm feeling, which is again, I'm clicking the merge button. That's what's happening. And as a result, that means my local branch is now like it's done its job. You've served me well. And in the Marie Kondo sense, I need to hold you up, thank you for your service, and then let you go. But I obviously wanted to automate that. So Git gone does that automation, and it was fun. So I found a blog post which we'll include in the show notes, that had most of the pieces here, but it was still fun to play with the shell pipeline in a way that I hadn't in a while. So it does a Git fetch and then git-for-each-ref with a particular structured format that references the upstream of the branch then uses awk to search for the word gone. Because Git, if you print it out in this particular way using this format, it will say the local branch name and then the upstream. But if you've deleted the upstream, it will specifically say (gone) in brackets, so you can actually use that to filter them down. And then I pipe that to git branch-D so..well, xargs of course. I love a little shell pipeline. As an aside, these are fun little things to build up. So that is Git gone. And then the other one that I have is Git down, which is what I use more. And Git down works on top of Git gone, so it's Git checkout main and and Git pull and and Git gone. But that means I get to type Git down into my terminal whenever a branch happens to get merged in the upstream land. [laughs] STEPH: [laughs] Oh, that's adorable. I love it. I like the Git gone, and yeah, I like the Git down just for fun. You are inspiring me where I now really want a Git bless your heart that's like maybe a Git blame or a Git revert. [laughs] CHRIS: I've definitely seen people do Git praise as an alias for Git blame. STEPH: That's nice. CHRIS: But Git bless your heart is...ooh, I love that. STEPH: [laughs] I might have to add that just so I can type it, and then someone can say, "What are you doing?" [laughs] Cool, I love it. CHRIS: Little things, little fun bits to add to your day and to automate and have a little fun while you're at it. So that's where I'm at. STEPH: All about the communication and fun. That's what I'm here for and the singing. Let's not forget the singing. CHRIS: And the singing, of course. STEPH: [singing] On that note, shall we wrap up? CHRIS: Let's shall. Oh. STEPH: [laughs] CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Bye. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

BIG NEWS! Steph's expecting a baby boy!

Steph is excited to be headed on a retreat with her mom in the mountains, but before that, she details how she helped troubleshoot a production issue with her team and appreciated their process. She's also looking into tooling around spinning up more machines to process more RSpec tests. Chris had a developer start their new job at Sagewell and highlights how they involved the new person in rectifying potentially missing and/or confusing existing documentation. He also has a gripe, and that is accounts. Handling too many accounts. Additionally, he talks about triaging an error and how it was tough initially to understand if something was actually broken. And then it was even harder to understand what was broken. So he paired through it and used the power of putting two heads together. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris, I am going on vacation next week, and I am so excited about that. It's going to be pretty much a week long. It's like a Tuesday through Friday ordeal. And it's a trip that I'm taking with my mom. So over the past year, she's gotten super serious about her health and nutrition and done a phenomenal job of being very focused on a plant-based diet, which is basically healthy vegan food is what that comes down to. So there is a retreat that's taking place in the North Carolina Mountains that she's really excited about. I'm going to go with her. We're going to do lots of cooking, and hiking, and hanging out in the mountains, and it's going to be lovely. CHRIS: Well, that does sound lovely. STEPH: Yeah, it seems like a really perfect time to disconnect just because you're headed into the mountains. So all you should take with you are books and things that are not iPhones, and tablets, and computers, and screens. So I'm looking forward to that, just to be away from screens for the week. On some more technical news, this past week, I helped troubleshoot a production issue, which was a bit novel for me because the work that Joël and I are doing with our current project it's all in the testing realm. And so it was probably around 10:00 o'clock at night my time, and I got a ping on Slack. And it looked like I was getting called in for a production issue. And I was like, I have touched zero production code. [laughs] So I'm very intrigued how I could have broken production at this point. And so I looked into it, and it turned out that it wasn't necessarily related to a commit that I had authored, but it was for a commit that I had reviewed and then approved. And so their strategy is they create a new channel. They'd gotten a ticket that an error was occurring. And then the site reliability team created a new Slack channel, and then they pinged everybody who either authored, reviewed, and approved that change to be like, hey, we think the issue is related to this commit. Our plan is we'd like to roll it back. But before we do, we just want to check in with folks who have more knowledge to help us confirm that, yes, this error message seems related. And I really liked that approach. I really like the idea that it's not just the person who merged the commit that then gets pinged on it, but it's like everybody else who happened to look at this and review it come help us too. So we spent some time looking into it, confirmed that yes, indeed, it was related to that particular commit. And then their team did the wonderful thing of then rolling it back. So then, it was no longer an escalated issue. And so then I asked, "What else can I do to help?" And they said, "Well, from here, it's no longer a production issue. So tomorrow, just follow up with the author and let them know and issue a fix for the bug, and then merge it like normal." So we're back in that normal pull-request flow, very calm. And overall, I just appreciated their process. I like very much how they pulled more people in because I think some of the other people that were involved weren't online, which makes sense because it was really late. So that way, you just spread in case some other people really aren't available that then hopefully you'll get lucky and one of those three or four people are available to help you troubleshoot. CHRIS: That does sound like a really nice and thoughtful and intentional bug response, communication, procedure, rollback, et cetera. All of that sounds like it worked very well and is nice to have. And it's the sort of thing that a larger organization ideally gets to, having these sorts of processes. Spoiler alert, later in the episode, I will talk about the other side of it of being a very young organization and trying to be like, wait, is this a bug? Is this not a bug? Should we roll back? What do we do? That's actually my topic de jour. But what you're describing sounds like the calm even in the case that there is a fire sort of like, yep, we've got procedures. We have workflows. We have communication channels and ways that even the exceptional things can be handled in an ideally as calm as possible way. So that's awesome that that's what you got to experience there. STEPH: Yeah, getting called in at 10:00 o'clock is never fun for anybody. But when it happens, because it's going to happen, then I appreciate the thoughtfulness and that process that they put behind it. So it all went fairly smoothly. And it was also one of those fun things where I haven't met...like this is a very big organization, so I hadn't met any of those people. So when I got pinged on it, and then I hopped in, I was like, hi, I don't know anything about this process and what y'all are doing, but I am here. I'm here to help. Where can I look? What can I do? So it was also a fun endeavor in that regard to just be like, I don't know what I'm doing, but I am here to help. Please let me know how I can help. And it ended up working pretty well. So yeah, that's been a fun adventure for this week. How about you? What's new in your world? CHRIS: What is new in my world? Well, we had a developer start this week, which has been really wonderful. Unfortunately, we had scheduled their first day to be Monday, which was Presidents' Day, and that's a holiday. So we got out in front of that one and figured it out. We're like, no, no, actually, feel free to start on Tuesday. We'll not be around on Monday, so you shouldn't be around on Monday. But then, on Tuesday, they started. And we intentionally structured things such that we have a contractor that has been working with us for like seven or eight months now. So it's been a long time and been very formative as well the work with that contractor. So this is their last week, and thus, we very purposefully brought the new person on the team and that contractor together to maximize the amount of pairing and overlap that we have there just to try and as intentionally as possible grab whatever is in their head, get another point of view. Because this new individual on the team will be able to work with myself and the other full-time developer on the team a bunch moving forward, so we want to maximize their overlap with the person who is on their way out. But otherwise, it's been great. We're a young organization, so the version of onboarding it's me running around setting up a lot of accounts, forgetting to set up other ones, getting pings in Slack, and then following up and setting up another account. Eventually, I hope that there are checklists and formalizations and, ideally, one-click SSO magic that makes all of that work. But for now, I'm happy to chase it down. But really, we're just leveraging pairing as much as possible as the onboarding tool to make sure that where we don't have formalization, procedures, documentation, et cetera, as thoroughly built out as I would love to be at, we can shore that up with some time with other humans. STEPH: That's awesome. It's always fun having someone new to join to highlight all the things you need to automate or at least have a checklist for to then help them onboard. But that's really exciting that you've got a new teammate. CHRIS: Yeah, definitely very exciting. And they've been great. They've hit the ground running and a couple of pull requests already and just contributing very effectively within their first couple of days. So that's always wonderful to see. We are definitely taking this moment to document what is undocumented or update the README where it needs to be and start to make that checklist. We have another person who will be starting in about two weeks' time. And so, ideally, that will be even a little bit more fleshed out of a process. So slowly, incrementally get a little bit better with each we add that we get there. STEPH: How much do you involve the new person in creating that documentation? Is that something that you ask them to help build, or is it something you take ownership of? What's that balance? CHRIS: It's interesting. So definitely some I want to be with that person because I think it can often be the easy first PR is an update to the README for like, oh, I tried to set up the app, and it did not work. For this reason, I have now updated the README, and now there's a pull request. And we get to experience that flow via the very low-stakes change of updating the README. So that's a definite one that I like to have. The other is I'll typically ask for the individual to capture as much as possible. There's a very delicate line in my mind between empowering them and being like, yes, absolutely. We're young. We don't have everything documented. So feel free to make changes where that makes sense to you. But at the same time, I know that joining a new team can be complicated, can be intimidating in certain ways. You're not sure what's okay to change? What's not okay to change? That sort of thing. So I simultaneously don't want to put the pressure on someone to be like, "Yeah, no, change anything you want. Literally, nothing is stable here. Nothing's glued to the ground. So feel free to pick up anything and throw it out the window." That feels too far in my mind. So I don't have an actual answer like, I'm ideally calibrated at this point. But it's sort of those two tensions that I'm holding in mind as I think about that. STEPH: Well, I really like your answer. I like that balance because I think it's really nice to include the person in those changes and also just because they're going through it. So they happen to have that insight, and it's fresh. But I agree, when you're joining a job, you want some stability and confidence that the people that you are joining that team with are also working hard to make it a very positive onboarding experience. And if you just were to push all of that responsibility on to them to be like, "Yeah, we know. We don't have this organized yet. So you tell us everything that we need to do," that would feel unkind to that new person. I think as a new person that I wouldn't fully enjoy that. I don't mind some of it, but I wouldn't want all of it. I'd have nervousness around ownership, around improving processes, and who that belongs with. CHRIS: Sort of a classic case of it depends, or it's a little from Column A, a little from Column B, but definitely some, just hopefully not too much. STEPH: The Goldilocks of onboarding, some onboarding responsibilities, but not all of them, just the right amount. [laughs] CHRIS: Shifting gears slightly, though, I just want to gripe for a minute. I'm just going to gripe. This is not my normal mode, but I'm going to lean into it. STEPH: Do it. CHRIS: Accounts, just accounts. I have so many accounts now. There are so many across different systems, and I'm trying to do the good thing, which is let's stop using personal accounts for anything and only use organizational accounts for the things that are for work. And some organizations do a great job with this. GitHub, I'm looking at you; really well done, super happy with the way that you folks have implemented accounts. You get that I am one human being that contains multitudes. I am my personal self; I am my work self. I am maybe even another version of work, and you get that. And you usually let me exist as all of those versions of myself and, man, do I appreciate that. Heroku, you're okay. Like, it's all right. You treat the different facets of me as different accounts, but that's okay. You make it relatively easy to switch between. Although you do make me two-factor auth and re-login every single day, and I don't love that. So I don't know what's going on there, but fine. Trello, aka Atlassian, I guess at this point, come on, what are we doing? What's going on here? So originally, I had started, and I had the one Trello account, and I had my personal boards. And then there was the Sagewell organizational account. And within that, there were some boards, and I would just bounce back and forth. But I realized, no, I need to do the right thing. So I created a new Trello account. And now Atlassian just forces me to switch between them, and it loses the link that I'm going to often. It's a different login interstitial screen. And it constantly shows me that like, hey, you don't have access to this. Do you want to switch accounts? And I say yes. And then they take me to a screen where I can pick between two options, the one that I was that didn't have the ability to do it and another. And as a developer, I know that the thing I'm about to say is not fair. But come on, folks, you could know the answer to this question. There are two, and one is the wrong answer, so the other one is probably the right answer. You don't need to autolog me into that; I get it. Just emphasize it because they almost look identical on the list. I have now accidentally tried to request access with my secondary account to my other account, and I can't get out of that state. So now, one of the ways that I try and do this it shows me a list of them to pick. The other it says, "You have requested access. We're waiting to hear back." And I'm like, no. So anyway, that's a thing. STEPH: So I know people can't see me. [laughs] So I'll narrate that I'm dying over here because I very much appreciate that we are positive people. We are very focused on bringing positive energy, but the descent into the amount of shade that you're throwing at different applications [laughter] just really made my day, and I feel that pain. I have felt that pain with Atlassian and can relate. And we should have some gripe sessions. This feels healthy. This feels very...okay, well, I don't know for you. I'm the one that's laughing and getting joy out of this. I don't know if it's helpful for you, but it feels very cathartic to me. [laughs] CHRIS: It is definitely somewhat cathartic. I think there's utility in having these sorts of conversations. And throwing shade at Atlassian, whatever, they're doing fine, so I'm not super worried about it. But generally, we try and keep things positive because I think that's, frankly, a more effective way to communicate. But occasionally, it is useful to look at the things where I'm like; that is a pattern that I do not want to repeat. And I'm sure that there are complex organizational enterprise-y reasons that it has to be this way. But I can look at that and say never that. That experience as a user is like, wow, yeah, I just tripped over nine layers of your enterprise there just trying to do very simple day-to-day things for myself. So I want to avoid that. I've griped about that one login, not the company OneLogin. But that one login page that I've experienced where I start to interact with the form, and suddenly some JWT handshake in the background happens, and I'm now logged in. And it just rips the page out from underneath me. That is unacceptable. That is not okay. And I really do think there's something worth occasionally looking at those and being like, well, not that. But anyway, I should probably stop my gripe session now. STEPH: [laughs] Well, if I may join in, I have one that I'd like to share. Since we're on this -- CHRIS: Throw it on the pile. What else we got? [laughs] STEPH: [laughs] So there was some code. There was a piece of code that I was looking at that was very not friendly. It was difficult to understand. It took a while to parse through what are they actually doing? What records are they creating? Why did they choose this manner? Why are we iterating over these particular numbers? What's the outcome here? And I was pairing with Joël and was going back and forth having a conversation trying to be the detectives of why this code exists, and we finally got there. And we finally understood what it's doing and why. And I just lost it for a minute once we finally got there. [laughs] I just thought the way this code is written, it does not improve readability, and it doesn't improve performance. All it did was make my life harder because it was very difficult to read. So all they did was become really clever with the code that they were writing and essentially drying it up, which I have such a beef with DRY because it has caused me pain. And so they essentially were drying up their code or introducing a way to make it just take up fewer lines that took up less vertical space. But overall, I was very grumpy about it. And Joël was very kind about it and was like, "Well, this is the type of code I could see maybe why they did this." But you're right; it doesn't help with readability and performance. And he was helping balance out my grumpy goose moment. I've been having a lot this week; maybe it's just the week I'm in. I'm in more of a fiery mode this week [laughs] with some of the code that I'm seeing, and that was one of them. That was the please, please, please don't DRY up your code. If it doesn't improve readability or performance, there's just no need. There is no benefit. CHRIS: Well, I definitely know that feeling. And I think I've probably, as a developer, gone through that arc where early on I was just trying to make stuff work, and then I learned how to be clever. And suddenly, being clever became a game that I could play. And then, pretty early on, I realized I would come back to my own code from two weeks ago and be like, what the heck does this do? I have no idea. And that's when I was drawn to Ruby. That was one of the things. I'm like, oh, I can write code that looks so much like the clear words that I have in my head about the thing. I like that. And so much of my career has been spent in the let's make it obvious and revisitable. I actually remember very clearly early on in my time at thoughtbot, I was working on something and was working on it with Joe Ferris, who is the CTO of thoughtbot and a very clever individual, and I mean that in the truly positive sense of the term, one of the most capable engineers I've ever worked with. He was describing an anecdote, but it was basically he'd put up a pull request. And someone replied, "Oh, that's clever." And Joe's reaction was, "Oh, crap." Just taking that as not an insult but as someone saying, oh, that's clever in a positive way, and Joe hearing that in the negative form of I went too far here, or this is not obvious in its initial interpretation. That really stuck in my head from there, just his reaction to it immediately of that being not a good thing. And I was like, that is interesting. And all the more so over time, I've come to believe that clever is probably something to avoid in code. STEPH: Yeah, agreed. I'm at the point that if I do see someone who's done something that I do think is clever in a positive way, I will still abstain from using that word clever because I do want to make sure they don't think that I'm saying in a bad way that this is clever, that it's not readable, and it's not friendly. So I totally avoid that word when I'm complimenting someone's code just to make sure there's no confusion. CHRIS: It's one of those words that got away from us that we lost the definition of, and then we came back, yeah. Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Let's see. In other news, you had mentioned this earlier, and then I had mentioned my side of it but errors in alerting and all of those sorts of things. They're an interesting question. We had a small situation over the weekend that turned out to be kind of real, kind of not real. But I happened to be away on vacation. I did have my computer with me because, at this point, we're early enough. And I'm like, I'm going to take my computer everywhere and just be ready in case it's necessary. And in this case, I did get a ping. I looked into it and what was unfortunate is it wasn't immediately obvious if something was broken or not. And to a certain degree, that's always going to be kind of true. There's so much noise, so many requests hitting a web application. And how do you tell the good ones from the bad ones? And ideally, I could threshold around certain volumes of traffic, but even that's going to have spikes, and ebbs and flows and things like that. So it was very hard initially to understand is something actually broken? And then all the more so to understand what was broken. Thankfully, it was tractable. It was solvable. And we've done, I think, some good work especially considering how early on we are and how we've instrumented things in Sentry, in particular, our usage of Sentry and also somewhat in the logs. But again, I think I've talked about this before, but I'm feeling this tension around there's data. There's data just kind of like, what happened? And right now, we've got logs. That's one of the places that goes to Sentry if it gets escalated up to that level. And we sort of have a weird Venn diagram between logs and Sentry. And then we also have analytics as another thing and then eventually data science, and what do we want to try and learn? And all of these kinds of want different facets of it's not the same data set. But I wonder, is there a superset of data that then we could filter and slice and cut up, do all those sorts of things? I think this is the dream of Honeycomb and platforms like that, but I'm not even certain if that's true. And so I'm in that awkward middle space is how I would describe it. But in that particular case, I was able to resolve it. I did take away as an action it's probably time to start thinking about PagerDuty anomaly detection, that sort of thing. When does alerting happen? When do engineers actually get calls when not just during the normal nine-to-five of the workday? So I'll be investigating that in the coming weeks and see where we get to. But it's sort of the first thing that really pushed us in that direction. The other thing I'll say is we have the idea of the point dev, which I've talked about on a couple of episodes. But the idea is for each week, one individual on the engineering team is in charge of the noise, for lack of a better term. They're looking at the error stream in Sentry. They're looking at any ad hoc requests that are coming from our admin team, et cetera, et cetera. And that's been really great. But one thing that I've noticed is that dealing with the errors is particularly tricky and what we did in this particular case was just to pair on that. As an individual, it is really hard to sometimes to reproduce, sometimes to just understand these are the things you didn't expect in your code, and therefore they are, by definition, harder to understand, harder to think about. And then sometimes you get to an understanding. You're like, ah, what do we do about that? Do we care? Do we not care? Is this just noise? Is this something we should solve? Is it something we should solve soon? Or is this something we can solve whenever we get to it in the backlog? And making that sort of determination is all the harder. And so I'm increasingly of the mind that there should be some amount of time that is pairing on that error backlog to bring two heads together. I hadn't been thinking of it this way, but I've now come around to thinking this is a really great place for pairing because it's so hard for one individual to deal with that complexity to make the hard value judgments. And to do that, if each individual does that in a vacuum, then we have n different value systems at play that are hopefully very similar. But if we start to pair up, then there's osmosis between those groupings. And ideally, we sort of coalesce towards a shared value structure around, like, what can we ignore? What should we snooze for a week? What should we put in the backlog? What should we prioritize and fix immediately? Because I think those are really hard things to otherwise...that's really hard to document, I would say. I would love to write up a page in the Wiki that says, "This is how you treat errors," except each error is a unique snowflake, and you just have to follow your values. STEPH: I have been on teams where we've written up documentation that helps you triage an error because you're right; you can't write documentation around a specific error. But that I always found really helpful where it was like, here's all the links that you can look at, here are some recommendations. When we were working on an application that was falling over more often, there were some specific outlines around if you see this problem, then this is typically how you can solve it. And then we had to fix that at a larger scale, but it was a nice band-aid to get us through at that point. I like the idea of pairing, especially as you mentioned; it's tricky. It's funny when you mentioned capturing those errors and putting them into the backlog because I like that idea that then you can prioritize and bring those into the sprint. It just made me feel a bit hesitant. If we don't work on it now, we're never going to work on it. But then that feels unfair to say because it really comes down to the team. If you have a team that's going to be able to look at those errors and say, "Yes, we're going to bring them in and prioritize them," then that feels really good to then be able to say, "This is an error. Let's capture it. Let's provide some content around it. But it doesn't need to be addressed at this moment. It's still pretty low in terms of risk for users or at least low in impact for users." So yeah, I guess it just depends as long as the team feels good about being able to prioritize errors, which I feel confident that your team would be able to do. And if you can't, then y'all could reassess that plan. CHRIS: That's why we definitely have that. We're revisiting the errors. They're part of the same backlog as everything else. So they're coming up in relative priority and getting worked on and getting resolved. But we're also shifting our thinking just a little bit to say, "We should take a little bit more time in the moment to try and resolve some of these where we can." I have the dream of there are just zero bugs ever. But that's hard, especially in different platforms. And we're seeing a lot of mobile traffic and from different older Android versions and so weird JavaScript edge cases and things like that. Like, why does your runtime not have object? That feels like a thing every JavaScript runtime should have. But that's a joke. Every JavaScript runtime, I'm pretty sure, does have object but that sort of thing. It's like, whoa, this is weird and specific to this one device. Cool, those are fun. So yeah, giving a little bit more time to do those. And again, so we definitely do have the document that describes here are the places to look and how to think about this category of error and this category of error. But at the end of the day, you get one that's just like, there's not a ton of detail in the error. It's hard to reproduce. It might be device-specific, et cetera. And so what do you do in that moment? And that's where we're trying to...I think pairing is a great way to share that thinking around the team. So overall, it's been great, though. I think everyone who has been involved has been like, "This was better than when I did it on my own," so cool. STEPH: Awesome. That sounds great. CHRIS: Yeah, I think so. This is one of those ever-evolving facets of how we work as a team and how we build the platform. So I will certainly report more in future episodes, but for now, happy with that. And yeah, what else is up in your world? STEPH: Yeah. So we've been looking specifically into tooling around how we're going to spin up more machines to process more RSpec tests. So specifically, we have around 80,000 RSpec tests that we are processing, and we have one machine that is parallelizing those and takes around just for that portion of the build because then there are other tests and things that get run that brings it up to about a total of 30 minutes. But for the RSpec portion, I think it's probably around 20-ish minutes to process those 80,000 tests. So we split that across four different containers, and then we run those tests. And so we'd really like to spin up more machines to then process because we've reached the point that we have given as much power to that one machine as possible. So now we're looking to add more machines. And one of those solutions that we're looking at is using Buildkite, which is built with the idea that you can add these build steps so then you can more easily say, "All right, once we get to this particular build step, hey Buildkite, we'd like to run n number of machines to process all these tests." And that seems really nice. And it is something that we are interested in. It is actually what Shopify uses. They use Buildkite ci-queue, which is built for mini-tests, which is what they use, and Redis to then run all of their tests. But we are using TeamCity, so we're not using Buildkite. And we would like to see if we can grow with our current CI infrastructure versus having to move to a new one. There's a lot of just risk involved in moving to a new one. And so we've been studying hard if TeamCity will let us do this. And so far, the answer has been no. But just recently, we found somewhere in the docs that it looks like there is a chance that with TeamCity, we can inform TeamCity that, hey, even though we have just this one build step, instead of only giving us one agent or one provisioned machine to then run these tests, instead that we actually want to spin up a couple of machines to then process these and then aggregate the results back to this one step. So we're looking into that. But I wanted to throw this out there in case anybody else is also using TeamCity and has already invested in this particular approach. I would love to hear about it because we are currently figuring out the capabilities and if this is something that we can stay with our current infrastructure or if we're really going to have to look for a new solution. CHRIS: Well, I'm hopeful that someone out there can give you some input. I definitely get the idea that you're stuck, and stuck is maybe too strong of a word. But if TeamCity is not ideal, the idea of moving off it does feel exceedingly heavy and the riskiness that you talked about. That's, I think, a critical word here because I think it's easy to think of CI as like it's a very important thing. But that's absolutely critical as part of your deploy pipeline, I assume. This is speaking generically about CI, and so it is, in fact, a critical piece of the infrastructure. If you've got a bug on production and suddenly CI is down, what do you do? I guess you can test locally and decide you're going to push past it, but then you have to circumvent it. And so I understand the intentional way that you're thinking about that and the risk associated. I do wonder, though, if TeamCity has felt like not the right platform for a while and if there are considerations. Is there the possibility of both trying to improve the world that you have now, so it's not the big move off of it but then also in parallel start to work on an alternative implementation? This is perhaps not entirely fair, but it feels like a Rails application is this repository of code. And typically, CI is configured via a file. And that's like, if you've got your teamcity.yaml or whatever it happens to be, could there also be a buildkite.yaml that is not on the critical path for deploying or anything like that? But it is a way to, frankly, somewhat inefficiently test on two different platforms but start to see if you can get the code moving on a different platform and be able to gradually build out and make that transition possible without it being one big swap over sort of thing, which eventually it would need to be. But just wondering, is that happening in parallel? Is that a possibility? STEPH: I think the short answer is, I'm sure there is. There's a way to look at the existing system and then find ways that we can tweak it. But I also know that the team has already invested a lot into working with the current system and making it as efficient as possible. So I don't know if there's any true big impact but intermediary steps that we can take. We are definitely in that proof of concept world. So we're not going to move anything over for the rest of the team until we can really prove that something is working for a small subset and then start to expand from there. But currently, our idea is to dig further in TeamCity, which I think also includes just a call to their team and say, "Hey, we'd love to talk to one of your engineers and see if the thing that we're trying to do if it's possible. Let us know if it's not and if we need to look elsewhere," which is intriguing to me because having a lot of tests isn't new. There are tons of companies that have lots of tests, and they want their CI test suite to be fast. So a company that then has built software that helps Team execute these steps that then the ability to say, "Hey, I want more machines to process. I want to give you more money and to give us more machines, and we can process more things." I feel like that should be a thing. And I'm getting at the edges of my knowledge. This is why we're exploring all of this. But it has been surprising to me to realize that that doesn't seem as easy of a thing as I would have expected it to be. There are also some other concerns around here where the client that we're working with if we're going to work with third-party vendors, then we have to get special approval to work with them. It's not just a hey, we can just go try it out. It's a lengthy contract process that we'd have to go through. So there are also some constraints that we have to keep in mind where we can't just work with anyone. We need to be careful to make sure that they're certified in a particular way. So yes, I like your idea. I will definitely keep it in mind. But I don't know if there are any true intermediary steps yet other than the building out a proof of concept and then finding small ways that we could move over. Then I think that would be ideal for sure. And then hopefully, if there's anybody that's listening that has experience with TeamCity or Buildkite, that's the other tool that we're looking at using, let me know. I would love to chat about it and find out your experience. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph joins Chris in trying new things! For her, it's a new email client – the Newton email client – because she really wants to love her inbox. She also talks about implementing a suggestion from Chris on improving CI speed. Chris continues his search for the perfect to-do list app. (It's not going great.) But he has made hiring progress and is excited to move on to the next step: onboarding. Together they answer a listener question who asked for advice on crafting project estimates for clients. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. Newton (https://newtonhq.com/) Subscribe to Email Newsletters in Feedbin (https://feedbin.com/blog/2016/02/03/subscribe-to-email-newsletters-in-feedbin/) GitHub - Shopify/packwerk (https://github.com/Shopify/packwerk) Sunsama (https://sunsama.com/) TickTick: To-do List, Tasks, Calendar, Reminder (https://ticktick.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: I am now recording. STEPH: Me too. CHRIS: [laughs] That's my recording voice. STEPH: [laughs] CHRIS: That's how you can tell. STEPH: I just like how it sounds suspicious where we're like; I'm now recording, so be careful. [laughs] CHRIS: This is now on the record. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hello. Happy, happy Friday. Oh, I have something that I'm excited or intrigued about. I don't know. Okay, I'm hyping it up. [laughs] But I'm realizing I'm also very skeptical of it. CHRIS: This is the best sales pitch I've ever heard. I'm so excited to hear what this is. [laughs] STEPH: I am trying a new email client; it is the Newton email client. And I so want to love my inbox. I want to check on it. I want to help it grow. Okay, that's the opposite. I want to help get through all the emails that come through, but I just want to love it. I want it to be a good space that I want to go to. And I just hate email so much. And it always feels like this chore that it's really hard for me to bring myself to do, but yet it's really important because a lot of good things come through email. So this is my rambly way of saying I'm trying the Newton email client because I saw on Twitter from Andrew Mason, who has very similar feelings that I do about email, where we are just not fans of it. And we rarely check it and have declared email bankruptcy at several points in our life. And he's also one of the co-hosts for Remote Ruby. But I saw on Twitter that Andrew was talking about the Newton email client and how it actually made him feel that he enjoyed writing and looking through his inbox. And I was like, yeah, that's the sales pitch I need. So I'm giving it a go. It's been only a couple of days. But one of the nice things I have noticed about it is it's very focused, and there's not much noise, and it actually feels like very minimal design where if you open up like a new email, so you're opening up a new draft, there's no much noise. You get to just focus, almost like you're writing a little blog post or journal post or something. It takes away a lot of the noise. While in Gmail, it's going to open up a small window in the right, but then you still have the rest of the noise that feels distracting. So I like that very intentional like, hey, you're just doing one thing, just focus on this. And then also you can integrate other email accounts as well. So you can have one-stop shopping versus Gmail, then you have to click around and sign in, sign out, or visit different email accounts. So we'll see if it helps improve my email life, but that's something new I'm trying. CHRIS: Very interesting. So you're fully on inbox zero life now. That's what I'm hearing. [laughs] STEPH: Ah, hmm. I don't want to lie to you. [laughs] We have a good friendship. I won't start lying now. CHRIS: I appreciate that. So you're halfway to inbox zero. You're not even entertaining that idea, right? This is just you want a better tool to do email. STEPH: Exactly. Inbox zero is not incredibly important to me. But I do want to make sure that I know that I've seen everything important, and I know where to find things. And then making sure that I am responding to people in a timely manner. Those are more my goals. Inbox zero, if that supports it, then great, I'll work on it. But not necessarily that has to be the goal that I reach. CHRIS: Gotcha. I'm not seeing Newton, but I'm intrigued. Particularly on mobile, I have the Gmail mobile app, and that has unified inbox, which I appreciate. But Gmail on the web does not, and I find that odd. And I've never found a mail app that I enjoy because I want some of the features of Gmail. I want to do Gmail snoozing because I still want that to be consistent and whatnot. And to be honest, that's the main way that I get to inbox zero. I just say future me will have more time. I actually tweeted recently. It was a screenshot from my Saturday inbox, which I think was 15 emails that I'd snoozed from the previous week into Saturday morning. Because I'm like, Saturday morning me will have so much time, and energy, and coffee, and it'll be great. And then it became Saturday morning and, ooph, what a view. STEPH: [laughs] Yeah, your snoozing tip has been life-changing for me because that's not something that I was using all that much. The two things are, one, schedule send so that way if I do have a sudden burst of energy and I want to write an email, but I want to make sure that person doesn't get notified until a decent time. Being able to schedule an email and snoozing is amazing. I think Newton and Gmail have pretty much similar features. I was trying to do a comparison. I was like, is there something really snazzy that Newton does that Gmail doesn't already give me? But it looks like they all do about the same, having those important features like snoozing and then also being able to schedule emails. So I think it really just comes down to a lot of the UI, and there may be some other stuff I'm missing since I'm new to it. But that's the main appeal for me right now is the focus and the look and feel of it. So then maybe I will find looking through my inbox a more zenful experience, I think is how I saw them advertise it. CHRIS: Well, I definitely look forward to hearing more as you explore this space. I will say looping back to what you were just commenting on around deferred send, which is definitely something that I use, but you described one of the reasons that I use it. So the idea of wanting to be respectful of someone else and not send them an email on Sunday night because you happen to be working at that point. But you don't want to put that on their plate. I would say equal amounts; that's the reason I use scheduled send. And then the other reason that I use scheduled send is please, for the love of God, I do not want another email back in my inbox. So I will reply to something such that now I'm done with that, but I will schedule send it for the next morning. Because tomorrow morning me can deal with whatever reply this generates. There's some adage; I don't know if it's an adage, but the idea that every email that you send generates 1.1 emails in reply. So emails just have this weird way of multiplying. And so if you send one out there, you're probably going to get something back. And so often, if I'm trying to clear my inbox, I don't want to get another email in my inbox at that moment. So I will not actually send the reply. I will schedule it for a future time because I do not want to hear. I want no new inputs at this point. I'm trying to process them. So that's part of why I use deferred send. STEPH: I had not thought of that, that yeah, that if you schedule it for tomorrow, you've really gamified this inbox zero because you're like, yeah, if you send something, then you might get an email back. But you're like, if I wait till tomorrow to send it, then I'm less likely to have another email, and then I've hit inbox zero, and I'm set for the day. I like it. It seems helpful. CHRIS: Yeah, inbox zero sounds like an altruistic thing, but it is not. It's a way to force myself to have to make decisions, which is something that I want to get better at broadly. And that's part of the role that I have now. A lot of what I'm interested in exploring is just getting better at making decisions, being more decisive, being more action-oriented. Because I just have a tendency to make many, many spreadsheets and think about stuff for a while and take a long time to make a decision. But I don't get to do that, particularly now. But broadly in life, that's probably not the right mode to be in. So inbox zero is another thing that forces me to deal with things rather than just be like, I don't know, I don't know, I don't know, and keep looking at the same thing over and over. So just more thoughts about inbox zero, but now I'll stop talking about it. STEPH: I do like that, though. And you're totally right; it can be a very helpful constraint. And I think that's sometimes why I fight it because then I haven't curated my inbox enough that then when I go to it, there are so many interesting things that then I feel a little bit overwhelmed where I'm like, oh well, I want to read this, and I will look at that. And this seems interesting, and maybe I should be a part of this. It feels like one of those like; you could be a part of these ten amazing things. Do you want to be a part of all of them? And given a person that it's hard for me to say no to or recognize that no, I'm just going to not do anything with this, that is hard for me and would be a good skill for me to hone in on and practice and make quick decisions and be very realistic. Because I used to be subscribed to more newsletters, and then I finally had to stop subscribing to them because it had that same effect on me of that FOMO of like, I'm missing out on this great article or this great video. And I've become more honest with the fact that my Saturday morning self isn't going to want to read through a bunch of newsletters and videos about coding, that I'm going to want less screen time. So that is a really good constraint and helpful skill to cultivate for sure. CHRIS: All right, I said it was done, but one more thing. I feel like I've mentioned this in the past, but Feedbin is the thing that I use for RSS. I still believe in RSS as a technology. But everyone's moved to newsletters these days that go via email. Feedbin gives you an email address that you can use to subscribe to newsletters, and then they do the job of converting that into an RSS feed. So for me, I take something that was now a push into my inbox, and now I can pull whatever I want from that RSS feed. And on Saturday morning, if I'm feeling like, with a cup of coffee, I can enjoy some newsletter about all the new hot tips in Svelte land or whatever it is or not. But it's not clogging up my inbox. And with that, I think I'm actually done talking about inbox zero. [laughter] STEPH: Yeah, that's a nice separation. We could keep going. I have full faith in us that we could keep going about this. But I'll share a slightly different update. I've been implementing a suggestion that you provided a couple of weeks back where we were talking about Rspec's selective test running and how some applications will speed up their test. If you change one part of the codebase, then perhaps you only need to test this chunk of test. You don't actually need to run the full test suite. And that is complicated and seems hard to get right, and really requires understanding boundaries. But then also knowing Ruby, then how do you really identify? Do you really know where this method is being called and can identify all the tests that need to be run? I think we'd mentioned before there's a really good article from Shopify where they have worked on this and created an open-source project called Packwerk. So we can link to that article in the show notes. But more specifically, you suggested, well, what if you just change a test file? That seems very low stakes and also has the benefit of creating a reward where if someone does see something that they can improve in a test, then that's a very quick feedback. Let me just get this change. It's going to be fast on CI. I can merge it right away and also saves time on CI. So I've been working on implementing that change. And it's one of those the actual change is easy, like checking with Git to say, "Hey, what files have changed?" Does it have an _spec.rb at the end of it? Great. Does it not? Okay, we've changed some application files. So let's run the full test suite. That part's easy. Getting it integrated into the build system has been more complicated just because this team has done a lot of work around trying to improve and speed up their test. And there's a fair amount of complexity that's there. So then figuring out a way to stitch my change into all the different build processes that take place has proven to be more difficult. But it's also been insightful just because it has now helped me really understand and forced me to learn, okay, what are all the different steps? What's important for each one? Where can I cut off the rest of the running of the test and instead just focus on running these tests? So in some ways, it's been challenging, but then on the positive side, it's been like, okay, well, this has taught me a lot about the existing system. So at this moment, it is still a work in progress. I'll have more updates in the future. I am excited to see the rewards. I've gotten to the point where I just have a proof of concept where I've gotten pushed up, but it's not production-ready. But it's at least I just wanted the feedback that I'm in the right spot and that we're running just the right test. And so far, it does seem like it's going to be a nice win, even if it's maybe not used by everybody because it's probably rare that someone is altering just a spec file. But for people who are looking specifically to improve the CI build time and working on tests, it will be very helpful to them. So yeah, I'm sure I'll have some more updates in the future. What's going on in your world? CHRIS: Well, I definitely look forward to hearing more about that. However, we can improve CI speed; I'm super interested in that as a topic. Mid-Roll Ad Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. CHRIS: Well, similar to your email adventures, I continue on my search for the perfect to-do list. It's not going great, if we're being honest. [laughs] To be clear, because I've mentioned this on a few different episodes, I'm not spending much time on this at all, some but not much. And so it's not really moving. But there are two interesting things. I took a look at TickTick, which was one that I mentioned in the past, a tool for this. It seems good. It seems like an intersection between things, which is what I'm currently using, Todoist, which I've used in the past, and some other tools. So I think I'll probably explore that a little more. It seems like a good option. Decidedly, the most interesting thing is a tool called Sunsama, which is different in some interesting ways but very interesting. So one thing to note about it is it's $20 a month, which is a lot of money for one of these tools because most of them are like, "We're $20 forever, and then it's free." And it's a surprisingly low-cost space. And so, they're definitely positioning themselves as a more costly entry. I would be fine with paying $20 a month for a tool if it really is like, no, cool, I feel great. I'm more productive. I'm happier when I'm not working, et cetera. But what's interesting is they seem to do a let's reach out to all the places that tasks can live for you. So there's your inbox for email. There's your Trello board that you've got. There are GitHub issues. There's Slack. There are all these different sources of potential tasks. And they do a really good job of integrating with those other tools and then allowing you to pull that list into Sunsama and then make each day you have a list. And those items can be like, this is a reference to a Trello card on that board. This is a reference to a Slack conversation over there. So I'm super intrigued by it. It's also got a very intentional plan your day mode, which I like because that's one of the things that I'm really looking for is at the end of the day, I want to clean everything up, make sense of all of the open items, and then reprioritize and set up for the next morning so that I can just hit the ground running. That said, I tried it, and it just didn't quite click. And I think it's one of those it takes some effort to understand how to use it. So I'm not sure that I'm going to get there. But it is super interesting because that idea of our work lives in all of these different tools these days feels very true. And so, something that is trying to act as a hub between them to integrate them is very interesting to me. Again, I haven't really gotten anywhere on this. I'm kind of just reading blog posts, as it were. So I'll report back if that changes, but -- STEPH: The search continues for the right to-do app. Yeah, that seems interesting. I don't know why I'm feeling hesitant towards it. I'm one of those individuals...you're right; there are so many tools. And the fact that they integrate with a lot of them seems really nice. I'm at the point where I just grab links to stuff, and I'm like, hey, if this is my priority, I grab a link to a Trello ticket, and then I just copy that into my to-do. I guess I like that bit of work over having to integrate with a bunch of different platforms. Because once you get used to integrating...I don't know; I'm just rambling. But I wish you the best on this journey. I'm excited to hear more. [laughter] CHRIS: Thank you. I will certainly report back. But yeah, nothing pointed to share at this point. But I do have something pointed to share on the hiring front, which is that we have hired some folks. STEPH: Hooray! CHRIS: Yay. So this has been a fun saga across a couple of different episodes. And in my mind, it feels like this much longer, more drawn out thing, but it's; actually, I think, come together relatively quickly, all things considering. We've got someone who's starting in a little over a week's time, and then someone else who's starting in, I think, two or three weeks after that. So that'll be great. Hopefully, we can transition into onboarding, which is a different whole approach. But hiring as a distinct activity can scale back significantly. As we discussed last week, I want to be in the always be hiring mindset but in the more passive mode of having conversations with folks, staying connected. And if a great candidate comes along and it's the right time, then bring them on the team but not actually actively reaching out and all that sort of stuff, which will be great. Because it turns out that takes a lot of time and also a lot of energy for me. Having those first conversations, going into it very intentionally trying to communicate about something, and there's a tone of salesmanship to it that is not my natural resting state. So I come away from each conversation being like, that was fun, but also, I'm drained now. Why am I so drained? So not having that be a thing that is filling up my calendar is great. And also super excited with the folks that'll be joining the team and to be able to now grow our little team and define the culture and the shape of the groups that we will be collectively. I'm excited for that work and what we can build together. So yeah, it's an exciting time. STEPH: That's awesome. Congratulations. Because yeah, everything you're saying sounds like it's just been a lot of work. So that's very exciting. There's someone that I was chatting with earlier today where they were talking about the value and the importance of understanding what your natural skills are and the things that bring you energy. And so you're mentioning there are certain activities that you enjoy them, but they're also draining because perhaps they are on the outer boundary of what you might define as your own natural skill or the things that get you really excited. And I found that all very interesting. It had me thinking about that today about where are the natural areas that I find that I get energy that are easier for me? And then making sure that I'm trying to prioritize my day so that I am more focused on the activities that just align with who I am and also that I'm engaged with and then also looking for ways to stretch. But they made the point that if you are always in a space where you are not using your natural talents, and you're always having to stretch, then that can be what leads to burnout. Versus if you're in that sweet spot, that zone of where you are using your natural skills, but then also stretching a bit. And I think there are some assessments and things like that that will help you then determine what are my natural skills, and what do I like to do with my time? I just like that style of thinking and recognizing, like you said, like, hey, I did a thing. It was fun, but I'm drained. So now I know that this is something that requires more effort for me. Like hiring, that's one for me. I really like interviewing. I like talking with people, but I'm so nervous for them because I know interviews suck. [laughs] I just have so much empathy for them where I'm like, this is going to be a hard day. We're going to make it as pleasant and positive as possible, but I know this is a hard day. And so I feel like I'm in it with them. And so afterwards, I feel that same relief of like whoo, okay, interview day is over. CHRIS: I don't know that I quite achieve the same level that you do but in no way am I surprised that that is your experience of hiring. And just to name it, you're a wonderful human being that feels for the people on the other side of the hiring table. Like, oh my God, this must be so stressful for you. It's so kind of you to be in that space with folks. But coming back to what you were saying a moment ago, that idea of, like, understanding where your strengths are and where they're areas that you're not quite as strong. And I think critically, the question of like which are the ones where I want to just kind of say no to? I'm like, that's fine. This is not going to be a competency of mine. And I'm going to just avoid that or find other people to work with that balance that out. So for me, sales is the thing that I don't think that's ever going to be my bag. I don't think I'm ever going to move in that direction, and that's totally fine. Whereas decisiveness, which I was describing, is like, I think that's the thing I could get better at. That is one that I don't want to sleep on that. I don't want to say, "That'll be fine. I'll just have other people make the decision." No, I need to get better at making decisions, making decisions with less information or more rapidly, having a bias towards action. All those things I think will be deeply beneficial. So I'm trying to really lean into that. Whereas yeah, again, the sales stuff I'm like, yeah, and there's plenty of examples of this otherwise. But I've also been coding a bit more this week, which has been lovely because the hiring stuff has ramped down. And that has freed me up amongst some other stuff that's been going on. And you know, I like to code, it turns out. It's fun. I just clack about on my cherry brown keys, and it's great. STEPH: Do you remember when we first got introduced to mechanical keyboards, and we had co-ownership of one of the keyboards? And we literally had days of where it was like your turn to use the keyboard. And then it was my turn to use the keyboard. How long did we keep that up before we were finally like, we should just buy our own keyboards? CHRIS: It was a while because we were working with a colleague who was trying out a Kinesis, I want to say, one of the split little bowl of keys. But yeah, we had a shared custody over a keyboard, and it was fantastic. I remember that very fondly. STEPH: The days that it was my keyboard, I would go to the office and be like, oh, today is my day at the keyboard. This is great. This is going to be such a wonderful day. [laughs] And now I'm just spoiled. CHRIS: It went on for a while, though. And this was something where we both obviously enjoy this keyboard. Why don't we just buy one of these keyboards? We totally could have done that. And yet, for some reason, both of us were like, no, but what if...I got to think about this. Again, decisiveness. [laughs] We come back to this topic of well; I had to really think about it. And then somebody got the 92-Key test or whatever it was in the office. And so I just went over and poked every one of those for a while. STEPH: Exactly. It was option overload where we're like, well, okay, we're going to buy one, and then you open it up and search, and you're like, oh, you want options? We have options. Do you know about the blues, and the browns, and the colors, and these different options? Like, I don't know any of this language that you're talking about. I just want to clackety-clack. So yeah, it took time. We had to do our research. CHRIS: And then I ended up on basic browns. So here we are. Let's see, popping back up the stack a couple of levels, hiring that went on for a while. Now it is less going on. Although to be clear, like I said, always be hiring. So if anyone out there in the world is hearing what I'm talking about with Sagewell or seeing any of the stuff that I'm putting on Twitter, which isn't much, I occasionally just post screenshots of my commit messages, which recently included better snakes as a commit message. [laughs] I have to dig into that or not. But we were just doing some snake case to camel case conversion. But the commit message was better snake, so here we are. Anyway, if any of that sounds interesting, please do reach out. But I'm excited to transition back to focusing more on the work. On that note, actually, I'm going to call it interesting things that is happening right now organizationally is; we are working with an external security firm to help with some...they helped us out with a penetration test when we needed that. And then they have stayed on retainer and are helping with various different configurations, taking our AWS S3 buckets and making sure those are nice and secure, and all that kind of stuff. But we've recently started to focus more on organizational security, specifically a bowl of acronyms. We've got SSO for single sign-on, MDM for something device management. I don't know what that first M is. I probably should learn it, but it's fine. That's why I've got help on this is I think they know what the acronym stands for. But so we're working on each of those. And on the one hand, they're probably going to be kind of annoying, like having to go through the single sign-on. It's a whole thing, and it's harder to sign into stuff sometimes. I mean, ideally, it's actually easier. But in my experience, it adds some friction at some points. And then MDM means that there's now some profile manager on the computer. So I can say like, "Every computer must have full disk encryption or else you can't use it. And we need a passcode, and it must be this long and those sorts of things." So it's organizational controls that I think are good for us having a robust security setup throughout the organization. But yeah, they're the sort of things that I think historically, I probably would have, as someone working in an organization, had been like, do we have to? Do we need these things? Couldn't I just do whatever? But now there's something about it that I really like. I'm trying to name it in my head, but I'm kind of like, I don't know. This feels like growing up as an organization. And there's always weird corollary that I've been thinking about with the Rails app that we've been building, intimately familiar with just everything that's going into it. And I know the vast majority of lines of code. I haven't written them all, but I've had an eye on all of the different features that we're building in. And it's hard to get out of that headspace where it feels like a bunch of pieces. It doesn't feel like a hole to me, even though it definitely is. But when does a bunch of boards that you nail together become a boat? To make a really weird analogy because that's what I do; it's a hobby of mine. But when does that transition happen? At some point, certainly. But that's harder for me to see on the code side. And organizationally, somehow getting these things in place feels like the organization sort of an inflection point for us, a growth point, which is I'm really excited about it. Even though they're probably going to mean a ton of annoying nuisance work for me because I'm the person in charge of making sure it all gets rolled out. And anytime anyone locks themselves out of an account, I have to help with that. And so it's probably just putting a bunch of annoying work on my plate. And yet, I don't know; I'm kind of excited about it. STEPH: I feel like that shows our roots in terms of how we approach projects that we work on where you mentioned do we need this? Do we need this yet? Because I feel that we're constantly as developers and consultants just we're trying to advise on the more simplified do we need this? Is this the right thing to spend the money on? How do we know? What are the metrics? What does success look like? And all those questions. So I feel like the way you just phrased all of that just really shows that sort of mentality that you grew up with in terms of checking in, and yeah, it's cool. Like you said, you're at a growth point where then it's like, yes, we are at this point that I've asked myself all those questions, and we're here. This feels like the right next step. CHRIS: I like the way you described it as that you grew up with, my formative growing years at thoughtbot. Mid-roll Ad Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Well, switching gears just a bit, we have a listener question for today, and this one comes from Stephanie. So not me, another Stephanie in the world. Hello, other Stephanie out there in the world. And they wrote in, "Hi, Steph and Chris, fellow software consultant here. And I'm wondering if you'd consider talking about how to craft a project estimate for a client on the pod. It's such an important aspect of consulting." Amen. I added the amen. "And I feel like I'm very much impacted as a project team member when the estimate isn't accurate." Double amen. So true. [laughs] "Would appreciate any and all thoughts, especially since it might be part of my job in the future. Thanks." I just realized I put us in consultant church by adding all those amens, but here we are. [laughs] CHRIS: I'm glad you clarified that they were additions by you and not part of the original question coming in. STEPH: Sure. I don't want to speak on behalf of Stephanie. So I have some thoughts on the matter. I think there are a couple of different ways that we can talk about this particular question because I think there are different formats as to when you're estimating and who you're providing the estimate for. But I'm going to pause because I'd love to see what you think. How do you go about approaching crafting an estimate? CHRIS: Sure. I'm happy to share some thoughts. And for a bit of context, this question came in to us, frankly, many months ago, but I did send an initial reply to Stephanie because I know that sometimes we take a little bit of time to get back to folks. So if ever you do send in a question, know that one of us will probably respond via email earlier, and then eventually, will make it on the show. And again, just to say, we do so appreciate when folks send in these questions. It's an interesting way to shape the conversation and a way to get topics that you're more interested in into the fold here. But so the two main ideas that I shared in my initial reply were, first, is an estimate really necessary? I think that's a critical question because an estimate implies that this thing is knowable. And as many of us, probably all of us, have found out at some point in our lives as software developers, it's really hard to do software estimation, like wildly difficult. And not just the thing that we'll eventually get better at it, which you do, but there's just some chaos. There's some noise in this work that we do that makes it so, so difficult to get it right. So pretty much always, I will ask, like, do we need to estimate here? What if, instead, we were to flip the whole question on its head and say, let's set a deadline. Let's say two months from now that's our deadline. And let's ruthlessly reprioritize every single week to make sure that we're building something that's meaningful, and we're getting there. And obviously, we have to have some general idea of what we're doing. Is two months a meaningful amount of time to build a rocket to go to Mars? Probably not. But is it enough time to build an app that can allow users to sign in and manage a simple list of items? Yeah, we can definitely do that, and we can probably add a bunch of more features. The other thing that I think is worth highlighting is there's a bunch of stuff that is table stakes and very easy to do. But I would, whenever doing estimation, emphasize unknowns. So, where are the external integrations with other systems? Where are the dependencies that rely on other folks to provide some inputs into this process that we can't be certain where there'll be? In my experience, the places where estimates go awry are often these little intersection points that you're like, well, this will probably take a day, maybe two. And it turns out; actually, this can somehow balloon into a month. That's not a thing that feels comfortable saying in an estimation process, but it is definitely real. I've seen it happen so many times. And so it's those unknowns. It's those little bits that I would emphasize as part of the process if you do need to do an estimate and say, all right, here's the boring stuff. I think we can do that pretty easily. But this part, I don't know, it could be a week, could be three months. And frame it in that way that there is this ambiguity there. Because if someone's asking you for an estimate and they're looking for like it is seven days and two hours exactly, it's like, well, that's not realistic. That's not how this thing works. Unfortunately, I wish it did. But pushing back and changing the conversation is the thing that I have found valuable. I think there's some other really interesting stuff in here around the team dynamics that Stephanie is talking about. But I want to send this over to other Stephanie to see your thoughts because I'm super interested to hear what you have to say as well. STEPH: Oh, I like how you hinted at the team dynamics. Yeah, that could be a fun one to circle back to. So I love how you called out highlighting the unknowns. There are a couple of ways that this comes to mind for me. So there's the idea of the weekly or the bi-weekly estimates that we make as developers and designers. So let's say we as a team are getting together to focus on a chunk of work and decide what we can and can't get through. And that feels one of those the more you get to practice it more frequently; you get to ask a bunch of questions. And that feels like a good rehearsal and exercise of how to go through estimates. And I know you and I have pretty similar strong feelings around how those estimates are then treated by the company. They should really just be used for the team to talk through the complexities in the work to be done versus used to communicate outwardly as to this is when it's definitely going to ship. So there's that more immediate practice of providing estimates. And then there's the idea for more of a consultancy or a company, and someone is coming to you, so thoughtbot being a great example of then how do we work with teams that are looking to come to us and gain an estimate for getting a certain feature implemented? So actually, I went to the source on this one. I went to Josh Clayton, who does a lot of the conversations for the Boost team when it comes to talking with clients and about the potential work that they would like to be done. And mostly our work is often teams will hire us. They have specific goals in mind, but they're really looking to hire ongoing development and services. So they really want to add to their existing staff. And then it's going to be an ongoing relationship versus a hey, we need you to quote us for how long it's going to take to implement this particular feature. And on that note, we don't do fixed-bid work. So we don't say it's X dollars for specific features. But on the realistic side, customers are often capped by a budget. And so that estimate is very important to them because it could be a difference between it's a go versus a no go. So if you have larger companies that are like, "Yep, we want to engage with thoughtbot. We really just want additional development power and design services," that's great. For those that are smaller, it could be an individual product owner, and they need to say, "I really want this feature, but I only have this much money. And frankly, if I can't ship it by this time, I'm not going to do it because it's not worth the investment to my company." And then, in those cases, those are the ones that we're going to spend more time with them to talk about what does the fallback plan look like? And what's our opportunity for simplifying the features? And Josh, in particular, referenced this as systems thinking. So he will go through the idea of drawing out the set of steps, understanding the complexity of the different screens. So what are the validations? What are the external dependencies? What is owned by us and what isn't? What is the likelihood that we're going to get permission to simplify or remove complexity? And even then, when we start to provide some estimates, it's going to be in weeks. It's not in hours; it's not in days. It's going to be in a slightly larger time frame. And then we're also going to spend more time in the discovery phase to say, okay, well, we know you need to fix this particular issue, or you need to integrate with this particular service. So we're going to need to ask a lot more questions about your codebase. What problems have you already run into? Have you tried to do this before? Do we have experience doing this? Is this something that we can lean on and ask someone in the team? And, say, how long do you think it would take for us to work on this? And that's knowledge that isn't privy to everybody. It depends on where you're at in your career as to like, oh yeah, I've done this like five times before, and I know exactly how this stuff can fall apart. I know where the complexity lies. So I think that's why estimation is so difficult is just because it does often pull from that existing experience. And so, if you don't have that experience for a particular set of work, of course, it's going to be hard to estimate because you just don't know. So that was a very broad scope of as day-to-day developer and designers; I feel like we're constantly getting practice and estimating and communicating the progress of our work. And then on the larger scope of if you are a consultant who's then looking to give estimates to clients, then understanding what other need can you sell them? Just ongoing development services. Or, if they are a smaller team and very focused, then what legwork can you do ahead of time to de-risk the project? And then understand how much control you're going to have to be able to simplify as you learn more as you go. Because you're going to, you're going to uncover some things, and you're going to learn some things. And what's that collaboration going to look like? I do have one more concrete example I can provide around some of the smaller projects that we take on. So when we are helping someone that's, say, getting a new product out to market, then we do have a more deliberate three, four-phase approach where we first focus on discovery, and ideation, and validation. And then, we move on to iteration and then launching. And I really like how you said about providing a deadline because then that helps us scope aggressively as to what is the minimum thing that we can get out into the world that will be valuable? And then there's usually some post-launch support as well. But that's often how we will structure those smaller, more specific engagements. CHRIS: I think one of the critical things that you highlighted in there is that thoughtbot doesn't do fixed-bid work. So we're going to do these 20 features, and it's going to take four months. thoughtbot does not do that, and frankly, that's a privilege to be able to take that position and say, "No, no, no," we're not going to work that way. But it is, I think, a trade-off. It's not just something that thoughtbot does to be like, listen, that doesn't sound fun. So I'm not going to do that. It's a trade-off. Not doing that comes in concert with saying, "But weekly, we're going to talk about the work that we have done and the work that remains and constantly, ruthlessly, reprioritize and re-decide what we're doing." And it's that engagement, the idea that you can have a body of work, look at it and say, "Yeah, that'll take about six months," and then go away for six months, and then come back with the finished software. Our strong belief is that that's not the way good software gets built. But instead, it's a very engaged team where the product owner and the development team are in constant communication about each of the features that are being developed. And then again, ideally, on a weekly cadence, coming up for air and saying, "How are we doing? Are we moving in the right direction? Are we getting towards the goals? If not, do we need to simplify? Do we need to change things?" And similarly, as I mentioned deadlines, I feel like deadlines is probably a word that many people think of as very bad because deadlines often come with also a fixed scope, but that can't happen. That's two constraints, and you can't have them fighting that way. But a deadline can be super useful as a way to say we're going to put something out there in the future and say we're heading towards that moment. And let's, again, cut scope. Let's change what we're building, et cetera. But critically, not say, "We got a deadline and a fixed scope. We're going to do that." And so it's, again, just ways to gently shift the conversation around and say, what if we were to look at this from a different angle? Because just having a pile of work and saying, "That'll take six months," I've never seen that play out. STEPH: Yeah, to me, deadline is a bad word when the deadline is set by a team that's not doing the work. So if you have leadership or if you have someone else that is setting this deadline and then just passing that down to someone else to then fulfill, regardless of the feedback or how things are going, then yeah, then it can be a nasty thing, which I think is a little bit of in that question that you picked up on that you highlighted where there could be some interesting team dynamics that Stephanie called out, highlighting that I'm very much impacted as a project team member when the estimate isn't accurate. And I'm making some assumptions here because I don't actually know the exact situation that Stephanie is experiencing. But it sounds like someone else externally is setting these team estimates. And so then you're handed this deadline, and then stuff goes wrong, but you're still pressured to meet this deadline. And I've certainly been part of projects that are like that. And then that is one of the number one things that then often comes up in a retro or like, we don't have control over these deadlines, or we don't know why these deadlines are being set. And then people are working extra hours and working nights and weekends to then meet this arbitrary deadline that none of us signed up for, and that's just not fair to treat deadlines in that way. So full-heartedly agree that deadlines can be a very positive thing, but they need to be set by the people doing the work. And then there has to be discussions and updates about how is this going? Do we have control to simplify this? We thought we could do this with this particular external provider. It turns out that that's a nightmare. Is there another provider we can go with? Can we ship this incrementally? Like some features, you can't. They may have to go out wholesale. But is there a small chunk of this that we can deliver that is then a success that leadership and others can brag about? And then we can keep working on the rest of it. So it's always identifying what are the smallest wins, and how do we get there and getting buy-in from the team? Going back to something that you said earlier around, it is a privilege, where so as thoughtbot, we don't do fixed-bid work. And that is a nice thing for us to be able to focus on. But for people who do need to do fixed bid work and are relying on that, I think that often requires more legwork. And maybe that becomes part of your estimate. I'm just making up how I might approach this if I were trying to do fixed bid work. But there's a discovery phase that's very important. So maybe the first part of your estimate is I need to really understand the feature and see the different screens and know what materials we do or don't have. What does the codebase look like? Do I feel like this is a codebase that I can work quickly in? And is it going to be hindersome for me? But answering a lot of those questions to then help me paint a picture of, like, okay, this is a feature that I've implemented before, so I feel pretty confident that I could do this in a month. And then also communicating that this is my estimate but just know it's an estimate. And I will continue to update you each day as to how things are going or each week as to how things are going, and things may adjust. And we can always talk about ways about simplifying this. But I think that's how I would go about it is; frankly, it's going to require more legwork for me to feel more confident as to then telling someone as to how long I think the work will take. I think that's a nice, broad scope of the different types of estimate work to be done with the general idea of if you can avoid estimates and go for more frequent updates, then that's wonderful. But then, if you are forced into a corner where you need to provide an update, then just do as much research and honesty as possible and then still include the frequent updates. CHRIS: Yeah, that I think summarizes it quite well. STEPH: As a side note, it's been a lot of fun to feel like I'm referring to myself as a third person as Stephanie is working through this problem. So that's been novel. But yeah, thank you, Stephanie, for the great question. I hope that was helpful. On that note, Shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Chris is making hiring progress and loves asdf and M1 laptops. Steph is anticipating the arrival of one dongle to rule them all and talks about moving away from having a lot of Bluetooth connections. Two other big things on Steph's mind are education around factories because they're v important and shared examples and how they can be overused. She and Chris agree that it is better to tell stories in tests instead. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. GitHub - asdf-vm/asdf: Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more (https://github.com/asdf-vm/asdf) Factories Should be the Bare Minimum (https://thoughtbot.com/blog/factories-should-be-the-bare-minimum) Mystery Guest (https://thoughtbot.com/blog/mystery-guest) GitHub - varvet/pundit: Minimal authorization through OO design and pure Ruby classes (https://github.com/varvet/pundit) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed. [laughs] CHRIS: Hello, and I'm singing, and I love singing. STEPH: It's Buddy the Elf; what's your favorite color? [laughter] For reals, here we go. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris. What's new in your world? CHRIS: My world continues to be focused on hiring as a pretty core aspect of things. We have happily had one offer extended and accepted, so that's great. We've got a person who will be joining the team in a couple of weeks. That's very exciting. And we're continuing in conversations with some other folks. So I look forward to the place where I can be on the other side of this and have that team and be growing the team and not having to focus because hiring takes a lot of effort. It is something that I believe should be done as well as possible and intentionally as possible and then just outreach and all that. So yeah, I'll be fine with being on the other side of that. But it's going well, so that is nice. STEPH: That's awesome that you're making progress. Once you have hired your team, will you then add to the agenda to hire someone to help with hiring? CHRIS: I don't actually know if the organization, if the whole company has someone who's focused on hiring. I think that can make sense. Working through recruiters and things like that is something that I've seen in the past. I've seen it work for certain organizations. I've also been on the receiving end of plenty of obviously copy and pasted very generic "Hey, person, I saw that you do lots of Java and other enterprise code software. Would you like to come work with us?" I'm like, none of those are true, and I do not want to go work with you. But thanks, I still appreciate the outreach. [laughs] So I am intrigued to see how we think about it. More generally, this is something that you and I have talked about offline but the idea that you kind of always want to be hiring. We do have specific roles that we've identified that the budget has space for. But more generally, ideally, we're going to need to hire more people down the road, and that will happen at a particular point. But having those conversations, starting to talk to people, now planting the idea of like, hey, you're great, and I would love to work with you someday and just keeping those lines of communication open. Networking is perhaps what the people call it. I don't know; I've never felt super comfortable with that word, but I think it's that and being friendly and staying connected with people whose work I respect and would love to work with more. So that's part of what I will come out of this with is yeah, let's always be hiring in a certain sense. STEPH: I'm glad you expanded on it because I was just thinking I have specific ideas as to what always be hiring means to me and what those activities would include. So I was curious what it means to you. And I agree, I think it's a lot of networking. It's a lot of taking chats and social chats with folks and just talking about the company and finding out where they're at. And then one day, if it works out that then they want to make a shift, then you've already got that relationship that started, and they're already potentially interested in your team. I guess some of the other big stuff that comes to mind, too, is like thoughtbot we have the blog. I feel like that's always really helpful too. Like when you help somebody, when you publish information that then helps them in their career, I feel like that will then draw people towards you as well. CHRIS: Yeah, the thoughtbot blog and basically everything that thoughtbot does, the podcast here, or Upcase, or all those things were so incredibly helpful in the hiring. But I also know they're hard to spin up, is what I would say. The thoughtbot blog has I don't even know how many hundreds of thousands of hours maybe. It's weird to try and put a number to it. But I've written a handful of posts for it, and I'm not great at writing them. They take me way longer than they should, but they took many hours. And then I had wonderful peer review by other developers at thoughtbot. And so, the amount of effort that goes into the thoughtbot blog absolutely produces wonderful benefits. But it's not free by any means, and similarly, the podcasts or Upcase or any of those sort of things. Similarly, the one that's actually most interesting that I see a lot of organizations go for initially and then often walk back is open source. Like, oh, we have this internal library that we built to do something. What we'll do is we'll just package it up and share it with the world, and then it'll be great. And the maintenance burden and support necessity of an open-source project is so high. I've actually historically gotten into the mode of suggesting...when I was working with clients, they would start to mention this and be like, "Oh yeah, we think we'll open source this thing, and it'll be great." I'm like, "Are you sure, though? Do you definitely want to?" There's definitely a difference between open sourcing and just putting an idea out there is one thing that I would say. Can you just write a blog post that has code snippets but not reusable code that you have to maintain that people, unfortunately, I think unfairly expect responsiveness and maintenance over time? And what if you stopped using that technology? What if you stop using this thing, but your name is still attached to it? And people have expectations of what that looks like. Or people come in and say, "Hey, this is great, but I want to change it in this way." And you're like, "Yeah, but that actually doesn't work for us. That's not how we use it. But we would be on the hook to maintain that code if we accept your pull request." And so, as wonderful as open source is, I tend to be on the more conservative end of the spectrum of like, are you definitely sure you want to open source this? Is there another way that you can share this with the world? Can it be a conference talk, or a blog post, or something like that? But it is an interesting one. STEPH: Yeah, I've been a part of several teams that have started with that; let's start an engineering blog. And their hearts are totally in the right place, and I understand why they want to do it. But like you just said, there's a cost to that. And if you don't have something like thoughtbot has like an investment day or a time for engineers to then be able to contribute to that blog, then either they're just not because they're not going to have their downtime to be able to do that. And it is hard to write and publish and be happy with what you're going to publish with the world. I really like what you're talking about in terms of the maintenance burden because I can't remember if it was an Upcase conversation or if there was something...but I was early on at thoughtbot and had a similar thought of why can't we just open source it? Why can't we make it public? And there was a very big thoughtful discussion around well, we have to have all these considerations in place. Who's going to maintain it? Just like FactoryBot is a really big internal project at thoughtbot. And there's typically a rotation of folks who will then take ownership and then onboard other people who are interested in it and curate the issues. And it's very important work, but you have to allocate time for it. All of that to say, I totally agree. There's a big burden that goes with it. CHRIS: Yeah, it's interesting that this has been an evolving thought in my head, and it makes me sad is another thing I'll say about it. I wish it were easier to just put code out there in the world and have the expectations properly calibrated for like, hey, I did this thing. Here's a code sample. It worked for me. Actually, I found dropping something in a Gist...a Gist just has a point-in-time connotation to it that I like. Like, if I see a code sample in a Gist, I'm like, I have no expectation that that person is going to do anything or respond to anything I have to say. But this is great because I now have this sample code that helps me get a little bit further. And I may have to vendor that code or take it on myself, and I now own it. It's not this person's responsibility. But the minute you have a repo with a README that says stuff and like, here are the installation instructions, the expectations just flip in a way that I don't think is...at least I become cautious around. And that does make me sad, though. STEPH: Yeah, it feels like you went from offering an example to I'm offering a product. And so then as soon as people feel like, oh, you're giving me something as a product that you maintain, then I'm going to have higher expectations of it should work how I expected it to work. I'm going to ask questions. And yeah, you make a lot of good points. CHRIS: Would you like to pay me $0 for me to build software for you? That sounds fun. STEPH: [laughs] CHRIS: And open source is such a wonderful thing. And so I'm interested in...like, I follow a lot of folks who are in the open-source world and have found ways to make it make sense financially or otherwise or organizationally. Open Collective and things like that is one option or OpenCore and then paid pro models and things like that like Sidekiq as an example. Sidekiq just celebrated ten years with some wild numbers in terms of the revenue, and it's like, yeah, that's fantastic. This is a cornerstone piece of software in the Ruby and Rails community. And also, Mike Perham had a great outcome from it. I think that's a win. So maybe blogging, maybe, but not sure. Probably not open source is my suggestion, at least for me. But one thing that I am interested in that hasn't been an option in my mind for a long time, but I'd love to get back to is conferences and going there, especially with a small team from an organization. The three developers we go, and we hang out at a conference and the company has a space there. And there's room to have conversations and meet people. That is one that I would love to continue in a way of making sure that our name is in people's minds as a place that they could work in this world. It is interesting, though, that it gets scoped a little bit like we are definitely a Rails shop. But that's not all that we are, or that's not the complete totality of our technical identity, so it becomes interesting. But I think it's probably the most representative. And I definitely see the Ruby and Rails community is having a good product-centric mindset that is definitely the sort of thing that I want in the teams that I'm building. STEPH: Yeah, I think that's an awesome idea because it's a way that you could focus on creating content. It'll likely have a big impact. But then you can also replay that content, but it's not the commitment of a blog or a commitment of open source. CHRIS: But yeah, so hiring has been, I would say, most of what I've been doing. One other thing that was fun this week, so I have my new laptop that I've had now for a couple of months, I'd say. And just this week, we had a very frustrating issue where Heroku stopped deploying our application. Just one day, it was like, nah, it doesn't work anymore. And I was like, well, that's less cool than I want it to be. And so one of the developers on the team dug into it, and it turned out Node-sass was the answer, which we're not even using is extra unpleasant. It's just part of Sprockets and Webpack or something like that. There's some downstream dependency sequence. We're using Tailwind and PostCSS. So we don't even need Node-sass. I think maybe PostCSS does. But anyway, turns out Heroku had switched to using version 16 of Node just without telling us. We were previously on 14, and then Node-sass didn't build on that. There was just this weird dependency chain that stopped working one day. And we weren't pinning the Node version within our application. So one of the developers figured this out, pinned us back to version 14 something of Node, and that was fine. But then my computer got confused because the versions were out of sync. Anyway, asdf is great. That's the first thing I'm going to say. So I use asdf to manage the versions of Ruby, and Node, and Yarn, and Elm, and basically everything else that I use. And I love that it's all under one hood, so asdf, wonderful. Also, my laptop, wonderful. I really love the M1 fancy laptop. But what was fun was I had to install the new Node version. And this was the first time in the three months I've had this computer that I've heard the fans come on. Finally, I asked it to do something hard enough that it was like, whoa, whoa, whoa, I'm going to need some backup here. And so the fans finally kicked in. So I don't know what's going on installing Node, but good for everyone involved, [laughter] impressive to make such aggressive use of all of the hardware in my computer. STEPH: Yeah, I love asdf. I miss it right now because I'm on my client machine, and we're not using asdf. Instead, we are using Chruby, C-H Ruby to manage Ruby versions. asdf is awesome. That's fun. It's the first time that the fans kicked on. I'm intrigued with my machine. I haven't really paid attention to it when the fans kick on except the one time where I had like a Ruby process that was running away, and I had to figure out what was going on there. Because then all the CPU was just being dedicated to Ruby even when I wasn't using Ruby. But since then, I haven't heard the fans. It's been very, very quiet. It's lovely. I like when it's quiet. CHRIS: Oh, it's been great. It was interesting because it was this weird noise that I'd forgotten about. STEPH: [laughs] CHRIS: My previous computer was so old that this was happening regularly whenever my backup process would run. Apparently, that is a very computationally intensive activity. So I would hear the fans kick in, immediately go find the backup process and say pause for 60 minutes or whatever it was. Just like, leave me alone. Stop it. The computer is getting too hot. You need to calm down. But now, with the new computer, there was nothing I could do to make it happen. And then finally it happened, and I was like, oh yeah, I guess this computer has fans. That's neat. But yeah, so things that are great, asdf and the M1 laptops. STEPH: Nice. Yeah, you're one of the few individuals I know that's using one of the M1 chip. So it's been reassuring to hear how well it's going because I did not opt in to that new-new. I opted in to the give me something stable and steady that I know so that way I don't have to fuss with it because I can then fuss with all the other things that I need to fuss about. CHRIS: So much fussing to do. STEPH: Lots of fussing. Fussing and cussing is what I do over here. CHRIS: [laughs] Mid-roll ad Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's New Relic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. CHRIS: Well, speaking of, what have you been fussing and cussing about this week, Steph? STEPH: So this is more in the pranting area, which is our portmanteau for praise and rant, where I'm super excited. I have a delivery coming from Amazon today. So I'm that person that keeps checking and waiting for it to show up. But I'm finally going to have one dongle to rule them all. I have a very messy approach right now [laughs] where I have all the dongles and have to plug everything in. And you know what? Normally it's fine. It's fine because I do it once, and I don't have to mess with it that much. But because I now have my thoughtbot laptop and I have a client laptop, and I needed to be able to switch back and forth, it is just too much. And I was realizing how many dongles I'm having to use. So I have one dongle to rule them all. It's showing up today. It's a very exciting day. CHRIS: I'm very excited for you. I recently made a similar switch when I got this new laptop. I was like, you know what? I'm going to look into it because power can come over USB-C and whatnot. And I was like, all right, it's finally time. I want to be able to just click in. And it's one of those things that feels trivial, or at least in my mind, I'm like, this doesn't feel like it'll make that big of a difference. But it makes it so much easier to disconnect my laptop, go somewhere else, and then come back. And I noticed myself doing that more, which I think is a positive thing. Otherwise, I'm just anchored to my desk. I'm like, I don't want to unplug everything and then have to replug it. That's like a whole thing. But now that it's not, I am more mobile, more flexible in where I'm working from, and I found benefits from that. So I'm a fan. I'm very happy that this is going to show up for you [laughs] and really change the way you're working. STEPH: Well, I've started moving away from a lot of Bluetooth connections as well because my keyboard will support Bluetooth, my headphones support Bluetooth. And I liked the idea of being wireless. But then, especially from switching laptops back and forth and then having to reconnect and all of it, it was just too tedious to go back and forth. And yeah, I'm with you where I didn't want to have to leave my desk and unplug everything and then bring it back where I'm playing, you know, like the game Operation where you had to reach in and then you had to grab different little bones? If you don't know the game Operation, that sounds really weird. But it felt like a game of Operation where then I was having to find all the dongles and connect them and plug them all in. And yeah, so it's going to be wonderful. CHRIS: Even knowing the game Operation, that still sounds kind of weird. STEPH: [laughs] CHRIS: But I really love that there are people out there listening that are like, what are they talking about? STEPH: What weird childhood did you have? CHRIS: Yeah, I'm definitely Team Wired-Almost-Everything. The only thing that I have that's wireless is my headphones. And it only works kind of, and I have to trick them sometimes. And the worst thing is occasionally my computer will have control, whatever, they're connected. So I'm listening to music on my computer and then suddenly, my phone will just steal it. It's like, what are you doing? No. Or, randomly, my headphones will be sitting away from me, and they'll just connect. And I'll be in the middle of a call on something else. Like, I'm here talking to you, and suddenly my headphones are like, hey, we wanted to join the party. It's like no, absolutely not, [laughs] not at this moment, under no circumstances. So I don't really believe in Bluetooth as a technology. I'm very much a fan, particularly with things like keyboards and whatnot. Bluetooth I've yet to be convinced that it is a sound technology. STEPH: I have the headphones where they try to be very smart, and they are pretty smart where they will block out sound. But then, if I am talking, then it will put me in more of an auditory space where then I can more easily hear, and it won't filter out sound as aggressively. But I've noticed a problem. And it's when I'm watching anything that's funny that then I'm laughing. So every time I laugh, my headphones think I'm talking to someone, and then it will switch over to where it's trying to let me hear more sounds out in the universe. And then it kicks back on because it's like, okay, she's done talking. It's a very jarring experience. [laughs] And I haven't figured out how to turn that setting off. It's like, oh, I just can't watch funny stuff with my headphones right now, which is also problematic with pairing because I tend to laugh a lot with pairing. It's a thing. I'm working on it. The struggles of Shteph. CHRIS: Well, at a minimum, it sounds like your dongle life is going to be improving very soon, and that's exciting. STEPH: Dongle life, it'll be single dongle life. That's it. [singing] All the single dongles, all the single dongles. Put your adapters up. [laughter] On a different note, talking about some of the work that I've been doing this past week with Joël Quenneville on our client work, is that we have been looking for ways that we still want to build up CI time. We've talked about the fact that we're working on some of that horizontal scaling. And I don't have an update there. But the other update I have is where we want to be very strategic about where we invest our time because improving the test is not trivial work. A lot of the low-hanging fruit has already been done, so triaging a flaky test can be very difficult, and it can take us a while. So we just want to make sure and verify that before we invest a lot of time into a portion of the test that then we know what the outcome is going to be. Are we improving developers' lives by this much? And how do we measure that? Are we reducing the CI build time, and how do we know that? And one of the areas that I really wanted to focus on is FactoryBot because there are a lot of factories. The factories tend to do a ton. So they are calling out to the database and building a lot of associations. And that's something that the team knows about as well is that there are just so many SQL queries that get executed in tests. And it would be great if we could reduce the number of SQL queries that are going out. And FactoryBot includes some ActiveSupport notifications, which means you can subscribe to factories being run which then gives you access to details like which factories are being used? What build strategy is used? Are you calling build build_stubbed or create? And the factory's execution time. So then the idea of this is that if we can harness a lot of the data that we can collect from FactoryBot, then can we ask questions around what's our slowest factory? How long does it take, and how many places is it being called? Because then ideally, we can calculate to say, okay, if this factory takes this long and it's used in this number of places, then we can have a formula to figure out how many minutes of our test suite is spent just on executing that factory. And then if we can reduce the time of that factory, let's say by half, then we know how much time we're shaving off of our CI build. And then we have this more concrete verified okay; this is worth our investment. We want to pursue this, even if the factory may take us a full day to improve because it does so much. And it's just gnarly. So it's going to take some time to really refactor it into a more simplified state. So, in theory, this sounds really, really great, and it was a lot of thanks to Josh Clayton, who was the one that advocated saying that we could use the ActiveSupport notifications to find a lot of this data. And so Josh and I paired on this for a bit to look into can we answer some of those other questions as well? And we were testing it on a small side project that he had, which was great because the other codebase is very big, and feedback is just a lot slower. So we wanted to first prototype it and have a proof of concept in a very quick space and just to be able to look through the data and make sure the assumptions that we had and the value would be there. So we applied that first, and that was going really well. And then Joël Quenneville took that strategy and then applied it to all the specs in the spec models directory and ran it for the much larger client codebase and got some really great results. And we also used a low fidelity approach where we wanted to be able to see which factories were the most popular. So how often are they getting called? And the average execution time. So that way, we could then quickly look at this scatter plot, and then we could see, okay, who's in the far upper right quadrant? Because those are the factories that are causing the most pain. But we started looking into a graphing library and what are we going to pull in. And Josh had the great idea. He's like, "I wonder if Google Sheets has a scatter plot. Can we export this to CSV data and then copy it from the terminal and import it into Google Sheets?" And it turns out that you can. So then we grabbed it and put it in Google Sheets and then just converted it into a scatter plot, which was really nice because then we didn't have to incorporate any chart library or any graphics or anything. We could just plop it into Google Sheets and then easily share it. So we now have this list thanks to Joël because he ran it through the spec models directory of all the factories that are getting called. And it's really interesting. And there's one, in particular, that is high on the list. And it was actually one of the first ones that we worked with when we were troubleshooting a test that took us a while when we first joined the project. And the average time for this factory is four seconds, and it gets called over 500 times. It's like 527 times. So then if we multiply that, so if we say, all right, it takes about 4 seconds times 527 and then divide it for 60 for minutes, that's 35 minutes, 35 minutes for that factory. Now, granted, these are getting parallelized across different processes. But still, if you divide that up across four processes, that's a non-trivial amount of time. So I think this is going to be really helpful and really interesting data that we can then use to drive our decisions to say, okay, we want to take this factory and let's say even if we can cut it into half, let's say if we bring it from 4 seconds to 2 seconds, it'll go from 35 minutes to 17 and a half. CHRIS: Oh wow, I love the methodical approach. I love that actually having a number you're like; this is how much pain or the cost of this right now. And so we've identified that this is this high-level thing. I love the intentional starting with, like, let's measure it. Let's understand where the most bang for the buck is. In particular, the graph that you're describing reminds me of one I haven't actually worked with it much. But Code Climate has a graph that they use, which is it's churn versus complexity. So it's like, you may have a very complex piece of your code, but someone wrote it once, and it just sits in the corner. And you know what? It quietly does its job. And yes, it's very complex, but nobody needs to touch it. So it's not a big deal. And then you have stuff that changes constantly, but it's super simple, so that's fine too. Your UsersController is probably going to change a bunch; that's fine. But the stuff that is constantly changing and very complex that's the magic quadrant that, like, pay a lot of attention to that. And similarly, which are the ones that are being used a lot and take a while? That's the magic quadrant. I'm intrigued now. I want to search for more magic quadrants that deserve attention. But for now, that sounds like a lot of fun. So now, what's the approach that you're going to take? I imagine you need to alias that factory and have it exist because some tests will rely on certain details of it. This is my guess. So let me see if this is the way that you're thinking about it, alias the factory, so you have a representation that does all the stuff that the current one does. But then you have a new one that is much more pared down. And then, on a test by test basis, you start switching it over and trying to move things to the lower weight, the slimmer version of the factory. But I would think you would want to do a gradual process if there are 520-ish usages. Because otherwise, just changing that factory out from under all the tests, I imagine you'd break some tests if you just were like, what if it did less? STEPH: Yeah, I like that idea of the incremental approach. And that all sounds great, especially the alias because you're right; we want to change it incrementally and not all of them at once. But then essentially implement, one, because I want to see what does the pared-down factory look like? What is the basic factory that we can get away with? And then how long does it take for that factory to execute? Because then that will help confirm, can we really get it down to two seconds? Or is this just a factory that's always going to take three and a half seconds, and then it's not really that much of a payoff? Maybe we should look for a different factory to investigate. And then also understanding from the test are people reaching for this factory all the time because it builds up the world and all of these tests need the full world? Or are people just reaching for this because it does the one or two things that they need, and we can get away with a much slimmer factory? So right now, it's in the space of understanding why are people reaching for this? What are the tests they actually need? And yeah, how can we do it incrementally? At one point, we may even be able to try to programmatically switch it out. Maybe we just find 50 tests that are using this once we have the slimmed-down version and we replace...50 is probably too big. But if we replace X number of tests with this factory, how many of them fail? Maybe 10% of them passed. Cool, let's just take those 10% as a win and issue those as a PR. So that could be a strategy as well just to find if there's any that are super easy to change. All we had to do is literally change the name of the factory. The other big part that's on my mind is education around factories. I think a lot of people on the team understand that factories are very important. They can be very helpful. They can also be very cumbersome. But it feels like a good opportunity to say, "Hey, we are specifically working on these factories. Here's the reasoning that led us to work on these factories. When you're in the space of factories, please be mindful about what are you reaching for? Is there a slimmed-down factory that you can reach for? Maybe you can implement your own slimmed-down factory if one doesn't already exist." So I like the idea of coupling it with also just broader awareness because we are but two people. So I would love for more people to be part of the changes. CHRIS: Unsurprisingly, there are some wonderful blog posts on the thoughtbot blog that speak to this topic. One that I'm a fan of is Factories Should be the Bare Minimum. This was written by Matt Sumner. And it describes basically that idea of factories shouldn't build the worlds. They should give you the pieces that you can use to build the world but not build the world entirely. And so I'm a big believer in that, having your factories be as minimal as possible. They should be valid, but that's about it. And then I will often reach for extracted helper methods and keeping those as locally scoped as possible often in the spec file, or if not, maybe they're sharing spec support. But being intentional with where we reach for them and not having everyone use the same thing that just slowly gets added to. And it's like, do I actually need everything that's in there? The other thing that's interesting is the idea of having a factory that does a ton is, in my mind, sort of in direct contradiction to what I believe factories exist for which is when I think of factories, they're useful to fill in the rest of the details such that you don't have mystery guests in your test. But you can explicitly say build me a user who has an email that looks like this because, in this test, I care about the email, but I don't care about the rest of the details. I don't care about their name. I don't care about their password, or the roles, or any of the other details. Just let the factory deal with that because it's not important to the test. But I want to make sure that the relevant detail is present and specified within the spec. If you have a factory that builds everything in the world, that's like build a user and then grabs the first action from the project that that user has, because I know that they do because they use the big factory, that is just in direct contradiction to what we want factories to do. We want tests to tell their story. We want to avoid mystery guests. Factories are a great way to do that while still remaining concise. But if your factories just build the world, then there are some mystery guests in the world, I can assure you. STEPH: Yeah, I agree where factories have served as an abstraction for what I think is important to the test. But then there becomes this moment of where someone thinks, well, I need to build up these records, but I don't really need to reference them directly. I just have some coupled code that's going to rely on these. And so I don't explicitly need them, but they need to be there. So I'm going to extract it away, and a factory feels like a good place for me to extract that too. And I would take the very hard opposite approach where if you have coupled code and you have these dependencies that aren't necessarily explicitly used in the test, but they are required for the test, I'd rather see a painful test setup than have all of that extracted away from me. Because then if I do need to triage or troubleshoot that test, it's going to take a lot of just mental overhead to work through what do I actually need here and why? So I'd rather see that painful test set up then have it moved somewhere else. But I think a lot of people take the opposite approach of where if I abstracted away, my test looks prettier. And I'm like, yeah, but maybe to you in the moment, but it's going to cause me a lot of pain further down the road when I have to work with this. So show me all the crap that you had to do upfront. Just let me know. [laughs] I'd rather the test be honest with me. And then it's a really nice jumping-off point because you can see a test that does all of this. And instead of blaming the test and thinking it's the test's fault, you recognize this test has a lot of complicated setup, and it's probably because of the code and how the code was written. And we should look at refactoring the code, not at how can we make our tests look prettier? CHRIS: Unsurprisingly, I agree with 100% of that. Someday we'll find things other than Pop-Tarts and IPAs that we disagree on. But today is not that day. [laughs] Once again, today is not that day. Mid-roll Ad Hi, friends. And now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Well, here's one more that maybe you'll agree with, maybe you won't. We'll see. I'll try not to lead you in either direction, but shared examples. If I'm going to rant for a little bit, shared examples are in that space of where they just get used so heavily, and they abstract away important information about the test. And it makes the test so succinct that I don't actually know what the test is doing. And I've seen a number of places where a shared example has been extracted, and it is only used within that test file once, maybe twice. And I'm just like, friends, too much abstraction. Please keep it close. [laughs] We don't need to move it away. We want our test to be friendly and just full of context, which is what I mean when I say friendly. I want full of context is what I'm looking for, well-named variables. And I won't be able to read the test and see what's happening. So my little complaint for today would also be about shared examples and how they can be overused. And they do have a really neat purpose. They can be helpful for if you're testing maybe a controller action and you want to say you're extracting that authentication, making sure that a controller always has authentication and then that is getting included. Sure, that feels very helpful. But that's really one of the few cases I can think of where a shared example comes into play. And if you are testing code over and over throughout different parts of your codebase, there's probably a part of your codebase there that needs to then be pulled out into a class and test that class in isolation. And then you don't need to retest it throughout all of your other classes. Have I already ranted about shared examples? I can't recall at this point if I have or not. [laughs] CHRIS: I don't think we have talked about shared examples before. And I appreciate you not leading the witness here. But I think I'm in agreement with you, particularly the way you refined it there at the end because that controller example is the one rare case where I might reach for it. But in general, I think this is one of those things that I saw early on in my career. I was like, oh, cool; this is a way to clean stuff up and DRY and all those wonderful things. And then I've definitely felt the pain of just overuse of shared examples and ways to pull details out of tests. But it's like, I want to see the details. And I think broadly, that's the theme that you and I are very aligned on is like, no, no, no, tell me the story in tests. I am much less interested in having these concise tests that have a single line, and it's like, expect foo to have bar. And it's like, why? Because...oh, there's a let and then a subject, and it's a shared...oh okay. Now that I can put it together, I can tell the story, but I cannot look at this test and see a story. I want to see a story, friends. So yes, I'm totally in alignment, especially with the slight caveat at the end of like, there are cases where it's useful. Similarly, I've used let. I definitely have not even that long ago. And I stand by the usage, but it was very rare. It's very rare, and it is something that I'll look at and be like, am I sure? Definitely, is this the right thing, or did I do something wrong? Because if I find myself leaning towards let, it's like there's something that I don't think is important to the story of this test that still needs to happen. Why is that? What's going on here? Something feels off about that. And similarly, with the shared examples, it's like, is there not a different way to extract this such that I can test it in a way that I have confidence in, and then we're good? I occasionally will talk myself into using shared examples or something like it where I'm like, oh, but it's really important that everything in the app has that authentication layer put in. And so, I should definitely have this very easily reusable test that can ensure that I have it. But there's a tautology there of well, if I write the test, then I'm definitely thinking about the implementation. But if I forget the implementation, I might also forget the test. And so, it actually doesn't provide any real safety. And in those cases, that's a rare case where I would reach for some weird metaprogramming thing that's like, controllers must do the thing. And we say that in application control and then everything inherited from that will raise if it doesn't implement the authentication layer. Something like weird code that says, "You shall not pass. You must, in fact, implement the authentication layer." Rather than saying, "Oh, we'll just make it really easy to test it so that we always test and, therefore, always use the necessary authentication layer." But yeah, that's a hard one to describe in the radio. So I don't know if that came through clearly. But that's sort of my headspace on this. STEPH: Yeah, and all of that makes sense. I'm trying to think of a good example. And it's been a while since I've used Pundit, but I feel like Pundit may have a really good example of this where it's very easy to document to say, hey, all of these controllers need to make sure that they call out to this class or that there's authentication. I can't remember the exact code and how that works. But I feel like Pundit has a really good example of that behavior. CHRIS: I think they do. It's something where I think it's a configuration level thing, but you say, "Hey, Pundit, we should definitely authorize any access to models." And so Pundit then has a before action, or it's an around filter one of those. But it will raise an unauthorized error, I want to say. Like, you did not do the authorization dance in this. And that's a great example of like, I like that it is loud and annoying and in your face. And it is not possible for me to forget it because we configured it throughout all controllers. And so it's that sort of thing that I would probably reach for even though that code gets complicated and messy, and actions at a distance. But it's worth that trade-off in my mind to have, like, I don't want to forget to do the authorization stuff. Permissions matter. STEPH: That was a really nice pre-emptive approach as well. Because in most cases that we're describing, it's the I'm going to write a controller, and then I need to add this test to verify and prove that yes, I didn't forget the authentication stuff versus upfront, you're setting in a configuration to say, "Hey, please remind me to do the configuration or the authentication step that I don't miss this." So that's also a really, really nice approach. CHRIS: Yeah, the same version of me that's going to forget to write the test is going to forget to write the implementation. So I don't want to trust that version of me to save that version of me. I'm equally untrustworthy in those situations. STEPH: You want to trust the version of you that's going to get yelled at by the code if you don't do it. CHRIS: Yep, I'm going to trust the version of me that was like, I don't trust any future version of me. I will yell at myself if I have not done the necessary things. STEPH: [laughs] CHRIS: To be clear, this is like a life philosophy of mine. I don't try to remember things because I forget stuff a lot. It just happens. And so if I need to take something out the door with me, it goes in front of the door but extra critically, and this is the subtle line. Because plenty of people do that trick where you put a thing in front of the door because then you can't leave without it. There's no way to forget it. But by virtue of that, you cannot put something in front of the door until it is time to use it. Like, if ever you have to go and be like, oh, I don't need it now, though, so I'm going to move it out of the way, open the door, and then leave. No, no, no, because then you've broken the magic of the thing in front of the door must leave with you. So it's a very subtle line. I will play games with myself. I'll be like, I am forgetful. I will not remember this. I do not trust future me, so I'm going to play a trick on them. But you got to calibrate it just right. STEPH: That's really funny because I totally [laughs] didn't think about it until now how you described it. But I have definitely done that where I set a rule for myself, but then I'll break it. And then, of course, everything all of it collapses. There is a time when Tim, my husband, was going through a developer bootcamp. And as he was learning the whole world and everything that's out there, he would ask me all these questions. And he's like, "Do you know this?" And I'd be like, "No." He's like, "Do you know that?" I was like, "No." He was like, "I thought you knew this stuff." He's like, "I thought this was your job." And I was like, "Yeah, I'm really good at finding it and Googling it. But I work really hard to not store this in short-term memory because I'm filling it up with other stuff. So I work really hard to be able to find this stuff and track it and Google it." But now, there's a lot of stuff that I try very hard to not hold on to until I need it. But that was a funny moment where he seemed very upset that I didn't know stuff. And I was like, "Well, welcome to web development. There is too much to know. You're going to have to have a really good catalog system." CHRIS: Also, just so we're clear, it's going to change by next Thursday, so don't hang on to anything like it's just true forever. STEPH: [laughs] CHRIS: SQL will probably be around. That's about it. That's the one thing that I'm really confident in. STEPH: Yeah, that feels fair. Get really good at understanding HTTP forms, SQL, all that feels like some really good groundwork. CHRIS: There are some foundations. We should have a foundations episode where we talk about what we think the foundations are, the stuff that we bet won't be different in 10 years. But everything else is going to change by next Thursday, specifically. STEPH: Yeah, I like the idea of foundations. I'd be intrigued to see what we talk about and what happens there because I feel like that's going to be very representative of already what we talk about. We often will sprinkle in some new-new, especially thanks to a lot of the adventures that you go on. But I feel like a lot of the stuff that we talk about we always bring it back to the foundation because we do want the experiences that we're having to be applicable to everyone else as well. So yeah, that would be interesting to see what comes out of that. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph talks about winter storms and thoughts on name pronunciation features. Chris talks about writing a query to add a new display of data in an admin panel and making a guest appearance on the Svelte Radio Podcast. Finally, Chris decided that his productivity to-do list system was failing him. So he's on the search now for something new. He asks Steph what she uses and if she's happy with it. How do you, dear Listener, keep track of all your stuff in the world? This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Upcase advanced Active Record (https://thoughtbot.com/upcase/advanced-activerecord-querying) Svelte Radio (https://www.svelteradio.com/episodes/chris-toomey-talks-svelte-rails-and-banking) Things (https://culturedcode.com/things/) Todoist (https://todoist.com/) MeetingBar (https://meetingbar.onrender.com/) SavvyCal (https://savvycal.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. We have Winter Storm Izzy headed our way. It's arriving in South Carolina early tomorrow morning. So that's kind of exciting just because it's South Carolina. We rarely see snow. In fact, I looked it up because I was curious because I've seen it every now and then. But I looked up the greatest cumulative snowfall in 1 season, and it was 19 inches in the winter of 1971. I was trying to add an old-timey voice there. I don't know if I was successful. CHRIS: Does 1971 deserve a full old-timey voice? STEPH: Apparently. CHRIS: I feel like people from 1971 would be like, "We were just people in the 70s." Like, what do you... STEPH: [laughs] CHRIS: Wait. Nineteen inches, is that what you said? STEPH: 19 inches. That was total for the season. CHRIS: Yeah, we can bang that out in an afternoon up here in the North. So yeah, okay. You were here for the terrible, terrible winter, right? STEPH: Oh, Snowmageddon? Yes. CHRIS: Yeah, that was something, oof. STEPH: I don't remember how many inches. Was it like 100 inches in a month or something wild like that? I've forgotten the facts. CHRIS: I, too forget the facts. I remember the anecdotal piece of data, the anecdata as it were where we shoveled our driveway, and then another storm came, we shoveled our driveway. And then finally, I was living in an apartment, and it was time to shovel the driveway again. But the pile of snow on the lawn was too big. So we had to shovel the pile of snow further up the lawn to make room for the snow that we were shoveling out of the driveway. But I also remember that being a really nice bonding moment, and I met more of the people living in the...it was a house that had been converted into six apartments. So I actually met some of the people from the house for the first time. And then we hung out a little bit more in the day. So I actually have weirdly fond memories of that time. But to be clear, that was too much snow. I will officially go on record saying too much snow. No, thank you again. STEPH: It was a lot of snow. I think it broke Boston for a while. I remember I don't think I went to...I worked remotely for two weeks because they were just like, "Yeah, don't even try to come into the office. Don't worry about it." So it felt like my first dabbling into understanding quarantine [laughs] except at least with less complicated reasons, just with lots of snow. We also went snowboarding in Charlestown, where we were living. And that was fun because there are some really great hills, and there was so much snow that that was delightful. But I'm not expecting Snowmageddon in South Carolina, although people may act like it and rush out and get their milk and bread. But hopefully, we'll get a couple of inches because that'll be lovely. I don't know that Utah has ever seen the snow. So this will be fun. CHRIS: Oh, that'll definitely be fun. I imagine you've got like even if you do get some amount of accumulation, a day later the sun will just be like, "I'm back. I got this," and clear it up, and you won't have any lingering. The year of Snowmageddon, if I remember correctly, the final pile of snow left in July, the shared one that the city had collected. So you'll probably do better than that turnaround time. [laughs] STEPH: Yeah, it's perfect. It's very ephemeral. It snows, it's beautiful. It's there for a couple of hours, and then poof, it's gone. And then you're back to probably 70-degree weather typically what's here, [laughs] which I have no complaints. There's a reason that I like living here. But in some other news, I have something that I'm really excited about that I want to share. So there's something that you and I work really hard to do correctly, and it's pronouncing someone's name. So whenever there is either a guest on the show, or we are referencing someone, we will often pause, and then we will look for videos. We'll look for an audio clip, something where that person says their name. And then we will do our best to then say it correctly. Although I probably put a Southern twang on a lot of people's names, so sorry about that. But that's really important to say someone's name correctly. And one of thoughtbot's projects is called Hub, which is something that we use internally for all of our project staffing and then also for profiles and team information; there's a new feature that Matheus Richard, another thoughtboter, implemented that I am just so excited about. And now that I have it, I just think I don't know how I lived without this. And I want it everywhere. So Matheus has added the feature where you can upload an audio file with your name pronunciation. So you can go to someone's profile, and you can click on the little audio button and hear them pronounce their name. And then a number of people have taken it a bit further where they will provide, say, the American or English pronunciation of their name. And then they will provide their specific pronunciation; maybe it's Greek, maybe it's Spanish, and it's just phenomenal. And I love it so much. And I can't wait for just more platforms to have something like this. So really big shout out to Matheus Richard for that phenomenal feature. CHRIS: Oh, that is awesome. Yeah, we definitely do pause pretty regularly to go scan through YouTube or try and find an example. And often, people just start into talks, or they'll only say their first name. We're like, oh, okay, keep searching, keep searching. We'll find it. And apologies to anyone whose name we still got wrong regardless of our efforts. But it's making this a paramount idea similar to people putting their pronouns in their name. Like, okay, this is a thing that we should get into the habit of because the easier we make this, the more common that we make this. And names absolutely matter, and getting the pronunciation right really matters. And especially if it can be an easier thing, that's really wonderful. I hope Twitter and other platforms just adopt this; just take this entirely and make it easy because it should be. STEPH: That's what I was thinking; if Twitter had this, and then I was thinking if Slack had this, that would be a wonderful place to be able to just see someone's profile because we can see lots of other helpful context about them. So yeah, it's wonderful. I want to hear more people how they pronounce their names. Because I'll always ask somebody, but it would just be really nice to then be able to revisit or check-in before you talk to that person, and then you can just say their name. That would be delightful. CHRIS: I do feel like creating it for my name would be interesting. I actually had someone this week say my name and then say, "Oh, is that how you pronounce it?" And I stopped for a minute, and I was like, "Yes. I'm really intrigued what other options you were considering, though. I would like to spend a minute and just...because I always thought there was really only the one approach, but I would love to know. Let's just explore the space here," but yes. STEPH: [laughs] You ask them, "What else you got? What other variations can I hear?" CHRIS: [laughs] I would like three variations on my desk by tomorrow so that I can understand what I'm missing out on, frankly. There's a theme or an idea that I've seen bouncing around on Twitter now of people saying, "Yeah, I really just want to apply, get hired, work for one day, make this one change to a platform, and immediately put in my resignation." And I could see this like, "All right, I'm just going to go. I'm going to get hired by Twitter. This is it. This is all I'm doing," which really trivializes the amount of effort that would go into it for a platform like Twitter. I can't even imagine what engineering looks like in Twitter and how all the pieces come together. I'm imagining some amount of microservices there, and that's just my guess. But yeah, that idea of just like, this is my drive-by feature. I show up; I work for a week, I quit. And there we go; now we have it. STEPH: Well, we are consultants. Maybe we'll get hired for all these different companies, and that will be our drive-by feature. We'll add it to their boards and be like, "Don't you want this? Don't you need this?" And then they'll say, "Yes." [chuckles] CHRIS: I am intrigued because I can't imagine this hasn't come up in conversations at Twitter. And so, what are the trade-off considerations that they're making, or what are the reasons not to do this? I don't have any good answers there. I'm just asking the question because, for an organization their size, someone must have had this idea. Yeah, I wonder. STEPH: Yeah, there's; also, I'm sure malicious things that then you have to consider as to then how people...because, at the end of the day, it's just an audio file. So it could be anything that you want it to be. So it starts to get complicated when you think about ways that people could abuse a feature. On that peppy note, what's going on in your world? CHRIS: I had a fun bit of coding that I got to do recently, which, more and more, my days don't involve as much coding. And so when I have a little bit of time, especially for a nice, self-contained little piece of code that I get to write, that's enjoyable. And so I was writing a query. I wanted to add a new display of data in our admin panel. And I was trying to write a query, and I got to build a nice query object in Ruby, which I always enjoy. That's not a real thing, just in case anyone's hearing that and thinking like, wait, what's a query object? Just a class that takes in a relation and returns relation but encapsulates more complex query logic. It's one of my favorite types of ways to extract logic from ActiveRecord models, that sort of thing. So I was building this query object, and specifically, what I wanted to do here is I'm going to simplify down the data model. And I'm going to say that we have users and reservations in the system. This may sound familiar to you, Steph, as your go-to example [laughs] from the past. We have users, and we have reservations in the system. So a user has many reservations. And reservations can be they have a timestamp or maybe an enum column. But basically, they have the idea of potentially being upcoming, so in the future. And so what I wanted to do was I wanted to find all users in the system who have less than two upcoming reservations. Now, the critical detail here is that zero is a number less than two. So I wanted to know any users that have no upcoming reservations or one upcoming reservation. Those were the two like, technically, that's it. But say it was even less than three, that's fine as well. But I need to account for zero. And so I rolled up my sleeves, started writing the query, and ActiveRecord has some really nice features for this where I can merge different scopes that are on the reservation.upcoming is a scope that I have on that model that determines if a reservation is upcoming because maybe there's more complex logic there. So that's encapsulated over there. But what I tried initially was users.leftjoinsreservations .groupbyusers.id havingcountofreservations. So that was what I got to. And thankfully, I wrote a bunch of tests for this, which is one of the wonderful things about extracting the query object. It was very easy to isolate this thing: write a bunch of tests that execute it with given data. And interestingly, I found that it worked properly for users with a bunch of upcoming reservations. They were not returned by the query objects which they shouldn't, and users with one upcoming reservation. But users with zero upcoming reservations were being filtered out. And that was a surprise. STEPH: Is it because the way you were joining and looking where the reservation had to match to a user, so you weren't getting where users didn't have a reservation? CHRIS: It was related to that. So there's a subtlety to LEFT JOINS. So a JOIN is going to say like, users and reservations. But in that case, if there is a user without reservations, I know they're going to be filtered out of this query. So it's like, oh, I know what to do. LEFT JOINS, I got this. So LEFT JOINS says, "Give me all of the users and then in the query space that I'm building up here, join them to their reservations." So even a user with no reservations is now part of the recordset that is being considered for this query. But when I added the filter of reservations.upcoming, I tried to merge that in using ActiveRecord's .merge syntax on a query or on a relation, as it were. That would not work because it turns out when you're using the LEFT JOINS...and as I'm saying this, I'm going to start saying, like, here's definitively what's true. I probably still don't entirely understand this, but trying to do the WHERE clause on the outer query did not work. And I had to move that filtering logic into the LEFT JOINS. So the definition of the JOINS was now I had to actually handwrite that portion of the SQL and say, LEFT OUTER JOIN users on and then, you know, the users.id=reservations.userid and reservations. whatever the logic there for an upcoming reservation. So reservations.completed is null or reservations.date>date.current or whatever logic there. But I had to include that logic in the definition of the LEFT OUTER JOIN, which is not a thing that I think I've done before. So it was part of the definition of the JOIN rather than part of the larger query that we were operating on. STEPH: Yeah, that's interesting. I don't think I would have caught that myself. And luckily, you had the test to then point out to you. CHRIS: Yeah, definitely the tests made me feel much more confident when I eventually narrowed down and started to understand it and was able to make the change in the code. I was also quite happy with the way I was able to structure it. So, suddenly, I had to handwrite a little bit of SQL. And what was nice is many, many, many years ago, I recorded a wonderful course on Upcase with Joe Ferris, CTO of thoughtbot, on Advanced ActiveRecord Querying. And I'm still years later digesting everything that Joe said in that course. It's really an amazing piece of content. But one of the things that I learned is Joe shows a bunch of examples throughout that course of ways that where you need to, you can drop down to raw SQL within an ActiveRecord relation. But you don't need to completely throw it out and write the entire query by hand. You can just say, in this case, all I had to handwrite was the JOINS logic for that LEFT JOINS. But the rest of it was still using normal ActiveRecord query logic. And the .having was scoped on its own, and all of those sort of things. So it was a nice balance of still staying mostly within the ActiveRecord query Builder syntax and then dropping down to a lower level where I needed it. STEPH: I love that you mentioned that video because I have seen it, and it is so good. In fact, I now want to go back and rewatch it since you've mentioned it just because I remember I always learn something every time that I do watch it. On a side note, the way that you represented and described query objects was so lovely. I know you, and I have talked about query objects before because we adore them. But I feel like you just gave a really good mini class and overview of like, this is what a query object is, and this is what it does. And this is why they're great because you can test them. CHRIS: Cool. I'm going to be honest; I have no idea what I said. But I'm glad it was good. [laughs] STEPH: It was. It was really good. If anyone has questions about query objects, that'll be a good reference. CHRIS: Well, thank you so much for the kind words there. And for the ActiveRecord querying trail, really, I was just along for the ride on that one, to be clear. I did write a bunch of notes after the fact, which I've found incredibly useful because the videos are great. But having the notes to be able to reference...past me spent a lot of time trying really hard to understand what Joe had said so that I could write it down. And I'm very glad that I invested that time and effort so that I can revisit it more easily. But yeah, that was just a fun little bit of code that I got to write and a new thing that I've learned in the world of SQL, which is one of those topics that every little investment of effort I find to be really valuable. The more comfortable I feel, the more that I can express in SQL. It's one of those investments that I'm like, yep, glad I did that. Whereas there are other things like, yeah, I learned years ago how to do X. I've completely forgotten it. It's gone from my head. I'm never going to use it again, or the world has changed. But SQL is one of those topics where I appreciate all of the investment I've put in and always find it valuable to invest a bit more in my knowledge there. STEPH: Yeah, absolutely same. Just to troll Regexs for a little bit, they're powerful, but they're the thing that I will never commit to learning. I refuse to do it. [laughs] I will always look it up when I need to. But Postgres or SQL, on the other hand, is always incredibly valuable. And I'm always happy to learn something new and invest in that area of my skills. CHRIS: Yep, SQL and Postgres are great things. But let's see. In other news, actually, I had the pleasure of joining the Svelte Radio Podcast for an episode this week. They invited me on as a guest. And we got to chat about Svelte, and then I accidentally took the conversation in the direction of inertia as I always do. And then I talked a little bit more about Sagewell, the company that I'm building, and all sorts of things in the world. But that was really fun, and I really enjoyed that. And I believe it will be live by the time this episode goes live. So we will certainly include a link to that episode in our show notes here. STEPH: That's awesome. I haven't listened to the Svelte Podcast before. So I'm excited to hear your episode and all the good things that you said on it. I'm also just less familiar with them. Who runs the Svelte Podcast, and what's the name of the show? CHRIS: The show is called Svelte Radio. It's hosted by Antony, Shawn, and Kevin, who are three Svelters from the community. Svelte is a really interesting group where the Svelte society is, as far as I can tell, a community organization that is seemingly well-supported by the core team and embraced as the natural center point of the community. And then Svelte Radio is an extension of that. And it's a wonderful podcast. Each week, they talk about various things. So there are news episodes, and then they have guests on from time to time. Recently, having Rich Harris on to talk about the future of Svelte, Rich Harris being the creator of Svelte. Interestingly, if you search for Svelte Radio, they are the second Google result because the first Google result is the tutorial docs on how to use Svelte with radio buttons. But then the second one is Svelte Radio, the podcast, [laughs], which is an interesting thing. Good on Svelte's documentation for having such strong SEO. STEPH: I was just thinking there's something delightful about that where the first hit is for documentation that's a very helpful; here's how you use this. That's kind of lovely. Well, that's really cool. I'm really looking forward to hearing more about Svelte and listening to you be on the show. CHRIS: Yeah, they actually had some very kind things to say about The Bike Shed and, frankly, you as well and our co-hosting that we do here. So that was always nice to hear. STEPH: That's very kind of them. And it never fails to amaze me how nice podcasters are. Everyone that I've met in this community that's a fellow podcaster they're just all such wonderful, nice, kind people, and I just appreciate the heck out of them. CHRIS: Yeah, podcasts are great. The internet is doing its job; that's my strong belief there. But let's see. In other news, I actually have more of a question here, sort of a question and an observation. My work has started to take a slightly different shape than it has historically. Often, I'm a developer working on a team, picking up something off the top of the Trello board or whatever we're using for project management, working on that thing, pushing it through to acceptance. But all of the work or the vast majority of the work is encapsulated in this one shared planning context. But now, enough of my work is starting to spill out in different directions. Like right now, I'm pushing on hiring. That's a task that largely lives with me that doesn't live on the shared Trello board. Certainly, the rest of the team will be involved at some point. But for now, there's that that's really mine. And there are other pieces of work that are starting to take that shape. So I recognize, or at least I decided that my productivity to-do lists system was failing me. So I'm on the search now for something new, but I'm intrigued. What do you use? Are you happy with what you have for to-do lists? How do you keep track of stuff in the world? STEPH: Oh goodness. I'm now going to overanalyze everything that I do and how I keep track of the things that I do. [chuckles] So currently, I have two things that I used to track, and that is...okay, I'm going to expand. I have three to-do lists that I use to track. [laughs] Todoist is where I add most things of where whatever I just think of, and I want to capture it Todoist is usually where it goes. Because then it's very easy for me to then go back to that list and prioritize or just simply delete stuff. If I haven't gotten to it in a while, I'm like, fine, let it go. Move on. And then the other place I've started using just because it's been helpful in terms of linking to stuff is Basecamp. So we use Basecamp at thoughtbot, and we use it for a number of internal projects. But I have created my own project thanks to some advice from Mike Burns, a fellow thoughtboter, because he created his own and uses that to manage a lot of his to-dos and tasks that he has. And then that way, it's already one-stop shopping since you're in Basecamp a lot throughout the day or at least where you're going to visit some of the tasks that you need to work on. So that has been helpful just because it's very simple and easy to reference. And then calendar, I just live by my calendar. So if something is of the utmost importance...I realize I'm going in this in terms of order of importance. If something is critical, it's on my calendar. That's where it goes. Because I know I have not only put it somewhere that I am guaranteed to see it, but I have carved out time for it too. That's my three-tier system. [laughs] CHRIS: I like it. That sounds great, not overly complicated but plenty going on there. And it sounds like it's working for you, sounds like you're happy with that. STEPH: It has worked really well. I'm still evaluating the Basecamp, but so far, it has been helpful. It does help me separate between fun to-do items which go in Todoist and maybe just some other work stuff. But if it's really work-focused, then it's going in Basecamp right now. So there's a little helpful separation there between what's going on in my life versus then things I need to prioritize for work. What are the things that you're currently using, and where are you feeling they're falling down or not being as helpful as you'd like them to be? CHRIS: My current exploration, I'm starting to look for a new to-do list-type things. Specifically, I've been using Trello for a long time for probably a couple of years now. And that was a purposeful choice to move away from some of the more structured systems because I found they weren't providing as much value. I was constantly bouncing between different clients and moving into different systems. And so much of the work was centrally organized there that the little bit of stuff that I had personally to keep track of was easy enough to manage within a Trello board. And then slowly, my Trello board morphed into like 10 Trello boards for different topics. So I have one that's like this is research. These are things that I want to look into. And so I can have sort of a structure and prioritization within that context in my world. And then there's one for fitness and one for cooking. I'm trying to think which else...experiments, as I'm thinking about I want to try this new thing in the world. I have a board for that. So I have a bunch of those that allow me to keep things that aren't as actionable, that are more sort of explorations. But then they each have their own structure. And that I found to be really useful and I think I'll hold on to. But my core to-do board has started failing me, has started being just not quite enough. And then, more so, I wanted a distinct thing for work for a professional context. So I was like, all right, let me go back to the drawing board and see what's out there. And I did a quick scan of Todoist and Things, respectively. And I've settled on Things for right now. It just matches a little bit more to my mental model. Todoist really pushes on the idea of due dates or dates as a singular idea associated with most things. Almost everything should have a date. And I kind of philosophically disagree with that. Whereas Things has this interesting idea of there is the idea of a due date, but it's de-emphasized in their UI because not everything has a due date; most things don't. But Things has a separate idea of a scheduled date or an intent date. Like yeah, I think I'll work on that on Wednesday. It's not due on Wednesday; that's just when I want to work on it. It can have a separate due date. Like, maybe it's due Friday. STEPH: Is the name of the application that you're saying is it Things? Is that the name of it? CHRIS: Yeah, it is. STEPH: I haven't heard this one. You kept saying Things. I was like, wait, is he being vague? But I realized you're being specific. [laughs] CHRIS: It's one of the few things that...yeah, one of the few things that I think is not great about Things. It's from a company Cultured Code, and the application is called Things. And that is all I will say on that topic. Different names maybe would have been better, but they seem to have carved out enough of an attention space. Enough people know of it that if you search for Things and to-do list, it will very quickly pop up. But yeah, that's a pretty ambiguous name. They maybe could have done a different one there. But the design of the application is really nice. It's on my desktop. And now I have it on my phone as well, and they sync between them and all the stuff. So there's never going to be a perfect system. I'm certain of that. I've at least talked myself out of trying to build my own because, man, have I fallen into that trap before. Oh goodness, so many times. STEPH: I'm very proud of you. CHRIS: Thank you. I'm trying. STEPH: But yeah, it'll be interesting to see how it evolves. I continue to struggle with there are these things that come to mind, and I want to capture them during the day. But some of them are just stories I'm telling myself, which would probably be best captured in a journal tool. And then there are notes that I might want to keep on remote work and how people think about that. And so I'm starting to think about Obsidian or a note-taking system for that. And then I've got this Trello board concoction. And now I've got a to-do...and suddenly I'm like, well, that's too many things. And so I'm trying to not overthink it. I'm trying to not underthink it. I'm trying to just find that perfect amount of thinking. That's what I'm aiming for. I'm not sure I'm going to hit it directly, [laughs], but that's what I'm aiming for. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Some of the topics that you mentioned earlier did stand out to me when you're talking about recipes and working out some other topics. Those are things for me that I often just put in notes. So I liked the word that you used for stories that you're telling yourself or things that you're interested in. Is that something that...I don't put it in Todoist or put it somewhere because I don't really have an action item. It's more like, yeah, this recipe looks awesome and one day...so I'm going to stash it somewhere so I can find it. I'm currently using Notion. I used Bear before. It is beautiful. I really liked Bear, but I needed a little bit more structure, and Notion gave me that structure. And so I will just dump it in Notion. And then it's very searchable, so I can always find whatever recipe or whatever thought that was as long as I try to add buzzwords to my own notes. Like, what would have Stephanie searched for looking for this? So I will try to include some of those words just so I can easily find it. CHRIS: I love you're defining yourself as a Stephanie. For a random Stephanie walking through the woods, what search terms? How can I SEO arbitrage a Stephanie? STEPH: What would she look for? CHRIS: Who knows? STEPH: That Stephanie, she's sneaky. You never know. CHRIS: You never can tell. Obsidian is the one that I'm looking at now. But I'm currently using Apple Notes. And it's really nice to be able to search directly into a note very quickly. I have that both via Alfred and then on my phone. And I'm finding a lot of utility in that, particularly for notes, for things I want to talk to someone about. But now there are seven different things, and how are they connected? And where is something? And to the question of where would a future Christopher look for this, let's make sure I put it in that place. But I don't know what that dude's going to be up to. He's a weird guy. He might look in a completely random place. So I'm trying to outsmart him, and oof, good luck, me. STEPH: [laughs] I have heard of Obsidian, but I don't recall much about it. So I'd have to look into it. I do feel your pain around Todoist and where it really encourages you to set a date. Because there are often things where I'm like, I saw something I want to read. And I know there are tons of tools. There are so many tools and videos and things that people could watch if they really want to invest in this workflow. But right now, I've told myself no, and so I use Todoist. And I see something I want to read, and so I just link to it. And I don't have a particular date that I want to read it. I'm like, this looks cool, and so then I add it to a reading list. But that also, I guess, could be something for notes. More and more, I'm trying to shove things into notes, so it feels less like a task and more of a I'm curious, or I'm interested in things that have piqued my interest. Let me go back and look at that list to see if there's something I want to pull from today or I need inspiration. That's what my notes often are; they're typically inspiration for something that I have seen and really liked, or maybe it's a bug that I looked into, and I want to recall how that happened or what was the process. But yeah, my notes are typically a source of inspiration. So I try to dump most things in there. I don't know if that's particularly helpful for your task, though, because it sounds like you're looking for a way to manage the things that you actually need to do versus just capturing all of your thoughts. CHRIS: Honestly, part of it is having a good system for those like, oh, I'd like to read this sometime. Ideally, for me, that doesn't go into my whatever to-do list system. But if my brain doesn't trust that I'll ever read it or if I feel like I'm putting it into a black hole, then my brain is just like, hey, you should really read that thing. Are you thinking about that? You should think about that and just brings it up. And so having a system externalized that I trust such that then the to-do list can be as focused as possible. It's a sort of an arms race back and forth battle type thing of like, I've definitely done the loop of like, all right, I want to capture everything. I want to have perfect, lossless, productivity system, and that is not possible. And so then I overcorrect back the other way. I'm like, whatever, nothing matters. I'll just let everything fall away. And then I'm like, well, then my brain tries to remind me of stuff or tries to remember more. And there's a book, Getting Things Done, which is one of the more common things recommended in the productivity world. And that informs a bunch of my thinking around this, the idea of capturing everything that's in your head so that you can get it out of your head. And in the moment, be focused and in the moment and not having to try and remember. And so that's the ideal that I'm searching for. But it's difficult to build that and make that work. STEPH: It seems the answer is there's no perfect system. It's always finding what works for you. And I feel like it's always going to change from hopefully not month to month because that would be tedious. But it may change year to year depending on how you're prioritizing things and the types of things that you need to remember or that you need to accumulate somewhere. So I feel like it's always this evolving, iterative process of changing where we're storing this. But I feel like where you store the notes and inspiration, that's something that, ideally, you want to make sure that you can always continue to keep forward. So even if you do change systems, that's something that's usually on my mind. It's like, well, if I use this system to store all of my thoughts, what if I want to move to something else? How stuck am I to this particular platform? And can I still have ownership of the things that I have added here? But overall, yeah, I'd be intrigued to see what other people think if they have a particular system that works for them, or they have suggestions. But overall, it seems to be whatever caters best to your personality and your workflow. That's why there are so many of these. There are so many thoughts, so many videos, so many styles. CHRIS: Yeah, I think a critical part of what you just said that feels very true to me is this is something that will change over time as well. Life comes in seasons, and my work may look a certain way, or my life may look a certain way, and then next year, it may be wildly different. And so, finding something that is good enough for right now and then moving forward with that and being open to revisiting it. And yeah, that feels true. So I'm in an explore phase right now. I'll report back if I have any major breakthroughs. But yeah, we'll see how it goes. STEPH: I will say I think the main tool that I have really leaned into, while some of the others will change over time, is my calendar. There are certain things I've let go. My inbox is always going to be messy. My to-do list is always going to be messy. But my calendar that is where things really go to make sure that they happen. And I will even add tasks there as well. So I feel like the calendar will always stick with me because I can trust that as the one source of like, these are the things that have to happen. Everything else I can check for during that day or figure it out as I go. Or if something gets dropped or bounces to the next day, it's okay. CHRIS: Yeah, the calendar is definitely a core truth in my world. Whatever the calendar says, that is true. And I'm actually a...I hope I'm not annoying to anyone. But I'm very pointed in saying, "This recurring meeting that we have if we keep just canceling it the day before every time, let's get this off our calendars. Let's make sure our calendars are telling the truth because I trust that thing very much." And two apps that I'm using right now that I've found really useful in the calendar world are MeetingBar, which I've talked about before. But it's a little menu bar application that shows the next meeting that's upcoming. And then I can click on it and see the list of them and easily join any video call associated, just a nice thing to keep the next thing on my calendar very top of mind, super useful, really love that. That's just open source and easy to run with. The other that I've been spending more and more time with lately is SavvyCal. SavvyCal is similar to Calendly. It's a tool for sharing a link to allow someone to schedule something on your calendar. And, man, it is an impressive piece of technology. I've been leaning into some of the fancier features of it of late. And it has an amazing amount of control, and I think a really well-designed sort of information architecture as well. It took me a little while to figure out how to do everything I wanted to do in it. But I wanted to be able to define a calendar link thing that I could share with someone that really constraints in the way that I wanted. Like, oh, don't let them schedule tomorrow, and make sure there's this much buffer between meetings. And don't let this calendar link schedule too many things on my calendar because I need to control my day, and give me some focus blocks. And they're not actually on my calendar, but please recognize that. And it basically supports all of these different ways of thinking and does an incredible job with it. As an aside, SavvyCal is created by Derrick Reimer, who is the co-host of The Art of Product Podcast, which is co other hosted by Ben Orenstein, former thoughtboter, creator of Upcase, and a handful of other things. So small world and all of that. But yeah, really fantastic piece of technology that I've been loving lately. STEPH: That's really cool. I have not heard of SavvyCal. I've used Calendly and used that a fair amount. And that is so awesome where you can just send it to people, and they can pick time on a calendar and do all the features that you'd mentioned. So it's good to know that there's SavvyCal as well. Well, pivoting just a bit, we have a listener question that I'm really excited to dig into. This question comes from fellow thoughtboter, Steve Polito. And Steve writes in that, "Hey, Bike Shed, I've got a question for you. I find it difficult to know if there's an existing method in a large class or a class that includes many concerns. How can I avoid writing redundant methods when working on a large project?" And Steve provided a really nice just contrived example where he's defined a class user that inherits from ApplicationRecord. And then comments, "Lots of methods making it really hard to scan this giant class. And then there's a method called formatted name. So it takes first name, adds a space, and then adds the user's last name. And then there are a lot more methods in between. And then, way down, there's another method called full name that does the exact same thing. Just to provide a nice example of how can you find a method that has existing logic that you want and avoid implementing essentially the same method and the same class?" So as someone who has worked on some legacy systems this year, I feel that pain. I feel the pain of where you have a really giant class, and that class may also include other modules. So then you have your range of all the methods that you may be looking through gets really widened. And you are looking for particular logic that you feel like may exist in the system, but you really just don't know. So I don't know if I have a concrete method for how you can find duplicate logic and avoid writing that other method. But some of the things that I do is I will initially go to the test. So if there's some logic that I'm looking for and I think it's in this class or I have a suspicion, I will first look to see what has test coverage. And I find that is just easier to skim where I can find, and I'll use grep, and search and just look for anything. In this particular case, let's use first name as our example. So I'm looking for anything that's going to collaborate with first name. Some of the other things that I'll do is I'll try to think of a business case where that logic is used. So, where are we displaying the user's full name? And if I can go to that page and see what's already in use, that may give me a hint to do we already have this logic? Is there something there that I should reuse, or is it something new that I'm implementing? And then if I really want to get fancy about it, for some reason that I really want to see all the methods that are listed, but I'm trying to get rid of some of the noise in the file, then I could programmatically scan through all the available methods by doing something like class.instance methods and passing in false. So we don't include the methods that are from superclasses, which can be very helpful. So that way, you're just seeing what scoped to that class. But then, let's say if you do have a class that is inheriting from other modules, then you may want to include those methods in your search. So to get fancier, you could look at that class' ancestor chain and then collect the classes or models that are custom to your application, and then look at those instance methods. And then you could sort them alphabetically. But you're still really relying on is there a method name that looks very similar to what I would call this method? So I don't know that that's a really efficient way. But if I just feel like there's probably already something in this space and I'm just looking for a clue or some name that's going to hint that something already exists, that's one way I could do it. To throw another wrench in there, I just remembered there are also private methods, and private methods don't get returned from instance methods. I think it's private instance methods is a method that you'd have to call to then include those in your search results as well. So outside of some deeper static analysis, this seems like a hard problem. This seems like something that would be challenging to solve. And then I guess the other one is I ask a friend. So I will often lean on if there's someone else at the team that's been there longer than me is I will just ask in Slack and say, "Hey, I want to do a thing. I'm worried this already exists, or I think it already exists. Does anybody have any clues or ideas as to where this might live?" I know I just ran through a giant list of ideas there. But I'm really curious, what are your thoughts? If you have a messier codebase and you're worried that you are reimplementing logic that already exists, but you're trying to make sure you don't duplicate that logic, how do you avoid that? CHRIS: Well, the first thing I want to say is that I find it really interesting that I think you and I came at this from different directions. My answer, which I'll come to in a minute, is more of the I'm not actually sure that this is that easy to avoid, and maybe that's not the biggest problem in the world. And then I have some thoughts downstream from that. But the list that you just gave was fantastic. That was a tour de force of how to understand and explore a codebase and try and answer this very hard question of like, does this logic already exist somewhere else? So I basically just agree with everything you said. And again, I'm deeply impressed with the range of options that you offer there for trying to figure this out. That said, sometimes codebases just get really large. And this is going to happen. I think the specific mention of concerns as sort of a way that this problem can manifest feels true. Having the user object and being like, oh man, our user object is getting pretty big. Let's pull something out into a concern as just a way to clean it up. That actually adds a layer of indirection that makes it harder to understand the totality of what's going on in this thing. And so personally, I tend to avoid concerns for that reason or at least at the model layer, especially where it's just a we got 1,000 methods here. Let's pull 200 of them into a file and maybe group them somewhat logically. That tends to not solve the problem in my mind. I found that it just basically adds a layer of indirection without much additional value. I will say in this particular case, the thing that we're talking about presenting the full name or the formatted name feels almost like a presentational concern. So I might ask myself, is there a presenter object, something that wraps around a user and encapsulates this? And then we as a team know that that sort of presentational or formatting logic lives in the presentation format or layer. Maybe I'm not entirely convinced of that as an answer. But it's just sort of where can we find organizational lines to draw within our codebases? I talked about query objects earlier. That's one case of this is behavior that I'll often see in classes as, say, a scope or something like that that I will extract out into a query object because it allows me to encapsulate it and break it out a little bit more but still have most of the nice pieces that I would want. So are there different organizational patterns that are useful? I think it's very easy to start drawing arbitrary lines within our codebases and say, "These are services." And it's like, what does that mean? That doesn't mean anything. App Services, that's not a thing, so maybe don't do that. But maybe there are formatters, queries, commands, those feel like...or presenters, queries, commands. Maybe those are organizational structures that can be useful. But switching to the other side of it, the first thing that came to mind is like, this is going to happen. As a codebase grows, this is absolutely going to happen. And so I would ask rather than how can I, as the developer, avoid doing this in the first place...which I think is a good question to ask. And again, everything you listed, Steph, is great. And I think a wonderful list of ways that you can actually try to avoid this. But let's assume it is going to happen. So then, what do we do downstream from that? One answer that comes to mind is code review. Code review is not perfect. But this is the sort of thing that often in code review I will be like, oh, I actually wrote a method that's similar to this. Can you take a look at that and see can we use only one of these or something like that? So I've definitely seen code review be a line of defense on this front. But again, stuff is still going to sneak through. And someday, you'll find it down the road. And that's the point in time that I think is most interesting. When you find this, can you fix it easily? Do you have both process-wise and infrastructure-wise the ability to do a very small PR that just removes the duplicate method, removes the usage of it, and consolidates on the one? It's like, oh, I found it. Here's a 10-line PR that just removes that method, changes the usage. And now we're good. And that can go through code review and CI very quickly. And we have a team culture that allows us to make those tiny changes on the regular to get them out to production as quick as possible so that we know that this is a good code change, all of that. I found there are teams that I've worked on where that process is much slower. And therefore, I will try and roll a change like that up into a bigger PR because I know that's the only way that it's really going to get through. Versus I've been on teams that have very high throughput is probably the best way to describe it. And on those teams, I find that the codebase tends to be in a healthier shape because it just naturally falls out of having a system that allows us to make changes rapidly with high trust, get them out into the world, et cetera. STEPH: This is that bug or inconsistency that's going to show up where on one page you have the user's full name. And then on another page, you have the user's full name, but maybe the last name is not capitalized, or there's just something that's slightly different. And then that's when you realize that you have two implementations of essentially the same logic that have differed just enough. I like how you pointed out that this is one of those things that as a codebase grows, it's probably going to happen, and that's fine. It's one of those if you do have duplicate logic, over time, based on your team's processes, you'll be able to then identify when it does happen, and then look for those preventative patterns for then how you organize your code. How quickly can you make that change? Can you just issue a PR that then removes one of them? But then look for ways to say, how are we going to help our future selves recognize that if we're looking for a user's full name, where's a good place to look for that? And then what's a good domain space or naming that we can give to then help future searchers be able to find it? I also really like your code review example because it does feel like one of those things that, yes, we want to catch it if we can, and we can leverage the team. But then also, it's not the end of the world if some of these methods do get duplicated. There's one other thing that came to mind that it's not really going to help prevent duplicate methods, but it will help you identify unused code. So it's the Unused tooling that you can run on your codebase. And that's something that would be wonderful to run on your codebase every so often. So that way, if someone has added...let's say there was a method that was full name but is not in use. It didn't have test coverage; that's why you didn't find it initially. And so you've introduced your own formatted name. And then, if you run unused at some point, then you'll hopefully catch some of those duplicate methods as long as they're not both in use. CHRIS: I think one more thing that I didn't quite say in my earlier portion about this. But in order to do that, to use Unuse or to have these sort of small pull requests that are going through, you have to have test coverage that is sufficient that you are confident you're not going to break the app. Because the day that you do like, oh, there's a typo here; let me fix it real quick. Or there's this method I'm pretty sure it's not used; let me rip it out. And then you deploy to production, and suddenly the error system is blowing up because, in fact, it was used but sneakily in a way that you didn't think of, and your test coverage didn't catch that. Then you don't have trust in the system, and everything slows down as a result of that. And so I would argue for fixing the root problem there, which is the lack of test coverage rather than the symptom, which is, oh, I made this change, it broke something. Therefore, I won't make small changes anymore. STEPH: Definitely. Yeah, that's a great point. CHRIS: So yeah, I don't have any answer. [laughs] My answers are like, I don't know, it's going to happen, but there's a lot of stuff organizationally that we can do. And granted, you gave a wonderful list of ways to actually avoid this. So I think the combination of our answers really it's a nice spectrum of thoughts on this topic. STEPH: I agree. I feel like we covered a very nice range all the way from trying to identify and then how to prevent it or how to help future people be able to identify where that logic lives and find it more easily. Also, at the end of the day, I like the how big of a problem is this? And it is one of those sure; we want to avoid it. But I liked how you captured that at the beginning where you're like, it's okay. Like, this is going to happen but then have the processes around it to then avoid or be able to undo some of that duplicate work. But otherwise, if it happens, don't sweat it; just look for ways to then prevent it from happening in the future. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee!!! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph and Chris recap their favorite things of 2019 and 2020 and share their 2021 list. Happy Holidays, y'all! Steph: * Feature flags and calm deploys * Creating observable systems * Debugging * Working in seasons * Don't forget the fun “The longer I'm in the software game, the more I want things to be calm” - Steph Chris: * Pushing logic back to the server * Svelte (https://svelte.dev/) * Remote work (but maybe hybrid!) * Vim * Joining a startup as CTO This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Listen to episodes from 2020 and 2019

Chris finally got his new computer!

Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. rspec-retry (https://github.com/NoRedInk/rspec-retry) Cassidy Williams - It Depends - GitHub Universe 2021 (https://www.youtube.com/watch?v=aMWh2uLO9OM) Say No To More Process (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) StandardRB (https://github.com/testdouble/standard) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: My new computer is due on the fourth. I'm so close. STEPH: On the fourth? CHRIS: On the fourth. STEPH: That's so exciting. CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer. STEPH: [laughs] CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles] STEPH: Take its soul. [laughs] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure. On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase. CHRIS: How long were you on this project for? STEPH: It'll be a total of I think eight months. CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things? STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I'm getting really comfortable with this new environment that I'm in. And so then I have that first month. And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team. CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project. STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project. Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it. But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch? CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it. I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file. So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that. That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI. And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there. STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this. CHRIS: I'm working here. [laughter] STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list. CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there. STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs] CHRIS: Yes. STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?" CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass." STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process. CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes. We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were. STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs] CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles] STEPH: [laughs] That was the second hot tip, and you got it. CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context. So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally. So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future. But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild. So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let's call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it. We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea. STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them. And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know? CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera? STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them? CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed. So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that. STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them? CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total. STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it's not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous. CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet. STEPH: I don't think so. CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken. And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter] STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve. So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this. But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes. CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles] STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off. And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before. It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial. And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it. CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is. STEPH: [laughs] CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit. And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that. Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production. And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness. And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently. STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize. The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through. But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself. CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us. And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine. But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind. Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic? STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral. CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be. STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information. CHRIS: Me too. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable. As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think? STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in. But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with. From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had. But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied. So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants. And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that. And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it's something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris? CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again. Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it's only a single commit in a PR for me. But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future. There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants. STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that. And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there's that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request. But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit. And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process. CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things. And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider. I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do. STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: 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, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Longtime listener and friend of the show, Gio Lodi, released a book y'all should check out and Chris and Steph ruminate on a listener question about tension around marketing in open-source. Say No To More Process, Say Yes To Trust by German Velasco (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) Test-Driven Development in Swift with SwiftUI and Combine by Gio Lodi (https://tddinswift.com/) Transcript: CHRIS: Our golden roads. STEPH: All right. I am also golden. CHRIS: [vocalization] STEPH: Oh, I haven't listened to that episode where I just broke out in song in the middle. Oh, you're about to add the [vocalization] [chuckles]. CHRIS: I don't know why, though. Oh, golden roads, Golden Arches. STEPH: Golden Arches, yeah. CHRIS: Man, I did not know that my brain was doing that, but my brain definitely connected those without telling me about it. STEPH: [laughs] CHRIS: It's weird. People talk often about the theory that phones are listening, and then you get targeted ads based on what you said. But I'm almost certain it's actually the algorithms have figured out how to do the same intuitive leaps that your brain does. And so you'll smell something and not make the nine steps in between, but your brain will start singing a song from your childhood. And you're like, what is going on? Oh, right, because when I was watching Jurassic Park that one time, we were eating this type of chicken, and therefore when I smell paprika, Jurassic Park theme song. I got it, of course. STEPH: [laughs] CHRIS: And I think that's actually what's happening with the phones. That's my guess is that you went to a site, and the phones are like, cool, I got it, adjacent to that is this other thing, totally. Because I don't think the phones are listening. Occasionally, I think the phones are listening, but mostly, I don't think the phones are listening. STEPH: I definitely think the phones are listening. CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey. So we have a bit of exciting news where we received an email from Gio Lodi, who is a listener of The Bike Shed. And Gio sent an email sharing with us some really exciting news that they have published a book on Test-Driven Development in Swift. And they acknowledge us in the acknowledgments of the book. Specifically, the acknowledgment says, "I also want to thank Chris Toomey and Steph Viccari, who keep sharing ideas on testing week after week on The Bike Shed Podcast." And that's just incredible. I'm so blown away, and I feel officially very famous. CHRIS: This is how you know you're famous when you're in the acknowledgments of a book. But yeah, Gio is a longtime listener and friend of the show. He's written in many times and given us great tips, and pointers, and questions, and things. And I've so appreciated Gio's voice in the community. And it's so wonderful, frankly, to hear that he has gotten value out of the show and us talking about testing. Because I always feel like I'm just regurgitating things that I've heard other people saying about testing and maybe one or two hard-learned truths that I've found. But it's really wonderful. And thank you so much, Gio. And best of luck for anyone out there who is doing Swift development and cares about testing or test-driven development, which I really think everybody should. Go check out that book. STEPH: I must admit my Swift skills are incredibly rusty, really non-existent at this point. It's been so long since I've been in that world. But I went ahead and purchased a copy just because I think it's really cool. And I suspect there are a lot of testing conversations that, regardless of the specific code examples, still translate. At least, that's the goal that you and I have when we're having these testing conversations. Even if they're not specific to a language, we can still talk about testing paradigms and strategies. So I purchased a copy. I'm really looking forward to reading it. And just to change things up a bit, we're going to start off with a listener question today. So this listener question comes from someone very close to the show. It comes from Thom Obarski. Hi, Thom. And Thom wrote in, "So I heard on a recent podcast I was editing some tension around marketing and open source. Specifically, a little perturbed at ReactJS that not only were people still dependent on a handful of big companies for their frameworks, but they also seem to be implying that the cachet of Facebook and having developer mindshare was not allowing smaller but potentially better solutions to shine through. In your opinion, how much does marketing play in the success of an open-source project framework rather than actually being the best tool for the job?" So a really thoughtful question. Thanks, Thom. Chris, I'm going to kick it over to you. What are your thoughts about this question? CHRIS: Yeah, this is a super interesting one. And thank you so much, Thom, although I'm not sure that you're listening at this point. But we'll send you a note that we are replying to your question. And when I saw this one come through, it was interesting. I really love the kernel of the discussion here, but it is, again, very difficult to tease apart the bits. I think that the way the question was framed is like, oh, there's this bad thing that it's this big company that has this big name, and they're getting by on that. But really, there are these other great frameworks that exist, and they should get more of the mindshare. And honestly, I'm not sure. I think marketing is a critically important aspect of the work that we do both in open source and, frankly, everywhere. And I'm going to clarify what I mean by that because I think it can take different shapes. But in terms of open-source, Facebook has poured a ton of energy and effort and, frankly, work into React as a framework. And they're also battle testing it on facebook.com, a giant website that gets tons of traffic, that sees various use cases, that has all permissions in there. They're really putting it through the wringer in that way. And so there is a ton of value just in terms of this large organization working on and using this framework in the same way that GitHub and using Rails is a thing that is deeply valuable to us as a community. So I think having a large organization associated with something can actually be deeply valuable in terms of what it produces as an outcome for us as consumers of that open-source framework. I think the other idea of sort of the meritocracy of the better framework should win out is, I don't know, it's like a Field of Dreams. Like, if you build it, they will come. It turns out I don't believe that that's actually true. And I think selling is a critical part of everything. And so if I think back to DHH's original video from so many years ago of like, I'm going to make a blog in 15 minutes; look at how much I'm not doing. That was a fantastic sales pitch for this new framework. And he was able to gain a ton of attention by virtue of making this really great sales pitch that sold on the merits of it. But that was marketing. He did the work of marketing there. And I actually think about it in terms of a pull request. So I'm in a small organization. We're in a private repo. There's still marketing. There's still sales to be done there. I have to communicate to someone else the changes that I'm making, why it's valuable to the system, why they should support this change, this code coming into the codebase. And so I think that sort of communication is as critical to the whole conversation. And so the same thing happens at the level of open source. I would love for the best framework to always win, but we also need large communities with Stack Overflow answers and community-supported plugins and things like that. And so it's a really difficult thing to treat marketing as just other, this different, separate thing when, in fact, I think they're all intertwined. And marketing is critically important, and having a giant organization behind something can actually have negative aspects. But I think overall; it really is useful in a lot of cases. Those are some initial thoughts. What do you think, Steph? STEPH: Yeah, those are some great initial thoughts. I really agree with what you said. And I also like how you brought in the comparison of pull requests and how sales is still part of our job as developers, maybe not in the more traditional sense but in the way that we are marketing and communicating with the team. And circling back to what you were saying earlier about a bit how this is phrased, I think I typically agree that there's nothing nefarious that's afoot in regards to just because a larger company is sponsoring an open-source project or they are the ones responsible for it, I don't think there's anything necessarily bad about that. And I agree with the other points that you made where it is helpful that these teams have essentially cultivated a framework or a project that is working for their team, that is helping their company, and then they have decided to open source it. And then, they have the time and energy that they can continue to invest in that project. And it is battle-tested because they are using it for their own projects as well. So it seems pretty natural that a lot of us then would gravitate towards these larger, more heavily supported projects and frameworks. Because then that's going to make our job easier and also give us more trust that we can turn to them when we do need help or have issues. Or, like you mentioned, when we need to look up documentation, we know that that's going to be there versus some of the other smaller projects. They may also be wonderful projects. But if they are someone that's doing this in their spare time just on the weekends and yet I'm looking for something that I need to be incredibly reliable, then it probably makes sense for me to go with something that is supported by a team that's getting essentially paid to work on that project, at least that they're backed by a larger company. Versus if I'm going with a smaller project where someone is doing some wonderful work, but realistically, they're also doing it more on the weekends or in their spare time. So boiling it down, it's similar to what you just said where marketing plays a very big part in open source, and the projects and frameworks that we adopt, and the things that we use. And I don't think that's necessarily a bad thing. CHRIS: Yeah. I think, if anything, it's possibly a double-edged sword. Part of the question was around does React get to benefit just by the cachet of Facebook? But Facebook, as a larger organization sometimes that's a positive thing. Sometimes there's ire that is directed at Facebook as an organization. And as a similar example, my experience with Google and Microsoft as large organizations, particularly backing open-source efforts, has almost sort of swapped over time, where originally, Microsoft there was almost nothing of Microsoft's open-source efforts that I was using. And I saw them as this very different shape of a company that I probably wouldn't be that interested in. And then they have deeply invested in things like GitHub, and VS Code, and TypeScript, and tons of projects that suddenly I'm like, oh, actually, a lot of what I use in the world is coming from Microsoft. That's really interesting. And at the same time, Google has kind of gone in the opposite direction for me. And I've seen some of their movements switch from like, oh Google the underdog to now they're such a large company. And so the idea that the cachet, as the question phrase, of a company is just this uniformly positive thing and that it's perhaps an unfair benefit I don't see that as actually true. But actually, as a more pointed example of this, I recently chose Svelte over React, and that was a conscious choice. And I went back and forth on it a few times, if we're being honest, because Svelte is a much smaller community. It does not have the large organizational backing that React or other frameworks do. And there was a certain marketing effort that was necessary to raise it into my visibility and then for me to be convinced that there is enough there, that there is a team that will maintain it, and that there are reasons to choose that and continue with it. And I've been very happy with it as a choice. But I was very conscious in that choice that I'm choosing something that doesn't have that large organizational backing. Because there's a nicety there of like, I trust that Facebook will probably keep investing in React because it is the fundamental technology of the front end of their platform. So yeah, it's not going to go anywhere. But I made the choice of going with Svelte. So it's an example of where the large organization didn't win out in my particular case. So I think marketing is a part of the work, a part of the conversation. It's part of communication. And so I am less negative on it, I think, than the question perhaps was framed, but as always, it depends. STEPH: Yeah, I'm trying to think of a scenario where I would be concerned about the fact that I'm using open source that's backed by a specific large company or corporation. And the main scenario I can think of is what happens when you conflict or if you have values that conflict with a company that is sponsoring that project? So if you are using an open-source project, but then the main community or the company that then works on that project does something that you really disagree with, then what do you do? How do you feel about that situation? Do you continue to use that open-source project? Do you try to use a different open-source project? And I had that conversation frankly with myself recently, thinking through what to do in that situation and how to view it. And I realize this may not be how everybody views it, and it's not appropriate for all situations. But I do typically look at open-source projects as more than who they are backed by, but the community that's actively working on that project and who it benefits. So even if there is one particular group that is doing something that I don't agree with, that doesn't necessarily mean that wholesale I no longer want to be a part of this community. It just means that I still want to be a part, but I still want to share my concerns that I think a part of our community is going in a direction that I don't agree with or I don't think is a good direction. That's, I guess, how I reason with myself; even if an open-source project is backed by someone that I don't agree with, either one, you can walk away. That seems very complicated, depending on your dependencies. Or two, you find ways to then push back on those values if you feel that the community is headed in a direction that you don't agree with. And that all depends on how comfortable you are and how much power you feel like you have in that situation to express your opinion. So it's a complicated space. CHRIS: Yeah, that is a super subtle edge case of all of this. And I think I aligned with what you said of trying to view an open-source project as more generally the community that's behind it as opposed to even if there's a strong, singular organization behind it. But that said, that's definitely a part of it. And again, it's a double-edged sword. It's not just, oh, giant company; this is great. That giant company now has to consider this. And I think in the case of Facebook and React, that is a wonderful hiring channel for them. Now all the people that use React anywhere are like, "Oh man, I could go work at Facebook on React? That's exciting." That's a thing that's a marketing tool from a hiring perspective for them. But it cuts both ways because suddenly, if the mindshare moves in a different direction, or if Facebook as an organization does something complicated, then React as a community can start to shift away. Maybe you don't move the current project off of it, but perhaps you don't start the next one with it. And so, there are trade-offs and considerations in all directions. And again, it depends. STEPH: Yeah. I think overall, the thing that doesn't depend is marketing matters. It is a real part of the ecosystem, and it will influence our decisions. And so, just circling back to Thom's question, I think it does play a vital role in the choices that we make. CHRIS: Way to stick the landing. STEPH: Thanks. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Changing topics just a bit, what's new in your world? CHRIS: Well, we had what I would call a mini perfect storm this week. We broke the build but in a pretty solid way. And it was a little bit difficult to get it back under control. And it has pushed me ever so slightly forward in my desire to have a fully optimized CI and deploy pipeline. Mostly, I mean that in terms of ratcheting. I'm not actually going to do anything beyond a very small set of configurations. But to describe the context, we use pull requests because that's the way that we communicate. We do code reviews, all that fun stuff. And so there was a particular branch that had a good amount of changes, and then something got merged. And this other pull request was approved. And that person then clicked the rebase and merge button, which I have configured the repository, so that merge commits are not allowed because I'm not interested in that malarkey in our history. But merge commits or rebase and merge. I like that that makes sense. In this particular case, we ran into the very small, subtle edge case of if you click the rebase and merge button, GitHub is now producing a new commit that did not exist before, a new version of the code. So they're taking your changes, and they are rebasing them onto the current main branch. And then they're attempting to merge that in. And A, that was allowed. B, the CI configuration did not require that to be in a passing state. And so basically, in doing that rebase and merge, it produced an artifact in the build that made it fail. And then attempting to unwind that was very complicated. So basically, the rebase produced...there were duplicate changes within a given file. So Git didn't see it as a conflict because the change was made in two different parts of the file, but those were conflicting changes. So Git was like, this seems like it's fine. I can merge this, no problem. But it turns out from a functional perspective; it did not work. The build failed. And so now our main branch was failing and then trying to unwind that it just was surprisingly difficult to unwind that. And it really highlighted the importance of keeping the main branch green, keeping the build always passing. And so, I configured a few things in response to this. There is a branch protection rule that you can enable. And let me actually pull up the specific configuration that I set up. So I now have enabled require status checks to pass before merging, which, if we're being honest, I thought that was the default. It turns out it was not the default. So we are now requiring status checks to pass before merging. I'm fully aware of the awkward, painful like, oh no, the build is failing but also, we have a bug. We need to deploy this. We must get something merged in. So hopefully, if and when that situation presents itself, I will turn this off or somehow otherwise work around it. But for now, I would prefer to have this as a yeah; this is definitely a configuration we want. So require status checks to pass before merging and then require branches to be up to date before merging. So the button that does the rebase and merge, I don't want that to actually do a rebase on GitHub. I want the branch to already be up to date. Basically, I only ever want fast-forward merges on our main branch. So all code should be ahead of main, and we are simply updating what main points at. We are not creating new code. That code has run on CI, that version of the code specifically. We are fully rebased and up to date on top of main, and that's how we're going. STEPH: All of that is super interesting. I have a question about the workflow. I want to make sure I'm understanding it correctly. So let's say that I have issued a PR, and then someone else has merged into the main branch. So now my PR is behind me, and I don't have that latest commit. With the new configuration, can I still use the rebase and merge, or will I need to rebase locally and then push up my branch before I can merge into main but at least using the GitHub UI? CHRIS: I believe that you would be forced to rebase locally, force push, and then CI would rebuild, and that's what it is. So I think that's what require branches to be up to date before merging means. So that's my hope. That is the intention here. I do realize that's complicated. So this requirement, which I like, because again, I really want the idea that no, no, no, we, the developers, are in charge of that final state. That final state should always run as part of a build of CI on our pull request/branch before going into main. So no code should be new. There should be no new commits that have never been tested before going into main. That's my strong belief. I want that world. I realize that's...I don't know. Maybe I'm getting pedantic, or I'm a micromanager of the Git history or whatever. I'm fine with any of those insults that people want to lob at me. That's fine. But that's what I feel. That said, this is a nuisance. I'm fully aware of that. And so imagine the situation where we got a couple of different things that have been in flight. People have been working on different...say there are three pull requests that are all coming to completion at the same time. Then you start to go to merge something, and you realize, oh no, somebody else just merged. So you rebase, and then you wait for CI to build. And just as the CI is completing, somebody else merges something, and you're like, ah, come on. And so then you have to one more time rebase, push, wait for the build to be green. So I get that that is not an ideal situation. Right now, our team is three developers. So there are a few enough of us that I feel like this is okay. We can manage this via human intervention and just deal with the occasional weight. But in the back of my mind, of course, I want to find a better solution to this. So what I've been exploring…there's a handful of different utilities that I'm looking at, but they are basically merged queues as an idea. So there are three that I'm looking at, or maybe just two, but there's mergify.io, which is a hosted solution that does this sort of thing. And then Shopify has a merge queue implementation that they're running. So the idea with this is when you as a developer are ready to merge something, you add a label to it. And when you add that label, there's some GitHub Action or otherwise some workflow in the background that sees that this has happened and now adds it to a merge queue. So it knows all of the different things that might want to be merged. And this is especially important as the team grows so that you don't get that contention. You can just say, "Yes, I would like my changes to go out into production." And so, when you label it, it then goes into this merge queue. And the background system is now going to take care of any necessary rebases. It's going to sequence them, so it's not just constantly churning all of the branches. It's waiting because it knows the order that they're ideally going to go out in. If CI fails for any of them because rebasing suddenly, you're in an inconsistent state; if your build fails, then it will kick you out of the merge queue. It will let you know. So it will send you a notification in some manner and say, "Hey, hey, hey, you got to come look at this again. You've been kicked out of the merge queue. You're not going to production." But ideally, it adds that layer of automation to, frankly, this nuisance of having to keep things up to date and always wanting code to be run on CI and on a pull request before it gets into main. Then the ideal version is when it does actually merge your code, it pings you in Slack or something like that to say, "Hey, your changes just went out to production." Because the other thing I'm hoping for is a continuous deployment. STEPH: The idea of a merge queue sounds really interesting. I've never worked with a process like that. And one of the benefits I can see is if I know I'm ready for something to go like if I'm waiting on a green build and I'm like, hey, as soon as this is green, I'd really like for it to get merged. Then currently, I'm checking in on it, so I will restart the build. And then, every so often, I'm going back to say, "Okay, are you green? Are you green? Can I emerge?" But if I have a merge queue, I can say, "Hey, merge queue, when this is green, please go and merge it for me." If I'm understanding the behavior correctly, that sounds really nifty. CHRIS: I think that's a distinct but useful aspect of this is the idea that when you as a developer decide this PR is ready to go, you don't need to wait for either the current build or any subsequent builds. If there are rebases that need to happen, you basically say, "I think this code's good to go. We've gotten the necessary approvals. We've got the buy-in and the teams into this code." So cool, I now market as good. And you can walk away from it, and you will be notified either if it fails to get merged or if it successfully gets merged and deployed. So yes, that dream of like, you don't have to sit there watching the pot boil anymore. STEPH: Yeah, that sounds nice. I do have to ask you a question. And this is related to one of the blog posts that you and I love deeply and reference fairly frequently. And it's the one that's written by German Velasco about Say No to More Process, and Say Yes to Trust. And I'm wondering, based on the pain that you felt from this new commit, going into main and breaking the main build, how do you feel about that balance of we spent time investigating this issue, and it may or may not happen again, and we're also looking into these new processes to avoid this from happening? I'm curious what your thought process is there because it seems like it's a fair amount of work to invest in the new process, but maybe that's justified based on the pain that you felt from having to fix the build previously. CHRIS: Oh, I love the question. I love the subtle pushback here. I love this frame of mind. I really love that blog post. German writes incredible blog posts. And this is one that I just keep coming back to. In this particular case, when this situation occurred, we had a very brief...well, it wasn't even that brief because actually unwinding the situation was surprisingly painful, and we had some changes that we really wanted to get out, but now the build was broken. And so that churn and slowdown of our build pipeline and of our ability to actually get changes out to production was enough pain that we're like, okay, cool. And then the other thing is we actually all were in agreement that this is the way we want things to work anyway, that idea that things should be rebased and tested on CI as part of a pull request. And then we're essentially only doing fast-forward merges on the main branch, or we're fast forward merging main into this new change. That's the workflow that we wanted. So this configuration was really just adding a little bit of software control to the thing that we wanted. So it was an existing process in our minds. This is the thing we were trying to do. It's just kind of hard to keep up with, frankly. But it turns out GitHub can manage it for us and enforce the process that we wanted. So it wasn't a new process per se. It was new automation to help us hold ourselves to the process that we had chosen. And again, it's minimally painful for the team given the size that we're at now, but I am looking out to the future. And to be clear, this is one of the many things that fall on the list of; man, I would love to have some time to do this, but this is obviously not a priority right now. So I'm not allowed to do this. This is explicitly on the not allowed to touch list, but someday. I'm very excited about this because this does fundamentally introduce some additional work in the pipeline, and I don't want that. Like you said, is this process worth it for the very small set of times that it's going to have a bad outcome? But in my mind, the better version, that down the road version where we have a merge queue, is actually a better version overall, even with just a tiny team of three developers that are maybe never even conflicting in our merges, except for this one standout time that happens once every three months or whatever. This is still nicer. I want to just be able to label a pull request and walk away and have it do the thing that we have decided as a team that we want. So that's the dream. STEPH: Oh, I love that phrasing, to label a pull request and be able to walk away. Going back to our marketing, that really sells that merge queue to me. [laughs] Mid-roll Ad And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. CHRIS: To be clear, and this is to borrow on some of Charity Majors' comments around continuous deployment and whatnot, is a developer should stay very close to the code if they are merging it. Because if we're doing continuous deployment, that's going to go out to production. If anything's going to happen, I want that individual to be aware. So ideally, there's another set of optimizations that I need to make on top of this. So we've got the merge queue, and that'll be great. Really excited about that. But if we're going to lean into this, I want to optimize our CI pipeline and our deployment pipeline as much as possible such that even in the worst case where there's three different builds that are fighting for contention and trying to get out, the longest any developer might go between labeling a pull request and saying, "This is good to go," and it getting out to production, again, even if they're contending with other PRs, is say 10, 15 minutes, something like that. I want Slack to notify them and them to then re-engage and keep an eye on things, see if any errors pop up, anything like that that they might need to respond to. Because they're the one that's got the context on the code at that point, and that context is decaying. The minute you've just merged a pull request and you're walking away from that code, the next day, you're like, what did I work on? I don't remember that at all. That code doesn't exist anymore in my brain. And so,,, staying close to that context is incredibly important. So there's a handful of optimizations that I've looked at in terms of the CircleCI build. I've talked about my not rebuilding when it actually gets fast-forward merged because we've already done that build on the pull request. I'm being somewhat pointed in saying this has to build on a pull request. So if it did just build on a pull request, let's not rebuild it on main because it's identically the same commit. CircleCI, I'm looking at you. Give me a config button for that, please. I would really love that config button. But there are a couple of other things that I've looked at. There's RSpec::Retry from NoRedInk, which will allow for some retry semantics. Because it will be really frustrating if your build breaks and you fall out of the merge queue. So let's try a little bit of retry logic on there, particularly around feature specs, because that's where this might happen. There's Knapsack Pro which is a really interesting thing that I've looked at, which does parallelization of your RSpec test suite. But it does it in a different way than say Circle does. It actually runs a build queue, and each test gets sent over, and they have build agents on their side. And it's an interesting approach. I'm intrigued. I think it could use some nice speed-ups. There's esbuild on the Heroku side so that our assets build so much more quickly. There are lots of things. I want to make it very fast. But again, this is on the not allowed to do it list. [laughs] STEPH: I love how most of the world has a to-do list, and you have this not-allowed to-do list that you're adding items to. And I'm really curious what all is on the not allowed to touch lists or not allowed to-do list. [laughs] CHRIS: I think this might be inherent to being a developer is like when I see a problem, I want to fix it. I want to optimize it. I want to tweak it. I want to make it so that that never happens again. But plenty of things...coming back to German's post of Say No to More Process, some things shouldn't be fixed, or the cost of fixing is so much higher than the cost of just letting it happen again and dealing with it manually at that moment. And so I think my inherent nature as a developer there's a voice in my head that is like, fix everything that's broken. And I'm like, sorry. Sorry, brain, I do not have that kind of time. And so I have to be really choosy about where the time goes. And this extends to the team as well. We need to be intentional around what we're building. Actually, there's a feeling that I've been feeling more acutely than ever, but it's the idea of this trade-off or optimization between speed and getting features out into the world and laying the right fundamentals. We're still very early on in this project, and I want to make sure we're thinking about things intentionally. I've been on so many projects where it's many years after it started and when I ask someone, "Hey, why do your background jobs work that way? That's a little weird." And they're like, "Yeah, that was just a thing that happened, and then it never changed. And then, we copied it and duplicated, and that pattern just got reinforced deeply within the app. And at this point, it would cost too much to change." I've seen that thing play out so many times at so many different organizations that I'm overwhelmed with that knowledge in the back of my head. And I'm like, okay, I got to get it just right. But I can't take the time that is necessary to get it, quote, unquote, "Just right." I do not have that kind of time. I got to ship some features. And this tension is sort of the name of the game. It's the thing I've been doing for my entire career. But now, given the role that I have with a very early-stage startup, I've never felt it more acutely. I've never had to be equally as concerned with both sides of that. Both matter all the more now than they ever have before, and so I'm kind of existing in that space. STEPH: I really like that phrasing of that space because that deeply resonates with me as well. And that not allowed to-do list I have a similar list. For me, it's just called a wishlist. And so it's a wishlist that I will revisit every so often, but honestly, most things on there don't get done. And then I'll clear it out every so often when I feel it's not likely that I'm going to get to it. And then I'll just start fresh. So I also have a similar this is what I would like to do if I had the time. And I agree that there's this inclination to automate as well. As soon as we have to do something that felt painful once, then we feel like, oh, we should automate it. And that's a conversation that I often have with myself is at what point is the cost of automation worthwhile versus should we just do this manually until we get to that point? So I love those nuanced conversations around when is the right time to invest further in this, and what is the impact? And what is the cost of it? And what are the trade-offs? And making that decision isn't always clear. And so I think that's why I really enjoy these conversations because it's not a clear rubric as to like, this is when you invest, and this is when you don't. But I do feel like being a consultant has helped me hone those skills because I am jumping around to different teams, and I'm recognizing they didn't do this thing. Maybe they didn't address this or invest in it, and it's working for them. There are some oddities. Like you said, maybe I'll ask, "Why is this? It seems a little funky. What's the history?" And they'll be like, "Yeah, it was built in a hurry, but it works. And so there hasn't been any churn. We don't have any issues with it, so we have just left it." And that has helped reinforce the idea that just because something could be improved doesn't mean it's worthwhile to improve it. Circling back to your original quest where you are looking to improve the process for merging and ensuring that CI stays green, I do like that you highlighted the fact that we do need to just be able to override settings. So that's something that has happened recently this week for me and my client work where we have had PRs that didn't have a green build because we have some flaky tests that we are actively working on. But we recognize that they're flaky, and we don't want that to block us. I'm still shipping work. So I really appreciate the consideration where we want to optimize so that everyone has an easy merging experience. We know things are green. It's trustworthy. But then we also have the ability to still say, "No, I am confident that I know what I'm doing here, and I want to merge it anyways, but thank you for the warning." CHRIS: And the constant pendulum swing of over-correcting in various directions I've experienced that. And as you said, in the back of my mind, I'm like, oh, I know that this setting I'm going to need a way to turn this setting off. So I want to make sure that, most importantly, I'm not the only one on the team who can turn that off because the day that I am away on vacation and the build is broken, and we have a critical bug that we need to fix, somebody else needs to be able to do that. So that's sort of the story in my head. At the same time, though, I've worked on so many teams where they're like, oh yeah, the build has been broken for seven weeks. We have a ticket in the backlog to fix that. And it's like, no, the build has to not be broken for that long. And so I agree with what you were saying of consulting has so usefully helped me hone where I fall on these various spectrums. But I do worry that I'm just constantly over-correcting in one direction or the other. I'm never actually at an optimum. I am just constantly whatever the most recent thing was, which is really impacting my thinking on this. And I try to not do that, but it's hard. STEPH: Oh yeah. I'm totally biased towards my most recent experiences, and whatever has caused me the most pain or success recently. I'm definitely skewed in that direction. CHRIS: Yeah, I definitely have the recency bias, and I try to have a holistic view of all of the things I've seen. There's actually a particular one that I don't want to pat myself on the back for because it's not a good thing. But currently, our test suite, when it runs, there's just a bunch of noise. There's a bunch of other stuff that gets printed out, like a bunch of it. And I'm reminded of a tweet from Kevin Newton, a friend of the show, and I just pulled it up here. "Oh, the lengths I will go to avoid warnings in my terminal, especially in the middle of my green dots. Don't touch my dots." It's a beautiful beauty. He actually has a handful about the green dots. And I feel this feel. When I run my test suite, I just want a sea of green dots. That's all I want to see. But right now, our test suite is just noise. It's so much noise. And I am very proud of...I feel like this is a growth moment for me where I've been like, you know what? That is not the thing to fix today. We can deal with some noise amongst the green dots for now. Someday, I'm just going to lose it, and I'm going to fix it, and it's going to come back to green dots. [chuckles] STEPH: That sounds like such a wonderful children's book or Dr. Seuss. Oh, the importance of green dots or, oh, the places green dots will take you. CHRIS: Don't touch my dots. [laughter] STEPH: Okay. Maybe a slightly aggressive Dr. Seuss, but I still really like it. CHRIS: A little more, yeah. STEPH: On that note of our love of green dots, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: 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, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeee!!! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Steph talks about a new GitHub feature and Twitter account (@RubyCards (https://twitter.com/RubyCards)) she's really excited about and Chris talks about his new job as a CTO of a startup and shifting away from writing code regularly. GitHub (https://docs.github.com/en/codespaces/developing-in-codespaces/web-based-editor) RubyCards (https://twitter.com/RubyCards) Resilient Management (https://resilient-management.com/) The Manager's Path (https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897) Transcript: CHRIS: Oh God, my computer is so stupid slow. I need a new computer. STEPH: Come on, little computer, you can do it. You know you could just buy a new one. You don't have to wait for the fancy-schmancy M1. CHRIS: I want to wait for the fancy. I want it so bad. STEPH: [laughs] CHRIS: Do you know how long I've had this computer? And if I can hold out one more month, I want the fancy stuff. I've waited this long. Why would I give in now when I'm right on the cusp of victory? STEPH: One more month. I'm going to send you...as a kid, did you ever make those construction… CHRIS: Oh yeah. STEPH: They look like chain links bow construction paper. So we would make those for a countdown to special days. I'm going to send you one that's all crumpled and folded in the mail. It would be delightful. And you'll be able to snip off a little chain each day as your countdown to your new fancy-schmancy. [laughs] CHRIS: I love it. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey. Well, I just got back from vacation. So getting back to work is what's new in my world. And vacation is nice. I miss it already. But it's also nice to be back, and see everybody, and see what they've been up to. CHRIS: I've heard wonderful things about vacation. STEPH: Yeah. Have you had one recently? I know you've been quite busy. CHRIS: I have. I think it's hard to tell, especially because everything just kind of blends together these days. But I think I took off a few days recently. I haven't had an extended vacation since much earlier on in the summer, I think. And so I think I'm due for one of those sometime in the not too distant future. But it's one of those things where you got to plan it. And you got to think ahead, and I haven't been doing that of late really with anything. So kind of living for the moment, but that's not how you take a vacation. So I got to rethink some strategies here. [chuckles] STEPH: Yeah, I've been trying to schedule more vacation time just further out. Because then if I don't want to take it, like if I decide that I don't want the staycation or I don't need the day off, then I can just change my mind, and that's pretty easy to do. But I'm like you; if I don't plan it, then I don't feel like I have the energy to plan a vacation, and then it just doesn't happen. So I know that's one thing that I've been doing. I've also been mentoring or coaching others, just checking in with them to say, "Hey, when's your next vacation? Have you scheduled any days off? Do you want to schedule a day off next month?" And saying that to other people has also been a very helpful reminder to me to do so. CHRIS: Oh, I like that a lot as a recurring one-on-one question of, so what can you tell me about vacation? What do you got in the works there? Because that's the most important thing, [chuckles] which it kind of is. It's the way that we keep doing the work that we do. STEPH: And I think so many people just haven't been taking a vacation. I mean, in 2020, we were all locked in and going through a pandemic, so then a lot of people weren't taking those breaks. And so part of it is just reminding people that even if you can't go somewhere, still please take some downtime and just know that you can step away from work and should step away from work. But for us, we did go somewhere. So we went out to Seattle, which I've never...I've been out to the West Coast, but it's more like I've been out to L.A., Santa Monica. But this time, we went to the Northwest region. We went to Seattle, and we explored and did a lot of hiking and camping around the Northern Cascades and then Mount Rainier. And both of those are amazing. And I've never flown with camping gear, but that went really well. It worked out nice. We had an Airbnb every so often just for showers and having a roof over your head. That's really nice. But for most of the trip, we did a lot of camping and hiking. CHRIS: That sounds like an awesome trip. STEPH: Yeah, it was really cool. I'd love to go back to the Olympic National Park because there are just so many national parks that are around Seattle and in Washington that we couldn't begin to do it all. But Olympic National Park is still on my list. And I'm really grateful to have also seen the Northern Cascades and Mount Rainier. But switching gears a bit, I have something that I'm really excited to share with you because I don't think you've seen it yet. I'm excited to find out if you have. But it's a new GitHub feature that came out, I think about a month ago, but there doesn't seem to have been much fanfare from GitHub about announcing this new feature. And I happened to find out through Twitter because someone else found it, and then they were really excited. And so now I think it's really gaining some more traction. But it still seems like one of those sneaky feature releases, but it's really cool. So GitHub has added the ability to open up a web-based editor that allows you to view the source code for a repo, view it in syntax, highlighting, make a code change, and commit the change. And it's free for everybody. And there's a couple of ways to get there, but I'll pause there. Have you seen this yet? Have you interacted with it? CHRIS: I think I've seen it and poked around ever so gently with it. I want to say this is GitHub Codespaces. Is that the name of this feature? STEPH: Yep. That's it? CHRIS: Yes. I poked around with it just a tiny bit, and I'm very excited about it. But it's very much in the like, huh, okay, cool; I'll look at that someday down the road and figure out what I want to do with it. But have you actually dug into it particularly deeply? STEPH: I used it to make a change for a personal project, just because I wanted to see the whole flow. So I went to a personal project, and there are two ways that you can open it up for anyone that hasn't seen this yet. So you can either press the period button that's on your keyboard, and that will open it up, or you can just alter the URL. So instead of github.com, replace that .com with .dev, and then that will also open up the browser. And so I made a change to a personal project, and it worked really well, and it commits the change to main. And it was nice. It was easy. In my case, I was just making a change to make a change. I think I actually went to an older project where I was still using the underscore target to force users that when they clicked on a link that it opened a new tab, and I was like, perfect. This is a good thing to just change. And I could do it from my iPad. I didn't have to be at my computer. And it was really nifty. I was very impressed with it. And they also mentioned that it's very easy to integrate your own VS Code settings and environment. I'm not a heavy VS Code user, so I haven't tried that. But I've heard really positive things about how easy it is to sync your settings between your local VS Code and then GitHub's editor. But overall, it was really easy to use. CHRIS: That's super cool. My very limited understanding of it is like GitHub has had the ability to edit files and things like that for a while. But it was very much like a simple web editor where it's a big text box that happens to contain the code. And they've added some stuff for like browsing with syntax highlighting and even some context-aware show usage and things like that. But as far as I understand it, this is like a whole VS Code instance in the cloud that is running it. And then I think what you're saying about you can have your VS Code settings in there, but even your project settings and the ability to run the tests, I'm not sure where the edges of it are. But my understanding with Codespaces it's like this is how your team can develop. Everyone gets one of these Codespaces. You're developing in the cloud. But it does VS Code remote sync type stuff. I'm very intrigued to see where it goes and that idea of...obviously, I like Vim. That's the thing that's probably known and true about me. So I will probably be one of the later adopters of this. But the idea of being able to bottle up the development environment for your projects and have those settings, and the ability to run the test and all of that packaged up as part of the repository, and then allow people to run with that, especially in the cloud, and be able to carry that with them as they move around, that's really intriguing. And the idea of having this very easy on-ramp, especially for open-source projects and things like that. If you want people to be able to contribute easily but with the linting, and the configuration, and the settings, and all the stuff, well, now you can have that packaged up. And that is very interesting to me. So I'm super intrigued to see where it goes. Again, I will probably be one of the later adopters of this platform for reasons. But I am super interested, and I continue to like...the work with VS Code is so interesting in the way it keeps expanding out and the language server stuff and now the Codespaces stuff. And it's super interesting developments across the board. STEPH: Yeah, I'm with you. I don't actually see this replacing my current development that I do day-to-day, but it's more generally nice to have access. So if I needed to make a change and I don't have my laptop or if it's just something small and I don't want to have to go through…I guess essentially, if I don't have my laptop, but I wanted to make a change, then I could do this realistically from something that doesn't have my full local dev setup. I don't know if you have the ability to run tests. I didn't explore that far as to whether you can actually have access to run those types of commands or processes. I did see some additional notes while reading through GitHub's documentation about this new editor. And they included some notes that talk about how the editor runs entirely in your browser's sandbox. So it doesn't actually clone the repo, but instead, it loads your code by invoking the services API directly from the browser. So then your work is saved in the browser's local storage until you commit it, and then you can persist your changes by then committing it back to the repo. And because there's no associated compute, you won't be able to build and run your code or use the integrated terminal. Ah, I think that actually answers the question about running tests. So only a subset of extensions can run in the web will appear in the extensions panel and can be installed. So this does impose certain limitations for particular programming languages and full functionality, things that we may need like running tests. CHRIS: Interesting. That now puts it back more on the uncanny valley for me where it's like, oh, it's just VS Code, except it can't do a bunch of the stuff. So yeah, I'll probably be hanging out in Vim for a while. But again, I'm super interested to see where they can push this and what the browser platform allows, and then how they're able to leverage that and so on and so forth. STEPH: There is one flow that I was testing out because I was reading someone else mentioned that not only can you use this for looking at source code and then changing that source code but also for a pull request. And so I went to a pull request and changed the URL to dev. And I do have the ability to make changes, but I'm not quite sure if I could commit my changes and if that would go to the branch or how that would work. It wasn't obvious to me how I could save my changes. But it was obvious to me that I could make changes. [laughs] So that part feels weird to me, and I will have to test that out. But I'm going to wait until I have my own PR before I start fooling around [laughs] so I don't ruin somebody else's PR. CHRIS: Ideally, the worst case is you just push commit to a branch, and commits are reversible. You can throw them away. You can reset, and you can do all sorts of stuff. But I agree with you that maybe I'll do this on my home turf first before I start messing around with somebody's PR. STEPH: That way, someone doesn't reach out to me and say, "Steph, what is this commit that I have on my PR?" And I'm like, "Oh, I'm just testing." [laughs] But that's something that I was excited to talk about and share with you. What's new in your world? CHRIS: Well, what's new in my world? I think we've talked about this a little bit, but to give a little bit of context on what's new in my world, I joined a startup. I am now engineer number one. I'm also CTO, a very fancy title, but again, I'm the team of one, so count it as you will. But we do have some consultants working with us. So there is a small team that I am managing, and very quickly, I found myself shifting away from the code or having to balance that trade-off of maker versus manager time. Like, how much of the time am I actually coding and shipping features versus managing and communicating, and trying to figure out the work to be done and triaging the backlog? And all of those sorts of things. I've also just been coding less, and I think that's a trend that will almost certainly continue, and I'm intrigued by that. And that's a thing that I want to poke at just a little bit. And then I've also noticed that my work has become much more reactive than it used to be, where there are lots of things in Slack. And there's stuff that I'm kind of the only person that can do certain things because I have certain access levels and yadda yadda. And I want to make sure other folks aren't blocked. So I'm trying to be as responsive as possible in those moments. But I'm also struggling with that that trade-off between reactive versus proactive. My ideal version I think of the work is gather all of the information, all of the different permutations, and what are all the features we want? And then I think about them holistically, and then I respond once solidly as opposed to little one-off interactions and things like that. So there are just a lot of subtle differences. And I think there are trends that will continue. And so I'm trying to just take a step back, observe them from a distance and say, "How do I feel about these?" But probably most interesting to me is the moving away from code. Have you noticed that at all in your work? Or is that something you've thought about, something you'd be interested in, opposed to? How do you feel about that space in the coding world? STEPH: That is a wonderful question. It's one that I have wrestled with for a while because I really love my current position. I love being a team lead because I feel like there's this wonderful balance between where I get to code a lot of the time, but then I also get to learn how to be a manager, and help those around me, and provide some coaching or mentoring or just help people find the resources that they need essentially. And I really like that balance. That feels like the right balance to me, where I still get to grow in both areas. But then, as you'd mentioned, it still feels like one tries to take over the other with time. Like you find that more responsibilities are growing as CTO of the company. And so you feel more responsible to do more of the managerial task or unblocking others and taking on that role, and then that reduces your time for coding. And I often find myself in that space where I think it's just how I'm wired. I'm very interested and empathetic towards how people are doing and how they're feeling. So I'm always looking for ways to support others and to help unblock them and make sure that they're having a very positive experience with our project. And so then that may mean I'm coding less because then I'm more focused on that. But then, it's still also a very valid part of my job to code. So finding the right balance between those is frankly hard. To answer your other question, I don't think I want to give that up. I've considered for myself if I'm going to head towards more of a manager path, and I'm going to reserve the right to change my mind. But currently, I still like maintaining most of my individual contributor status with a dash of management sprinkled in there and then some responsibilities for making sure that the team is doing well and that people are enjoying their work. Along that line, as I've been having conversations with others around, tell me more about your job as a manager, and what does that look like? What responsibilities do you have? How much coding do you still get to do? There have been a couple of books that have been recommended to me that really help someone define are you interested in management? Is that a place that you see yourself going? This is really an honest look at what it means to be a manager. The fact that a lot of your fulfilling work isn't necessarily work that you get to produce, but it's actually helping someone else produce that work and then getting to see them succeed. That is your new fulfillment or a big part of it. So you are losing that closeness of being a maker,, but instead, you are empowering someone else to be the maker, and then that becomes your win. And that becomes an indication of your success. Versus as an individual contributor, it's really easy to see our wins in a different light: how many tickets have we addressed? How many PRs have we reviewed? That type of work. So there is an interesting dichotomy there, and I can't remember the books off the top of my head, but I will find them and I'll add a link to them in the show notes. CHRIS: Yeah, definitely interested to see the book recommendations. And generally, yeah, everything you're saying makes sense to me. I think I'm somewhat on the adventure right now. I very much intentionally chose this, and I want to lean into it and explore this facet of the work and doing more of the management and leading a team. But I have to accept that that comes with letting go of some of the individual contributor parts. And I was coding a bit over the weekend. I was just rediscovering the flow of that. And I was like, oh yeah, I really like this. Huh, that's interesting. What am I going to do with that? But I think, again, it's an exploration. And there are facets of both sides that I really like. And I've spent a lot of time deeper in the individual contributor side. And I've explored the manager side somewhat but not quite as much. And so this is very much about that I want to push on those edges and try and find what feels true to me. So the moving away from code and then moving more into management, I think I like that overall. Although I know there's the small amount in the back of my head that I'm like, I know there's a cost there. That is a trade-off. And so do I find more time in my evenings and weekends to do personal coding projects and things like that just to have that enjoyable work for myself? The maker versus manager stuff is interesting, though, where my day is now split up into smaller pieces. And even if I'm not coding, there's still writing up docs, or there are things that still require structured blocks of time. And my day is now just sprinkled with other things. And so trying to find that heads down of I want to just do the work right now, and I want to think hard about something is just fundamentally harder to do with more meetings and things speckled throughout the day. So that's one that I think I just don't like overall. But it's sort of a trade-off inherent to the situation. So I think there's also a version of trying to be intentional about that and saying, you know what? I need some heads-down time. And so Tuesday and Thursday afternoons those are going to be mine. I'm going to wall those off on my calendar and try and protect that time so that whatever necessary heads-down work that I need to do this week fits into those blocks of time and then fit the rest of things around that. But I think I have to make that intentional choice to do that. Mid-roll Ad And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. STEPH: Your mention of having more meetings really resonates with me. And it also made me think of a recent episode of a new TV show I just started watching. Have you seen the TV show called Schmigadoon!? CHRIS: I have indeed. STEPH: Okay. We need to have a whole conversation about Schmigadoon! in an upcoming episode. I'm very excited about this show. It's delightful. [laughs] There's a particular line that Keegan-Michael Key says that I just love so much where he says that he became a surgeon because he wanted to help people without talking to people. And I was like, oh, that's a developer. [laughs] I'm the same way. And I really enjoyed that. Although I do like talking to people but still, it just made me think about when you're talking about more meetings and then increasing the amount of talking that needs to be done as you progress into more of a management role. Also, circling back, I really like what you said earlier about you're noticing the changes that are happening. You're letting those changes happen, and then you're reflecting on how you feel about it. I really like that approach. Do you think that's working well for you? Does it feel too loose because then you don't feel in control enough of those changes? Or do you actually feel like that's a really good way to explore a new role and then find out if you like those changes? CHRIS: Now that you are restating it back to me, I'm like, oh yeah, I guess that is a good way to do things. But to clarify, I'm not doing nothing with it. I am trying to proactively, where I can, structure my days and do things like that or recognize that right now, I'm probably not the right person to be moving code along. And so I'm saying okay, that is true. And I'm actively choosing to not pick up the bigger pieces of work or to pair with someone else so that they can then run with it but not having me being the person that owns it. So it's not completely letting it happen, but it is almost like meditation to invoke that idea of I'm observing that I'm having these thoughts, and I'm just going to let them go. And it's more about the thinking and the response to it. So I'm trying to name the thing and be like, oh, this is interesting that this is happening. And I'm noticing an immediate visceral reaction to it where it's like, you're taking away my coding? And I'm like, well, hey, it's not them, it's you; you chose to do this. But let's just spend a minute there. That's okay. How do we feel about this? And so it's trying to not have it be a purely reactive response to it but have it be a more intentional, more thoughtful, and more observing, and then giving it a little bit of time to ruminate and then see a little bit more what I think. And also, some of it is purposefully pushing myself out of my comfort zone. I think I'm happy, and I do a reasonable job when I'm the person moving the code along. But I also have really enjoyed being at the edge of an engineering team and working with sales or working with other groups and facilitating the work that's happening. And so, if I explore that a little bit more, what's that going to look like for me? So this period of my career, I'm very intentionally trying to do stuff that I'm like, well, this is a little bit different for me, or this is stretching a little bit, but that is the goal. And I hope good things will come out of it across the board. But it may be that I find like, you know what? Actually, I really miss coding, and I need to find a way to restructure that. And I have seen examples of individuals who are even in CEO positions that are like, no, no, no, I still make some time to code. Like Amir, the founder of Todoist talks regularly about the fact that he is a CEO who still codes. And that organization has a very particular approach to work. And they're very much about async remote, et cetera. So having these blocks of times and being intentional about how they work. So it's not surprising that he's been able to do that and a purposeful thing that he's structured. I don't think that will make sense for me immediately. But I could see a version down the road where I'm like, this is who I am. I need to get this thing back. But for now, I'm purposefully letting it happen and seeing how I feel from there. Also, as I'm saying all of this, it sounds like I'm totally on top of this and really thinking it through. I'm like, no, no, no, this is in the moment. I'm noticing some stuff and being like, oh, okay, well, that's interesting. And some of it I intentionally chose. Again, intentionally chose to get out of my comfort zone. So I think I'm just actively out of my comfort zone right now and saying things about it. And then I think I'm telling the story of how I want to respond to it moving forward but not necessarily perfectly achieving that goal immediately. STEPH: I think that's a nice representation of essentially how you and I have processed things. We've highlighted before that you and I...it's funny, I just made the joke about not talking to people, but it's how I actually process stuff. And the best is when I'm talking out loud to somebody else. And so it totally makes sense that as you were noticing this and reflecting on it, that then this is another way that you are then processing those changes and reflecting on it and thinking through is this a good change? Is it something that I'm going to enjoy? Or am I really going to miss my street coding creds? I need to get back to the editor. CHRIS: I just need that precious flow state that comes from drinking some Mountain Dew and coding for hours. STEPH: Do you drink Mountain Dew? CHRIS: No, I gave it up years ago. STEPH: [laughs] CHRIS: I don't drink soda broadly. But if I'm going to drink soda, it's going to be Mountain Dew because if we're going to do it, let's do this thing. I'm pretty sure that stuff is like thermonuclear, but that's fine. STEPH: [laughs] That's funny. I know we've had this conversation before also around Pop-Tarts where you're like, hey, if I'm going to have a Pop-Tart, I'm going to have the sugariest (Is that a word - sugariest?) Pop-Tart possible. CHRIS: To be clear, that means it has icing on it because some people in the world, namely you, would prefer the ones without icing. Although we recently learned that the ones without icing have a higher fat and calorie content, so I don't know. The world's murky. I wish it were all just clear, and we could just work with it. But it turns out even Pop-Tarts icing versus not is not a simple question. STEPH: It's a very simple question. You just need to be on the right side, which is the non-frosted side. [laughs] I can simplify this for you because fat is delicious. Fat trumps sugar; that's my stance. That's my hot take. CHRIS: I'm saying both, a little from column A, a little from column B. You got yourself a stew. STEPH: [laughs] You got a fat sugar stew. CHRIS: Yeah. That was in Arrested Development. All right, we're veering way off course now. [laughter] To bring it back, what you were highlighting of I'm definitely someone who thinks through stuff by talking out loud, and so it's been wonderful. I've learned so much about myself while talking to you on this podcast. I'll say something, and I'll be like, wait, I actually believe that thing I just said. This is fantastic. Now I can move forward with the knowledge that I've just gained for myself by talking about it on a podcast. So highly recommended: everybody should get a podcast. STEPH: Plus one. I also have a very real, maybe silly, follow-up question for you as we are, like you just said, exploring the things that we believe or not. My question for you is part of the transition to management and moving away from coding. Isere some fear in the back of your mind where you're like, if I stopped coding, I'm going to lose this skill? CHRIS: Honestly, no. And I feel kind of bad saying that because I feel like I should say, "Yeah, I feel like it'll fade away and whatnot." But I think I have an aptitude and an interest towards this work. And if I were to ignore it for two years, then frankly, I also know myself. And I'm still going to keep an eye on everything for a while. So I think I'll be aware of what's going on and maybe just haven't spent as much time with it. But I think if I need to two years from now, I'm like, all right, I got to rebuild my coding muscle. I'll skip a couple of JavaScript frameworks, which will be nice, and I'll be on to the 15th iteration that's new now. But I hope that I could revisit that not trivially, not with no effort. It's the wonderful nature of coding. It's one of the things that I love about it so much is that there are blog posts and YouTube tutorials. And it's so individually discoverable that I'm not really worried about that aspect. My concern, if anything, isn't so much that I'm going to lose my skills or not be able to code anymore; it's that I really enjoy coding. It's a practice that I find very enjoyable. A workweek is enjoyable when it contains big blocks of me putting on my headphones, listening to music, and digging into a problem, and then coding and producing a solution. And those tiny little feedback loops of test-driven development or running something and then going to the browser and clicking around like that, there's a directness there that has always really worked well for me. And so the more I'm abstracted away from that sort of thing, and the more of my work is I'm helping a team, and I'm directing strategy, or whatever it is, that just feels so indirect. And so I'm very interested to find out how I respond to that sort of thing. I've definitely enjoyed it in the past, and so that's why I'm intentionally leaning into it. But I know that I'm giving up a part of the work that I really love, and giving up is too strong of a word as well. I'm going to find what shape makes sense moving forward. And I expect I'll still be pairing with the other developers on the team and helping to define architecture and things like that. So it's not like it's 100% gone. But for now, I think the world where most of my week was spent coding is no longer the case. And so just naming that and being intentional about it. And yeah, that's the game. STEPH: Cool. Yeah, that makes a lot of sense. I was mainly interested in that question because that is a question that I've asked myself from time to time that I think I do have that worry that if I step away from coding for too long, then it won't be easy to jump back into. And I've talked myself out of that many times because I don't think it's true for all the reasons that you just said. But it is something that I have considered as like, well, if I take this leap of faith into this other direction, how easy is it for me to get back if I decide to change my mind and go back to being more of an individual contributor? And one other thing that weighs on me as I'm splitting my time between two areas that I really want to grow…So I'm constantly trying to grow as a developer. I'm also trying to grow as a manager, and I don't want to do a bad job at either. I want to do a great job at both, and that's frankly not always possible. And at times, I have to make trade-offs with myself around okay, I'm going to focus a little heavier this day or this week on being a really great manager or focus a little bit more on being a developer and to pick and choose those topics. And then that sometimes means doing like B+ work in one area, and that's really hard for me. I'm an A-work person. So even downgrading to a B+ level of effort is challenging. But I have found that that's a really great space to be because then I'm doing well in both areas, not perfect, but doing well enough. And often, that's really what counts is that we're doing well enough and still pursuing growth in the areas that are important to us. CHRIS: Yeah, I think that intentional switching back and forth between them is the space that I'm in. I expect my work will remain very technical, and I hope that that's true. And I think to a certain extent; I get to shape it and determine that. And so how much of it is strategy and planning and things like that? Versus how much of it is helping the team with architecture and defining processes as to how we code, and what are our standards, and what are our languages and frameworks and all of that? I expect I'm still going to be involved in the latter. And again, I think to a certain extent; I get to choose that. So I am actually interested to see the shape that both naturally the organization needs out of the role that I'm in. But also, what sort of back pressure I can apply and be like, but this is how I want it to be. Is there room for that, or is there not? And it's all an experiment, and we're going to find out. But personally, for me, I'm going to keep reading Twitter and blog posts every day, and I'm probably going to code on the weekends and things. So the idea of my coding muscle atrophying, I don't know, that one doesn't feel true. But we'll see what I have to say a year from now or after what that looks like. But I expect...this has been true of me for so long, even when I had an entirely different career that I was just reading blogs and other things all the time because this is a thing that deeply interests me. So we will see. STEPH: Yeah, I'm excited to hear how it goes. And I think there's something to be said for the fact that you are also a CTO that's very close to the work that's being done. So being someone that is very involved in the technical decisions and the code that's being written but then also taking on more of the management responsibilities. And that feels more of a shift where you still have a lot of your coding skills. And you are writing code day-to-day at least based on what you're saying, but then you are also acquiring a lot of these management skills to go along with it. Versus if someone were going into management and maybe they're at a really large company and then they are very far away from the development team. And they're focused on higher-level themes and discussions, at least that's my guess. But I'm very excited to hear more about your updates and how this experiment is going and to find out who is the true Chris? CHRIS: Who's the true Chris? That feels complicated. I feel like I contain multitudes. But yeah, you know what? I'm excited to find out as well. Let's see what's going on there. But yeah, so that's a grand summary of the things that are going on in my head. And I expect these are topics that will be continuing to evolve for me. So I think we'll probably have more conversations like this in the future but also some tech stuff. Because like I said, I don't know, I can't stop. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Yeah, that's actually the perfect segue as we were talking earlier about just ways that we're looking to grow as developers. And I saw something that I really enjoyed, and it's published by another thoughtboter. Their name is Matheus Richard. And Matheus runs a Twitter account that's called @RubyCards. And I don't recall the exact cadence, but every so often, Matheus will share a new snippet of either Ruby or Rails code and then will often present the information as a question. So I'll give you an example, but the highlight is that it teaches you something, either about Ruby or Rails. Maybe you already knew it, maybe you didn't. But it's a really nice exercise to think through okay, I'm reading this code. What do I think it's going to return? And then respond to this poll and then see how other people did as well. Because once the poll closes, then Matheus shares the actual answer for the question. So one example that I saw recently highlights Ruby's endless method definition, which was introduced in Ruby 3. So that would be something like def, and then let's say the method name is message. And then you have closing, but empty parenthes equals a string of "Hello, World." And so then the question is if you call that method message, what would that return? And then the poll often has options around; it would return "Hello World," or it's going to return a syntax error. It's going to return nil. And then it highlights, well, because of Ruby's endless method definition, this would return "Hello, World." And then I also saw a new method that I hadn't used before that's defined in Ruby's Hash class that's called store. And so you can use it calling it on a Hash. So if you have your hash equals and then curly brackets, let's say foo is equal to an integer of zero, then you can call hash.store and then pass in two arguments. The first argument's going to be the key. The second argument is the value. And then, that would essentially be the same syntax that we use for assigning a value to a hash. But I just hadn't actually seen the method store before. So there are fun snippets of Ruby or Rails code. A little bit of a brain teaser helps you think through how that code works, what it's going to execute, what it's going to return. And I really enjoy it. I'll be sure to include a link to it in the show notes so other people can check it out. CHRIS: Oh, that sounds fun. I hadn't seen that, but I will definitely be following. That's the word on Twitter, right? You have subscribing, subscribe and follow, smash that like button, all of the things. I will do all of the things that we do here on the internet. But I do like that model of the question and answer, and it's slightly more engaging than just sharing the information. So yeah, super interested to see that. STEPH: Yeah, I like the format of here's some code, and then we're going to ask you what does it return? So that way, you get a moment to think it through. Because if I read something and it just shows me the answer, my brain just doesn't absorb it. And I'm like, okay, that makes sense, and my brain quickly moves on. But if I actually have to think about it and then respond with my answer, then it'll likely stick with me a lot longer. At least we'll find out; that's the dream. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: 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,; maybe as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.) Steph needs some consulting help. So much to do, so little time. Sarah Drasner tweet about shared element transitions (https://twitter.com/sarah_edo/status/1431282994581413893) Article about Page Transitions API (https://developer.chrome.com/blog/shared-element-transitions-for-spas/) Svelte Crossfade layout demo (https://svelte.dev/repl/a7af336f906c4caab3936972754e4d6f?version=3.23.2) Svelte Crossfade tutorial page (https://svelte.dev/tutorial/deferred-transitions) (Note - click "Show Me" on the bottom left) Transcript: CHRIS: I have restarted my recording, and we are now recording. And we are off on the golden roads. Isn't software fun? STEPH: Podcast battle. Here we go! Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been? CHRIS: Happy Friday to you as well. My week's been good with the exception of right before we started this recording, I had one of those experiences. You know the thing where software is bad and software is just terrible overall? I had one of those. And very briefly to describe it, I started recording, but I could hear some feedback in my headphones. So I was like, oh no, is that feedback going to show up on the final recording? Which I really hope it doesn't. Spoiler alert - listener, if I sound off, sorry about that. But so I stopped recording and then I went to go listen to the file, and I have our audio software configured to record directly to the desktop. And it does that normally quite well. But for some reason, the file wasn't there. But I remember this recently because I ran into it another time. For some reason, this is Finder failing me. So the thing that shows me the files in a graphical format, at least on my operating system. Although I think it also messes up in the terminal maybe. That feels like it shouldn't be true, but maybe it is. Anyway, I had to kill all Finder from the terminal to aggressively restart that process. And then suddenly, Finder was like, oh yeah, there's totally files there, absolutely. They were there the whole time. Why do you even ask? And I know that state management is a hard problem, I am aware. I have felt this pain. I have been the person who has introduced some bugs related to it, but that's not where I want to experience it. Finder is one of those applications that I want to just implicitly trust, never question whether or not it's just sneakily telling me that there are files that are not there or vice versa. So anyway, software. STEPH: I'm worried for your OS. I feel like there's a theme lately [chuckles] in the struggles of your computer. CHRIS: On a related note, I had to turn off transparency in my terminal because it was making my computer get very hot. [chuckles] STEPH: Oh no, you're not a hacker any more. CHRIS: I'm not. [chuckles] I just have a weird screen that's just dark. And jellybeans is my color scheme, so there's that going on. That's in Vim specifically. Pure is my prompt. That's a lovely little prompt. But lots of Day-Glo colors on just a black background, not the cool hacker transparency. I have lost some street cred. STEPH: What is your prompt? What did you say it is? CHRIS: Pure. STEPH: Pure, I don't know that one. CHRIS: It is by Sindre Sorhus; I think is his name. That's his Twitter handle, GitHub name. He is a prolific open-source creator in the Node world, particularly. But he created this...I think it's a Bash and a Zsh prompt. It might be for others as well. It's got a bunch of features. It's pretty fast. It's minimal. It got me to stop messing around with my prompt, which was mostly what I was going for. And it has a nice benefit that occasionally now I'll be pairing with someone, and I'll be like, "Your prompt looks like my prompt. Everything is familiar. This is great." STEPH: Well, if you get back in the waters of messing around with your prompts again, I'm using Starship. And I hadn't heard of Pure before, but I really like Starship. That's been my new favorite. CHRIS: Wow. STEPH: Wow. CHRIS: I mean, on the one hand… STEPH: You're welcome. [laughs] CHRIS: On the one hand, thank you. On the other hand, again, let me lead in with the goal was to stop messing around with my prompt. So you're like, oh, cool. Here's another prompt for you, though. [chuckles] STEPH: [laughs] But my goal is to nerd snipe you into trying more things because it's fun. CHRIS: I don't know if you know this, but I am impervious to nerd sniping. STEPH: [laughs] CHRIS: So try as you might, I shall remain steady in my course of action. STEPH: Are we playing two truths and a lie? Is that what we're doing today? [laughs] CHRIS: Nah, just one lie. It's easier. Everybody wins one lie. STEPH: [laughs] CHRIS: But anyway, in other news, we're going to do a segment called this really grinds my gears. That's today's segment, which is much like when I do a good idea, terrible idea. But this is one that I'm sure I've talked about before. But there's been some stuff that I saw moving around on the internet as one does, and it got these ideas back into my head. And it's around the phrase single-page application. I am not a fan of that phrase or SPA as the initialism. Thank you, Edward Loveall, for teaching me the difference between an initialism and an acronym. I really hope I'm getting it right, by the way, [laughs] SPA as people call them these days. I feel weird because of how much I care about this thing, how much I care about this idea, and how much whenever I hear this acronym, I get a little bit unhappy. And so there's a part of it that's I really do think our words shape our thinking. And I think single-page application has some deeply problematic ideas. Most notably, I think one of the most important things about building web applications is the URL. And those are different pages, at least in my head. I don't know of a different way to think about this. But if you are not emphasizing the URL and the fact that the URL is a way to address different pages or resources within your application, then you are throwing away one of the greatest advancements that humankind has made, in my mind. I care a lot about URLs; it turns out. And it's not inherent to an SPA that you will not be thinking about URLs. But again, in that idea that our words shape our thinking, by calling it an SPA, by leaning into that idea, I think you are starting down a path that leads to bad outcomes. I'm going to pause there because I'm getting kind of ranty. I got more to say on the topic. But what do you think? STEPH: Yeah, these are hot takes. I'm into it. I'm pretty sure that I know why URLs are so important to you and more of your feelings around why they're important. But would you dive in a bit deeper as to why you really cherish URLs, and why they're so important, and why they're one of the greatest advancements of humanity? CHRIS: [laughs] It sounds lofty when you say it back to me, but yeah. It's interesting that as you put into a question, it is a little bit hard to name. So there are certain aspects that are somewhat obvious. I love the idea that I can bookmark or share a given resource or representation of a resource very simply. Like the URL, it's this known thing. We can put hyperlinks in a document. It's this shared way to communicate, frankly, very complex things. And when I think of a URL, it's not just the domain and the path, but it's also any query parameters. So if you imagine faceted search on a website, you can be like, oh, filter down to these and only ones that are more than $10, and only ones that have a future start date and all those kinds of nuance. If you serialize that into the URL as part of the query param, then that even more nuanced view of this resource is shareable is bookmarkable is revisitable. I end up making Alfred Workflows that take advantage of the fact that, like, oh, I can look at this URL scheme, and I can see where different parts are interpolated. And so I can navigate directly to any given thing so fast. And that's deeply valuable, and it just falls naturally out of the idea that we have URLs. And so to not deeply embrace that, to not really wrap your arms around it and give that idea a big hug feels weird to me. STEPH: Yeah, I agree. I remember we've had this conversation in the past, and it really frustrates me when I can't share specific resources with folks because I don't know how to link to it. So then I can send you a link to the application itself to the top URL. But then I have to tell you how to find the information that I thought was really helpful. And that feels like a step backward. CHRIS: Yeah. That ability to say, "Follow this link, and then it will be obvious," versus "Go to this page, click on this thing, click on the dropdown, click on this other thing." Like, that's just a fundamentally different experience. So one of the things that I saw that got me thinking about this was I saw folks referring to single-page applications but then contrasting them with MPAs, which are multiple-page applications. STEPH: So the normal application? [laughs] CHRIS: And I was like, whoa, whoa, everybody. You mean like a website or a web app? As much as I was angry at the first initialism, this second one's really getting me going. But it really does speak to what are we doing? What are we trying to build? And as with anything, you could treat this as a binary as just like there are two options. There are either websites which, yeah, those have got a bunch of URLs, and that's all the stuff. And then there are web apps, and they're different. And it's a bundle of JavaScript that comes down, boots up on the client, and then it's an app thing. And who cares about URLs? I think very few people would actually fall in that camp. So I don't really believe that there is a dichotomy here. I think, as always, it's a continuum; it's a spectrum. But leaning into the nomenclature of single-page application, I think pushes you more towards that latter end of the spectrum. I think there are other things that fall out of it. Like, I believe deeply in having the server know more, have more of the logic, own more of the logic, own more authorization and routing, and all of those things because really great stuff falls out of that. And that one has more of a trade-off, I'd say. But I won't name any names, but there is a multiple billion-dollar company whose website I had to interact with recently. And you land on their page on their marketing site. And then, if you click log in, it navigates you to the application, so a separate domain or a separate subdomain, the application subdomain, and the login page there. And the login page renders, and then I go to fill in my username and password. Like, my mouse makes it all the way to click on the little box or whatever I'm doing if I'm using keyboard things. But I have enough time to actually start to interact with this page. And then suddenly, it rips away, and it actually just renders the authenticated application because it turns out I was already logged in. But behind the scenes, they're doing some JWT dance around that they're checking; oh no, no, you're already logged in, so never mind. We don't need to show you the login page, but I was already on the login page. And my feeling is this sort of brittle UI; this sort of inconsistency erodes my trust in that application, particularly when I'm on the login page. That is a page that matters. I don't believe that they're doing anything fundamentally insecure. But I do have the question in my head now. I'm like, wait, what's going on there, everybody? Is it fine? Was that okay? Or if you see something that you shouldn't see and then suddenly it's ripped away from you, if you see half of a layout that's rendered on a page and then suddenly you see, no, no, no, you actually don't have access to that page, that experience erodes my trust. And so, I would rather wait for the server to fully resolve, determine what's going to happen, and then we get a response that is holistically consistent. You either have access, or you don't, that sort of thing. Give me a loading indicator; give me those sorts of things. I'm fine with that. But don't render half of a layout and then redirect me back away. STEPH: I feel like that's one of the problems with knowing too much because most people are not going to pick up on a lot of the things that you're noticing and caring deeply about where they would just see like, oh, I was logged in and be like, huh, okay, that was a little weird, but I'm in and just continue on. Versus other folks who work very closely to this who may recognize and say, "That was weird." And the fact that you asked me to log in, but then I was already logged in, did you actually log me in correctly? What's happening? And then it makes you nervous. CHRIS: Maybe. Probably. But I wonder…the way you just said that sounds like another dichotomy. And I would say it's probably more of a continuum of an average not terribly tech-savvy user would still have a feeling of huh, that was weird. And that's enough. That's a little tickle in the back of your brain. It's like, huh, that was weird. And if that happens enough times or if you've seen someone who uses an application and uses it consistently, if that application is reasonably fast and somewhat intuitive and consistent, then they can move through it very quickly and very confidently. But if you have an app that half loads and then swaps you to another page and other things like that, it's very hard to move confidently through an application like that. I do think you're right in saying that I am over-indexed on this, and I probably care more than the average person, but I do care a lot. I do think one of the reasons that I think this happens is mobile applications came along, and they showed us a different experience that can happen and also desktop apps for some amount of time this was true. But I think iOS apps, in particular really great ones, have super high fidelity interactions. And so you're like, you're looking at a list view, and then you click on the cell for that list view. And there's this animated transition where the title floats up to the top and grows just a little bit. And the icon that was in the corner moves up to the corner, and it gets a little bigger. And it's this animated transition to the detailed view for that item. And then if you go back, it sort of deanimates back down. And that very consistent experience is kind of lovely when you get it right, but it's really, really hard. And people, I think, have tried to bring that to the web, but it's been such a struggle. And it necessitates client-side routing and some other things, or it's probably easiest to do if you have those sorts of technologies at play, but it's been a struggle. I can't think of an application that I think really pulls that off. And I think the trade-offs have been very costly. On the one positive note, there was a tweet that I saw by Sarah Drasner that was talking about smooth and simple page transitions with the shared element transition API. So this is a new API that I think is hoping to bring some of this functionality to the web platform natively so that web applications can provide that higher fidelity experience. Exactly how it'll work whether or not it requires embracing more of the single-page application, client-side routing, et cetera, I'm not sure on that. But it is a glimmer of hope because I think this is one of the things that drives folks in this direction. And if we have a better answer to it, then maybe we can start to rethink the conversation. STEPH: So I think you just said shared element transitions. I don't know what that is. Can you talk more about that? CHRIS: I can try, or I can make a guess. So my understanding is that would be that sort of experience where you have a version of a certain piece of content on the page. And then, as you transition to a new page, that piece of content is still represented on the new page, but perhaps the font size is larger, or it's expanded, or the box around it has grown or something like that. And so on mobile, you'll often see that animate change. On the web, you'll often see the one page is just completely replaced with the other. And so it's a way to have continuity between, say, a detailed view, and then when you click on an item in it, that item sort of grows to become the new page. And now you're on the detail page from the list page prior. There's actually a functionality in Svelte natively for this, which is really fancy; it's called crossfade. And so it allows you to say, "This item in the component hierarchy in the first state of the application is the same as this item in the second state of the application." And then, Svelte will take care of transitioning any of the properties that are necessary between those two. So if you have a small circle that is green, and then in the next state of the application, it's a blue rectangle, it will interpolate between those two colors. It will interpolate the shape and grow and expand it. It will float it to its new location. There is a really great version of it in the Svelte tutorial showing a to-do list. And so it's got a list on the left, which is undone things, and a list on the right that is done things. And when you click on something to complete it, it will animate it, sort of fly across to the other list. And if you click on it to uncomplete, it will animate it and fly back. And what's great is within Svelte because they have this crossfade as a native idea; all you need to say is like, "It was on this list, now it's on this list." And as long as it's identifiable, Svelte handles that crossfade and all the animations. So it's that kind of high-fidelity experience that I think we want. And that leads us to somewhat more complex applications, and I totally get that. I want those experiences as well. But I want to ask some questions, and I want to do away with the phrasing single-page application entirely. I don't want to say that anymore. I want to say URLs are one honking good idea. Let's have more of those. And also, just to name it, Inertia is a framework that allows me to build using some of the newer technologies but not have to give up on URLs, give up on server-side logic as the primary thing. So I will continue to shout my deep affection for Inertia in this moment once again. STEPH: Cool. Thanks. That was really helpful. That does sound really neat. So in the ideal world, we have URLs. We also have high fidelity and cool interactions and transitions on our pages. We don't have to give it a fancy name like single-page application or then multi-page application. I do wonder, with our grumpiness or our complaint about the URLs, is that fair to call it grumpy? CHRIS: It's fair to call it grumpy, although you don't need to loop yourself in with me. I'm the grump today. STEPH: [laughs] CHRIS: You're welcome to come along for the ride if you'd like. And I'm trying to find a positive way to talk about it. But yeah, it's my grumpytude. STEPH: Well, I do feel similarly where I really value URLs, and I value the ability to bookmark and share, like you said earlier. And I do wonder if there is a way to still have that even if we don't have the URL. So one of the things that I do is I'll inspect the source code. And if I can find an ID that's for a particular header or section on the page, then I will link someone to a section of that page by then adding the ID into the URL, and that works. It's not always great because then I have to rely on that being there. But it's a fix, it's a workaround. So I wonder if we could still have something like that, that as people are building content that can't be bookmarked or the URL doesn't change explicitly, or reference that content, to add more thoughtful bookmark links, essentially, or add an ID and then add a user-facing link that says, "Hey, if you want to link someone to this content, here you go." And under the hood, it's just an ID. But most people aren't going to know how to do that, so then you're helping people be able to reference content because we're used to URLs, so just thinking outside the box. I wonder if there are ways that we can still bookmark this content, share it with people. But it's okay if the URL isn't the only way that we can bookmark or reference that content. CHRIS: It's interesting that you bring that up, so the anchor being the thing after the hash symbol in the URL. I actually use that a ton as well. I think I built a Chrome extension a while back to try what you're saying of I'll inspect the DOM. I did that enough times that I was like, what if the DOM were to just tell me if there were an ID here and I could click on a thing? Some people's blogs...I think the thoughtbot blog has this at this point. All headers are clickable. So they are hyperlinks that append that anchor to the URL. So I wouldn't want to take that and use that functionality as our way to get back to URLs that are addressing resources because that's a way to then navigate even further, which I absolutely love, to a portion of the page. So thinking of Wikipedia, you're on an article, but it's a nice, long article. So you go down to the section, which is a third of the way down the page. And it's, again, a very big page, so you can link directly to that. And when someone opens that in their browser, the browsers know how to do this because it's part of the web platform, and it's wonderful. So we've got domains, we've got paths, we've got anchors, we've got query params. I want to use them all. I want to embrace them. I want that to be top of mind. I want to really think about it and care about that as part of the interface to the application, even though most users like you said, are not thinking about the shape of a URL. But that addressability of content is a thing that even if people aren't thinking of it as a primary concern, I think they know it when they...it's one of those like, yeah, no, that app's great because I can bookmark anything, and I can get to anything, and I can share stuff with people. And I do like the idea of making the ID-driven anchor deep links into a page more accessible to people because you and I would go into the DOM and slice it out. Your average web user may not be doing that, or that's much impossible to do on mobile, so yes, but only more so in my mind. [laughs] I don't want to take anchors and make them the way we do this. I want to just have all the URL stuff, please. Mid-roll Ad Now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. STEPH: I have a confession from earlier when you were talking about the examples for those transitions. And you were describing where you take an action, and then the page does a certain motion to let you know that new content is coming onto the page and the old content is fading away. And I was like, oh, like a page reload? We're just reimplementing a page reload? [laughs] That's what we have? CHRIS: You have a fancy, though. STEPH: Fancy, okay. [laughs] But that felt a little sassy. And then you provided the other really great example with the to-do list. So what are some good examples of a SPA? Do you have any in mind? I think there are some use cases where...so Google Maps, that's the one that comes to mind for me where URLs feel less important. Are there other applications that fit that mold in your mind? CHRIS: Well, so again, it's sort of getting at the nomenclature, and how much does the acronym actually inform what we're thinking about? But taking Google Maps as an example, or Trello is a pretty canonical one in my mind, most people say those are single-page applications. And they are probably in terms of what the tech actually is, but there are other pages in those apps. There's a settings page, and there's a search page, and there's this and that. And there's like the board list in Trello. And so when we think about Trello, there is the board view where you're seeing the lists, and you can move cards, and you can drag and drop and do all the fancy stuff. That is a very rich client-side application that happens to be one page of the Trello web app and that one being higher fidelity, that one being more stateful. Stateful is probably the thing that I would care about more than anything. And so for that page, I would be fine with the portion of the JavaScript that comes down to the client being a larger payload, being more complex, and probably having some client-side state management for that. But fundamentally, I would not want to implement those as a true client-side application, as a true SPA. And I think client-side routing is really the definition point for me on this. So with Trello, I would probably build that as an Inertia-type application. But that one page, the board page, I'd be like, yeah, sorry, this is not going to be the normal Inertia thing. I'm going to have to be hitting JSON endpoints that are specifically built for this page. I'm going to have a Redux store that's local. I'm going to lean into all of that complex state management and do that within the client-side app but not use client-side routing for actual page-level transitions, the same being true for Google Maps. The page where you're looking at the map, and you can do all sorts of stuff, that's a big application. But it is one page within the broader website, if you will. And so, I still wouldn't want client-side routing if I can avoid it because I think that is where I run into the most problems. And that thing I was talking about where I was on the login page for a second, and then I wasn't; I do not like that thing. So if I can avoid that thing, which I have now found a way to avoid it, and I don't feel like I'm trading off on that, I feel like it's just a better experience but still reserving the right to this part of the application is so complex. This is our Wiziwig drag and drop graphical editor thing, cool. That's going to have Redux. That's going to have client-side state management, all that stuff. But at no point does single-page application feel like the right way to describe the thing that we're building because I still want to think about it as holistically part of the full web app. Like the Trello board view is part of the Trello web app. And I want it all to feel the same and move around the same. STEPH: Yeah, that makes sense. And it's funny, as you were mentioning this, I pulled up Google Maps because I definitely only interact with that heavy JavaScript portion, same for Trello. And I wasn't even thinking about the fact that there are settings. By the way, Google Maps does a lot. I don't use hardly any of this. But you make a great point. There's a lot here that still doesn't need such heavy JavaScript interaction and doesn't really fit that mold of where it needs to be a single-page app or even needs to have that amount of interactivity. And frankly, you may want URLs to be able to go specifically to these pages. CHRIS: That actually is an interesting, perhaps counterpoint to what I'm saying. So if you do have that complex part of one of your applications and you still want URL addressability, maybe you need client-side routing, and so that becomes a really difficult thing to answer in my mind. And I don't necessarily have a great answer for that. I'm also preemptively preparing myself for anyone on the internet that's listening to this and loves the idea of single-page applications and feels like I'm just building a straw man here, and none of what I'm saying is actually real and whatnot. And although I try to...I think we generally try and stay in the positive space of like what's good on the internet. This is a rare case where I'm like, these are things that are not great. And so I think in this particular case, leaning into things that I don't like is the way to properly capture this. And giant JavaScript bundles where the entirety of the application logic comes down in 15-megabyte download, even if you're on 3G on a train; I don't like that. I don't like if we have flashes of a layout that they can get ripped away b; it'secause it turns out we actually aren't authorized to view that page, that sort of thing. So there are certain experiences from an end client perspective that I really don't like, and that's mostly what I take issue with. Oh, also, I care deeply about URLs, and if you don't use the URL, then I'm going to be sad. Those are my things. Hopefully, that list is perhaps a better summary of it than like...I don't want it to seem like I'm just coming after SPA as a phrase or a way of thinking because that's not as real of a conversation. But those particular things that I just highlighted don't feel great. And so I would rather build applications that don't have those going on. And so if there's a way to do that that still fits any other mold or is called whatever, but largely what I see called an SPA often has those sorts of edge cases. And I do not like those edge cases. STEPH: Yeah, I like how you're breaking it down where it's less of this whole thing like I can't get on board with any of it. You are focusing on the things that you do have concerns with. So there can be just more interesting, productive conversations around those concerns versus someone feels like they have to defend their view of the world. I have found that I think I'm a bit unique in this area where when people have a really differing opinion than mine, that gets me really excited because then I want to know. Because if I believe very strongly in something and I just think this is the way and then someone very strongly says like, "No, that's not," I'm like, "Oh yeah. Okay, we should talk because I'm interested in why you would have such a different opinion than mine." And so, I typically find those conversations really interesting. As long as everybody's coming forward to be productive and kind, then I really enjoy those conversations. CHRIS: That is, I think, an interesting frame that you have there. But I think I'm similar, and hopefully, my reframing there puts it in the way that can be a productive conversation starter as opposed to a person griping on a podcast. But with that said, that's probably enough of me griping on a podcast. [chuckles] So what's up in your world, Steph? STEPH: Oh, there are a couple of things going on. So I am in that pre-vacation chaotic zone where I'm just trying to get everything done. And I heard someone refer to it recently as going into a superman or superwoman mode where you're just trying to do all the things before you go, which is totally unreasonable. So that has been interesting. And the name of the game this week has been delegate, delegate, delegate, and it seems to be going fairly well. [chuckles] So I'm very excited for the downtime that I'm about to have. And some other news, some personal news, Utah, my dog, turns one. I'm very excited. I'm pretty sure we'll have a dog birthday party and everything. It's going to be a thing. I'll share pictures on Twitter, I promise. CHRIS: So he's basically out of the puppy phase then. STEPH: Yeah, the definition for being a puppy seems to be if you're a year or younger, so he will not be an adult. Teenager? I don't know. [laughs] CHRIS: What about according to your lived experience? STEPH: He has calmed down a good bit. CHRIS: Okay, that's good. STEPH: He has gotten so much better. Back when we first got him, I swear I couldn't get 15 minutes of focus where he just needed all the attention. Or it was either constant playtime, or I had to put him in his kennel since we're using that. That was the only way I was really ever getting maker's time. And now he will just lounge on the couch for like an hour or two at a time. It's glorious. And so he has definitely calmed down, and he is maturing, becoming such a big boy. CHRIS: Well, that is wonderful. Astute listeners, if you go back to previous episodes over the past year, you can certainly find little bits of Utah sprinkled throughout, subtle sounds in the background. STEPH: He is definitely an important part of the show. And in some other news, I have a question for you. I'm in need of some consulting help, and I would love to run something by you and get your thoughts. So specifically, the project that I'm working on, we are always in a state where there's too much to do. And even though we have a fairly large team, I want to say there's probably somewhere between 7 and 10 of us. And so, even though we have a fairly...for thoughtbot, that's a large team to have on one project. So even though there's a fair number of us, there's always too much to do. Everything always feels like it's urgent. I can't remember if I've told you this or not, but in fact, we had so many tickets marked as high priority that we had to introduce another status to then indicate they're really, really high, and that is called Picante. [chuckles] CHRIS: Well, the first part of that is complicated; the actual word that you chose, though, fantastic. STEPH: I think that was CTO Joe Ferris. I think he's the one that came up with Picante. So that's a thing that we have, and that really represents like, the app is down. So something major is happening. That's like a PagerDuty alert when we get to that status where people can't access a page or access the application. So there's always a lot to juggle, and it feels a lot like priority whiplash in terms that you are working on something that is important, but then you suddenly get dragged away to something else. And then you have to build context on it and get that done. And then you go back to the thing that you're working on. And that's a really draining experience to constantly be in that mode where you're having to pivot from one type of work to the other. And so my question to you (And I'll be happy to fill in some details and answer questions.) is how do you calm things down? When you're in that state where everything feels so urgent and busy, and there's too much to do, how do you start to chip away at calming things down where then you feel like you're in a good state of making progress versus you feel like you're just always putting out fires or adding a band-aid to something? Yeah, that's where I'm at. What thoughts might you have, or what questions do you have? CHRIS: Cool. I'm glad you brought an easy question that I can just very quickly answer, and we'll just run with that. It is frankly...what you're describing is a nuanced outcome of any number of possible inputs. And frankly, some of them may just be like; this is just the nature of the thing. Like, we could talk about adding more people to the project, but the mythical man-month and that idea that you can't just throw additional humans at the work and suddenly have that makes sense because now you have to coordinate between those humans. And there's that wonderful image of two people; there's one line of communication. Three people, suddenly there are a lot more lines of communication. Four people, wow. The exponential increase as you add new people to a network graph, that whole idea. And so I think one of the first questions I would ask is, and again, this is probably not either/or. But if you would try and categorize it, is it just a question of there's just a ton of work to do and we're just not getting it done as quickly as we would want? Or is it that things are broken, that we're having to fix things, that there are constant tweaks and updates, that the system doesn't support the types of changes that we want, so any little thing that we want to do actually takes longer? Is it the system resisting, or is it just that there's too much to do? If you were to try and put it into one camp or the other. STEPH: It is both, my friend. It is both of those camps. [chuckles] CHRIS: Cool. That makes it way easier. STEPH: Totally. [laughs] To add some more context to that, it is both where the system is resistant to change. So we are trying to make improvements as we go but then also being respectful of the fact if it is something that we need to move quickly on, it doesn't feel great where you never really get to go back and address the system in a way that feels like it's going to help you later. But then, frankly, it's one of those tools that we can use. So if we are in the state where there's too much to do, and the system is resisting us, we can continue to punt on that, and we can address things as we go. But then, at some point, as we keep having work that has slowed down because we haven't addressed the underlying issues, then we can start to have that conversation around okay; we've done this twice now. This is the third time that this is going to take a lot longer than it should because we haven't really fixed this. Now we should talk about slowing things down so we can address this underlying issue first and then, from now on, pay the tax upfront. So from now on, it's going to be easier, but then we pay that tax now. So it is a helpful tool. It's something that we can essentially defer that tax to a later point. But then we just have to have those conversations later on when things are painful. Or it often leads to scope creep is another way that that creeps up. So we take on a ticket that we think, okay, this is fairly straightforward; I don't think there's too much here. But then we're suddenly getting into the codebase, and we realize, oh, this is a lot more work. And suddenly, a ticket will become an epic, and you really have one ticket that's spiraled or grown into five or six tickets. And then suddenly, you have a person that's really leading like a mini project in terms of the scope of the work that they are doing. So then that manifests in some interesting ways where then you have the person that feels a bit like a silo because they are the ones that are making all these big changes and working on this mini-project. And then there's the other one where there's a lot to do. There are a lot of customers, and there's a lot of customization for these customers. So then there are folks that are working really hard to keep the customers happy to give them what they need. And that's where we have too much to do. And we're prioritizing aggressively and trying to make sure that we're always working on the top priority. So like you said, it's super easy stuff. CHRIS: Yeah. To say it sincerely and realistically, you're just playing the game on hard mode right now. I don't think there is any singular or even multiple easy answers to this. I think one question I would have particularly as you started to talk about that, there are multiple customers each with individualized needs, so that's one of many surface areas that I might look t say, "Can we sort of choke things off there?" So I've often been in organizations where there is this constant cycle of the sales team is going out. They're demoing against an InVision mock. They're selling things that don't exist. They're making promises that are ungrounded and, frankly, technically infeasible or incredibly complicated, but it's part of the deal. They just sold it, and now we have to implement it as a team. I've been on teams where that was just a continuing theme. And so the engineering team was just like, "We can never catch up because the goalpost just keeps moving." And so to whatever degree that might be true in this case, if there are ten different customers and each of them right now feels like they have an open line to make feature requests or other things like that, I would try to have the conversation of like, we've got to cut that off right now because we're struggling. We're not making the forward progress that we need to, and so we need to buy ourselves some time. And so that's one area that I would look at. Another would be scope, anywhere that you can, go into an aggressive scope cutting mode. And so things like, well, we could build our own modal dialogue for this, but we could also use alert just like the JavaScript alert API. And what are all of the versions of that where we can say, "This is not going to be as nice, and as refined, and as fitting with the brand and feel and polish of the website. But ways that we can make an application that will be robust, that will work well on all of the devices that our users might be using but saves us a bunch of development time"? That's definitely something that I would look to. What you described about refactoring is interesting. So I agree with we're not in a position where we can just gently refactor as we find any little mess. We have to be somewhat ruthless in our prioritization there. But like you said, when you get to that third time that a thing is working way harder, then take the time to do it. But really, like just every facet of the work, you just have to be a little better. If you're an individual developer and you're feeling stuck, raise your hand all the earlier because that being stuck, we don't have spare cycles right now. We need everybody to be working at maximum efficiency. And so if you've hit a wall, then raise your hand and grab somebody else, get a pair, rubber duck, whatever it is that will help you get unstuck. Because we're in a position where we need everybody moving as fast as they can. But also to say all of those aren't free. Every one of those where you're just like, yeah, do it the best you can. Dial it up to 11 on every front. That's going to drain the team, and so we have to also be mindful of that. This can't be forever. And so maybe it is bringing some new people onto the team or trying to restructure things so that we can have smaller communication channels. So it's only four people working together on this portion of the application, and therefore their communication lines are a bit simpler. That's one way that we can maybe save a little bit. But yeah, none of these are free. And so, we also need to be mindful that we can't just try harder forever. [laughs] That's a way to burn out the team. But what you're describing is like the perfect storm of every facet of this is difficult, and there's no singular answer. There's the theory of constraints (I think I'm saying that right.) where it's like, what's the part of our process that is introducing the most slowdowns? And so you go, and you tackle that. So if you imagine a website and the app is slow is the report that you're getting, and you're like, okay, what does that mean? And you instrument it, and you log some stuff out. And you're like, all right, turns out we have tons of N+1s. So frankly, everything else doesn't matter. I don't care if we've got a 3 megabyte JavaScript bundle right now; the 45 N+1s on the dashboard that's the thing that we need to tackle. So you start, and you focus on that. And now you've removed that constraint. And suddenly, the three megabyte JavaScript bundle is the new thing that is the most complicated. So you're like, okay, cool, let's look into tree shaking or whatever it is, but you move from one focus to another. And so that's another thing that could come to play here is like, which part of this is introducing the most pain? Is it feature churn? Is it unrealistic sales expectations? Is it developers getting stuck? And find the first of those and tackle it. But yeah, this is hard. STEPH: Yeah, it is. That's all really helpful, though. And then, I can share some of the things that we are experimenting with right now and then provide an update on how it's going. And one of the things that we're trying; I think it's similar to the theory of constraints. I'm not familiar with that, but based on the way you described it, I think they're related. One of the things that we are trying is breaking the group into smaller teams because there are between 7 and 10 of us. And so, trying to jump from one issue to the next you may have to really level up on different portions of the application to be able to make an impact. And there are areas that we really need infrastructure improvements and then essentially paving the way for other people to be able to move more quickly. We do have to prioritize some of that work as well. So if we break up into smaller teams, it addresses a couple of areas, or at least that's the goal is to address a couple of areas. One is we avoid having silos so that people aren't a bottleneck, or they're the only ones that are really running this mini-project and the only one that has context. Because then when that person realizes the scope has grown, bringing somebody on to help feels painful because then you're in an urgent state, but now you have to spend time leveling someone else up just so that they can help you, and that's tough. So the goal is that by having smaller teams, we will reduce that from happening because at least everything that feels like a small project...and by feels like a small project, I mean if we have more than one ticket that's associated with the same theme, that's going to start hinting at maybe this is more than just one ticket itself, and it might actually belong to an epic. Or there's a theme here, and maybe we should have two people working on this. And breaking people into groups, then we can focus on some people are focused more on the day-to-day activity. Some people are focused on another important portion of the codebase as we have what may be extracted. I'm going to say this, but we're going to move on, maybe extracted into its own service. [laughs] I know that's a hot one for us, so I'm just going to say it. CHRIS: I told you I can't be nerd sniped. This is fine. Let's continue on. [laughs] STEPH: [laughs] And then a small group can also focus on some of those infrastructure improvements that I was alluding to. So smaller teams is something that we are trying. We are also doing a really great job. I've been really happy and just proud of the team where folks are constantly reaching out to each other to say, "Hey, I'm done with my ticket. Who can I help?" So instead of immediately going to the backlog and grabbing the next thing. Because we recognize that because of this structure where some people are some silos, they have their own little mini backlog, which we are working to remove that to make sure everything is properly prioritized instead of getting assigned to one particular person. But we are reaching out to each other to say, "Hey, what can I do to help? What do you need to get done with your work before I go pick something else up?" The other two things that come to mind is who's setting the deadlines? I think you touched on this one as well. It's just understanding why is it urgent? Does it need to be urgent? What is the deadline? Is this something that internally we are driving? Is this something that was communicated without talking to the rest of the team? Is this just a really demanding customer? Are they setting unrealistic expectations? But having more communication around what is the sense of urgency? What happens if we miss this deadline? What happens if we don't get to this for a week, a month? What does that look like? And then also, my favorite are retros because then we can vote on what feels like the highest priority in terms of pain points or run these types of experiments like the smaller teams. So those are the current strategies that we have. And I'm very interested to see how they turn out because it is a tough way. Like you said, it's challenge mode, and it is going to burn people out. And it does make people feel fatigued when they have to jump from one priority to the next. So I'm very interested. It's a very interesting problem to me too. It just feels like something that I imagine a lot of teams may be facing. So I'm really excited if anybody else is facing a similar issue or has gone through a similar challenge mode; I'd love to hear how your team tackled it. CHRIS: Yeah, I'm super interested to hear the outcome of those experiments. As a slightly pointed question there, is there any semi-formal version of tracking the experiments? And is it just retro to retro that you're using for feedback on that? I've often been on teams where we have retro. We come up with it, and we're like, oh, this is a pain point. All right, let's try this. And then two weeks later, we're like, oh, did anyone actually do that? And then we just forget. And it's one of those things that I've tried to come up with better ways to actually manage, make slightly more explicit the experiments, and then have a timeline, have an almost scientific process of what's the hypothesis? What's the procedure? What are the results? Write up an executive summary. How'd it go? STEPH: We are currently using retro, but I like that idea of having something that's a bit more concrete. So we have action items. And typically, going through retro, I tend to revisit the action items first as a way to kick off retro. So then that highlights what did we do? What did we not do? What do we not want to do anymore? What needs to roll over to the current iteration? And I think that could be just a way that we chat about this. We try something new, and we see how it's going each week in retro. But I do like the idea of stating upfront this is what we're looking to achieve because I think that's not captured in the retro action item. We have the thing that we're doing, but we haven't captured this is what we hope to achieve by taking this experiment on. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: As for the other thing that you mentioned, I do have an idea for that because a former client that I worked with where we had experiments or things that we wanted to do, we were using Trello. And so we would often take those action items…or it was even more of a theme. It wasn't something that could be one-and-done. It was more of a daily reminder of, hey; we are trying this new thing. And so, we want to remind you each day to embrace this experiment and this practice. And so we would turn it into a Trello ticket, and then we would just leave it at the top of the board. So then, each day, as we were walking the board, it was a nice reminder to be like, hey, this is an ongoing experiment. Don't forget to do this. CHRIS: I do like the idea of bringing it into a stand-up potentially as like that's just a recurring point that we all have. So we can sort of revisit it, keep it top of mind, and discard it at some point if it's not useful. And if we're saying we're doing a thing, then let's do the thing and see how it goes. So yeah, very interested to hear the outcomes of the experiment and also the meta experiment framework that you're going to build here. Very interested to hear more about that. And just to say it again, this sounds like your perfect storm is not quite right because it doesn't sound like there's a ton of organizational dysfunction here. It sounds like this is just like, nah, it's hard. The code's not in perfect shape, but no code is. And there's just a lot of work to be done. And there are priorities because frankly, sometimes in the world, there are priorities, and you're sort of at the intersection of that. And I've been in plenty of teams where it was hard because of humans. In fact, that's often the reason of we're sort of making up problems, or we're poorly communicating or things like that. But it sounds like you're in the like, nope, this is just hard. And so, in a way, it sounds like you're thinking about it like, I don't know, it's kind of the challenge that I signed up for. Like, if we can win this, then there's going to be some good learnings that come out of that, and we're going to be all the better. And so, I wish you all the best of luck on that and would love to hear more about it in the future. STEPH: Thank you. And yeah, it has been such an interesting project with so many different challenges. And as you've mentioned, that is one area that is going really well where the people are wonderful. Everybody is doing their best and working hard. So that is not one of the competing challenges. And it is one of those; it's hard. There are a lot of external factors that are influencing the priority of our work. And then also, some external areas that we don't have control over that are forcing some of those deadlines where customers need something and not because they're being fussy, but they are themselves reacting to external deadlines that they don't have control over. So it is one of those where the people are great, and the challenges are just real, and we're working through them together. But it's also hard. But it's helpful chatting through all the different challenges with you. So I appreciate all of your thoughts on the matter. And I'll report some updates once I have some more information. On that note, shall we wrap up? CHRIS: Let's wrap up. STEPH: The show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I'm @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

CHRIS NEWBOLD: Hello, Well-being friends. Welcome to the Path to Well-Being in Law podcast, an initiative of the Institute for Well-Being in Law. Obviously, Chris Newbold here, executive vice president of ALPS Malpractice Insurance. We've been very clear on what our hope is for this podcast and that's to introduce you to people doing awesome stuff in the well-being space as we work to build and nurture a national network of well-being advocates intent on creating a culture shift within the profession. I am joined once again by my fantastic co-host, Bree Buchanan. Bree, how are you? BREE BUCHANAN: I'm doing great, Chris. And when you started, just there was a little bit of introduction of yourself, I realized we're well into our 17th or 18th episode of the podcast, which is really exciting. And I just want to let everybody know who we are a little bit again and why we're doing this if people didn't listen to the first episode. And Chris is a great podcast host, he's also an integral part of the Institute for Well-Being in Law, which is who is bringing you this podcast series. He's our vice president of governance and I have the great privilege of being the board president of the Institute. And so just giving you a message from that and the progress that we're doing is it's really exciting to be able to host this podcast, get more involved in communications and spreading the word about the work of the Institute and the well-being movement and getting ready for our annual conference in January of 2022. Lots is happening in regards to the Institute. And so, just a little message for our listeners there. CHRIS: And it's been a wonderful five to seven years since this movement started and there's been one constant in the development of this movement and it's been Bree Buchanan. In terms of being the original co-chair on the national task force on lawyer well-being, Bree has just invested countless hours to give back to the profession through this work and Bree, we're just so fortunate to have you and to continue to have your leadership of this movement. It's important and I just want you to know how much we all appreciate it. BREE: Thank you. I'm glad this is a podcast and not a video because I'm a redhead and I blush easy so I'm flaming red right now. Anyway, to our guest. CHRIS: Let's get to it. Let's get to our guest. Again, we love our guests because our guests are bringing interesting angles and I think it's so important that we think about the collective holistic sense of well-being. And one of the areas that I think really catapulted the movement was the fact that we could actually for the first time, based upon a couple of groundbreaking studies, that we could rely on data to drive the well-being movement. And again, we are an evidence based profession, so the ability for us to really kind of put some numbers behind and some statistics and some scientific nature to the well-being movement, I think it's been really critical in terms of catapulting what we've been working to do to engineer the culture shift. This is again, part two of our, kind of our research focus. We had Larry Krieger on previously and are really excited to introduce you and our listeners today to Matt Thiese. And so Bree, why don't I pass the baton to you to introduce Matt and kick off the podcast? BREE: Sure. Matt, Professor Thiese is really, I think the key position that he holds in the movement right now is to be a lead researcher and looking at what's happening with lawyers today in regards to their well-being and really assisting us getting that data so we know what to do, where to go, what to work on. Matt is an associate professor in the Rocky Mountain Center for Occupational and Environmental Health at the University of Utah. One of 18 centers funded by the Centers of Disease Control and Prevention across the US. He's deputy director for the center, director of the occupational injury prevention program and director of the targeted research training program. Matt has a PhD in occupational epidemiology, a Master's of science in public health and is a prolific writer, having co-authored 99 peer reviewed articles, 46 practice guidelines and 19 book chapters. Whew. Matt, welcome. CHRIS: Busy. Busy guy. MATT THIESE: Thank you very much. Thank you. I'm happy to be here. BREE: Yeah. I warned you a little bit, we have this question, first question we ask all our listeners about what brings you to this work because we found everybody has something that's driving their passion and for you, it's interesting because you're not a lawyer. You come out of the sort of the field of occupational health, which is a new kind of construct for me to think about all of this work that we're doing. Let me ask you the question, what in your life are the drivers behind the passion, your passion for this work? MATT: Sure. I'll start sort of broadly and then get into a little more specifics related to lawyer well-being but just generally occupational health and safety for me is really important. One of my first jobs was working as a mover. I worked as a mover for one day and working there it was during the summer between high school and college. And when you have people in the profession telling you, "Get out, go do something else. This will just tear you apart," it really makes you look and think and say, "Well, you're here, you're 50 years old. You've been doing this for 35 years. Why are you here?" And it's got to be able to be better. There needs to be a way to improve it. That's what got me into occupational health and safety originally and I've just really, really enjoyed it. MATT: We all spend so much time at work, whether we like it or not. And I think any way that you can make that healthier and safer is good for you as an individual but then it's also good for those around you, whether it's your business or your family or both. In terms of law specific, all of my interactions with lawyers have been really positive. And I know a bunch of lawyers. I know a lot of people who went to law school and decided not to actually go practice law and a lot of reasons that they cited were because of the mental challenges, the stress, the depression, that type of stuff. And then I have a neighbor across the street who was really involved and said, "Hey, we would like to be able to have some data to help guide decisions." And I said, "Hey, that's actually something that I know about. What can I do to help?" And that was in 2019 and we've just been off to the races since then. BREE: Wonderful. CHRIS: Again, thank you for your work. We're excited to kind of talk about some of your findings and your first foray into the legal space. Professor Thiese, talk to us about, you're an occupational epidemiologist. That's something that I certainly don't have on my resume. What sorts of things do you study? What's the goal of your work? MATT: Sure. And please call me Matt, unless I'm in trouble, then call me Matthew. And so as an occupational epidemiologist, before the pandemic, epidemiology, I'd say I'm an epidemiologist to people and they say, "Oh, so you study skin diseases? Or what exactly do you do?" The pandemic has been good in that sense, if there's any type of the silver lining, it has really helped highlight the importance of individual health and having data to make these types of decisions. I've done all sorts of different things. Another area of interest for me is transportation health and safety. Truck drivers have all sorts of different challenges. Some of them are oddly somewhat parallel to law professionals but there's all sorts of other things going on with them too. I do all sorts of stuff. Really anywhere your job overlaps with your health, whether that's physical, mental, looking at different types of exposures, chemical hazards, electrocution, slips, trips and falls, automobile crashes, interactions with clients and violence, all of that type of stuff. BREE: Yeah. Matt, you started to intersect with the legal community. I think it came about with the Utah Supreme Court's lawyer well-being task force and made a recommendation that there needed to be a study of their lawyers in their state to see what is sort of the condition of their well-being. And so how did you come to become a part of that? And what happened with that process? MATT: Sure. I don't think actually I am the person who came up with a recommendation. I think that really was the committee had the foresight to say, "Look, we don't even know where our attorneys are on the spectrum. How are we doing? Are there pockets of attorneys that are doing better or worse than others? Are there other individual factors, personal factors? Where do we stand? Basically, let's get a metric at the beginning and then can use that data to make informed decisions." And then I knew some lawyers who were on the committee and they came to me and said, "Hey, can you just come talk with us about this?" And I said, "Absolutely that's right up my alley." We started having a discussion about doing a baseline assessment piece of all lawyers, which then expanded to lawyers and law students and other law professionals like paralegals and legal secretaries to get a baseline. MATT: And then the plan was to do a subsequent followup or a series of follow-ups with those same individuals. In epidemiology terms, that's called a prospective cohort study. You're getting a group of people and then following them through time, that's better than just taking a snapshot at time at different time points of just a random representative sample. It's better to have the individual people. That was the plan. That was 2019. And then the pandemic hit and everything sort of went sideways in terms of being able to contact people in research and everyone's mental health. And now that we're sort of coming back out of that, we're planning on doing our first followup of the same group and then we're actually probably going to end up using that as our new sort of baseline data element, just because so many things have changed due to the pandemic. BREE: Yeah. And just to follow up, so it was the Utah state bar that actually commissioned for you to do the research, is that right? MATT: Correct. Correct. BREE: Okay, great. CHRIS: Matt, what was the lawyer study? Explain for our listeners, what was the objective? MATT: Sure. The objective was to identify, there were a couple. The first was to try and get as representative an assessment as we can of lawyers in Utah, practicing lawyers and in a whole range of areas. We have in our, and it was just a one time survey. It was done online at baseline. We asked about the big ones. Obviously depression, anxiety, burnout, alcohol use, other substance use and abuse. But then we also wanted to ask questions about other aspects of an individual's well-being. We asked about engagement, satisfaction with life, physical activity levels, chronic pain and chronic medical conditions, family life. And we wanted our goal was to keep it short so that we can get a lot of participants. And then also really once we have that baseline, look both within the lawyer population to see if we can identify pockets of individuals, whether that's the type of law they practice or their practice setting. One of the big questions that we had was is there a difference between urban and rural lawyers? That was one. MATT: And then we also used a lot of nationally validated questions and questions that are used nationally so that we could also compare Utah lawyers to general working populations or other large groups. It wasn't just sort of an echo chamber of saying, "Oh well, within Utah lawyers, this is what we see." But really be able to say, "Okay, Utah lawyers compared with general working population other lawyers in other states, what are the differences or what are similarities?" And then ideally, and we've been able to do this highlight sort of some of the challenges statistically to say, "Okay, this random chance? Or is this actually something that in epidemiology is statistically significant and that is beyond what we would expect just by random chance?" CHRIS: And what were your response rates just in terms of again, the scientific validity is always important in your field. I'm just kind of curious on what level of engagement you had from Utah legal professionals. MATT: Absolutely. I'm going to answer that in that sort of a three stage approach. Our first way of recruiting participants was to do a stratified random sample. We got the entire list of active bar members and randomly selected 200 who are rural and 200 who were urban. Send them email invitations asking them to participate. Our participation rate from just those email invitations was surprisingly high. Traditionally, if you were doing this type of a thing, you could get it participation rates in 20 or 30% would be great. We were upwards of 68% from all of those participants. We got a lot of participants that way. We also went to bar conventions and just set up a booth. I have a team of research assistants who were armed with iPads and during breaks or before meetings started and stuff, we just asked if people would be willing to participate, if they have not participated already. It took about our survey was only about five or six minutes long. We had a fair amount of people participating that way. MATT: And then our third route was actually having entire law firms come to us and say, "We would like to know where our firm stands. And not only that, we would like to know where everyone in our firm stands, not just our attorneys." We have 13 different firms of all varying sizes, who we invited to participate. And participation rate for that, depending on the firm was between, I think our lowest was 83% and our highest was 97 and change. Great participation rate. Being a scientist I said, "Okay, is there meaningful differences between these three groups?" Is there in an epidemiological term, is there a self selection bias? Are the people who were at the conferences more likely to participate? Or the people who were in the firms more likely to participate and vice versa? Looking at it, all three groups were statistically equal on almost every metric that I assessed. Not just not statistically different but statistically equal, so interchangeable from a statistical sense. I was nicely relieved and confident that this actually is a pretty good representation of what we have going on here in Utah. CHRIS: You can see you get commissioned, you want to be able to survey the Utah lawyer community. You want to figure out why this is happening and how they can best address the issue. You get great response rates. What did you find from the study? MATT: We're still analyzing stuff. Like any good researcher you want to, one, answering one question begets gets three more. But we're looking at several different things right now. One was looking at comparisons between amounts of depression and among Utah lawyers at compared with the general working population in the United States. We're comparing with individuals who are at least employed three-quarter time in the United States, compared with our attorneys and found that our attorneys are not doing very well. We're calculating odds ratios. An odds ratio of two, for example, means that you're twice as likely to have whatever outcome if you're part of that group. For us looking at depression, the diagnosis and I'm getting a little bit into the weeds here so I apologize, but likely having a diagnosis of a major depressive disorder, our attorneys in Utah were five and a quarter times more likely to have that level of depression as compared with the general working population. BREE: Wow, that's really significant. Just to underscore that, over five times the rate of depression of the general working population, is that right? MATT: Yeah, as compared to the general working population. And that was even after controlling for different, we call them confounders. Other factors that may play a role in that. Age differences or gender differences, other chronic medical conditions, that type of stuff. BREE: Yeah. Did you dig into gender differences? Is that something you are able to talk about at this point, a difference in depressive issues between men and women? MATT: Sure. Yeah, absolutely. In our data, lawyers were about, they were more likely. In general, our lawyers were more likely to be depressed. However, women were more likely to be depressed than men, which also parallels what you see in the general working population or in any other subsets of population. And I'm actually trying to find the exact number because being a scientist, I like to give you that full number. But it was meaningful. We also had our older attorneys were less likely to be depressed compared with the older general working population, which actually is also something that you would expect. It's called the healthy worker effect. And so people who are depressed tend to go try and figure out and solve their depression. Try and get into a better situation. Because everyone's spends so much of their time working, that's one of the common things is people choose a different profession or a different subset of their profession. That healthy worker effect also suggested that what we have here probably actually is a really solid data sample from which to draw some conclusions. CHRIS: Go ahead, Bree. BREE: Well, I know that this has been written up, there was an article in the Utah Bar Journal and then there was another peer reviewed article that I had read. And how has this been received? Do you have a sense that the bar people are surprised at the rate of sort of distress among their members? MATT: I'm going to say yes and no. I think that directionally, there was not a lot of surprise. Looking at ABA report and other research that's out there, it's yes, there is increased rates of depression, anxiety, suicide, alcohol abuse. Those are really the big ones. And I think generally everyone on the committee, in the Utah bar and probably most practicing attorneys say, "Yeah, that's totally believable." I think the part that really was most moving was the magnitude of that relationship. More than five times more likely to be diagnosed with a major depressive disorder but then it gets even worse when you look at the severe group. Our metric that we use is one that's commonly used, it's called the Patient Health Questionnaire 9, it's a nine question battery. It's been well validated to be related to more than 90% accurate for diagnosis of depression and major depressive disorder. The severe people are those who are contemplating suicide or have had suicidal attempts that they're at the far end of the spectrum. Our Utah attorneys were more than 18 times more likely to be in that category as compared to the general working population. BREE: Wow. MATT: Those magnitudes of numbers, when you think about, okay, relationship between things like smoking and lung cancer, you're about two and a half times more likely to get lung cancer if you smoke. We're talking 18 times more likely to be severely depressed if you're a Utah practicing attorney as compared to the general working population. BREE: Wow. CHRIS: Matt, on the front end, did either you or the task force go in with any kind of hypothesis to begin with? Or was this more designed as a kind of compare and contrast national data with state based data? MATT: Yeah, so I definitely did have some hypotheses going into it. One thing that was really great about this relationship with the state bar and the well-being committee was, they said, "This is your domain. These are things that we're curious about but you come up with your hypotheses, you develop the questionnaire." It was completely under my purview, which I think also helped with the recruitment aspect in that it was a recruiting effort done by me through the University of Utah. We used our institutional review board. Everything is strictly confidential, even going through, even with the firms, none of the firms received any individualized data or any potentially identifiable data. The bar does not get any of that. There's some benefits to that but in terms of actual hypotheses, yes. MATT: I mentioned that there potential relationship between the urban and the rural to see if there's differences in well-being there. Looking at different types of practice, whether criminal litigator or transactional law, so on and so forth, as well as looking at the size of the firm. Whether people are solo practitioners or part of a larger firm and trying to actually take all of that into account at once. If someone is a sole practitioner in criminal law in a rural setting, is that sort of just an additive effect in terms of challenges there? Or is it compounded? Or is it sort of somewhat mitigated? Being able to gather enough data to be able to identify some of those relationships was where we were going from the onset. MATT: And then also in my previous work in terms of other working populations and their mental well-being, I knew that things like physical activity, social support, both in the workplace as well as outside of the workplace can have a very positive aspect on both prevention, as well as treatment of mental challenges, mental health challenges. Those are some of the hypotheses that I had created going into this and was able to then tailor the questionnaire to address all of those, both like I said, internal comparisons, as well as comparing with other external groups like general working population. BREE: One of the things, Matt, that we are trying to do with the podcast is to sort of spread the word about strategies, ideas, policies, et cetera, that other state well-being taskforces can pick up and run with. And so a question, just how replicable is this process? You are doing this with Utah lawyers but say there is a task force in Colorado or another state that wanted to do this. Could they pick this up and deploy the same sort of survey for their bar members? MATT: Absolutely. I think not only the same survey, similar methods but then I've also, I've had some conversations with other states and other states have different challenges too. Being able to modify this and ask some other scientifically valid questions to address some of their sort of conceptual questions or anecdotal information that they may have. But it can easily be rolled out and it's something that I think is actually a lot of fun to do. BREE: Good. CHRIS: It feels like there'd be some benefit of actually having again, some standardization across the states that allow us to kind of compare states, yet providing them the ability to be able to narrowly tailor some questions that are specific to our state. Like for instance, I live in Montana, the plight of the solo rural practitioner is something that maybe kind of critically important to look at it relative to a state like Delaware where all the lawyers are kind of more concentrated. But yet it certainly feels like there'd be some benefit there. MATT: Yep. Absolutely. I wouldn't go as far necessarily as benchmarking. But I think that being able to have similarities as well as differences pointed out to say, and one thing, another thing that I've found in doing this research is that a lot of attention is paid to the negative side of things. Depression and anxiety, what are the big risk factors there? But there's the other side of the coin about, okay, who's being really successful? What are the people who are mentally healthy? What do they have in common? And then how can we help to reinforce that? And then, so being able to look within sort of some of those subsets too, can help provide more information. But I absolutely agree, having some similarities across different states would be able to sort of say, it answers that question, how systemic is this? Is this something that's more isolated to our bar? Or is this something that's more of a systemic question across the entire United States? And then how those may have different potential solutions, both on the positive and the negative side of the fence. CHRIS: Yeah. I think this is a good time for a quick break here from one of our sponsors. I would like to kind of come back, I think maybe after the break and maybe talk about whether all the data is grim. And whether there were some nuggets that you picked out of the Utah study. And then talking a little bit more about just kind of barriers to thriving in work in law firm environments and other legal environments. Let's take a quick break and we'll be back. Speaker 4: Meet VERA, your firm's virtual ethics risk assessment guide. Developed by ALPS, VERA's purpose is to help you uncover risk management blind spots from client intake, to calendaring, to cybersecurity and more. Speaker 5: I require only your honest input to my short series of questions. I will offer you a summary of recommendations to provide course corrections if needed and to keep your firm on the right path. Speaker 4: Generous and discreet, VERA is a free and anonymous risk management guide from ALPS to help firms like yours be their best. Visit VERA at alpsinsurance.com/vera. BREE: Welcome back, everybody. And we are here today with Professor Matt Thiese and talking about his study of the Utah bar population and also the potential of replicating that around the country. One of the things I saw, Matt, in the write up of your research that you got some information of barriers that were identified by your survey participants to thriving in their work. And I think that's really instructive for the rest of us. Could you talk a little bit about that? MATT: Sure, absolutely. In the survey we asked both, what are some things that help you thrive and enable you to be able to thrive in your work? As well as your barriers. And there were some consistent answers across all the different domains, regardless of age, gender, type of law practice, practice setting in terms of small firm, large firm, rural, urban. Challenges were actions of other attorneys at their firm or frustrations with opposing counsel. Those were two different obviously responses but talking about individual, other attorneys that they work with. Whether in an adversarial role or in a complimentary role. Others were billable hour requirements, client stress and or pressure. Just external pressure from clients and then inflexible court deadlines. Those were the big five sort of umbrella categories that prevented them from doing well or thriving in their job. CHRIS: And Matt, I think the other thing that I think is interesting about kind of going about a data driven approach, I think sometimes the fear is we get the data and then the data sits on the shelf. One of the things I love about what's happening in Utah is, the Utah state bar's well-being committee is now looking at really kind of more actionable plans to be able to kind of advance the well-being dialogue. And I know one of the things that they have you doing at this point is assessments for legal employers. Can you tell us a little bit more about that? MATT: Sure. That was sort of an organic thing that happened, that came about from this project with the state bar. The bar said, "Let's just get a sample of practicing attorneys in Utah and then go from there." Throughout that process though, we had several managing partners who came and said, "I would love my entire firm to take this and be a part of this." I was able to expand this to use firms, we have like I said, 13 different firms right now who are participating and we invited everyone in their firm to participate. Again, it went through the university so the firm doesn't get any individual information but we are providing information back in a aggregate form to be able to say, "This is where your firm stands and this is how your firm compares with other firms." And these other firms are de-identified. Your firm versus firm A, B, C and D who are comparative in size or that type of stuff, as well as the larger general population that we have participating. MATT: It's been really great. It's been well received. I think firms who are participating are sort of those firms that really want to do something better. They either have something in place and they want to assess how is this making a difference? Or they're thinking of getting something in place, and saying, "Where can we get the largest bang for our buck really?" And they're concerned about making sure that their lawyers are happier and healthier and therefore more productive, more likely to stay with the firm. And really it's a winning situation if you can identify those aspects where people in your firm need more help and then go to the evidence for what's out there to actually provide that. Does that make sense? BREE: Yeah. Yeah. Matt, you've got this background just sort of general long, wide view around occupational health. And so here you come to the specific part of the working population. You've got a little bit of data around lawyers. You're starting to hear some feedback around what's happening with legal employers. Just imagine we've got in your audience, some law firm managers, human resources staff for law firms, based on what you've learned so far do you have any advice to give them, to help them have thriving, successful lawyers? And as a result of that, a more profitable and successful firm? MATT: Right. Yes, in terms of based on what we've seen so far, there's definitely some things that can be done to improve. Taking a step back and saying, all right, I'm going to take an even bigger step back. We're generally have been focusing here on this discussion on depression, but there's a lot of other issues, burnout, anxiety. Looking at the evidence though, for those for prevention and treatment for those, there's some big things like individual therapy, medication, but there are challenges with those as well. There's cost barriers, the time for those both in terms of needed, if you're going to a therapist but then also medication takes, SSRIs, anti-anxiety and anti-depression medication takes three weeks to kick in. If you have someone who's depressed, three weeks can be an awfully long time. MATT: But some of the other treatments out there are actually really easy to implement and there's very little side effects. Two that I would highlight would be physical activity and we have data that's not published yet but found that if you're physically active meeting the standard of most days a week for at least 20 minutes of moderate to vigorous physical activity, so getting your heart rate up enough that you can't carry on a solid conversation, you have to sort of catch your breath, lawyers who were that level of physical activity, so four or five days a week, we're about a third, three times less likely we'll say it that way, three times less likely to have depression or anxiety. If they worked out six days or seven days, they were about between five times and seven times less likely to have depression and anxiety. MATT: Implementing some, and then there's all of the other benefits. Implementing some type of workout, moderate or vigorous workout activity is something that has demonstrated efficacy in other domains. And these preliminary data look like they would help. And then there's the cardiovascular benefits and all those that go along with it, as well as increased productivity after the physical activity, that's a whole other domain that we could talk about maybe at a different podcast. And then another thing is cognitive behavioral therapy and that's a treatment that sounds large and onerous but it's really just being able to approach problems differently and being able to think about things and it can be self directed or you can work with a therapist on it but it's pretty immediate in terms of results like physical activity but it's easy to do and it can help people, whether you're severely depressed, actually, if you're severely depressed, you should probably be seeking additional help beyond just cognitive behavioral therapy and physical activity but all the way to minimal or no depression. People are reporting better engagement, better focus after both physical activity and cognitive behavioral therapy. MATT: Those are two very specific. Maybe they're a little too specific for what you were going for. Other evidence out there in terms of mindfulness and meditation is somewhat mixed. Mindfulness, meditation, psychological capital, those all in general populations have been mixed efficacy but in attorneys, they may be more efficacious. CHRIS: And I'd love to kind of spend the final few minutes talking just a little bit about the replicability of what you've done in Utah in other, not just states, but either state bars, local bars, county bars, specialty bars. There are so many opportunities for us to continue to utilize survey techniques as a way to not just to engage and learn more about the constituencies that we serve. But as you know, surveys can also be great educational tools at the same time. And I just would love your perspective. If again, a lot of our listeners are members of task forces, they're advocates for well-being in their local communities, just how easy is it to kind of execute on a survey tool? Can anybody do it? Just your recommendations for the time, the cost, the structure, obviously when individuals like you have done it before, others have kind of learned on your dime, so to speak. And so I'd just love your perspective about the replicability of utilizing survey tools as part of our well-being strategy map. MATT: Absolutely. Ours was done almost exclusively online, so it's super easy to do. You can implement it. You can have actionable data in a matter of weeks. Ours was all done online and with a few exceptions, we had a couple of opportunities where individuals wanted to talk on the phone or do a paper copy. Email invitations, online data collection aspects in terms of even returning results, a lot of that has also been done online through video conferences and that type of stuff. The whole thing from soup to nuts I think is relatively easy to actually implement. MATT: One of the cautions that I do have though is making sure that it's scientific. Anyone can come up and create a questionnaire but to actually come up with a scientific question, a scientific survey that's using questions that have some validity and comparability is important. And then also your sampling technique. That's always a challenge in that when you're enrolling people, are there biases? Is there a selection bias like I mentioned earlier, where only people who are healthy enough to be participating, mentally healthy enough to be participating are participating? You therefore have a biased sample and any results from that would be either deeply discounted or practically useless. CHRIS: And are you interested in continuing to aid either institutions, entities, taskforces? I know that you've had limited work in the legal space but it sounds like you've enjoyed what you've done thus far. MATT: Yes. Short answer is absolutely yes. Can I give my email address and say reach out? CHRIS: Sure you can. MATT: Please, I would love to participate and help in any way I can, whether that's running the entire thing or anything sort of that. My email address is matt.thiese M-A-T-T dot T-H-I-E-S-E@hsc, for Health Sciences Center, .utah.edu. And I would love to help in any way that I can. Like I said, this is a career focus for me. I've done a lot of work in terms of mental well-being and psychosocial health in other domains. But I really, really enjoyed working with attorneys. I think that it's very, very important. And I think that there's a lot of opportunity here to actually do good. MATT: One of the things that you asked me before was how I fell into this. I was actually planning on going to medical school, was accepted in medical school and in talking with some of my mentors, they said, "You're great at science, you're great at epidemiology and you can actually do more good doing scientific research in epidemiology than seeing patients on a one on one basis and trying to get them to change their behavior." This is absolutely something that is my career focus and I want to help. Can I be more emphatic about it than that? CHRIS: This guy wants work. This guy wants work. MATT: No, and that's the thing, it's not necessarily work. I have a bunch of other stuff going on but in academia I have some of the ability because I'm not out, this is not a business, a profit making business for me. I obviously need to cover my time but I want to be able to help out. And so whatever. CHRIS: Well, I think it's interesting, Matt, and again, I think we should always try to end these on a high note that you've also tried to look at it in your Utah findings, what aspects of their job help them do well or improve their well-being. And I think it was, and I think these are tips for really any work environment, which is if you work in an environment in which you enjoy working with others, in which you're intellectually challenged, in which you have flexibility in your work schedule to some degree and that you know that your contributions are both recognized and valued, that that's a recipe to drive well-being higher. MATT: Absolutely. CHRIS: And those are things that anybody who sets the tone for a culture, anybody who's in HR, anybody who's in management, those are tips that go across industry. They're not unique to the legal environment but it is important in terms of just the notion of how we treat people ultimately drives whether they find their contributions and their commitment worthwhile and whether they will actually want to stay there or not. And those who don't generally then go down one path and those who do you generally have higher productivity, better results. All the reasons why corporate America has kind of I think generally leaned in on well-being as a creative to the bottom line. There's an economic element to it but also frankly, the right thing to do. MATT: Absolutely correct. All of those things that you listed really speak to engagement. And even in the data that we're seeing, you said, it generally leads to better productivity or generally leads to less turnover. I would say most of the data that's out there says it does. There's very few exceptions to that and it's just a matter of the magnitude of that relationship. Having people stay engaged and really that creativity, intellectual challenge, I think is one of the things that came up often helped and reduces, it sort of tempers the negative aspects of things and makes people more resilient and able to handle, less likely to burn out, less likely to be depressed, more likely to be productive. All of that great stuff. CHRIS: Matt, one final question, on the Utah study you've cited a couple times preliminary data. Is there a point in time in which preliminary goes to final data and something is released? MATT: Yes. The depression versus the general working population that we've talked about, those are final. We've looked at those, we're confident in those. In terms of preliminary data, we're looking at burnout and engagement. We're looking at substance abuse, alcohol abuse issues. We're looking at physical activity and then we're also doing similar things with students. The challenges with those are just being able to make sure that we're dotting all of our I's and crossing all of our T's from a scientific standpoint and making sure that we're taking everything into consideration there. And then it goes through a peer review process. We have three separate papers right now that are undergoing the peer review process and then several others that are nearly ready for that. And then dissemination, I would love to help have you guys help disseminate some of these findings and be able to continue to have a positive impact on attorney well-being. BREE: Absolutely. Matt, I'm so glad that you are on our team. Really important piece of this. Well, a wonderful 45 minutes or so with you, Matt. Thank you for spending your time today and dedicating so much of your energy and your expertise to helping us lawyers have to be more likely to thrive in our profession. And for our listeners, please join us again in the next couple of weeks, we'll be continuing our miniseries on those who are doing research and scholarship in the area of lawyer well-being. Thank you, everybody. Stay safe, be well. CHRIS: Thanks for joining us, Matt. MATT: Thank you. My pleasure.  

Transcript: CHRIS NEWBOLD: Hello, well-being friends and welcome to the Path to Well-Being in Law podcast, an initiative of the Institute for Well-Being in Law. I'm your co-host, Chris Newbold, Executive Vice President of ALPS Malpractice Insurance. Most of you are listeners. For those of you who are new to the podcast, our goal is pretty simple. It's to introduce you to thought leaders doing meaningful work in the well-being space within the legal profession and in the process to build and nurture a national network of well-being advocates intent on creating a culture shift within the profession. I want to introduce my co-host, Bree Buchanan. Bree, how have you been doing? BREE BUCHANAN: Wonderful, Chris. Great to be here. How are you? CHRIS: Bree, I think I heard that you had just come off some vacation doing some bicycling in my neck of the woods. Tell us a little bit more about where you went and why. BREE: Yeah. So I got to go with a group of friends out over to your neck of the woods in Montana, the Trail of the Hiawatha and the Trail of the Coeur d'Alenes and got to get some cycling in, which was just really wonderful. CHRIS: Awesome, awesome. Glad to hear you get off the grid and that's such an important part. My vacation is next week where I'll be with my family on a lake, just relaxing, and we all know that, that's an important part of recharging and being our best selves. BREE: Absolutely. CHRIS: Yeah, so we are again, super excited for today's podcast. We are wrapping up a three-part series looking at the interconnection of well-being in law schools. We have had Linda Sugin from Fordham Law School, we have had Jennifer Leonard from Penn Law, and today we are so excited to welcome Janet Stearns from the Miami School of Law. Bree, I know that you have a personal relationship with Janet, a friendship. I would love it if you could introduce Janet to our listeners. BREE: Absolutely. I'm delighted that we've got Janet here today. I'll give you the official introduction to Janet, but from a personal standpoint, Janet and I have been sort of on the front lines of working in this area, gosh, Janet, I don't know, six, seven years starting back with the ABA's Commission on Lawyer's Assistance Programs. Janet has been a true leader in that space. So let me give you the full introduction, and then we'll go ahead and hear more from Janet. BREE: Janet Stearns is the Dean of Students and a lecturer in law at the University of Miami Law School. Has been there since October 1999. In 2007, she was appointed Dean of Students. Since 2011, she's regularly taught professional responsibility. Last year, she received NALSAP's CORE Four Annual Award recognizing the competencies, values and ethics of the very best law student affairs professionals, and I absolutely agree with that. She is the immediate past chair for the AALS Student Services Section, and as I know her, a member of ABA CoLAP, and not only an advocate for wellness programming in the law schools, but has also been the Chair of the Law School Committee and has led all of those efforts for, I'd say at least five years. Since she became the Dean of Students, she has been passionate about wellness initiatives there at Miami, including the Fall Wellness Week, Spring Mental Health Day, and a weekly Dean of Students constitutional walk around the campus. Finally, I'm proud to say that she won the CoLAP Meritorious Service Award in November 2020. So Janet, so glad to have you here. How are you doing today? JANET STEARNS: Well, Bree, that's such a generous introduction. So I'm blushing a little now, but I am delighted to be here with you and Chris and looking forward to chatting. BREE: Great. So Janet, because I know you, and I know how dedicated you are to this, I think that you've probably got a really good answer to this question that we ask all of our guests because we know that people that are committed to the well-being movement often have a real passion for the work. So what experiences in your life are the drivers behind your passion for being such a leader in the well-being movement in law? JANET: Well, Bree, I think I've often, for a long time been really interested in my own personal well-being. As I think back on my own experience in law school, a classmate of mine, we decided to decaffeinate together in law school. Not many people do that, but we did. We went off coffee cold turkey and really just recognized it made us less jittery and that we could actually feel better and be more present for what was happening around us. I tell students that's just one example of how we can actually use the law school experience to think about our own well-being. JANET: But I think that certainly my work here at the University of Miami has brought me into a space where I have had to work and counsel way too many students who have been struggling. Struggling with drugs and alcohol and suicide. JANET: I have spoken many times about a student of ours, Katie Corlett, who died just shortly after her graduation, really, I think about the week before the bar results came out. In a time, many of us can remember and relate to of incredible and stress, and she died of a drug overdose, and it had a huge impact on me because I had worked so hard with her to get her through law school. I had gotten to know her parents so well, and the time that we spent shortly after the overdose visiting her in the hospital and just thinking of the huge opportunity that was lost for her and for us. That has stayed with me. I often do say, as I talk to other law schools about our programming and our more institutional initiatives, we do not want to have any more Katies. BREE: Right. JANET: We want to do everything possible so that we can see our students graduate and be happy and not have any more Katies. BREE: Yeah, absolutely. Wow. That's powerful. CHRIS: Yeah. I mean, as the Dean of Students, you certainly get a window into some of those challenges. Janet, tell us a little bit about ... We're all creatures of our own experience and we all recall our own law school days ... Give us a little flavor of Miami Law. The location and the size, the focus, anything that you find particularly unique about the culture that you've worked to build at Miami Law. JANET: Okay, Chris. Well, Miami Law, we are actually in Coral Gables. We are not in Miami. But Coral Gables is a suburb of Miami, and the University of Miami Law School has typically been on the larger side of law schools. This year we're probably going to be welcoming just under 400 students, 1L new students to our law school, but we have about 1,300 students. So we have JD students, and we also have a very large population of LLM students in many different programs, but our international LLM is bringing students from all over the world with a particularly large focus on Latin America. So it is a school where we have a lot of international diversity. Miami is just a very, at its nature, multilingual community, but there is a lot of Spanish that is spoken and Portuguese and other languages. JANET: We have a lot of first-generation students, Chris, and working families, first-generation students from our community. As we know, Miami has been all over the news for various reasons. But it is certainly a very dynamic community with a lot of temptations, cultural temptations, drug, alcohol, late-night partying. Miami Beach goes around the clock. It's against that backdrop that we are trying to encourage people to really both focus on their studies and focus on their well-being. BREE: Yeah. So over the time ... You've been at Miami Law a little bit over 20 years ... What are some of the mental health and well-being issues you've seen your students face? I mean, certainly Katie that you talked about is the worst case scenario, but just from my experience, I imagine you've seen a lot of other things that don't lead up to such a tragic end. JANET: Right. Well, Bree, I do think that Miami is a community where there is a lot of opportunity to focus on well-being, the good and the bad, as I said. There are, I think a lot of stresses and temptations, but I think there also are a lot of an incredible amount of natural beauty here. Beaches and opportunities to get into the outdoors and enjoy the tropical climate, the Everglades when people take advantage of that. We really work hard to model that for our students. JANET: I think that we have gone through certainly over time, our students face a lot of challenges. I do think that being in such an active and vibrant place and such a, from my perspective, a city that never sleeps, we have to work really, really, really hard from the beginning of orientation to try to model limits. Limits on your time, learning how to say no, learning the value of sleeping, learning the value of focus. The fact is that you're not going to be at every single event or movie or social or networking opportunity. There's just too much. So I think learning how to set limits from the very beginning is actually one of the things I talk about in our orientation message. JANET: I do think another well-being issue and one we were just discussing some, it is an expensive city. There is a lot of opportunities to go out and spend a lot of money. There's a lot of variation in housing that's expensive. So we have to work very early to try to help people to understand their financial budget and how to plan for their law school years in a way that will make sense and leave them where they still can feel in control as they graduate and move into the legal profession. So financial literacy is another important aspect of well-being and one that we try to also talk to our students about from the very beginning. BREE: Yeah. I'm glad you brought that up because that's not something that we really talked about. There's the six dimensions of well-being, but that financial piece of it, that financial dimension, can be such a heavy burden for the students. Sure. JANET: Right. Right. Then of course, I mean, Miami Law and the whole world has had the opportunity, I would say through this pandemic, to even talk more about well-being. Right, Bree. I know that when I was sent home in March 2020, the first thing that I brought home from my office with me was I have a framed copy of The Serenity Prayer next to my desk. BREE: Right. Wonderful. JANET: In March, there were many, many calls with deans and faculty and students, "What about this? And what about this?" I just said, "We're going to say our Serenity Prayer. We are going to try to figure out what we can control here and what we cannot and how to distinguish those things." I think actually as we model that, because our students and people around us see our own process of trying to figure those things out and yet trying to stay calm and make decisions through the pandemic, I think we've really taught some valuable lessons. BREE: I think The Serenity Prayer should be standard issue with your law school diploma. JANET: Absolutely. BREE: That would be helpful. JANET: It always does the trick for me. CHRIS: Janet, I'm curious, as you think about kind of the state of well-being in your law school, has it become more challenging? Has it improved? I mean, you have the context of kind of stability and seeing it over a longer period of time, but just curious on your reflections on at least within your school what kind of trends that you're seeing as it relates to well-being. JANET: That's such a great question, Chris. I think what's interesting if we go back, I don't know ... I think when I started to work with Bree with the CoLAP but I would say we've been involved in planning ... I probably have done a Fall Wellness Week since I first became Dean of Students in 2007. I had been working with the ABA CoLAP and the ABA Law Student Division on the Mental Health Day Initiative now for, I don't know, five, six, seven years. JANET: There was a point I think when we would announce Mental Health Day and everybody would be like, "What is that? Why?" I would say in the last few years, what I'm noticing is I have a lot of people around the country, deans of students at other schools, they're like, "When are you going to announce the Mental Health Day plans? When is it coming? What's the theme this year because we're putting it on our calendars." I think people are very, very eager to talk about this right now, Chris, at some level. Of course, then we just have to reflect on the events of the last week of the Olympics. I mean, it just feels like we are truly having a national conversation, thanks to the courage of Michael Phelps and Simone Biles and others. BREE: Absolutely. JANET: We are having a national conversation, and people are eager to have this conversation with us. So there is a level of attention and focus that can only be a good thing right now for the work that we're doing. CHRIS: Yeah, for sure. Talk to us about some of the well-being initiatives at Miami Law that you're most proud of. I mean, you talked about Fall Wellness Week. Talk to our listeners about some of the things that you have initiated and instituted there that you think are actually driving results. JANET: So I do think that the Fall Wellness Week has become a great catalyst, and we try to have a very intentional conversation ... I was actually talking with some CoLAP colleagues yesterday about this, about when. When is the most effective time to raise these issues? My view has been orientation is not always the best time. I think your students are a little bit deer in headlights and it's a little bit too early, but we have been doing ... Recently we moved the National Mental Health Day to October. Now we try to program around October 10th. So for many of us, that's about six weeks into the school year, give or take. I think people are really receptive. They're starting to feel the stress. They're starting to feel some of the anxiety and self-doubt as they're trying to work their way through, and it's a really good time to come in and try to do some positive programming. JANET: We try to both do some national programming, but many schools are also using that to do school-based programming, often in partnership with the LAP in the state, everything from healthy smoothie happy hours, constitutional walks, yoga, physical fitness, and sometimes some actual conversations with thought leaders around the value of sleep as something that actually promotes your learning or the worries of study steroids. So we have used the Fall Wellness Week, I think, to maximum effect for a lot of programming. CHRIS: Do you keep that programming broader in terms of different areas of focus or do you actually look at kind of a 1L track, a 2L track, a 3L track? I'm just kind of curious on the structure of how you do that. JANET: Well, that's a great question. I would say right now the Fall Wellness Week has been broader for everybody. CHRIS: Okay. JANET: I think that we are actually starting to have some more conversations. We have been doing some 3L specific sort of pathway to the bar exam kinds of programming. I actually think there's a lot more that we can be doing in that regard. I think the ABA Law Student Division is also interested as we think about bar success and wellness. I think that there is some 3L targeted work that we have been doing, but I think that we could be doing more around that Chris, from my own perspective. JANET: But I think that point is well taken. I do think that we find by and large that if we were to hold a program either around suicide or around study steroids, or pick your topic, depression, and we just said, "Show up for a program," law students by and large are not going to show up for that program. They don't want to walk into a room and be identified and tagged as the person who's thinking about suicide. But if you can market your program, and I think we've thought hard about this, whether it has to do more broadly with mindfulness, well-being, success in law school, happiness in the profession, I think if you can market that program, you can deliver the same content, but you can get people in the room and then get the buy-in and really get much broader participation. So I feel very strongly about that. JANET: I just also wanted to highlight that I think over this last year, we have also tried to be a lot more intentional ... I'm not sure we weren't doing it before ... But about the crossover between the struggles over racial injustice that we are all experiencing, and certainly that some of our students in various affinity groups are experiencing with well-being. Last year's Mental Health Day highlighted my colleague, Rhonda Magee, who spoke about her fabulous book, The Inner Work of Racial Justice. We then had several follow-up programs that students found really, really impactful, where we were really focusing on the impact of well-being on targeted communities of color. JANET: We've had a lot of, I think, requests for some more programming targeted with our first-generation students around well-being. I think there is a huge outcry for doing more programming of this sort as we move forward. BREE: What advice do you have for others who may be working at a law school and are listening to this? Maybe they're faculty or administration and who want to enact some of their own initiatives. Do you have some advice for them? How to get it started and how to make sure it's successful? JANET: Well, Bree, I think, as you know, because you and I have talked about this a lot, I do feel that right now the vast majority of law schools in the country are doing positive things around well-being. Many want to do more. Some of us are doing it differently. Some have more resources than others to do this kind of programming. But I think there's a huge interest, and in fact, I think a demand to have well-being programming in law schools right now and to really connect this for our law students. This is one of the things I say to students all the time, "You're coming to us not only to learn about contracts and torts, you're coming to learn how to become a future professional. Some of the skills that we can teach and model for you about your personal well-being and learning to set limits and finding balance between yourself and your work, these are some of the most important skills and probably the most important skills we can teach you in law school." BREE: I think of sort of the fancy word for that, professional identity formation. Is that? JANET: We are all talking about professional identity formation. Exactly. Exactly. And this is a critical element of this. I think that the well-being community and the professional identity community have found a great partnership and shared interest. These are things that we are working together to message, and we're messaging them in all parts of the law school. We're messaging them in clinics and in externship programs. We are messaging this in all kinds of core courses, including professional responsibility. This is all a part of our shared mission right now. CHRIS: Janet, it's great to hear that. I mean, again, with your perspective. When I think of law schools and well-being, I think of you because I think that you've been kind of at the epicenter of kind of looking at what's been going on in the law school environment. It's encouraging to hear that your sense is that the vast majority of law schools have kind of leaned in on this particular subject. I'm just curious about maybe the why. Why we find ourselves in a significantly better position today than say we did 10 years ago? JANET: Well, I think first of all, I do believe as I both talk to people at Miami Law but people around the country, in fact, Chris many of us are experiencing issues or challenges around mental health and substances with our own families, with our friends. We have faculty ... In fact, I was on the phone the other day with a faculty member and she said, "My child is in the process of being hospitalized." So I think we are actually at a point where ... I have another faculty colleague ... Fabulous, very, very smart person who lost his wife to suicide. I'm coming to the world at this point. I think this it's not a Democratic issue, it's not a Republican issue. This is an issue that affects all of our families and things that we hold near and dear to us. I think people are being a little more open about that. JANET: I think as all of the work and certainly, Bree, all of the anti-stigma work that you and others have been doing for so long, I think this is seeping in, and I think people are coming forward and saying, "This affected my family. This affected my child. This affected my brother." I think faculty are also a little more willing, and I'm not saying everybody, but to be a little more vulnerable themselves with their students. I think some of this happened during the pandemic. I think there was something very equalizing about all of us being on Zoom. BREE: That's a great point. JANET: Struggling with Zoom, and I saw some faculty members, and then I heard about it from students who said, "I'm really struggling here. I haven't been able to see my parents. I'm divorced and I haven't been able to visit my child. And this really sucks right now. So I appreciate that this is really a confusing time for all of you as students and the faculty. Where it's like, "Oh my gosh, that torts professor's a real person." JANET: I view this as some of the, I like to call it the gifts of the pandemic, but I think that there were people who became a lot more real with each other. And that includes faculty members becoming a little more real with students as well. CHRIS: That's such a great observation. I've always been prone to say that we are obviously human beings before we are a law student, a lawyer, a professor, a judge. It feels like we're kind of getting more back to some of those kinds of basic levels of empathy and kind of all on the same trajectory of just kind of trying to live our best life. JANET: Right. Absolutely. CHRIS: Let's take a quick break here. We'll hear from one of our sponsors, and we'll be right back. — Advertisement: Meet Vera, your firm's virtual ethics risk assessment guide. Developed by ALPS, Vera's purpose is to help you uncover risk management blind spots, from client intake to calendaring to cybersecurity and more. Vera: “I require only your honest input to my short series of questions. I will offer you summary recommendations to provide course corrections if needed and to keep your firm on the right path.” Generous and discreet, Vera is a free and anonymous risk management guide from ALPS to help firms like yours be their best. Visit Vera at alpsinsurance.com/vera. — BREE: Welcome back everybody, and we're here with Dean Janet Stearns from the University of Miami School of Law. Janet, so one of the things that I really want to dig into with you because you sit at such a unique position of this nationally, and that is some of the policy initiatives that are occurring across the country to really try to change this circumstances for law students. I want to hear, and this is particularly in your spot as Chair of CoLAP's Law School Committee, could you tell us about some of the initiatives that you all are working on? In particular, I'm thinking about the whole character and fitness process, which has had such a detrimental impact on students' willingness to ask for help. And then also to dig into some of the changes you guys are seeking for the ABA standards. JANET: Well, thank you, Bree. I have to say, I think it has been a tremendous honor for me to be able to be involved with the American Bar Association CoLAP because you really feel the capacity to make change, to be in a room with people who are not only passionate about these issues, but who actually have some policy vision and the power to then act upon that vision. JANET: So we have been working through the CoLAP on several national projects that we think can really shift the conversation on health and well-being for students. As you mentioned, the first has to do with character and fitness. Why is this so important? Because in surveys that have been done and the preeminent survey by Jerry Organ, David Jaffe and Kate bender, looking at law student well-being, we learned the very scary high numbers of students who are experiencing depression, suicidality, substance use/abuse. We also learned that a very small percentage of those students were willing to come forward and ask for help from deans of students like myself. And the primary number one reason they told us they would not come ask for help is because they were afraid that they would have to disclose it on their bar application. JANET: So this became a huge cultural issue for us. How can we shift that culture so that people understand that when they need help, they actually indeed must ask for help, that we are here to help them, and that the bar character fitness doesn't become a barrier to that. So we have been working on trying to both evaluate what states are doing around the country and advocating for change, and specifically trying to either eliminate questions in the character and fitness process asking about mental health history or history of substance use disorders or narrowing those questions in time and scope so that people understand that their first duty is to take care of themselves and get help, and it will not stand in their way of ultimately being able to become a lawyer. JANET: We have had, I think we both, there has been, I think some policy conversations, we've been able to do some writing in this field, but as we know, in 2020, one of the great gifts of the pandemic was that early on the State of New York removed their questions relating to substance use mental health. Anything outside of conduct is no longer asked by New York. BREE: That was huge. JANET: That was huge. It was huge. So many people came together including great advocates in Massachusetts, which had been doing this for a long time that made possible the change in New York. Shortly after New York, I think in March, literally as we were moving into the pandemic, Michigan removed its questions. Again, thanks to a lot of great advocacy by Tish Vincent and others involved with the LAP in Michigan, the law schools in Michigan, and a month later, Indiana followed Michigan's suit just after the pandemic had started. JANET: The Chief Justice in Indiana, who I just think is one of ... My Ruth Bader Ginsburg I tell her ... Justice Rush, who really was so eloquent in recognizing the importance of this issue. The Supreme Court took very quick action under her leadership to remove the problematic character and fitness questions in Indiana. Then by the summer, New Hampshire also followed suit. So those were four states all in 2020. I feel like there's a great momentum there, Bree, and I continue to remain hopeful that we can continue to make progress in other states, particularly where we have some matching of an active law school community, an active bar well-being community, a judiciary, and we know that there are other State Supreme Court justices that are very, very enlightened on these issues, that we can work together to have more states implement reform in the character and fitness process. JANET: I feel strongly also where we can, if we can get either frequently asked questions or preambles, things that we can use as educational materials with students as they enter law school, as we talk about bar admission, so that they are very clearly told that this should not in any way keep you from accessing mental health or other counseling resources when you need it. BREE: Right. I mean, that's one of the things also is to include very explicit language in the introduction to the questions of the application process or somewhere, we want you to get help. That can be helpful too. I know that the Institute for Well-Being in Law is going to be joining in the policy efforts there too around trying to bring about state by state change on those character and fitness questions. So we're going to have a good group of advocates working on this around the country. BREE: I know another thing that CoLAP has been doing, and you've been a leader on really, and I can't imagine how many, maybe hundreds of hours that you've spent writing and working on this, Janet, but that is around the ABA standards for law schools. Can you talk a little bit about that? What you've been working on and the progress that's been made? JANET: Well, thank you, Bree, and this truly has been a labor of love. So the CoLAP Law School Committee, hand-in-hand with the ABA Law Student Division, has been seeking changes in the ABA accreditation rules to recognize the integral role of well-being in law schools, student services, and law school curriculum. As you know, all accredited schools are subject to the ABA accreditation standard. These standards are voted through the Council on Legal Education, through the ABA, and then ultimately approved by the House of Delegates. JANET: And so we have asked for several years for some language on well-being. We didn't get very far the first two years, but this year, I think again, another gift of the pandemic has been the incredible focus and importance of well-being. The Council in fact, did put out some draft language. It was not all that we wanted, but it did include a recognition that every law school needed to provide some well-being resources to its students, either directly or in collaboration with university resources, LAP resources, looking as well at financial well-being, emergency funds, and other essential resources that every law school must do. So the ABA Council recommended this language. We then had a large comment period. We are currently in the middle of a second comment period on proposed language. We hope to hear more in this month of August as to whether or not the package of proposals will be pushing forward by February to the House of Delegates. JANET: I will note that the package right now also has some other very significant changes on professional identity education in law schools, and it also has a large package of proposals that have to do with diversity and inclusion and core curricula requirements in law schools around diversity inclusion initiatives. There is a very rich package of proposed revisions to the standards. We are going to remain hopeful that these can get to the House of Delegates this year. But I think the fact that we finally have well-being in a draft proposal as an essential part of every accredited law school, that is institutional change, and I'm very proud of how far we've come with this so far. BREE: Absolutely. And Janet, if our listeners, if somebody wanted to dig in further and learn more about that, can they go to the ABA website or how could they learn more or track what's going on in that area? JANET: All of the proposed changes and indeed all of the comments that have been received are all on the website for the ABA Section on Legal Education, as well as the notices of ... There will be a meeting as we're recording this, we are in the week of the ABA Annual Meeting ... But my understanding is August 19th and 20th, the Section on Legal Education will meet again, we understand, to discuss next steps on these standards. Of course, if that is a problem, anybody is free to email me at the University of Miami. We have a large community of friends across the country who are in a very close conversation about continuing to advocate for these changes to the standards. Please join us. CHRIS: Let's talk a little bit about the future as we kind of look ahead. Obviously we've made a lot of progress through the efforts of you and other folks who are keeping a close eye on this. You talked about the fact that there's more awareness, more eagerness, more focus, but we also know that culture shifts in our profession, they don't happen overnight. I'm just kind of curious on your perspective of what's on the horizon. What things do you see in the future being done by law schools to continue to move the needle on improving the well-being of law students? Because we obviously know that you're preparing the next generation in some respects. There are general generational aspects to the improvement of the profession. So I'd love for you to break out the crystal ball, so to speak, and kind of talk about what you see kind of coming down the road as we continue to maintain an emphasis on this issue in the law school environment. JANET: Well, thank you, Chris. I'm not very good with a crystal ball, but let me try here. So I do believe, and I think at the CoLAP level, first of all, I believe that we need to work hard to make sure that not just student services folks, but faculty and administration do need to be trained on mental health first aid, which is a course, i an eight-hour course, to make sure that they have basic skills to be prepared to have conversations with people. This course, this mental health first aid course is not only for law schools, this is being done in law firms, it's being done with police, it's being done all over the country right now so that people are more equipped when they come in contact with a client or a patient or a student or a colleague or a child that they have some more basic skills to be able to triage the situation and feel prepared to understand what somebody is going through. So I do think we need to continue to push that course out, number one. JANET: I think number two, that we need to have some more institutional structure for keeping these conversations going, as you've said, Chris. I would say at the University of Miami, I have formed some great partnerships with other people at our university. I would include the people, my friends at the medical school. I think that our medical education and legal education in our student populations, there're strengths and there're weaknesses. There's a lot of overlap. So I've tried to partner closely with the medical school, our counseling center, other people at the university so we have some institutional structure for continuing a conversation. I think that's incredibly important because me, one person, I get busy and distracted by other things. But when you know that people are coming together at regular intervals to have a conversation that is empowering. That creates accountability, JANET: I think we also get a lot of accountability by working with the LAPs in our state. We just, this summer, just last month, the Florida LAP got all of the law schools in Florida together for a program. I know that these regional meetings are taking place right now in other states. That also creates a catalyst for change. Also when you're working with the State Supreme Court on the character and fitness topic. I think there is a strength in numbers when we can bring people together, whether it's under the auspices of a well-being committee or whether it's just again, a time of coming together to support one another, share, and then try to again, begin to imagine ways that we can work together to create change. BREE: Absolutely. I've always felt that in regards to these policy initiatives and the work around the well-being movement, get passionate people together sitting around a table, you have a bunch of lawyers, they're brilliant, they're creative, they're solution-focused. We can figure this out. And so Janet, thank you for being there at the head of the table in these discussions, in this work around law school. BREE: I want to thank our listeners for joining us. This is the third and the final of our miniseries on initiatives and innovations in law school space. Please join us for our research miniseries, where we'll have three episodes digging in and talking with some of the lead researchers and thought leaders in the lawyer and well-being space movement. So want to thank everybody for joining us again today. We will be back with you in the next couple of weeks with more episodes. In the meantime, be well. Take care. Thank you all.  

Chris gives a DB sessions update and talks bifunctors & command objects. Steph shares the coolness of a gem she's been using called after_party, and excitedly gushes about her new laptop. (Chris is hoping to hold off on replacing his until the end of the year and then they can compare!) The two then answer a listener question on retrospectives and how they've seen productive ones run, while giving some of their own helpful opinions on dos and don'ts. They're talking to you, Grumpy Goose! dry-monads gem (https://github.com/dry-rb/dry-monads) attr_extras gem (https://github.com/barsoom/attr_extras) after_party gem (https://github.com/theSteveMitchell/after_party) What Went Well? - Bike Shed 123 (https://www.bikeshed.fm/132) What I Believe About Software - Bike Shed 172 (https://www.bikeshed.fm/172) Is Agile Over? - Bike Shed 299 (https://www.bikeshed.fm/299) Running a Retrospective - Upcase (https://thoughtbot.com/upcase/videos/running-a-retrospective) Transcript: STEPH: Cool. [laughter] CHRIS: Good. No, I like what you did there. STEPH: Yeah, I feel like we can get rambling on that one. CHRIS: It's been great. This is what the Bike Shed is at its best. It's the two of us just rambling and being like, well, what about this? And if it's this, then that, then these, and it depends. And it's complicated and it's nuanced. And what about the humans? That's the story of The Bike Shed right there. [laughs] STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm CHRIS Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week? CHRIS: My week has been good. I have some updates actually on some topics from previous episodes. One of the things that I can update on is the discussion around the cookie versus the database store. So I had posed this as a thing that I was going to be doing in the app for a handful of reasons. Most notably, I wanted the ability to invalidate sessions from the server-side, wanted to have a little more control over that. And so that's a dream that the database-backed session store can do. Eventually, I have to make that actually work in the way that I want. But I was asking the question in that episode, which we can include a link to the specific episode, but I was asking the question of why don't we just do this all the time? The database-backed sessions seem better in all these ways. It's a lower overhead per request because you're just sending the session ID and the cookie instead of the whole payload of the session. You actually can have more data stored in it, a bunch of things that seemed really great. And then right after I introduced it, I figured out the thing. I figured out the secret. It's not a big issue, and we're going to stick with database session stores. But we have to be purposeful because it turns out they are essentially plain text in the database. And so if there's anything that you are putting into the session like say a social security number or an authentication token or other things which naturally I might have done if it was in a cookie that lives on the user's browser and never actually lives on the server, persists on the server, that seems fine to me. But now these things are getting stored in the database and that really changes the calculus, especially because if I'm not purposeful, they'll just stick around for forever. So social security is probably the most pointed example of this. If you happen to have a form in the app that accepts a social security number and you want that to persist through some number of other steps, not actually going to store the social security number in the database because that's a thing that I have actively chosen not to do. I need to send it off to some other system, but I do need to hold onto it for a few minutes. The session is a perfect place to put that unless the session gets stored in my database. STEPH: That's such a great point. I'm so glad you discovered that. And in our recent conversation, we were trying to think of the reasons why this isn't the default case. You may be headed in this direction, but this may also be timely, the fact that you're discovering this issue but also the fact that Rail 6.0 now has encrypted columns. Is that where you're headed with the fact that you can still keep session data in a database? CHRIS: That is a great question, and it is an intriguing option. But it's not the one that I'm going with here. I think broadly, my hope is to completely avoid ever persisting this data in the database, this truly sensitive user-specific PII or PCI or social security numbers or any of these other fancy acronyms that get collected together under the umbrella of I probably don't want that on my server. For those, I'm just opting to push them back into a cookie. So I'm using particularly a...In rails, it's fun because they have a fluent interface where you can just chain together things, so it's cookies.signed.encrypted.whatever, and then you go from there. But I'm using signed, encrypted cookie, which is essentially what the session store views; the cookie session store uses itself. So I'm basically reverting to the old session store behavior for specific values. So anything that is truly sensitive like that, I'm just saying, cool, that's actually just going to live in a cookie, and that will be it, but not leaning on the ability to encrypt the database sessions. There's just enough subtlety around that. There's so much volume of data if I do allow that sensitive data into the system that any failure, any exploit that happens, would be somewhat catastrophic. So, in my mind, this lowers the surface area and says, yeah, this data really never lives on the server. It comes with a request, and then it's gone after the fact. And that's the world I want to live in. STEPH: Yeah, that's super interesting. You're also raising questions for me that I hadn't considered when we originally had this conversation where there's necessity or that you're looking to store form data or sensitive data in that session as well. So that makes a lot of sense to me that for that type of behavior, we're going to separate that from the idea of authentication and the user session and still use encrypted cookies for those details. So it only stays with the user's browser, but then the actual authentication of a user that part could still live in the database. CHRIS: It is ending up being a weird Venn diagram of; this is data that I want to stick around but only sometimes and particular to the machine that the user is interacting with because the session is still associated with a cookie at the end of the day. So a user may have multiple sessions in the database-backed session version. It is somewhat interesting, and I'm going to see how it develops over time. But yeah, at a minimum, I have now found this edge case of like, ooh, okay, sensitive data, that's a thing, which is one of the reasons that I would reach for the session inherently. So it turns out, as always, it depends. Things are complicated. STEPH: It's a nice update. I like when we have closure to a question like that, especially so quickly. CHRIS: Love to provide that continuity. It's what I'm all about. But yeah, what's up in your world? STEPH: What's up in my world? I am excited that I have a new laptop. So I have been using a MacBook Pro for about the last...it's lasted me for a while. I think I've had it for a good four, four, and a half years, but that's on the fritz. The keyboard, in particular, the keys are popping off, and that's something that I could go get fixed. But I'm at the point that I need a new laptop. So I have a brand new shiny laptop. And I had the option to either go with a 16-inch MacBook Pro or to go with one of the new, fancy laptops that has the M1 chip. And I was torn for a little while because having the M1 chip sounds really cool and novel, and there's a lot of speed improvements that come with that. But I ended up going with just the 16-inch MacBook Pro; specifically, one, it's still very fast. It's very reliable. I can use this as my work machine and just know everything's going to work. That part feels really important to me. And then also the screen size is important. So any Mac laptop that is using the new M1 chip, I think they only go up to a 13-inch, right now, screen size. And I really want the 16-inch in case I am traveling, so I have that larger desktop. But I did do some research into the M1 just because I know about it. I know it's out there. I know it's hot. People are interested in it, but I didn't know a whole lot about it. So for anyone else that's like me and is curious about what the heck this M1 chip is, it's essentially Apple's foray into making their own processors. So traditionally, their machines have used Intel CPUs and third-party graphic processors, and other parts. And this introduction of the M1 chip really represents Apple's switch to having their own internal architecture rather than relying on those third-party parts. And it also means that all those features that were sourced from other parties like the CPU and its security are now being combined into a single chip, which has also led to some performance improvements. And while I was reading about the M1, there's a lot to go through, but the thing that stood out to me was this idea of Apple's Neural Engine. And I thought, well, that sounds super fancy. What is that? Are you familiar with Apple's Neural Engine? Have you read about that? CHRIS: I don't think I am. What all is that? STEPH: Yeah, good question. That was a question I was asking myself just recently. So essentially, their neural engine it's a microprocessor that specializes in the acceleration of machine learning algorithms. So it's really similar to how a GPU will focus on accelerating graphics rendering. And their neural engine or neural engines in general then focus on accelerating neural network operations. And the inclusion of a neural engine isn't something that's new because Apple introduced this into iPhones and iPads back in 2017 to support their features like Face ID and emoji, searching for photos with dog pictures. Siri speech recognition is also one that's using this engine and other machine learning tasks. But the sparkly stat that Apple is sharing with this new design is it's a 16-core design that can perform 11 trillion operations per second, which sounds very fancy, very fast. But it really got me thinking about how companies are working to improve, not just laptops but also our mobile devices to run machine learning software more efficiently, and then how that's just going to evolve and change all the different features that we use, and then how developers can integrate with this engine. I think currently, Apple hasn't shared much information about how this engine works, but I think they've exposed a few developer tools so people can still build features that will then use the power of this faster, improved neural engine. CHRIS: Oh, that's super interesting. I have still not really delved into machine learning or artificial intelligence, or any of that stuff in any real way. But it's one of those things like the number of mentions is ticking up. And at some point, I'm like; I probably have to pay attention to this, don't I? I'm still in the not paying attention to it camp. So if I'm understanding, though, you just described this wonderful feature, but you opted for the machine that does not have all the fancy stuff. You did not... STEPH: Exactly. [laughs] CHRIS: Okay, yeah. STEPH: Yes, it would have been nice. That would have been neat, but yeah, I needed a machine with a larger screen, all those good things. And that's still really fast, for the record. CHRIS: Oh yeah. I'm desperately hoping to make it to the end of this year. This is going to be a bit of a rumor mill here, but my understanding is the expectation is that Apple is going to release a 14-inch MacBook Pro with the M1 and the return of MagSafe, and the removal of the touch bar. And that sounds like my dream machine right there. I want that piece of hardware. I also seem to care a little bit less about the size of the laptop screen. I'm so often working at my desk with a large-format monitor that I'm connected to. And so, when I'm on the road, I want to optimize for portability when I'm traveling because I do it so rarely, and then I'm hopefully focusing on travel at that point. But we'll see if that remains true as the shape of my work changes and I start to not only work from home. And maybe I'll actually change my tune on that. But for now, that's my hope is to make it to that machine and then get one, and that it exists because right now, those are all rumors. STEPH: Well, I totally support this goal of yours. So that way, you can have that new-new, and then you can report back on what it's like, and then we can compare. Because I'll have the other version, the Intel CPU, and then you'll have the M1 chip, and we can see how our lives are different. CHRIS: You'll have the new, and I'll have the new-new, and that's how we'll categorize them. STEPH: [laughs] But yeah, I'm very much looking forward. Having a new laptop is always just such a fun feeling. It's just a clean space that I get to rebuild. It's like going through and prioritizing; what are the things that still spark joy? And then I get to only port over the stuff that I still really use all the time and want to keep. So I'm looking forward to getting it set up. CHRIS: I need to do that sometime soon. I'm like five years deep, at least on this machine. So I've been dragging along. Also, the hard drive is just completely full, and I regularly have to go through and delete things before we start recording because it turns out these audio recordings start as very large files. [chuckle] So it's almost a weekly thing where I'm just like, got to throw something out today. I don't know what. It's fine. I'm going to be fine. [laughter] I'm going to make it to the end of the year, and it's going to be great. STEPH: What else is going on in your world? CHRIS: Well, I wrote some fancy code, and I use fancy not necessarily as a good word. [chuckle] So I'm intrigued that the code could be described perhaps as clever or other words like that, which I think are very complicated words in the coding space. I tend to try and avoid this type of coding where I'm trying to introduce abstractions and clean things up, and remove duplication because I've been burned by that so many times in the past. But this time, I think maybe this time it'll work. So, in particular, there are two different areas of the application. There were two sets of refactorings, but they really went together. One is we have the idea of command objects within the application that we're working on. So there are a lot of cases where we need to save something to the database and then communicate something to an external API. And then presuming the results of that is a successful response from them, then unpack some data, make sure it's in the right shape, and then save something else to the database. And ideally, wrap that all in a transaction and keep everything together and then return some data at the end of it. So that whole sequential operation, I've been using dry-monads to model that. I've talked about this on a few previous episodes. I'm really enjoying it. The more I lean into it, the more I find that it is just a really great way to wrap up that very procedural code. But ideally, do it in almost a functional way so that we've got these sequential operations that feed into each other. There's the railway-oriented programming stuff, which is associated with this idea. But there is a lot of boilerplate to these objects. So the way we've defined them is they have a class method called run that takes whatever the arguments are, and then it needs to pass those arguments into the initialize and then call run on the instance. So in order to define one of these objects, what we had been doing was def self.run and then all the arguments. And then inside of the body of that, it's new, and then pass forward all the arguments .run, and then define initialize to capture all of those and set all the instance variables, and then define the run method, which actually does stuff. Also need to define an Adder reader for all of those instance variables, which is a thing that I enjoy doing. So that's the interface I want, or that's the way that I want this class to work. I know other folks in the Ruby world feel differently. But that's the shape of the thing that I want, but that's a lot. And there's also I regularly would find myself forgetting to duplicate something that we put into the class method run interface into the initialize method. And it was just like, this is all just wiring up and plumbing. There's also the binding of the dry-monads do notation for the run method as well as the inclusion of the results type within dry-monads. Type is a strong word, but that gives us the success or the failure objects that we can create. So ideally, all of these command objects either return a success object or return a failure object. It's one of the two. And that's one of the things that I really like about them. But yeah, so much plumbing. So we define a base command, and the base command has the self.run method, the class method, and that method is defined very abstractly. So it's just args * keyword args. So we're capturing all of the arguments and then forwarding them on to new. So that way, I don't have to think about that interface. It basically just says, "Give me anything, and I'll forward it onto new." And the new or initialize is in charge of actually defining things. It also includes the result type. It includes the macro annotation for the run method, which is how dry-monads does its magic, that actually I had to include inline within the self.run, just because of the sequence of definition and the metaprogramming that's going on there. As I said, that sentence terrifies me a little bit, but hopefully, no one ever needs to look at this magic base class [chuckles] and figure anything out. So that was one part of it. That cleaned a lot of things up, so that meant I didn't have to write a ton of the wiring up code. Then there was still the noise of actually defining all of the arguments to these classes. They often take a handful of arguments because that's their job is to grab a bunch of things and do some work with those things. So for that, I have brought Adder Extras, which is a gem that I've talked about probably in previous episodes, I think so. But this is the first time that I've really leaned into it and used it. And it gives some very high level what look like macros are just class methods. But the one that I'm using is Adder private initialize, and that you can then pass a variety of values too. And it will then say, okay, this method accepts a required keyword arg, a defaulted keyword arg, and a positional argument or something to that effect. But it's a very, very concise way to express that and then also get the private Adder readers, which again is the direction that I want to go with all of this. So that's a bunch of things that I have said. But all total, it cleaned up these command objects very nicely. And now, when you look at one of these command objects, all you see is the run method that does the work. And the plumbing and the wiring up behind the scenes should just happen. I am concerned about the day that someone forgets to inherit from the space command, and then it's like, why does nothing work? I thought command objects just worked in the system. But we're going to deal with that when we get there, which is hopefully a while down the road. STEPH: I like how you're pushing at the boundaries of our comfort zone. I say our comfort zone because I imagine we feel similar. CHRIS: It is. We definitely got a shared comfort zone. [laughter] STEPH: Yeah, we have a shared comfort zone with inheritance, but you're pushing at that boundary of that comfort with inheritance because it is something that can be so painful. But you've identified an area where inheritance feels useful. And then it also sounds like a very meaningful...you're introducing this pattern and then trying to make it easier for others to follow this pattern. So it's a very intentional design decision of where we want to group these behaviors together and then make it very easy for other developers to then pick up this pattern and run with it, and then also work with these classes. So I am intrigued to hear how it goes and how others feel about the pattern as well. I also wonder, this is one of those areas where it feels like this very intentional design decision. Is it something that you think in the base class would be worth highlighting? Like, hey, here are the things that we are using in this base class. This is the intention of this base class. I don't know if that's maybe a comment or if that's something that's documented in the README. I know; I see your eyebrows went up when I said comment. But it does feel like one of those areas where it's like, hey, we have introduced this new concept. We want you to follow along. Here are some helpful guidelines. CHRIS: Those were mostly joking eyebrow raises because I have thought of that. I haven't actually gone to that level. But in the back of my mind, there's this pattern that we have within this application. Ideally, we're going to lean into it more and more so that A, we have a clear way that we do things within the app but also make that as understandable and discoverable as possible. I'm not sure if a comment in the class is the right thing or...so I'm deferring what I want to do on that for now because right now, it's myself and one other developer. We sort of developed this in tandem. So we were working together on it. We would pair in a bunch of the features. And what we have now is the crystallization of what we found useful. And we're both very comfortable with it. So there isn't the need to explain it. I'm almost thinking about it as just-in-time educational content around this piece of our application. I don't actually trust that I would do a good job describing it in the abstract because I know it. Like, to me, this thing makes sense right now. But I've been on the other side of stuff where someone was like, "Hey, this totally makes sense." And I'm like, "I don't know any of the words you just said," and so I felt that pain being on the other side. You could say I'm just being lazy, but I do think this is a purposeful delaying of that where I want to wait until I actually have someone to teach this to. And at that moment, I want to see what that conversation looks like. And I'll try and explain it to the best of my ability, but I'm sure they're going to ask questions, and I'll be like, "Oh, wow. Yeah. I hadn't even thought of that. But now that you ask the question, totally let me explain this part that I was going to gloss over and forget to mention." And so, ideally, that is what will happen down the road. And then from that, hopefully, some artifact becomes clear, whether it's a documentation page in the repo or a comment in the class if it's simple enough or maybe even it's a recording of a pairing session. And that's the artifact that we keep around that explains this piece of the application. So I definitely think a version of that makes sense, but I am not doing it yet. STEPH: It's funny; you're saying so many good things that I agree with. I love the just-in-time education; that part is fun. And yeah, there's a part of me that definitely still leans into the idea because we've talked about this in the past too, where we write down, in the moment, the things. Having that context when we're implementing it is really important and helpful. So even if it's not this grand explanation…which I really like what you said around having someone to explain it to or have that conversation with so that way you're documenting the useful bits, that part I like very much, but capturing the intent as soon as the change was introduced. So even if it is a very high level like, hey, we are using dry-monads and Adder Extras, even if it's just links to those things, that's something that I think I would still favor just to go ahead and start surfacing this is a pattern. This is a choice. And then, as you continue to work with the pattern, if you change your mind, it's still very easy to scrap that documentation. So I think if it were me, I would still go ahead and document it. I think it's that piece about discoverability that's calling to me so strongly where that's where I want to then highlight the things that are in use. So even if there's not an explanation, people can find the resources very easily. Because you're right, you did say a lot of interesting bits in describing this pattern. And the fact that we're talking about it now also just deepens my suspicion that it would be nice to comment somewhere, and perhaps a repo is a perfect place for it and just get it out there, and then it can always be revisited later and improved. CHRIS: Okay. I like that you are keeping me honest on this because I do think there's a certain amount that I'm just being lazy here and not wanting to do that because it is actually really hard to try and document something like this. Like, what are the important pieces versus what are the extraneous details that people don't actually need? I do wonder, so the pull request that did this refactoring and introduced this base command object that does have the explanation captures the point in time and whatnot. And so I wonder, is there a version of tagging important pull requests that tell the story of the application? A lot of things are just going to be like; this is adding a feature. It's the same as the other 30 pull requests recently that added a new feature. But this one is special from an architecture perspective. And so let's tag this, let's add a label. I don't know what it is but something that allows for discoverability of the story of how this application became what it is today because anything else I worry will go out of date almost instantly. But this pull request is true fundamentally in that same way that we say commit messages should capture as much of that detail. So I did do that writing for the pull requests/the commit message. And I wonder if maybe that's the best artifact for this moment but then the question of surfacing it and making it discoverable because otherwise, it's just lost in the sea of other pull requests. So I don't know. But I do like the slight push back that you're giving me here of like, yeah, but what if you did something though? And I'm like, yeah, that's fair. I should probably do something. STEPH: Being able to pin those specific PRs that have significant architecture changes sounds really novel, but I'm going to take this opportunity for me to be lazy. And if I'm joining a project, I don't want to read through what has happened. I just want to know what's true now. And if I go back and look at those PRs, I won't know if all of that is still relevant and how it's changed. So it sounds neat from telling the story of how an application has evolved. I like that sort of developer lens, and what are the things that we have tried and then changed over the years? But from I am onboarding to this application, I just want to know what's true today? What are the things that you want me to follow? What are the patterns that are going to be really helpful for me to look at? And so then, I don't know if I would use it in that context. And this may be one of those areas where I'm feeling overly skittish in response to the number of things that you said and the use of inheritance. Because I have felt so much pain of where I'm going up the tree to figure out what the heck is happening in the world and then to understand all of those pieces, and then swimming all the way back down to the class that I'm actually working in. So it could just be past experiences that are now influencing how I want to document or work with inheritance. It probably is. [chuckles] That's probably a big factor of it. It doesn't mean I disagree with it because those painful experiences are meaningful. [chuckles] CHRIS: Yeah. I think the foundational thing...I tried to start this with the context of like; I did a thing. This is another example of good idea, terrible idea; my favorite segment on The Bike Shed. I stand by it. I think it was useful. It does use things that we have traditionally moved away from. I say we because, again, I think we have a shared approach to development at this point. But I think it's worth it. I hear everything that you're saying about the documentation, but I've been burned by that so many times where the documentation is like, here's what's true now. And you're like, no, there isn't even a class called that anymore, and no less does it work that way. And so, my inclination is not to go that way. The solution that I have in mind is when someone is onboarding into the application, I don't expect there to be documentation and other things that I can hand them so that they can run. I expect to sit down with them and work with them. I'm going to pair with people when they join a team for a long time. There's a period where that's true, I think, and then you get to a certain size of an organization, and you're onboarding enough people regularly enough that that's a thing that you should get better at. But for I think a surprisingly long time, my answer I'm more than happy for it to be, yeah, we're bringing someone new into the team. Let's sit down with them. Let's spend the time. Let's tell them what's true because I know currently, and I can give them an up-to-date version of that. And ideally, as part of that, then update the static documentation, the repo, the README, the other things based on the conversation that we have and recognize oh, that that link is very out of date. Let me change that one real quick. But I'm not expecting to have comprehensive documentation for that. I'm expecting to use real human interaction to fill that gap. STEPH: Yeah, I really like that you're also calling out how fallible documentation is and how it has misled us so many times. I also love what you highlighted where when somebody new is joining the team, we are more than often going to sit with them and then explore the app together. And it just made me revisit that phrase that you used earlier about the just-in-time education. Because for this command object, you may join the project and not need to interact with this design pattern for your first couple of weeks, first couple months, who knows? So then it comes back to the idea of how when someone is in the space of where using a command object feels like the right approach, then how do we introduce them to this pattern and then make sure that they have the tools that they need? And if someone is accessible to then sit down and go with them, that's great. But if someone is not accessible, then I still want them to have at least a few of the resources that they need to dive into some of the more complex things that are being included. So, yeah, it's a tricky one. I like this thought experiment. CHRIS: But yeah, overall, I'm happy with it for now. I'm hopeful it will work out for us moving forward, and I'm hopeful that it will also be a sufficiently discoverable or teachable thing within the application. But again, I will certainly report back and see how that one plays out for us. But yeah, that's what's up in my world. What else is going on in your world? STEPH: Something else that's up in my world is I have pulled in a tool that I've used in the past, and I really like it. So I'd really like to talk about it here for a bit because I just find it so useful. And now that I've added it to this new project, it's just really top of mind for me. So I found that when working on a project, there are often times where I want to run something right after a deploy has happened, and I want that to be automated. I can do it manually. I can hop in, but then perhaps if you're deploying across many environments or many systems, you don't want to have to do all that manual work, or you also just want the convenience of you can set it and forget it. And that way, you know something's going to happen. So perhaps it's something where you want to change some data, or if you want to enable a feature flag, then this is really helpful. So the gem I've been using for this is called afterparty, where you can write automated deploy tasks that essentially behave very similar to migrations. So you can write a Rake task. It has a timestamp. You can implement the logic that you want to be run right after your code has deployed, and then afterparty itself, we'll check the timestamp. It will see if it has been run. If it's already been run, it won't run it again. Or if you like, you can set it up so that way, you can tell after_party to say, "Hey, after every deploy, I want you to run this particular task," but it's such a nice improvement to the workflow. And the other thing that I really like about this that I feel is a bit contentious is separating changing data outside of migrations. So I am a big fan of migrations are focused on changing your schema itself. But if there's actual data that you need to change, I really like when that is separated outside of the migration. There are definitely times that I understand it's really nice to just do it all at once, and it's easier. But anytime it starts to get even a little complex, I immediately want to write tests for it. And I can't test my migration. But if I'm changing some meaningful data on production, I want tests to back it up to make sure that I'm scoping correctly, that the outcome is exactly what I expect. It also makes it easier for other people to review. And after_party gives me that functionality so then I can have my migration. But then I'm like, oh yeah, but I still want to automate changing this data because that's often one of the complaints that I hear from people when I do ask them to separate into a Rake task, changing the data. They're like, "But I don't want to have to then follow up and then run this task later." And I'm like, that's cool. Afterparty has you, and you can automate it and not worry about it. So afterparty has been one of my favorite gems to add to applications. CHRIS: That's interesting. There's a bunch of layers to everything that you just said. I think I've worked with after_party on a project. I think we were working together on that project, if I'm remembering correctly. I have no bad memories of it, which given the nature of the tool, makes me think it did its job very well because its whole point is just like, oh cool, now you can just do this thing, and you don't even really have to think about it. Because there are plenty of other times where I've had to orchestrate or do a deploy. And then I SSH tunnel into production, which is a bad idea, and then I'm running Rake tasks manually. And so, I think the fact that I don't have any pointed memories of this is a really good sign for a tool like this. So that's a weird vote in its corner for me. You did say something that was interesting that I want to poke at a tiny bit which was you can't test migrations, and I think that's true. Like, I don't know of any way. And it feels like a thing that is sort of fundamentally deeply true. But I do wonder, is there any gem out there? Has anyone done a weird science experiment to figure out like, I would actually really like to be able to test my migrations? So I think the idea of having to pull data change out of migrations for the reasons that you said totally makes sense. But there are often times where I want to convert from non-nullable to nullable. And in the process, I want to backfill with a given value or something to that effect. And I like to encapsulate that altogether such that if it fails or succeeds, it's transactionally consistent. And I do wonder, could I wrap a test around that? I don't know of a way, and I think it may actually be the Rails testing infrastructure is just like no, we prepare your schema for you in the background, so it's just up to date. And therefore, you don't even have a way to be in a state where the migration hasn't run. But it's an intriguing one. STEPH: Yeah, that's probably a hard absolute that I said where you can't test it, and I'm sure there is a way to test it. How friendly or how easy that is to do, I'm really not sure of. It also feels like one of those areas where it feels like I'm testing this other service that I should trust fully, so then I'm not necessarily testing the migration itself. I'm testing some logic that I've added inside of the migration where I'm changing some data. And the example that you provided is perfect because that's one of those that I'm inclined to include in a migration. It's more like where we want specific users who have this value or in this category. And then, we want to migrate them from this data to the other data. And when we start getting complicated in our migrations, that's when I'm like, this is a bit much, and I'd really like a test that documents that we're doing this correctly. That's where I get squeamish about having data changes in migrations. But you do raise a good point. I don't know; I've never tried to test one. I've just always reached for this other approach, but that is more the pain point of if I could test this data change inside of migration, then that would work for me. That would solve my problem. CHRIS: I wonder if an alternative approach would be to just introduce an object or a class that does this work. So like a command object as it were, to do a call back to earlier in the episode, that does that data transformation because it's exactly what you're describing, for this subset of users do this. But if they're in this state, then do these things and create two new records for any user like this. That sort of stuff is really complicated. Definitely want to have some tests around it. But you're talking about a gem that allows you to extract it into a Rake task-like situation. But I wonder, could we just have a class for that? And I used to be a big believer in your migration should live forever, and they should always be runnable from the beginning of time. I've given up on that belief. That's one of the things that I've been like; I don't know. It turns out I've never done that. It's not an important thing. Just DB schema load is going to be fine most of the time. It's great for the past ten migrations to be around just to tell a little bit of a story. But I'm not tied to migrations being runnable forever. So the idea of you introduce this class, it encapsulates that data transformation. You can test it because it's its own thing. It will still be run within the context of the transaction of the migration. And then you throw it away down the road along with the migration, and you do that migration roll-up thing. It's just a different thought there, although I do like the...well, I guess that would also run automatically, but that runs as part of the deploy as opposed to after the deploy, which is meaningfully different than what after_party does because there might be one of these migrations that takes a long, long time to run because you've got a ton of data. And you want to decouple it from the true deploy release sequence that happens and the time limits that are there. So I think I've now talked myself in three circles, and I'm going to stop. STEPH: I like how you highlighted that part where it does decouple you from the deploy process where it's still automated; it runs afterwards. But say if it's something that doesn't need to hold up the deploy, you don't need to wait for this data to be migrated before the deploy can go out. Then that's a nice separation because then it can happen afterwards. Or if you do need it to happen part of the deploy, yeah, there's lots of interesting bits there. I feel like you and I could talk about it for a while. But we have a listener question that I'm really excited for us to talk about. So I'm going to hard pivot over to our listener question. This question comes from Jonathan. And Jonathan wrote in, "Hey, gang, longtime listener, first-time emailer. I've heard you reference retrospectives a few times as part of your normal development practice. In my limited experience with them, I often find retrospectives don't feel productive because team members are reluctant to raise issues without seeming critical or blaming another team member. I would love to hear you describe how you typically run retrospectives to foster open discussion and make it a productive use of time. Bonus points," oh, I love bonus points "if either of you have experienced rescuing an existing team that was not having productive retrospectives. P.S. Thank you for ongoing participation in the Ruby and Rails communities. I look forward to seeing a new episode pop into my podcatcher each week." All right, retrospectives. I love this question because I've definitely been part of teams that are really struggling to have a productive retro. So I think it would be helpful, as Jonathan highlighted, to go ahead and share how thoughtbot runs a retro. And then I'd also love to touch on some of the areas where I have seen teams really struggle to have a productive retro. So with the thoughtbot format, there are really two questions that we focus on. The first question is, what went well? And this starts the meeting on a positive note, which can help people get engaged before then we move on to heavier topics like concerns and issues. When we run a retro, we ask each person these two questions. So that first question, we go around to the room, and we say, "Hey, what went well for your week or for your last two weeks?" And then we document all of those positive things that people say. The next question is, "What concerns do you have, or what are you worried about?"And the goal here is to highlight issues early, which then gives us the chance to address them as they come up rather than waiting till an issue has grown out of control. And it's usually during the concerns portion that I often see retrospectives fall apart. The reason for that is hearing someone describing a concern is often something that can stir up a lot of emotions. And I know for me, it certainly triggers my instinct to where I really want to dive into that issue, and then I want to solve it. But by reacting to a specific issue and then trying to solve that issue, I'm interrupting that retrospective flow to then focus on that issue. And we may not get to a bunch of other important issues that people had. So that's often where I see retrospectives fall apart. And the way to fix that is to then have the team consensus that hey, this is a space where everybody gets to air concern. We're going to go around the room, so everybody has a chance to speak. We're going to document it, but then we're going to move on and then come back to this later. So when do we talk about concerns? So once everybody's had a chance to share their concern and that's been documented, during that process, you're often upvoting other concerns. So someone may bring up a concern that I also have as well. So when it's my turn to speak, I'll say, "I'd like to plus-one that particular concern," and then maybe add my own or just plus-one some of the others. So then, by the time that everybody's had a chance to speak, you already have an idea on…whoever's taking notes or if it's being ideally shared so the whole team can see. You can already see the concerns that most of the team is identifying with or that are the more popular concerns. So then, as a team, you can say, "Hey, we're going to focus on the top two concerns because that's really the amount of time that we have," and that way, we're focusing on concerns that impact the majority of the team. So at that point, then we can start talking about those specific issues and how we'd like to address them. And then out of that conversation is then the next part of the retro format, our action items. And then action items are where we can capture the things that we would like to try during our next iteration of work until our next retro. This is our experiment area. So then we can say, "Yes, we'd like to try something different, or we'd really like to monitor how this goes." And then one other fun thing that I typically include in retros are housekeeping. So then we can talk about time off, team celebratory events, anything like that that's helpful to highlight to the team. That's a quick overview of how typically I myself run a retro. Chris, do you have anything you'd like to add or anything that I've missed? CHRIS: No. I think that that mirrors pretty well the best retros that I've been a part of. There are a couple of things that I think I would add or emphasize in that. So one is foundationally, with a retro, what are we doing? What's the goal? And the goal with a retro is to identify and evolve our process. So identify where there are any bottlenecks or things that aren't working, and then ideally change things over time. I've been on many teams where just the same issues get brought up over and over in retro, and nothing changes. And that will just completely deflate the team. And so, if that is happening, that's a fundamental thing that we need to fix. And I can totally understand folks being like, "Retro is awful. We just sit down and say the same things, and then nothing ever changes." If that's happening, we have to fix that at a more fundamental level. That is going to be more than a retro's worth of effort. But ideally, retro is now this structured space each week, each iteration, whatever it is where we are discussing what's going on and ideally, slowly, incrementally making the process slightly better. In my experience, it's something that I really love because I come to associate it with stuff is going to get better now. That's what retro means. If that's not the feeling you have, then I totally get why you wouldn't want retro. But I promise that that can be a reality. And then to touch on some of the particular procedural points, everything you said definitely maps. And I've found that structure works really well, but there's a lot of subtle things in that structure that I think are important to highlight. So one, going around the room and actually asking everyone individually for their thoughts, I find to be so useful because it's very easy for one or two more vocal individuals to just dominate the conversation. So particularly by starting with what went well and then also by actually going around the room and requesting "Everyone reply to this question please," even if it's just like, "Yeah, you know what? It just felt like a good week." That's an answer we'll accept but ideally, a little more structure or a little more meat to it. But I find that to be really important. Likewise, I have found that having a facilitator, so someone who is guiding the retro but not actually a part of it. They're not going to be saying what went well or what didn't go well. They are just directing the conversation and somewhat critical as you're going around and asking for concerns. They are the person whose job it is to prevent the team from starting to try and address the concern when it's first voiced. So ideally, we're just collecting the concerns. We're collecting the plus-ones so that we know which are the more prominent ones, and then we can focus on those. And I think that idea of the plus-oneing of concerns and then really focusing on the ones that have more folks that are concerned about it feels really critical in my mind. So ideally, we are a team. We're working as a team, and if one person has this gripe that they really feel deeply, but nobody else really cares about it; ideally, we find a way to help that person not feel that way. But that's not necessarily where the team collectively should put all of their energy. So yeah, that's a bunch of little pieces. Also, just as a note, we'll include these in the show notes, but there are a couple of previous episodes, so Episode 132: “What Went Well?” is a discussion between Derek and Sage, previous hosts of the show, talking about retros. Episode 172: “What I Believe About Software” was the first guest visit by a certain Steph Viccari. And so that is a wonderful episode in which we dug into retro because it's one of our favorite topics. Also, Episode 299: “Is Agile Over?” We definitely touched on...that was a pretty recent one, but we touched on retro. Then there's also a video on Upcase called “Running a Retrospective” that basically describes exactly this process and shows actually an example retro and running through it. So there are lots of other things that we can point out here. But again, I think fundamentally, what are we doing, and how are we doing it? If we can answer those questions well, retro is going to be great. If not, it's probably not going to be that great. STEPH: I appreciate you calling out all of those important nuances because those nuances are what lead to then a retro feeling more productive. And to address Jonathan's other question around if people are feeling timid to bring up an issue because they don't want to blame anyone, then I think to address that one; specifically, you have to come to retro with a WE mindset. And I think HBO accidentally sending a test email is a really good example of that. Because in the Twitter thread, a bunch of other I presume developers were commenting and responding in support of the person that sent that out to say, "Hey, you discovered a missing safety net in the system," or the fact that it was fairly easy to make this mistake and send it out. So if you come to retro with this mindset of if a mistake was made, how can we as a team improve this so then it's less easy to make that mistake? Then you won't have the sense of we're blaming this on one person, but instead, we as a team are responsible for helping each other out. CHRIS: It's interesting to have that conversation in the context of retro because I don't necessarily think of retro in exactly this way. But there is the idea of blameless postmortems, which come out of the Google Site Reliability Engineering; I think it's a book, maybe it's a website. We can include a link regardless. But that idea of blameless postmortems of collectively as a team, this thing made it out into the world, this bug, this problem. So we need to own that as a team, and we need to have a blameless conversation around that, just talking about what happened. And there are subtleties there. And that's a nuanced idea that needs to be evolved, but that is at least some writing that exists in the world that talks specifically to that part of it. That said, I wonder if a true postmortem, so a distinct meeting just dedicated to those more pointed issues, might be more relevant, and then retro is more of a shared overall conversation. But if there are smaller versions of that, then I think using that framing could be really helpful in retro. STEPH: Yeah, I think you said that perfectly where there needs to be team ownership over all of the issues that are being discussed. And I think there is one other very tricky area to navigate with having a productive retro. And I don't know of a better way to say this. But you have a grumpy goose on your team. You have someone who doesn't like retros, and they're going to be negative, and they're going to be vocal. And that is a hard one. I have been there before. And I often approach that situation by speaking with them specifically around what are your concerns with retro? Are you willing to at least buy-in and give this new format a chance? But you essentially need them to buy in or have leadership buy-in so then they know to follow suit as well that this is a team process that we're going to improve and work on together. And if you don't like it, then that's what retro is for. So how we can make this a better, more productive meeting? But just showing up and being grumpy isn't helpful. And then helping people who have been burned by retros overcome that negative reaction to retros is something that takes time. CHRIS: Oh yeah. The grumpy goose just affects everything on the team. But definitely retro is one where I've seen that particularly pointed. I think in those cases, the best luck I've ever had is to, like you said, have a separate conversation but have the conversation at a higher level. So the question isn't about do we have retro or do we have it in this shape? The question is, do we think we are operating at our best? Do we think everything is going perfectly? And almost never will the answer be "Yeah, this is great. We have no bugs. We're moving as fast as we possibly can. Everyone is happy. No one is burnt out." And so if we get to an agreement that is like, well, yeah, sure, there are things that we could improve, then I think that's a toehold that we can then build on and say, "Okay, so how do you want to go about that? I am fine to explore a different approach than retro as a meeting to continually improving and evolving our process. I'd love to know what thoughts you have, Mr. Goose." But if they don't have an alternative, retro is the most effective structure that I've found for this continuous feedback loop around the process. I'm very happy to find an alternative, but I critically think we need something like that. And so if they're going to be pushing back on retro specifically, then I'll bump up to the higher level and say, "Okay, how do you want to be improving our process? Let's try something else, but let's make sure we are asking the question of how do we improve our process and is that succeeding?" And also, stop being so grumpy. Come on, what are you doing? STEPH: [chuckles] I recognize that approach so much because then it really gets to the heart of the purpose of retro whether it's actually called retro or how we handle it is not significant, but the fact that we together as a team can get together and discuss how to improve. That's really the important thing that we're after. And retro just happens to be the format that I use and really enjoy. But like you said, it's always open to each team's interpretation. On that note, Jonathan, I hope this quick overview of the thoughtbot retro has been helpful. And we will also include some other links that also highlight how thoughtbot runs retros and some other discussions that we've had about retrospectives. But on that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Tune in as Co-founder and CTO of Honeycomb, an observability platform, Charity Majors joins Chris to drop some knowlege bombs such as: Thinking of observability as being about the unknown unknowns: Allowing for high cardinality, high dimensionality, ad hoc queries at any point in time. Comparing instrumentation to a muscle: It's a habit that needs to be developed and fostered. Sincere continuous deployment: 15 minutes or bust. And bunches more, since y'all know you hear her name come up at least once during every other episode! Honeycomb.io (https://www.honeycomb.io/) o11ycast (https://www.heavybit.com/library/podcasts/o11ycast/) Charity's blog (charity.wtf) (https://charity.wtf/) Charity on twitter (https://twitter.com/mipsytipsy) Charity's post on cost of not doing continuous deployment (https://charity.wtf/2021/02/19/how-much-is-your-fear-costing-you/) Charity's post - The Engineer Manager Pendulum (https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) Transcript: CHRIS: Hello, and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week Steph is taking a quick break, but while she's away, I was joined by a special guest, Charity Majors. Now, folks who've been listening to the show lately will know I've been mentioning one idea or another from Charity almost every episode these days. Charity's work spans from the deeply technical through to the deeply human. And across all of it, she brings such a wealth of experience in pragmatism while consistently providing grounded, actionable advice about how we can improve all aspects of our work. And to give a bit more context for those who aren't as familiar with Charity's work, she is the co-founder and CTO of Honeycomb, which is an observability platform that we talk about more in the episode. Charity is also a prolific blogger, tweeter and speaker, and general leaver of digital breadcrumbs for the rest of us to hopefully follow. And Charity is also one of the hosts of the o11ycast podcast. That's observability, o11y podcast. And in fact, in the intro to the first o11ycast episode, Charity provides a beautiful summary of her approach to the varied work that we do. Quote, "I'm someone who's always been drawn to where the beautiful theory of computing meets the awkward, messy reality of actually trying to do things." And that quote rang so deeply true to me when I heard it and really encompassed what I see across the variety of work that Charity has shared with us. And frankly, I've been so impressed with the quality and quantity of wonderful content that Charity has shared over the years. I was really just thrilled to get the chance to sit down and talk with her directly. So without further ado, here's our conversation with Charity Majors. Thanks so much for joining us today, Charity. CHARITY: Thanks for having me. It's great to be here. CHRIS: As I've mentioned on many an episode, I've been following your work for a while now. And at this point, I would say that just about every Bike Shed episode has a reference to you and some piece of work that you have put out into the world, whether it be a tweet or a blog post, or a conference talk or something. So I'm so grateful for all the work that you put out into the world and for taking the time to chat with us today. CHARITY: That's so exciting. Yay. I feel right at home here then. [chuckles] CHRIS: Fantastic. Well, I want to dive in. I think it's sort of the core of some of the conversation that we'll be having, which is around instrumentation and observability, and observability as a newer, noveler form of how we think about this space. But to give a bit of context, I was hoping you might be able to give just the quick summary for anyone who might not be as familiar with observability as a concept and what that means now, and Honeycomb as a product and how it offers affordances around observability and pushes that envelope forward. CHARITY: Yeah, I think of the observability as being about the unknown unknowns. For a long time, all of the complexity was really bound up in the app. You had the load balancer, you had the app, and the database. And all the complexity you could just attach to a debugger and step through it if you had to. But then we kind of blew up the app, the monolith, and now it's in services scattered to the winds, and you can't just trace it. And so observability is a way of passing that context along hop by hop so that you can actually slice and dice in real-time. And the hardest problem is not usually debugging the code. It's finding out wherein the system is the code that you need to debug. And observability, if you accept my definition, which is it's about unknown unknowns, that you should be able to ask any question of your systems, understand any internal state just by observing it from the outside, well, then a lot of things proceed from that, in my opinion. Like, you need to be able to handle high cardinality, high dimensionality. You need to be able to string together a lot of these high cardinality dimensions. You need to... any kind of schema or indexing scheme in advance is verboten because you don't know what questions you're going to need to ask. And so there's a lot that flows from that definition; arbitrarily-wide structured data blobs is the source of truth, et cetera. But at its heart, it's just about the concepts, that our problems are getting harder and harder. We don't get paged to go, "Oh, that again? Oh, that again?" CHRIS: [chuckles] CHARITY: Ideally, we fix those things. But we still get paged. What the hell is this? It's about allowing engineers, empowering them in a reasonable amount of time to be in constant conversation with that code that's out there in the world because most problems honestly we never get paged about. They're too subtle until they snowball, and they pick up other problems. It's like a hairball under your couch until it gets so big and so impacting that it actually does alert someone. And then you just start picking up the rock and be like, oh God, what's that? Well, we've never understood this. And that's why ops has such a reputation for masochism. [chuckles] CHRIS: Absolutely. There are so many little pieces in what you just said that really deeply resonate with me, although there is one facet of some of the way that you talk about observability that I find interesting. I'm someone who likes to cling to the perhaps unrealistic these days ideal of a monolith of what if we were to just keep everything in the same place and all the data lived together in one database, and I could have foreign keys, and consistencies, and asset compliance? CHARITY: Which you should do for as long as you possibly can. You should never impose more complexity on yourself than you absolutely need to. And I would say that it's never not better to have observability than the older paradigms of monitoring and so forth. Some of Honeycomb's biggest and best customers still use monoliths. But they still find it really valuable to be able to apply the principles. I think that it's the microservices revolution, if you will, that forced this set of changes. It was inevitable. The steps that I started talking about, like, somebody would have because the older way just became untenable when you started adopting containerization and a lot of these things that made everything suddenly a high cardinality including the number of applications you have. But it's never not better to have high cardinality tools and to be able to instrument your code for spans and tracing. Tracing is still valuable even in the monolith. CHRIS: Yeah. As I've observed and started to play around with Honeycomb, that's definitely what I've seen is I'm almost exclusively working in the context of monoliths and, like I said, clinging to them for as long as I possibly can, which isn't going to be forever. CHARITY: It's true. [chuckles] CHRIS: I recognize that truth, but already I see the value. And so Honeycomb is a platform that you've built that allows for this high cardinality, high dimensionality ad hoc queries at any point in time. And so the idea that I can come into the tool and say, "Huh, I've got a new novel problem today." I don't need to re-instrument my code. I can just ask a new question, and the system will responsively be able to answer that question, ideally. And that feels like it holds true in a monolith all the more so, like you said, in an SOA architecture. But even in my safe little playground of everything is in the same space, I still don't know how everything's working all the time if we're being honest. So being able to answer those questions feels meaningful. CHARITY: Totally. I think that one way of thinking about the SOA or microservices is that it pushes a lot of what was in the operations realm into a realm of development, and suddenly you're responsible for a lot more of the operating of your services, things like retries and backoffs, and load distribution, and thundering herds, and all these things that ops traditionally took care of. Well, now you have to think about them. So you need some ops tools, too. What I like about...of course I like everything about Honeycomb because we designed it for this problem. But it speaks in the language of variables, and endpoints, and functions, and not in the low-level language of proc IPv6 timeouts and stuff where I feel like ops has also traditionally been the translation layer between software engineers and their actual code in production. And it's time to start giving software engineers those tools in their own language. CHRIS: Yeah. I love that. And I'm very happy to have Honeycomb as part of an instrumentation stack, which actually shifts me to the next question, which as I look at Honeycomb, very quickly the first time I saw it, I was like, oh okay, this makes sense. I want this in the world. CHARITY: Oh, I like you. [laughs] Not all people are like you. CHRIS: It might have been my second or third look, but it was definitely...once I got it, I was like, oh yes, I absolutely want that. But now, the question that I have is I typically will have a collection of tools that exist in this space. And there's a weird Venn diagram overlap of well, there's logging, and there's error tracking, and there are APM performance tools, and there's metrics, dashboards. And my sense is that Honeycomb perhaps can or an observability tool more generally can subsume a bunch of those, but it's not clear to me exactly. I think I probably still want logging. I think I still want error tracking as a discreet service tool that I'm using but maybe not APM and maybe not metrics as a distinct thing. Maybe I can infer those from a tool like Honeycomb. But I'm wondering what's the current thought on that? CHARITY: Well, part of what you're seeing is just observability tooling is very new, and we haven't had time to grow up. And here I'm like, officially, we play very nicely with all other vendors, and none of us would ever try to compete or take away from each other's faces. But I do think that ultimately, logging pretty much the only real use case for it is security stuff, the security archiving, just keep every log light. It's gotten cheap enough, but it's not actually useful for debugging or understanding your system, not really. It's useful for compliance. It's useful for proving that you did something in the past. Most logs are just a pile of trash, but they can be useful trash. And I understand people's emotional want to hold onto them for a while, and there's nothing wrong with that. There's nothing wrong with keeping some trash around for a while, while you make it...[laughs] Sorry, not to totally slam on logs, but they are trash. CHRIS: I love the analogies that we're going for. [laughs] CHARITY: But the thing about observability is I do think the kind of center of the world is these arbitrarily-wide structured data blobs from what you can infer logs, from which you can infer metrics, from which you can roll-up. So I do think that well metrics are the right first tool for understanding infrastructure. Like if you're Amazon and you're responsible for all this hardware and stuff, you should be asking yourself, is my service healthy? But if you're someone who's writing and shipping code on top of that service you care about, can my request complete? What is my user's experience? And that's observability's territory. So I think that ultimately, I do think metrics, logs, and traces all get subsumed under the observability umbrella and performance management, too, if the tools get built correctly. There will still be use cases. They will just get smaller, for logs, for standalone metrics tools. Honeycomb just launched our metrics product. Metrics is like a 30-year-old piece of technology. Prometheus and Datadog are going to be the last best metrics tools ever built. We have wrung the water out of this laundry. [chuckles ] But we aren't trying to compete with that. What we are trying to do is give people an on-ramp into Honeycomb. They've got decades' worth of stuff. They've been corralling metrics, structuring them. You rely on them. You don't want to give them up. So yeah, let's feed them in. Let's give them an overlay. And number two, the more interesting use case for me is when you're a software engineer who's writing and shipping code, you do care about did the memory usage just triple, or is the CPU completely buzzing after I shipped my last change? But there's really only like three or four of those metrics that you really care about as system metrics. The rest are mostly legacy. CHRIS: I like the idea that aspirationally, Honeycomb is moving towards a place where given sufficient input data, given this arbitrarily-wide data blob with high cardinality, et cetera, that we can infer basically all of those others from it. But also speaking to also observability is somewhat new, and so we got to build a lot of product to get there and that idea that there is perhaps a space right now where you might be bringing together a few of these tools. But if there is a future world in which I can have one of these tools that just handles everything and tells me about my code and directs me to the line of code that I incorrectly instrumented, that would be wonderful. Happy to do the work in the interim to cobble it together from the pieces. CHARITY: The place in the meantime that we're at where all of these big vendors are acquiring other vendors and trying to put together...they're like, we have three pillars. Coincidentally, we have three products to sell you. It's like, it's not good for the users because when you're...like, you're sitting in the middle here. You've got your metrics dashboard. It's telling you that there's a problem. Okay, if you can't slice and dice and figure out what it is, you have to jump over into logs and visually correlate based on the times and hope no timestamps are wrong and try and find the thing. And then, oh, okay, so you want to trace it. So you've got to copy over and try and find that in your tracing product and hope that that would get sampled in. It's not good. You can't follow the question from the beginning. I have a problem to the end. I have a solution and back. And it's not linear. You're going to be following a trail; then you're going to need to back up, then you're going to find another trail. And then you're going to want us to zoom out and see who else is impacted. And you really can't back your way into that with different products. You have to start with the arbitrarily-wide structured data blob. What does confuse me is I know that New Relic is built on this. New Relic has these. And we almost didn't start Honeycomb because we were just like, edit data, and New Relic is going to figure it out. Here we are like six years later, and they still haven't fcking figured it out. [laughs] But like Datadog, they aren't based on that arbitrarily-wide structure, so they are really...and I know that they're trying to get...all of these big vendors are trying to get to where Honeycomb sits technically faster than we can grow up and become a business. CHRIS: The race is on. CHARITY: Yeah. It's fun. CHRIS: One of the related things that I've seen you talk about a few times is the idea that instrumentation is a muscle. It's a habit that needs to be developed and fostered, and that rings very true to me. At the same time, a lot of my instrumentation work has been more in a reactive space. If we're being completely honest, something went wrong; we can't figure it out from the information that we have available, so then we go in, and we add a new logging line. We wrap the code in some way. And so I'm wondering if you can talk a little bit more about that. What does that look like in practice or perhaps some examples or something? But how can we tease that apart and understand that a little bit better? Because it sounds wonderful to me. CHARITY: I think of instrumenting a lot like commenting your code. It's a way of thinking to the future and reverse engineering; what am I going to care about? What is someone else going to care about? And I really do think of commenting as just a less true version of instrumentation, honestly. It's you talking about what you think the code should be doing, but you've left production out of the loops. You don't know what the code is doing. [chuckles] But ideally, they're kind of the same muscle. It's why you're writing your code. You've just developed a monitoring thread almost in your brain. It's like, yeah, this is going to be valuable. Oh, this is going to be valuable. And so I do think that it's on vendors to make sure that we do as much for you as possible. And this, honestly, is the long winding journey to Honeycomb finding product-market fit, which took almost three and a half, four years. And for a long time, I was like, it's not magic. You have to understand your code. You have to blah, blah, blah, which is true. But also, we need to walk closer to the user. We need to make it easier. We need to do the beeline, which will initialize the event, pre-populate it with a bunch of stuff, create the framework so that all you have to do as a user is just printf now and then just stuff this in the blob, vendors making it as easy as possible, as automated as possible. We have more to do. We really should be pre-populating it with all of the language internals and all of the stuff about the environment. We'll just be glad to tap that well. But there's something that we can't do for you, which is understand what you're trying to do and what is important. Honestly, here's a story from the past. The reason that New Relic was so big, they hit the ground, and they super hockey-sticked everything was because they dovetailed with the rise of Ruby and Rails because Ruby allows for so much fcking monkey patching. Every web app looks the same. You can just be like, we assume all this crap, and so we could make it just like magic for you. You just install this library. Boom, you're off to the races. Well, try as you might, I want to say a type language like Go, you can't do that stuff with. You can't make it as magical. You have to think a lot more about how you're structuring things for better or for worse, which is why their growth slowed because those languages just aren't so popular anymore. So it's trade-offs all the way down. Yes, everybody should be an expert in forecasting the future and understanding all the subtle things that you don't know you're going to know, but you're super are going to want to know. But as you've discovered, most of your learning comes from being in the trenches, which is why it's so good for devs to be on call and be close to their code and be in this constant conversation with it because you develop a sixth sense. I can't tell you exactly why I know it's going to be a problem, but I'm just going to wrap it because I'm pretty sure it is. CHRIS: There was a tiny bit that I was hoping that you would have some very specific like, oh, you just do X, Y, and Z. I kind of knew that wasn't going to be the answer, but it also represents something that I so appreciate about your thinking and the work that you put out into the world, which is it's realistic. Sometimes you're like, you know what? There's going to be some tacit knowledge involved here. You got to put in the work. You got to learn the thing, and that's just true sometimes. And so I appreciate your willingness to be like yeah, you know what you got to do? You got to do the work. And then after that, you'll know...and so there's sort of a virtuous cycle that can happen here. There is a feature, as far as I understand it, of Honeycomb, too if I can briefly hype up your products slightly but the idea that you can observe the series of questions that another developer asks. So if they were in a debugging session, you can see like, oh, they asked this, and then they asked this, and then they filtered on that. CHARITY: It's like your Bash history but for debugging. [chuckles]. CHRIS: I want this for everything. CHARITY: Right? CHRIS: Let's have a shared hive mind of the developers on a team, both in terms of our observability tool but also just kind of everything. CHARITY: What did you do? CHRIS: Yeah, what did you do, and why? What were you thinking? I saw you went down a road there, but then you stopped and backed up, and you went a different way. That's interesting to me. CHARITY: This is why we keep trying to build things into the product that will incentivize people to write texts about what they're doing, whether it's retroactively applying tags or writing a breadcrumb to yourself. Why was this meaningful? As you're putting it in your bookmarks, why are you putting it in your bookmarks? Collaboration is just as much about collaborating with your past self and your future self as it is with the rest of your team. I don't remember why the fck I did that two years ago. I don't know. I don't know why I did that two months ago. But the more you can leave breadcrumbs for yourself and then surface that to the team, you're right; it's transformational. I wanted this so selfishly because I have never been that person on the team who loves graphs. I hate graphs. I don't think visually very well at all. I've been working with my friend, Ben Harts, off and on for like 10, 12 years now. He's always the person I've hired repeatedly. He's always the person who comes in and makes the graphs. And then I look over his shoulder, and I bookmark them. I can be up all night making the perfect dashboard. And then I'm like, great, mine. [chuckles] So there's room in the world for both of us. But the point is that not all of us should have to go through that effort. [chuckles] We should be able to learn from each other. Only one person should ever have to have to craft the perfect query, and then the rest of the team should be able to effortlessly piggyback on it. CHRIS: Yeah, absolutely. And again, I want that but for everything. I dream of a future in which that's true. CHARITY: And so much of debugging is this wandering path where you go down the wrong place, and you need to be able to zoom back to all right; where did I first know that I had a beat on it? CHRIS: There's a corollary that I see to pair programming where one of the things that I find so valuable is, what Google query do you type in when you hit that wall? When you're like, oh, this isn't working as I'm thinking, and then you type something and I'm like, whoa, wait, I wouldn't have even thought to ask that question of the internet. CHARITY: Oh, I love that. That's fantastic. CHRIS: But now you've productized that, and I love that. So thank you for building that thing in the world. CHARITY: Excellent. CHRIS: Shifting gears slightly, one of the other themes that you really pushed for in the world is the idea of continuous deployment and not like yeah, you should ship your code pretty quickly after you merge it, but true, sincere continuous deployment. CHARITY: 15 minutes or bust. CHRIS: 15 minutes of bust, test in production. There are some really wonderful if we're being honest, scary themes that you talk about. I love the ideas that you're putting out there, but they're probably the things that I look at, and I'm like, ooh, that seems like a whole thing right there. CHARITY: It assumes a lot. Let's put it that way. It assumes a lot. CHRIS: It definitely does that. I desperately want to get to that world. I want to get to the place where there's that confidence. And similarly, there's a theme that you've talked about around Friday deploy freezes and why that's not a good thing. And the empathy for humans that part's good, but maybe we're applying it in the wrong way if we say we're not allowed to deploy code on Friday. Because it's like yeah, deploying code is terrifying and scary. No, let's solve that problem. But I wonder if you can talk a little bit about that. How do you get there? How do you get to the place where continuous deployment is a realistic outcome for you? CHARITY: Yeah, that's a very good question. There are no easy answers, unfortunately. And the answer is always going to depend on where are you starting from? Are you starting from a clean slate? Are you starting...a lot of the advice that I give sounds like Looney Tunes to someone who's coming from enterprise because they're just like, "You don't understand the constraints that I am operating under." And I'm like, "Yeah, you're right. I'm not of your world. That probably shows." [chuckles] So I think the easiest way, though, is always when you're starting a new project that what you do on day one would be to set up your CI/CD and deploy it to prod before you've even started building. My favorite analogy to that is to like...you know the myth about Alexander the Great and his horse how when he was a little boy he would pick it up every day before he had breakfast? And so, by the time he was an adult, he could pick up his horse because he picked it up every day, and it was never hard. When you start deploying that way, it's never hard. When you're just like, okay, anytime this gets above 10 minutes, we're going to put in a couple of hours of work, and it's never hard. It's just the easiest thing in the world. And everything's easier because you get to watch what you're doing and in real-time, and you develop that muscle of I'm merging it to main. I'm going to go look at it in a couple of minutes. And you don't feel done in your gut until you've looked at it. And that's doing it on easy mode. And you can do this in a hybrid way. Even if you have like, well, I'm paying for a deploy. Nobody is saying you have to sign up for a long, painful deploy process when you got to spin up a new project. And I've seen it gain momentum. If you start something that's clearly the new way, everybody sees how fast this team is executing. Everybody wants a piece of it. And so you start learning from the way that you are able to do it in your unique environment. You're the best evangelist to the rest of your team members because you know the subtleties. You know the problems. So that's the easy answer is start fresh. [laughs] CHRIS: [laughs] That makes sense. I do, again, I appreciate the pragmatism or the realism of the way that you approach a lot of the topics. CHARITY: Another answer, though, it's just that the engineering work involved in taking a deployed pipeline down from hours, days, to 15 minutes it's just engineering work. It is just labor. It can be done. The political problems are the hard ones. I mean, in the past, sometimes our deploy probably would get up to two or three hours, and we were just like, oh God, this is not…put in the work. You just start instrumenting your pipeline, and you start looking at where the tests are taking time. And it will pay dividends every bit of time that you pay down, which is why I really see these long…our own pipelines is it's a vacuum of engineering leadership that they've allowed it to happen because there's nothing fancy about it. You just put in some work. CHRIS: Yeah, the solvability of the technical challenge feels very true, but what you're saying of it's people problems which again, that's always true of the tech stuff. CHARITY: It is people problems, but I also hate it when people are just like, oh, it's people problems. That means mysterious and unsolvable. Now, most of the time, when you see this, it's a lack of collective confidence in themselves. They see this as being as just for the elite engineers, or only ex-Googlers are allowed to do this or something. Or they go to conferences, and they hear about it, and they're just like, God, I wish I was allowed to do that, or I wish we could do this. But the thing is that engineers have more power than they realize. We build these companies. They wouldn't exist if it's not for us. We have all the power if we just choose to use it. I know that a lot of these people who I've talked to that were just like, "Oh, I wish we…" I'm like, "Have you ever lobbied for it?" And they're like, "No, I just know we could, or that's someone else's decision." I'm not going to promise you that you can get whatever you want. But I promise you that if you start speaking up if you start talking to your colleagues and being like, "Wouldn't it be nice?" And they start speaking up...if a quarter of the engineers want something in the company, it gets done. [chuckles] CHRIS: That definitely feels true. And to the topic of actually lobbying for this and having the hard conversations internally and working on the people problems, you have done, I think, a really fantastic job of providing actual benchmarks in terms of timing and what does this look like as a practice and what are the multitasks? CHARITY: It's so expensive. It's so costly to organizations. And it's the easy answer for any engineering leader to be like, "Well, we need to hire." That is the laziest answer in the world. You probably don't. You probably just need to fix your CI/CD system and then bask in the resources that you suddenly freed up. [chuckles] CHRIS: You have a wonderful blog post that really I think does such a good job of highlighting the cost that you're talking about there, the human costs for every slowdown in your deploy process, it has this downstream ramification. And having that as sort of a piece, a bargaining chip in the conversation of here's a voice that is saying a very clear thing about this cost of not doing this work, which granted, it's always trade-offs. Everything is an optimization. But here is a way to actually measure the cost of not going with this approach. And again, I appreciate you're putting that out there in the world so that the rest of us can be like, "Look, on the internet, it says so." CHARITY: [chuckles] Exactly. I'm happy to be the internet for you. But it's so true because other people in your business don't want you to suffer too, either. They don't want everything to get slow. They just aren't equipped to understand the cost of this slowness the way that engineers are. And I feel like sometimes this is...it's like we're always lamenting like, why does product get to own all the engineering cycles? Where aren't we allowed to do all this other stuff? I promise you're allowed to. You just have to make the case because the case is righteous and justified. But you have to explain to them the cost that it's incurring your organization in terms of your ability to execute and in terms of your ability to hire and retain people. You just have to explain those costs. And engineers are just like, "Well, we only say it once, right?" Well, that's not how you win arguments. You have to say it. You'll probably lose. And you say it again, and you'll probably lose. You say it a third. And you will win eventually because you control all of the creative labor of the technical organization. So just make the fcking case. [chuckles] I don't know. I make it sound simple; it's not. CHRIS: I love the sound bite of the cause is righteous, and that is the kernel of the thing here, which is like, just to be clear, this is a virtuous path that you were going down, battle for it, work towards it, absolutely. So I think a related topic here, so continuous deployment is one of those things that you want to get to and a practice that you want to evolve to. But in exploring some of your other work, one of the things that I was exposed to is the DORA metrics, which is not something that I hadn't seen before. But for anyone who's unfamiliar, the DORA metrics is a set of four key metrics to track developer and team productivity, so their deployment frequency, lead time for changes, change failure rate and the time to restore the service. And they are deeply interesting because frankly, I have for a long time felt like developer productivity was not really a quantifiable thing. CHARITY: It's not, yeah. CHRIS: Individual developer productivity I still feel like this is a bad thing. Don't do that. But team productivity these metrics actually are like oh, actually, as I look at those, those seem like the good ones. We should do that. I'm wondering, what does that look like in practice when you see that actually employed within an organization? What are the feedback loops, and how does this appear in the world? CHARITY: Yeah. We all owe a huge debt of gratitude to Jez Humble, Gene Kim, and Nicole, who worked on this for years and got this out into the world, just putting some actual research behind the stories that we were telling ourselves about productivity. And people who haven't read Accelerate...a lot of people are always asking me, do we have any stories? Do you have any research? Do you have any proof or something? I just always point to the book Accelerate. That's where it all comes from. Yeah, it's true because it's such a noisy world. When you're an engineering org, and there's just so much going on, and there's so much stuff that bugs you personally, and some of the stuff that you have true beliefs about. And it's hard to just cut through the noise. And I feel like that's the great gift of the DORA metrics. If you start focusing on one of them, you will lift your org out of poverty, and the others will get better too. And it provides just this wonderful focus point for teams that aren't sure where they stand or aren't sure how to get better because it can be so mystifying. When you're in the trenches, and you're just like, why does everything feel so hard? Why is it that we thought this would take two days, and here it is two months later, and we can't ship anything? And it feels like the more we ship, the farther behind we get. These are the beacon of hope. It's like, you pay attention to these, your lives will get better. You can dig yourself out of this ditch. That's certainly been true for the teams that I've been on. And high-performing teams, I think we all have this idea in our heads that high-performing teams are ones where the great engineers join when in fact, those great engineers could join your team, and they wouldn't get any more done than you are. Because most of our productivity is defined not by the data structures and algorithms that you know but by these social-technical systems that we swim in every day, it's the water around us. It's the friction involved in getting that code to production. If it takes the magical engineer from Google 24 hours to get their code changed out, well, they're not a member of a high-performing team either. You mentioned earlier all these people are out there who haven't experienced a world like this don't live in a world like this. And in my experience, they often lack a lot of confidence because they don't think they're that good, or they don't think that they can have nice things. And the DORA metrics that's your ticket to a better life. It's like go to college and graduate because it kicks off these virtuous feedback loops, these cascading cycles of things getting better for everyone and people getting more excited and energized. And they just don't get burned out by shipping too much code. They get burned out by not being able to ship code. And if you're a leader in any type of organization, and I don't just mean manager, I mean any type of senior engineer or manager or whatever, then it's part of your job to pay attention to these metrics, lobby for them, track them, track them on your own if you must, and try to make them better because every engineering team has two customers or two...whatever. I'm blanking on the word. But it's your customers and your engineering team. You're responsible to both of them. And I've never seen one of those sets deliriously happy and the other set miserable. They tend to rise and fall in tandem. CHRIS: I'm just nodding along for anyone in the audience who can't see what my head's doing. But I love so much all of the things that you're saying and, again, the passion and conviction that you bring to this conversation because these are amorphous, hard to pin down ideas. But I appreciate the North Star that you're setting across all of these different things that as I'm reading, I'm like yeah, that sounds true. I want that. Those things are the things that I want. But interestingly, one of the other threads that I see weaving through a lot of your work is obviously we've talked a bunch about just deeply technical topics thus far, but also a lot of your work spans across to the interpersonal. And frankly, even dividing in that way is not representative of the world because it's a Venn diagram mishmash of some days it's technical, some days it's personal, some days it's both. But one of the things that you've talked about is the engineer manager pendulum which I find super interesting. I think every engineer at some point has that question, that internal oh, do I want to go engineer track or manager track? And this distinct idea or the idea that management is a promotion and any other movement would be different, and you have wonderful things to say about that. The other thing that you've pointed out is that former managers can often make great engineers after the fact because of the earned empathy that they have now from looking at things from a slightly different angle. CHARITY: Amazing engineers. CHRIS: But I'd love to hear a little bit more of your thoughts on that because I think it's such an important space, and I've definitely previously operated under I'm an engineer, and then I guess I got to be a manager, and then I guess I don't know where I go from there, but it's this very linear path. And you shook that worldview of mine, and again, I appreciate that shaking. But yeah, I'd love to hear a little bit more about that. CHARITY: The best people that I've ever worked with have been engineers who had been managers for a while and then went back to engineering, and it's not just empathy, although there's a lot of that too. It's also a deeper understanding of the business and the reason that we do things. So much of being a powerful engineer is choosing the right work to work on so that you get a lot done very efficiently and quickly, and you don't spend a lot of time just foundering, which you've mastered, and you know the basic technical principles. And how do you get better? A lot of it is just getting better at identifying what to do and what not to do because we have to not do so much more than we can ever do in order to move forward. I wrote a blog post as a present for a friend of mine who was a director of engineering at the time, and he was suffering. He was just miserable, and he kept thinking about going back to engineering, just kind of dragging his...because he wasn't in an org where that was really celebrated or anything. When you've been there from the beginning, you built the organization; you're like a senior director and everything. It feels like a long way to fall. And I wrote that post for him. And he did end up going on to be an engineer after that. And he was so much happier. But I think he was surprised at how he didn't fall at all. He actually probably had...I think the engineers had a higher opinion of him afterwards when he was one of them again. And he still had this vaunted voice because he could speak to how the system had been there since the beginning. And he basically got to look around and look out farther than the engineers who were heads down every day and go, "This is going to bite us. I'm going to take a small team. We're going to do this forward-looking security product." I don't want to identify details, but that for me really just kind of cinched...It was like the more we can strip hierarchy out of these discussions; the healthier everyone's going to be because we're just monkey brains. And the monkey brain in our skull hates losing hierarchy, hates losing power or stance or anything. And I think that the thing that you learn after you've been a manager is a lot of it is just the wizard behind the curtain, the idea that you have more power as a manager. You have more of some types of power, and you have a lot less of other types. And you're just as constrained as the engineers but in other ways. And the path moving forward is not to dominate people or be above them but to combine your powers for good and self-sort to find a place that actually gives you the most joy. CHRIS: It's a wonderful philosophy. And actually, a thing that you said in there really stuck out to me, which was you wrote that blog post as a gift to someone, and that is such a kind thing to do. And it also, again, reflects what I see in your work overall. You're really clearly leaving a trail of breadcrumbs behind you to help other folks that are traversing a similar path by questioning aspects of it. Or how do we do this well? Why is everyone sad, and why is it bad? And so again, I so appreciate all of that work that you've done. CHARITY: I think that that comes from my lifetime in the trenches of operations. [chuckles] Ops is notorious for the pain that we bring upon ourselves and try to solve. But I would just like to add a pitch out there for other ops engineers of the world and our colleagues. I was fortunate enough to rise up through the ranks in organizations that really respected operations. We always felt we ruled the roost. We felt like we were way above all the other developers. We got to say what went into production and what didn't. And I feel like ultimately...if you have to have an imbalance of power, I think that's slightly healthier than the developers ruling the roost. Ultimately, there shouldn't necessarily be any imbalance of power. But I just want to pitch it; this whole no-ops thing really got my goat for a while there because operations is just the engineering workaround delivering value to users. I think the second wave of DevOps is now about okay, software engineers; it's your turn. It's time to learn to write operable software. And so I just wanted to throw in my hat in the ring for all the ops people out there. You're just as good. You're just as good as anyone else. [chuckles] CHRIS: I mean, it's sort of a theme that I've seen in your writing of everybody's doing good, important work and breaking down hierarchy and just collaboratively moving in the same directions and trying to choose the right North Stars to aim towards. And yeah, it's all fantastic. And so with that, I think we probably reached a perfect spot to wrap up. But Charity, if folks want to keep up with more of your work online, where are the best places to find you? CHARITY: My blog post is at charity.wtf, and I'm @mipsytipsy on Twitter, and of course Honeycomb.io and our blog. CHRIS: We will include links to all of that and many of the blog posts, and other podcasts interviews that you've been on, and a bunch of just various things that I collected as I was preparing for this episode because, again, you've produced such a wealth of information on the internet that I want to point as many folks as possible towards those things. But yeah, thank you so much for taking the time. CHARITY: My pleasure. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,; you as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

What do you get when you mix a worm and a hammerhead shark? Also ants. Steph made some cool new discoveries in bug-land. She also talks about deploys versus releases and how her and her team has changed their deploy structure. Two words: feature flags. Chris talks about cookies: cookie sessions, cookie payloads, cookie footprints, cookie storing. Mmm cookies! The convo wraps up with lamenting over truthiness in code. Truthy or falsy? What's your call? Flipper (https://www.flippercloud.io/) Bike Shed - Ask a Question Form (https://docs.google.com/forms/d/e/1FAIpQLSdaFfPYoWmtV3IR3eQRjNz731GJ_a2X6CpZFxKjdPZeztGXKA/viewform) Transcript: STEPH: At the top of my notes for today, I have marauder ants and hammerhead worms. [laughs] CHRIS: I'm sorry, what? I lost you there for...not lost you, but I stopped following. I...what? Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going? STEPH: Hey, Chris, it's been a good week. It's been busy, lots has been happening. I learned about a new creature that's in our backyard. They're called hammerhead worms. Have you ever heard of those? CHRIS: I've heard of hammerhead and worms, but not together. The combination is new and novel for me. STEPH: Cool. Cool. So take a hammerhead shark and a worm and combine the two and then you have a hammerhead worm. And it rained really heavily here recently because there's a tropical storm that's making its way up the East Coast. And when I was outside on the porch, I noticed that there were these new worms or worms that I'd never seen before on the back porch. And so I had to Google them to understand because they had the interesting hammer-shaped head. And I found out that they're called hammerhead worms. They're toxic worms that prey on earthworms. And they're basically immortal because if you cut them into multiple pieces, each section can regenerate into a fully developed organism within a few weeks, which is bananas. And a lot of people online highly recommend that you should kill them because they are a toxic predator and they prey on earthworms, which you want in your garden and in your yard. But I didn't, but I learned about them. CHRIS: Wow. That's got some layers there, toxic, intense worms that you can cut in half. And so does their central nervous system just spread throughout their whole body? Where's their brain? How does it...I don't have any real thoughts here. That's just a bunch of stuff, and it's awesome. Thank you for sharing. STEPH: I will warn you. I wouldn't read about hammerhead worms right before bed. Otherwise, you might have some nightmares because the way that they do prey and consume earthworms or other creatures that they prey on is the stuff of horror movies, which I find happens so much in nature, but them especially they fall into that category. So just be aware if you're reading about hammerhead worms and how they consume their food. Now I feel like everybody's going to go read. But as long as you have that warning, I feel safe sending you in that direction. CHRIS: Yeah, first thing in the morning on a very sunny morning, that is the time to do this research. STEPH: Exactly. He got it. I also learned about marauder ants because apparently, this is the day that I'm having. I'm learning about all these creatures. But I won't go into that one, but they're really interesting. And this one's thanks to someone on Twitter who shared, specifically @Rainmaker1973 is their Twitter handle if you want to go see what they shared about marauder ants. So I'll just leave that one for those that are curious. I won't dive into that one because I don't want to take us in the direction of that we're all about worms and ants now. CHRIS: Not all about worms and ants but definitely some. STEPH: But in technical news, I've got some stuff to share, but I was so excited about worms and ants that now I have to figure out which is the thing that I want to share from the week. So there's a couple of interesting things that I'd love to chat about with you, one of them, in particular, is there's been some interesting conversations going on with my client team around deploys versus releases and how we have changed our deploy structure, and then how that has impacted the rest of the team as they are communicating to customers as to what features are available. And there have been some interesting conversations around how to migrate this process forward. So to provide a bit of context, we were previously having very strict, rigid deploys. So we would plan our deploys typically every Tuesday. It was usually once a week. And then we would make sure that everything had been through QA, things had been reviewed and tested. And then we would have one of those more like grand deploys, things are going out. And then hey, if you need to get something into the deploy, let us know; we need to talk about it. So there was just more process and structure to that. And so deploy really mapped to the idea that if we are doing a deploy, then that means all these feature bug fixes are going out, and this is now the time that we can tell customers, "Hey, this new feature is available or this bug that you reported to us has now been fixed." We have since been moving towards a more continuous deployment structure where we're not quite there where we're doing continuous deploy, but we are deploying at least once a day, so it's a lot more frequent. And so this has changed the way that we really map the idea of the work that's being done versus the work that's actually available to customers. Because as we are merging work into the main branch, and then let's say if I'm working on a feature and then I merge that into the main branch and then push it up staging, we have an overnight QA process. So then overnight QA, if they say, "Hey, there's something that's wrong with this feature. It didn't quite meet the required specs," then they can kick that ticket back to me, but that's not true for my code. We could do a revert and take my code out at that point. But at this point, it's in main, and main may have been deployed at that point. So there have been some interesting strategies around how can we safely continue to deploy while we know we often have a 24-hour wait period for QA and to get sign-off on this work? But we want to keep moving forward and then also communicate that just because the code has been deployed doesn't necessarily mean that it's available to customers. There's a lot there. So I'm going to pause and see if you have questions. CHRIS: Well, first, I'm just super excited to talk about this. This is something that's been very much top of mind for me, and it's a direction that I want to be going more and more, so yeah, excited that you're pushing the boundaries on this. I am intrigued. I'm guessing feature flags is the answer about how you're decoupling that and how you're making it so that you've got that separation of deployment and actual availability of the feature. So, yeah, can you talk more about that? STEPH: Definitely. And yes, you're right. We're using feature flags, so we'll use the same scenario. I'm working on a feature, and I want to be able to release it safely, so I'm going to wrap it in a feature flag. And I'll probably wrap it, and maybe it's like a beta feature flag, something to indicate that this is a feature that's going to be available to all, but we don't actually want to turn it on until we know that it's truly ready to be turned on. So then that way, it's hidden, but then we can still merge it into the main branch. We can still have a deploy even if my code hasn't gone through QA at that point, but we know it's still safe to deploy. And then, QA can go to a staging environment; they can test it. And if they say, "No," it's fine because nothing was churned in production. But then, if it gets approved, then we can turn it on, and then we'll have a follow-up to then remove that feature flag. CHRIS: So some follow-on questions. I'm wondering about the architecture of the application. Is this like traditional Rails app rendering HTML on the server, or do you have any more advanced client-side stuff? And then I'm also wondering what you're using for the actual feature flagging, and those will probably inform each other. But what's the story on both of those fronts? STEPH: It's a traditional Rails application. So we're not using any other client-side application. It is Rails and rendering HTML. As for feature flags, so we're not using something traditional. And by traditional, I mean I typically have reached for Flipper in the past for managing feature flags. We're using more of a hand-rolled approach because there's a lot of context there that I don't know is necessarily helpful. But to answer your question, we essentially do have feature flags as columns in the database, and we can just check if they are enabled or disabled. And then that also allows us to easily turn it on, turn it off as well since it's just a database update. CHRIS: Okay, that makes sense. I think the nature of being a Rails application rendering HTML on the server like what you're doing totally makes sense in that context. I think it becomes a lot harder the more complex the architecture of your application is. So if you've got microservices, then suddenly you've probably got to synchronize across some of them, and that sounds like a whole thing. Or even if you have a client-side application, then suddenly you've got to serialize the feature flag stuff across the boundary or somehow expose that, which really does push the issue of we could just render stuff on the server and send it to the client and let that be good enough, then man, is stuff simpler. But unfortunately, that's not the case in a lot of situations. I'm expecting to be introducing feature flags on the app that I'm working on pretty soon. And again, we've got...so it's a Rails server-side thing. So there's going to be plenty of feature flag logic on that side. And then I'll need to do something to serialize it across the boundary and get it onto the client-side without ballooning every payload and adding complexity, and lookups, and whatnot. I think it's doable. Inertia, again, being the core architecture of the application, I think will make this a little bit easier, but I am interested to see what I'm able to pull off and how happy I am with where I get to. Another question that I have for you then are you testing the various flows? So given a Boolean feature flag, you now have two different possible paths for your code to go through. And then there may be even more than Boolean, or you may have feature flags that sort of interact with each other. And how much complexity are you trying to manage and represent in the test suite? STEPH: Yeah, good question, and we are. So we're testing both flows, especially if it's a new feature, then we are testing when the flag is enabled or disabled. One that's been tricky for me is what about a bug fix? Is that something that should be feature flagged? And I think at the surface level, if you're presuming that it needs to go through QA before this is live on production, then the answer is yes, that then you have to feature flag a bug fix, which feels weird. But then the other consideration would be, well, it is a bug fix. And could we find another way to QA this faster or some other approach so that way we don't have to wrap it in a feature flag? And I don't have a great answer for that one because I can see arguments in favor of either approach. Although wrapping everything in a feature flag does feel tedious, it's something that I'm not accustomed to doing. And it's something that then becomes a process for the team to remind each other that, hey, is this wrapped in a feature flag? Or just being mindful of that as part of our process. And it prompted me to think back on the other projects that I've worked on and how did we manage that flow? How did we go from development to staging to QA and then out to production? And one additional consideration with this flow is that we do have an overnight QA team. So in the past, when I've worked with teams, often product managers or even other developers, we would QA each other's work. So then it was a pretty fast turnaround that then you could get something up on staging. Someone could check it out and say, "Yes" or "No." But then I'm also pretty confident most of the teams that I've worked with we have had a distinct staging branch. So we would often merge work into a staging branch, and then deploy that work, and then get it tested. And then, if it passed everything, then we would essentially cherry-pick that work and move it over into production. And I can see there's a lot of arguments against that, but then I have also experienced that and had a really positive experience where we could test everything and not have to worry about going out to production. We didn't have to wrap everything in feature flags, and it just felt really nice to know that everything in the main or production branch, whatever you call your production branch, that everything in there was deployable versus having to go the feature flag route, or the hey, did this go through QA? I don't know. Let me check. Can I include this? Should I cherry-pick some commits into our actual deployment to avoid stuff that hasn't gone through QA? I've been through that dance before too, and that one's not great. CHRIS: I like the way you're framing the different sort of trade-offs that we have there in velocity or deployment speed and ease of iteration versus confidence as things are going out. I have worked with a staging branch before, and I personally did not find it to be valuable. It ended up adding this indirection. Folks had to know how to use Git in a pretty deep way to be comfortable with that just as a starting point. So it already introduced this hurdle of knowledge, and then beyond that, that idea that you have commits going in in a certain order on the staging branch. But then say we verify the functionality of the third commit in that list, and we want to cherry-pick it across to the main branch. Commits don't actually...you can't just take the thing that you had there. That commit existed in the context of all the others. There are subtleties of how history exists in Git. And I would worry about those edge cases where you're taking a piece of work out of the context of the rest of the commits that were around it or before it is, more importantly…that preceded it in the history on the staging branch, and you're now bringing it across to the main branch. Have you now lost something that was meaningful? Ideally, you would get a conflict if it was really bad, but that's more of like a syntactic diff level thing. It's not a functionality-level thing. So personally, I may be overly cautious around this, but I really like as much as possible to have the very boring linear history in Git and do everything I can such that work happens on feature branches and then gets merged in as a fast forward into the main branch or rather the main branch is fast-forward marched into my feature branch such that I'm never working with code that I haven't fully worked with in an integrated way before. But again, even that, as I'm saying that, I have this topological map of Git in my head as I'm saying all of that, and it's complicated. And having any of that complexity leak out into the way we talk about the work is something that I worry about, but maybe I'm worried about a bunch of things that don't matter. Maybe a staging branch is actually fantastic. STEPH: I think you make a lot of good points. Those are a lot of good concerns that come up with...it comes back to the idea that we want to mimic production as much as possible, and we don't want to lose that parity. So then, by having a staging branch, then it feels that we've lost that parity. There could be stuff that's in staging that's not in production. And so staging could be a little bit of this Wild West area, and then that doesn't fully represent then what's going to production. So I certainly understand and agree with those points that you're making. And to speak specifically to the Git challenges, I agree. It does require some more Git knowledge to be able to make that work. Specifically, I think how we handled it on a previous project is where we'd actually cherry-pick our commits into staging and then deploy that. But we always had the PR issued against main. So then merging into main was often a bit easier. But then you're right; things could get out of sync. And the PR is issued against main, so then you still could run into those oddities where then if you are cherry-picking commits in the staging, but then you have your final draft that's going into main. And then what are the differences between those, and what did you lose along the way? And as I say all of that out loud, I definitely understand the Git concerns. And I don't know; I just feel like there's not a great answer then here, which is shocking to me. I've been doing this for a while, and yet here I am feeling like there's not a great answer to this very vital part of our workflow. And I'm surprised even though that we do have a delayed QA process that this still feels like a painful thing to figure out how do we have a continuous deployment workflow even though we do have that delayed QA process? CHRIS: I think somewhat fundamentally your comment there of "I'm surprised that we don't have a good answer to this is," I'm not surprised, I guess, is my reaction. I don't want to go to the software is bad and broken, and we don't know anything end of the spectrum. But I don't feel like we have great answers to a lot of the things about development. I feel like software is more broken than it should be. It costs more to develop. It is difficult. It's hard to create, and maintain, and build over time. And that's just, to get lofty about it, that's what the entire focus of my career is, is trying to solve that problem. But it's a big, hard problem that I do not think is solved, unlike just about any of the fronts. I know how to put stuff in a database and take it back out. And even that, I'm like, oh yeah, but what if the database gets really big? Or what if the database...everything has complexities and edge cases. STEPH: [laughs] CHRIS: And we've joked a handful of times about the catchphrase of The Bike Shed being it depends, and that really feels true, though. I don't know that that's unique to this industry either. I feel like everything in the world is just more complicated the more you look at it, and there aren't clear, good, obvious answers to just about anything in the world, but that's the human condition. I got weirdly philosophical on this, so we should probably round this out. [laughs] STEPH: Well, I can circle us back because I was providing context, and I went a bit into the deep end providing all of that context. So if I circle back to what I wanted to share with you around deploys and releases, there has been that interesting conversation. Now that we have the context, there has been that interesting conversation around originally; we had this very structured deploys, a deploy map to the fact that features were going out to the world. And now we have this concept of a deploy doesn't necessarily mean that's available to customers. It doesn't mean that the code is running. It is more a deploy represents that we have placed a commit. We have placed code on the server. But that doesn't mean that it is accessible to anyone because it's probably hidden behind a feature flag. But from the perspective of the rest of the team that then is communicating these changes out to customers, they still really need to know, okay, when is something actually available to customers? And we kept using this terminology around deploy. And so Joël Quenneville, another thoughtboter who's on this project with me, has done a lot of great, thoughtful work around how can we help them know when something is truly available versus when something is deployed? Because right now, we're using Jira for our ticket issue tracking. And there's a particular screen in Jira that was showing what's being deployed. And from that screen, you can see the status of the ticket, and you would see stuff like in code review, in QA. So, of course, those looking at the tickets are like, hold up, you're deploying something that's in QA? That sounds really dangerous and risky. Why are you doing that? And then we'd have to explain, well, we're deploying it, but it's not actually live or accessible to anybody, but we want to get close to that continuous deploy cycle. So we have shifted to using the terminology of a release. So a deploy is more for the we're putting the code on the server and then release really represents okay, we have now released these features and these bug fixes, and they're now available all with the goal just to make sure that our teams are working well together. But it's been such an interesting conversation around how tickets move, the fact that they can progress linear and then also get moved backwards. But in continuous deployment, things don't go backwards and then making those things align. Typically, things don't go backwards. Technically, yes. CHRIS: History is a directed acyclic graph that only points forward. The arrow of time is very clear on this matter. Yeah, that really does add one more layer of like; what does it mean to actually be out there in the world? I do wonder if giving view-only visibility to the feature flag dashboard and only when it's fully green does someone think that that's deployed? But if you're putting feature flags around everything, there's complexity. And yeah, it's just one more layer to having to manage all of this. And it sounds like you've gotten to a good place, or at least you're evolving in a way that's enjoyable. But yeah, it's complicated. STEPH: Yeah, it definitely feels like we're moving in the right direction and that this will be a better...I want to say workflow, but it really focuses more around vocabulary and some of the changes to our processes and how we surface tickets in Jira. But it's more focused on how we talk about the changes that are getting shipped and when they're available. So, yeah, that's my story. What's new in your world? CHRIS: Well, I very much appreciate your story. In my world, I am in the thick of the MBP initial drive to get something into production, which is one of my favorite times, especially if everyone's in agreement about what exactly do we mean by MVP? Who are the users going to be? What's it going to look like? What's the bar that we're going to maintain? What features can we drop? What can't we drop? When there's a good collaborative sort of everyone rowing in the same direction set of conversations around that, I just love the energy of that time. So I'm happily in that space hacking away on features building as much as I can as quickly as I can. But as part of that, there are a lot of just initial decisions and things that I have to wire up and stuff that I have to change or configure. Thankfully, Rails makes a lot of that not the case. I can just go with what's there and be happy about that. But there is one thing that I did decide to change just today. But it's interesting; I don't think I've actually ever made this change before. I'm sure I've worked on an app that had this configuration, but typically, a Rails app will store the session in a cookie. So there is a signed HTTP only encrypted. I think those are all the things, but it uses a cookie to store that. And the actual data of the session lives in the payload of that cookie. And so, each time there's a request-response lifecycle, the full payload of that cookie is going up and down from the server to the client and then back and forth with all of the requests. And there's a limit; I think it's 4k is the limit on the cookie session. But there are some limitations to cookie sessions as far as I'm coming to understand them; one is the ability to do replay attacks. So if someone gets a hold of that cookie, then unless you rotate the secret key base, which will have some pretty wide-ranging effects on your application, that cookie can be reused in the future because it basically just has like, this is the user's ID. There you go. And there's no way to revoke that other than rotating the secret key base. Additionally, there are just costs of that payload of data, especially if you're putting a non-trivial amount of stuff. Like, if you're getting close to that 4K limit, then you have 4K of overhead, both on the request and the response of your HTTP requests. So especially in apps that are somewhat chatty and making a bunch of Ajax requests or doing different things, that's some weight that you should consider. So all of those mixed together, more so on the security side, I decided to look into it. And I have now switched from a cookie store, and I went all the way to the ActiveRecord database store. So I skipped over...there's a middle option that you can do with Memcached or Redis. We do have Redis in this particular application. We don't have Memcached yet; we probably will at some point. But you can do a memory store, so do Redis and store the session there, but I opted to go all the way to the database. And my understanding of the benefits here are we have a smaller cookie footprint, so smaller overhead on all the requests because now we're only sending the session ID. And then that references the actual payload of data that's stored in the database. We do have the ability now to invalidate sessions, so we can just truncate that table if we just want to sign all the users out and reset the world, which can be useful at times. We also have the ability...if there's any particular user that's like, "I left myself logged in somewhere," we can…well, I actually don't know how to do this now that I say that. I don't know how to log out a specific user because the sessions don't inherently have the user associated with them. You can have an unauthenticated session, which then transitions to be authenticated when someone signs in, and then the user ID gets installed in there. I would love to have these indexed to users such that I could invalidate and have a button on the admin dashboard that says, "Sign out all instances," and that will revoke all of the sessions or actually delete them from the database table now. I think I would have to add some extra instrumentation to do that. So anytime a user signs in via device, we annotate the session records so that it's got a user ID column and then index on that so that we can look them up efficiently. I think that's how that would work, but that's one of those things that I'm like; I think I should think very hard about this before I do it. It has security implications. It's not part of the default package. There's probably a reason for that. I'm going to do that another day. But yeah, overall, it was a pretty easy upgrade. I think I'm happy with it. It feels like one of those things that it's not clear to me why this isn't the default sort of thing where SQLite is often the database that you use just because it's slightly easier to get up and running? But for any application that we're working on, we're like, no, no, no, we're going to go to Postgres for local development and for everything because obviously, that's what we want to do. And I'm wondering if this should be in that space, like yeah, of course, the session should go in the database. There are so many reasons that it's better that way. I'm wondering if there are some edge cases that I'm not thinking about, but overall it seems cool. Have you ever worked with an alternative to the cookie store? STEPH: I'm thinking back to the recent projects that I've worked on. And it's been a while since I've mucked around with session work specifically. And the more recent projects that I've been on, we've used JWTs, or they're pronounced jots, I found out, which is really surprising. I don't know why, but that's a thing. CHRIS: What? STEPH: [laughs] CHRIS: This doesn't feel true. STEPH: It's JWT, but it's pronounced jot, J-O-T. CHRIS: I think I'm just going to not do that. This is a trend I'm not going to get on board with. [chuckles] STEPH: I don't even know if it's a trend. I'm not sure who decreed this into the world. CHRIS: You're familiar with the great internet war around GIF versus JIF, right? I think there's room for different opinions. STEPH: I mean, it's really not a war. There's a correct side. CHRIS: We're on the same side, right? STEPH: [laughs] And this is how The Bike Shed ended. No, this is perfect for The Bike Shed. What am I talking about? CHRIS: This is perfect for The Bike Shed. I'm just going to need to hear you say the word real quick. [chuckles] STEPH: Oh, it's GIF, absolutely, CHRIS: Okay. All right, phew. Steph, I was worried, I was worried. Also, anyone out there that says JIF, it's fine. These things don't really matter. Although I am surprised when you have an acronym that gets turned into...I think it's an initialism, like jot versus JWT. I forget which is which. I think JWT would be the acronym. But jot, that's not even...I'm going to move on and say...[laughs] And so I think that JWTs, which is what I'm going to call them in this context, are, as far as I understand it, an orthogonal, different sort of thing. Like, you can put a JWT in the session, and the session can be stored in a cookie or in the database or wherever. You can also put JWTs...often, they are in local storage, which my understanding is that's a bad idea. That is a security vulnerability waiting to happen from cross-site scripting, I think, is the one that is coming to mind. But I think that's an independent thing where JWT is this signed assertion that you are someone. But it's coming often from an external system versus I'm using devise in this case on a Rails app and so devise is using the warden session, which is signing and encrypting and a bunch of stuff that I'm not thinking about. But it's not using JWTs at the end of the day. Jot, really, huh? STEPH: [laughs] I like how that's the thing that stuck out to you. CHRIS: Of course it is. STEPH: But it's fair because it did the same to me too, so I had to share it. [laughs] CHRIS: This is The Bike Shed, after all. [laughs] STEPH: So, going back to your question, what you've done sounds very reasonable to me, especially because you wanted to address that possibility of a replay attack. So I like the idea. I'm also intrigued by why it's not the default. What's the reasoning there? And I'm trying to think of a reason that it wouldn't be the default. And I don't have a great answer off the top of my head. Granted, it's also been a while since I've been in this space. But yeah, everything that you've done sounds really reasonable. I like it. I also see how being able to sign out a specific user would be really neat. That seems like a really nice feature. I don't know how often that would get used, but that seems like a really nice thing to be able to do to identify a particular user if they submitted and, I don't know, if some scenario came up and someone was like, "Help, please sign me out," then to have that ability. So I'll be intrigued to hear how this advances if you still really like this approach or if you find that you need to change back to using Memcached or the cookie store. CHRIS: Yeah, I'm in that space where as I'm looking at it, I'm like, I only see upside here. I guess there's a tiny bit of extra complexity. You have to watch that database table and set up a regular recurring job to sort of sweep old sessions that haven't been touched in a while because this is sort of like an append-only store. Every time someone signs in anew, they're getting a new session. So over time, this database table is just going to grow and grow and grow. But it's very easy to stay on top of that if you just set up a recurring job that's cleaning them. It's part of the ActiveRecord session store is the name of the gem. It's under the Rails namespace or the Rails GitHub organization. So that seems manageable. Maybe that's the one complexity is it has this sort of runaway trait to it that you have to stay on top of, whereas the cookie-based sessions don't. But yeah, I'm seeing a lot of upside for us, so I'm going to try it. I think it's going to be good. I'm also unfortunately in that space where I think I see all the moving parts as to how I could implement the sign out a user in all of their sessions. But I'm worried that I'm tricking myself there. It's one of those things it's like this feels like it would be built in if it was that straightforward, or it could easily have subtle...it's like, don't invent your own crypto. Like, I think I know how crypto algorithms work. I can just write one real quick. No, don't do that, definitely don't do that. And this one, it seems clear enough, but it's still in the space of crypto security, et cetera, that I just don't want to mess with without really thoroughly convincing myself that I know what I'm talking about. So maybe six months from now, I will have talked myself into it. Or if anyone out there is listening and knows of a good founded, well-thought-out version of yeah, this is totally a thing that we do; here's what it looks like; I would love to hear that. But otherwise, I'll probably just be happy with the ability to wipe everyone's session as necessary. If any one user leaves themselves logged in at a library and needs me to log them out, I'll just log out every user. That's fine. That's a good enough solution. STEPH: Yeah. All of that makes sense. And also, the part that you highlighted around that there is that additional work of where then you have to make sure that you have a rake task that's running to then sign people out since there's that additional lift that you mentioned. But I'm excited to hear what folks have to say if they're using this approach and what they think about it. It is super interesting. CHRIS: Well, yeah, I am very excited about this new development and the management of sessions. And I will let you know if I make any headway on the signing out a user sort of thing. But I think that covers that topic. As an aside, I just wanted to take a quick moment to ask folks out there; we are getting to the bottom of our listener question queue, and we absolutely love getting listener questions. They really help us find novel things to talk about that whenever we start talking about them, it turns out that we have a lot to say. So please do send in any questions that you have. You can send them to hosts@bikeshed.fm. That's an email option. You can tweet at us; we're @bikeshed, or either of us individually. I'm @christoomey. STEPH: And I'm @SViccari. CHRIS: And we also have a Google Form, which we will link in the show notes of this episode. So any of those versions send us questions. It can be about more tech stuff, more process stuff, more team-building, really anything across the spectrum. But we really do love getting the questions in, and definitely helps provide a little bit more structure to the show. So, with that aside, Steph, what else is going on in your world? STEPH: Yeah, I love when we call from our listener questions, for the reason that you highlighted because it often exposes me to different ways of thinking in topics that I hadn't considered before. And you're right; we're often very opinionated souls. [laughs] And along that note, so I have a question for you. The context is another developer, and I ran into a bug. And when we initially looked at the bug, it was one of those there's no way. There's no way the code is in this state. That does not make sense. And then, of course, it's one of those well, the computer says otherwise, so clearly we're wrong. We just can't see how the code is getting to this place. And what was happening is we were setting a value. We were parsing some JSON. We're looking for a value in that JSON, and we're using dig specifically in Ruby. So if it's the JSON or if it's a hash, and then we're doing dig, and then we're going two layers deep. So let's say we're going foo and then bar, and then dig; if it doesn't find those values, instead of erroring, it's just going to return nil. And then we have an or, and then we have a hard-coded string. So it's like, hey, we want to set this attribute to this value. If it's the hash, then give us back that value; if not, it's going to be nil, and then give us this hard-coded string. What we were seeing in the actual data is that we were getting an empty string. And initially, it was one of those; how are we possibly getting an empty string when we gave you a hard-coded string to give us instead? And it's because empty strings are truthy. When we were performing the dig, it was finding both of those values, but that value was set to an empty string. And because that evaluates to truthy, we weren't getting the hard-coded string, and then we were setting it to an empty string, and then that caused some problems. So then my question to you is should we have truthiness in our code? CHRIS: Oh wow. That's a big question. It's also each language I might have a slightly different version of my answer. Yeah, I'm going to have to go sort of across languages to answer. I think in Ruby, I have generally been happy with Ruby's somewhat conservative implementation of truthiness. Yeah, anything that isn't nil false...is that it? Are those the only falsy values? There's maybe one more, but zero is not a falsy value. Empty string is not a falsy value. They're truthy, to name it in the affirmative. And I like that Ruby has a more conservative view of what things are. And so it can have this other surprising edge. I will say that I do reach for present? in Rails, so present? Present with a question mark at the end, that method in Rails, which I pronounce as present, huh? STEPH: Which is delightful, by the way. CHRIS: Well, thank you. That method I reach for often or presence would be the variant in this case where you can presence or and then chain on the thing that you want, and that gets the value. It will basically do the thing that you want here. And so, I do find myself reaching for that, which does imply that maybe Ruby's default truthiness is not quite what I want. And I want a little more permissive truthiness, a little more like, no, empty strings are not truthy. Empty string is an empty value, so it is empty. But yeah, I think I can always convince myself of the other argument when I'm angrily fighting against a bug that I ran into, and I'm surprised by. Like, I've experienced this from both sides many times in my life. I will say in JavaScript, I am constantly surprised by the very, very permissive type coercion that happens where you compare a string and a number, and suddenly they're both strings, and they get smashed together. It's like, wait, how is that ever the thing that I would want? And so JavaScript's version feels like it is definitively foundationally wrong. Ruby's feels like it's maybe a tiny bit conservative, but I like that as a default and then Rails building on top of that. I think I lean towards that most of the time. I will say at the other end of the spectrum, I've worked with Haskell, and Haskell has I want to say it's like a list of chr, like C-H-R list of characters as the canonical way to do strings. I may be mixing this up. It may be actually the string type, but then there's also a text type, and they're slightly different. Maybe it's UTF. I forget what the distinction was, but they both exist, and they are both often found in libraries and in code. And you end up having to constantly convert back and forth. And there are no subtle equivalents between them or any type coercion between them because it's Haskell, and there isn't really any of that. And this was early on. I never got particularly far in Haskell, but I found that so painful and frustrating. It was just like, come on; they're like strings. Please just do the thing. You know what I mean. And Haskell was like, "I do not. And I require you to be ridiculously specific about it." So that was sort of the high end for me of like nope, definitely not that JavaScript of like anything's anything and it's fine. That feels bad. So somewhere in the middle, Ruby feels like it's a happy in the middle. Maybe Rails is actually where I want to land, but I don't know that there is a good answer to this. I don't know that there's a language that's like, we got it. It's this very specific set of things. It's truthy, and these are falsy, and it's perfect every time. Like, I don't think that can happen. STEPH: As an aside, I like how your Haskell voice had the slight air of pretension that really resonated with me. [laughs] CHRIS: I don't know what you're talking about. That doesn't sound familiar to me at all. [laughs] STEPH: I agree. I don't know that anyone has gotten this perfect. But then again, I also haven't tried all the languages that are out there, so I don't feel like that's really a fair statement for me to make either. Specific to the Ruby world, I do think Boolean coercions are a bit nice because then they do make certain checks easier. So if you are working with an if statement, you can say, "If this, and then do that, else, do this." And that feels like a pretty nice common idiomatic flow that we use in Ruby but then still feels like one of those areas that can really bite you. So while having this conversation with some other thoughtboters, Mike Burns provided a succinct approach to this that I think I really like where he said that he likes the use of truthy and falsy for if statements, Booleans for the and statement, and only truthy falsy for Booleans, so no nulls. So Boolean should not have three states is what that last part is highlighting. It should be just true or false. And then if we're working with the double ampersand and in Ruby, that then if you have that type of conditional that you are conveying, then to use a strict Boolean, be more strict and use the methods that you were referring to earlier, like empty and explicitly checking is this an actual...like turn it into a Boolean instead of relying on that that truthy falsy of is it present? Is it an empty string? Does that count? But then, for the if statements, those can be a little more loose. And actually, now that I'm saying it, that first part, I get it. It's convenient, but I still feel like bugs lie down that path. And so, I think I'm still in favor of being more explicit. If I really care if something is true or false, I want to call out explicitly. I expect this to be true or false versus relying on the fact that I know it will evaluate, although I'm sure I do it all the time, just because that's how you often write idiomatic Ruby. So I'm interested in watching my own behavior now to see how often I'm relying on that truthy, falsy behavior, and then see the areas that I can mitigate that just because yeah, that bug is fresh in my mind, and I'd like to prevent those bugs going forward. CHRIS: I really liked that phrase of that bug is fresh. So that bug is going to own a little bit more mindshare than that old bug that's a bit stale in the back of my brain. I will say as you were talking about idiomatic Ruby, I think you're right that the sort of core or idiomatic way to do it would be if the user or whatever to see is the user here, or are they nil? Did we find one, or did we not? That sort of thing is commonly the way it would be done. I almost always write those as if users are not present? I will convert it into that because A, I'm writing Ruby, and I write Ruby because I want it to sound like the human words that I would say. And so I wouldn't say like, "If user," I would say, "If the user is present, then do the thing." And so I write the code to do that, but I also get the different semantics that present? Brings or blank? Is the counterpart, the other side of it. That seems to be the way that I write my code. That's idiomatic me, Ruby, and I don't know how strongly I hold that belief. But that is definitely how I write those, which I find interesting in contrast to what you were saying. The other thing that came to mind as you were saying this is that particular one of an empty string. I kind of want to force empty strings to not be okay, particularly at the database level. So I'll often have null false on a string column, but then I'll find empty strings in there. And I'm like, well, that's not what I meant. I wanted stuff in there. Database, I want you to stop it if I was just putting in an empty string because you're supposed to be the gatekeeper that keeps me honest. And so I do wonder if there is a Postgres extension that we could have similar to the citexts, citext, which is case-insensitive text. So you can say, "Yeah, store this as it is, but whenever you compare it, compare case-insensitively," because an email is an email. Even if I capitalize the third letter, it doesn't make it a different email. I want a non-empty text as a column type that is both null false but also has a check constraint for an empty string and prevents that. And then similarly, the three-state Boolean thing that you're talking about, I will always do null false on a Boolean column because it's a lie if I ever tell myself. I'm like, yeah, but this Boolean could be null, then you've got something else. Then you've got an ADT, which I also can't represent in my database, and that makes me sad. I guess I can enum those, but it's not quite the same because I can't have additional data attached. That's a separate feeling that I have about databases. I'm going down a rabbit hole here. I wish the database would prevent me from putting in empty strings into null, false string columns. I understand that I'm going to have to do some work on my side to make that happen, but that's the world I want to live in. STEPH: I'm trying to think of a name for when you have a Boolean that's also a potential null value. What do you have? You have nullean at that point? CHRIS: Quantum Boolean. STEPH: Quantum Boolean. [laughs] CHRIS: Spooky Boolean. STEPH: The maybe Boolean? CHRIS: Yeah. STEPH: No, that's worse. [laughs] Yeah, I'm with you. And I like the idiomatic Ruby. I think that is something that I would like to do more of where I'm explicitly checking if user instead of just checking for that presence and allowing that to flow through doing the present check and verifying that yes, we do have a user versus allowing that nil to then evaluate to falsy. That's the type of code that I think I'd like to be more strict about writing. But then it's also interesting as I'm formulating these ideas. Is it one of those if I'm reviewing a PR and I see that someone else didn't do it, am I going to advise like, hey, let's actually check or turn this into a true Boolean versus just relying on the truthy and falsy behavior? And probably not. I don't think I'm there yet. And I think this is more in the space that I'm interested in pursuing and seeing how it benefits the code that I'm writing. But I don't think I'm at the state where then I would advocate, at least not loudly, on other PRs that we do it. If it is, it'd be like a small suggestion, but it wouldn't be something that I would necessarily expect someone else to do. CHRIS: Yeah, definitely the same for me on that, although it's a multi-step plan here, a multi-year plan. First, we say it on a podcast, then we say it again on a podcast, then we change all the hearts and minds, then everyone writes the style, then we're all in agreement that this is the thing that we should do. And then it's reasonable to bring up in a pull request, or even then, I still wouldn't want it. Then it's like standard rb or somebody else's job. That's the level of pull request comment that I'm like, really? Come on. Come on. STEPH: This is a grassroots movement for eradicating truthiness and falsyness. I think we're going to need a lot of help to get this going. [laughs] CHRIS: Thankfully, there are the millions of listeners to this show that will carry this torch forward, I assume. STEPH: Millions. Absolutely. CHRIS: I'm rounding roughly a little. STEPH: There are a couple, yeah. [laughs] I'd be far more nervous if I knew we had millions of people listening. CHRIS: I kind of know that people listen. But at the same time, most of the time, I just entirely forget about that, and I feel like we're just having a conversation, which I think is good. But yeah, the idea that actual humans will listen to this in the future is a weird one that just doesn't do good things in my head. So I just let that go. And you and I are just having a chat, and it's great. STEPH: Yeah. I'm with you. And just to reiterate what you were saying earlier, we love getting listener questions. So if there's anything that you'd like to send our way and have us to chat about or something you'd like to share with us, then please do so. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: 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, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._