Podcasts about chris thanks

Join host Carol Pankow as she dives into the complexities of Order of Selection (OOS) in vocational rehabilitation with two expert guests: Theresa Kolezar, Director of Indiana Combined, and Chris Pope, Director of the State Monitoring and Program Improvement Division at RSA. In this episode, they break down: ·      Why agencies implement OOS due to financial and staffing constraints ·      Key regulatory requirements and compliance considerations ·      Strategies for managing and eventually lifting OOS ·      Indiana VR's data-driven approach to decision-making and communication ·      RSA's insights on fiscal forecasting and policy compliance If you're in the VR field, you won't want to miss this insightful conversation on planning, stakeholder engagement, and using data to overcome challenges.   Listen Here   Full Transcript:   {Music} Chris: As you know, we have 78 VR agencies and only eight of them have a closed priority category, and only one of those eight have all priority categories closed.   Carol: So by going back and saying hey you gotta look at this other side of the house and really analyze what's happening. It will give you the full picture, than what is playing into what's happening over here on the fiscal side of the house.   Theresa: For the majority of folks. They were maybe even having somewhat of a positive impact because we were able to get them processed, get them in sooner. And you know, there's obvious benefits that go along with lower case load sizes.   Intro Voice: Manager Minute brought to you by the VRTAC for Quality Management, Conversations powered by VR, one manager at a time, one minute at a time. Here is your host Carol Pankow.   Carol: Well, welcome to the manager minute. Joining me in the studio today is Theresa Kolezar, director of Indiana Combined. And Chris Pope, director of the State Monitoring and Program Improvement division at the Rehabilitation Services Administration. So, Theresa, how are things going with you in Indiana?   Theresa: Oh, we're doing well. Thanks. So happy to be here.   Carol: Thanks for being here. And, Chris, how are things going for you in D.C.?   Chris: Things are cold in D.C. at the moment, Carol, but we're hanging in there.   Carol: Yeah, not as cold as Minnesota.   Chris: I knew you were going to say that.   Carol: Yeah. I'm like, wow, we're 14 below people. Well, there has been a lot happening with the VR program over the past decade, and we certainly have had our ebbs and flows with funding and staffing. And as of late, the fiscal pendulum has been swinging, VR programs have been experiencing a tightening of the belt, so to speak, and discussions about the order of selection have been ramping up. And so for our listeners, order of selection is a process required under the VR regulations. When a VR agency does not have enough resources, whether it's funding staff or both, to serve all eligible individuals, and it's designed to prioritize services for those with the most significant needs. But over the years, order of selection really has sparked a lot of tension. And for some it's seen as just another layer of government red tape adding to the stigma around bureaucracy. Others argue that it undermines the very spirit of the rehab act by limiting access to services instead of promoting inclusion. Critics point out that it can widen service gaps. It leaves individuals with moderate disabilities without support, even though they still face serious barriers to employment.   And for our counselors, order of selection can bring its own challenges, including the emotional burden of explaining to clients why they can't receive immediate services. And for clients, being placed on a waitlist can feel disheartening and frustrating. And at the same time, agencies are grappling with a harsh reality. There's limited resources. Tough decisions have to be made. So how do we balance fairness, inclusion and the constraints of funding? And that is the question at the heart of today's conversation on order of Selection. So, Theresa, I've been a fan of yours for a long time. I think you bring a really thoughtful approach to almost every difficult situation in VR, and you been around a while, so I definitely want to pick your brain about your thoughts and approach on the topic. And Chris, I'm really count on you to bring the facts from an RSA perspective on what needs to happen with the Order of Selection. So let's dig in. So, Theresa, can you just tell us to start out with a little bit about yourself and your journey into VR?   Theresa: Sure. I probably have the least interesting journey, but maybe the most classic. I went from straight from undergrad to graduate school to get my masters in rehabilitation, got my CRC that same summer, and I entered the rehab field initially with a nonprofit, CRP, before coming to Indiana VR in 2004. So I've been with the VR program for a little over 20 years. Made my journey starting from a VR counselor and now director with, as you can imagine, a lot of other roles along the way. And I think I'm a fairly tenured VR director with almost nine years under my belt in this role.   Carol: Yeah, definitely you would be. Because I remember being told when I left, I had six years, you know, and people were telling me usually the lifespan of a VR director is about five years because the job is tough. So you're definitely one of our longer term folks. So, Chris, how about you? How did you venture into the VR world?   Chris: Thanks, Carol. Well, similar to Theresa, my graduate degree in rehab counseling, I became a CRC and began my career as a VR counselor with the State of New York in the general agency at the time, for about four years. And I've been with RSA now for a lucky 13. Just had my 13th anniversary. And in that time have served in a variety of roles. So, yeah, really happy to be here and now leading the division that's responsible for all of our formula grant.   Carol: Yeah, it's super cool. It's been fun to watch your career, Chris, as  you have grown. I remember one of the very first conferences you presented at, and I believe you were still, you know, more kind of on the staff level. And I thought, who's this guy? You were up there, you just had such a great presence about you. And I'm like, he's going somewhere. And you have, it's come true.   Chris: Thanks, Carol.   Carol: So let's talk about the realities of Order of Selection. It's not something that can be implemented at the snap of a finger. And so I want to start with you. What are those factors via our leaders need to take into account.   Theresa: Yeah. You know it's hard I feel like I sort of came to terms with it because it's it didn't feel so much like something we had to choose or decide upon, but more something we had to do. if your circumstances are such that you don't have the resources to serve everyone. So in Indiana, we enter the order in 2017, and I believe that was the first time in our history, as far as I know, it came after years of trying other things, you know, implementing strategies to improve our capacity, stretch our resources. And just a few examples. Implementing efficiencies, changing to our staffing structure, changing our minimum VRC qualifications to a bachelor's degree, and a whole lot more. And those strategies were definitely focused for us at that time around staffing resources. But there were also some fiscal unknowns or concerns because right around that time, the 15 earmark requirement was also, you know, kind of hitting us. And we were trying to figure out how to shift those resources. So the strategies we did pre they were definitely helpful. They were effective, but we still were left with a deficit. You know, we still had high caseload sizes. It was taking way too long for new referrals to get an intake appointment. Our VRC turnover rate was much higher than is optimal. Ultimately led us to identify that we were not able to provide the full range of ER services to everyone who was eligible, and therefore we needed to enter the Order of Selection.   So we started planning for that probably around nine months prior to. The implementation and when I was making my talking points, there's a lot that you have to do, right, to prepare for Order of selection. So discussion with our internal leadership, our VR council, our stakeholders, our staff conversation with RSA, drafting that state plan amendment, getting that out for public comment. We took a couple extra steps and met with our other workforce partners because we thought, hey, they may get more referrals here. We may want to tell them why and what's going on over here and what this means. And then we of course, you have to develop written procedures, adapt your case management system. And then we also wanted to be really careful with our messaging to applicants. So we drafted some materials that we wanted our intake counselors to share and get that consistent message out there and, of course, training our counselors. So I think the nine month runway was probably a fast track Approach, thinking about all those steps. You want to do it right? You want to be planful. But at the same time, once you identify that this is a need, you usually need it to happen pretty quickly.   Carol: Absolutely. I know for me, when I was a new director in Minnesota, I actually faced this. And Minnesota Blind had not been on an order for many, many, many, many, many, many years. And being a little naive, you know, coming into VR going, we have this situation, you know, I'm thinking this all can happen super fast. It does not. But I found for me, really getting grounded in understanding our data was so important because I see these things all going on. But you had to put all the pieces together, get your fiscal side of the house and what's going on and how you're making expenditures and investments in different things and what's happening with that. But what also is happening programmatically, the people that are coming in and the characteristics of your caseload and all those different things, you had to put it all together to really get the complete picture. And for me, I know I had to do that rather quickly. So it becomes super important to have people around you. If you are not that person you know, that can pull all that data and present it in a way so you can really see the picture of what is happening and kind of unfolding in the state.   I think it just so foundationally because I know I have this little list at my desk of people that have called me looking at needing to go on order selection or thinking they're going to need to. And we have over a dozen states that have outreached in the last two months. And part of my advice to them has been back, you know, you have to get grounded to and what was your data telling you? Because you can't just base this all in sort of an assumption or something. You've got to be grounded. So I always think that that's a really important piece to start with. Now, Chris, I know from a regulatory perspective there are items that are absolutely critical for VR to have in place when you were considering Order Selection. Can you help us with that? Because I want to make sure people aren't making a mistake, you know, as they're kind of thinking through the process.   Chris: Definitely. There are several regulatory requirements, and before we address those, I thought I could provide just a little bit of context at the moment of where we're at with Order selection across the country. As you know, we have 78 VR agencies and only eight of them have a closed priority category, and only one of those eight have all priority categories closed. So this is significant progress over the past several years, I'd say since the passage of WIOA in 2014, in the past, as many as a fourth of our VR agencies had at least one closed priority category. And I can say that when RSA meets with congressional committees and other stakeholders, they often ask us for a status check on Order of Selection, and I can tell you that they respond really positively when we share that very few VR agencies are unable to serve all eligible individuals. Further, since RSA and our federal partners approved, the latest state plan would be the 2024 to 2027 state plans, RSA has approved one VR agency's new order of selection, and at the moment, we have 2 to 3 VR agencies that have submitted paperwork and are pending implementation.   Carol: You might have a few more. Chris now coming because I have I have my list of people calling. I mean really we do have 12 now on the list, so I expect maybe some more outreach.   Chris: Yep. So in terms of all of those regulatory requirements, like you said, VR agencies need to have a few things in place as they consider implementation. These include a comprehensive fiscal forecast, cost containment policies if necessary, and assessment of staff resources. And as Theresa talked about, consultation with the State Rehabilitation Council, so that fiscal forecast needs to address six data points. Average case costs, the projected number of new IPEs, the current number of IPEs, the projected number of applicants and the cost of any assessment services that might be needed to determine them eligible for the program. Projected increase or decrease in the cost of providing VR services to these groups of people, and projected income, or in any other budget resources that may become available. The fiscal forecast produces that data, Carol, that you were talking about, that demonstrates whether or not the VR agency can do the following four things. Whether the agency can continue to provide services to all individuals currently receiving services under their plans. Provide assessment services to all those individuals expected to apply to the program over the next fiscal year. Provide services to all individuals who are expected to be determined eligible in the next fiscal year. And finally, that fiscal forecast needs to include data that demonstrates that the VR program will continue to meet all of the various program requirements, like that 15% reserve requirement that Theresa discussed. So in terms of creating an Order of Selection policy, there are about five things that the VR agency needs to include in that actual policy.   First is it's priority categories, including the regulatory definition of what significant disability means, how the VR agency will determine which individuals have the most significant disabilities. And that definition must build on that regulatory definition of significant disability. The policy needs to address whether the agency has elected to serve individuals outside of the order of selection, who may require specific services or equipment to maintain their job or to keep employment, was one of those new requirements. The policy must indicate how the VR program will provide information and referral services to individuals who may be placed on a waiting list. And finally, the policy needs to describe how the agency will carry out the order, how it will be implemented so, in effect, how the waitlist will be managed and how the VR agency will decide when to open all of those other priority categories. I was happy that Theresa also mentioned that VR agencies need to ensure that their case management system can fulfill the administration of the order. And we like to see in the policy some discussion of what tracking mechanisms VR agencies will use to account for such things as cost, staff time and caseload sizes. So in other words, sort of that real time data analysis that That informs whether the order continues to be necessary or whether it can be lifted.   Carol: Awesome. I'm sure people are probably, as they're listening, taking copious notes. So folks need to know that there also is always a transcript that goes along with the podcast. So if your wrist just broke, you will be able to just take a look at the notes and get all those things. That is super helpful. Chris, I wanted to ask as a follow up, so that people that have outreached so far, those states that have outreached are you seeing? Is it a fiscally related issue? Is it a staffing? You know how sometimes the states are really struggling with having appropriate staffing? I know it's only been a few, but do you know kind of what that looks like if it's based on more of the fiscal end of things, or is it they don't have capacity because they don't have any staff?   Chris: It's been a combination of all of those things, Carol. So we're seeing agencies with limited fiscal resources, whether that be state appropriated funds, their inability to kind of fully leverage the federal award. It may be retention and recruitment of VR counselors. It could also be sort of capacity of providers, whether those are community rehab providers or contractors who provide VR services. And oftentimes it's other things that kind of just contribute to those as well. And what we're hoping to see in those justifications that VR agencies submit is a real data informed discussion of those factors, like real time data in terms of both fiscal data and performance data. So the money and the people.   Carol: Yeah, I can't underscore that enough, because I know the folks that have reached out to us a lot of times they tend to talk about, you know, their hair is on fire about this thing. And then I'm always bringing  back. So if they're all focused just on the fiscal. But I said, what's happening in your program, what's going on? And that has been very interesting as people are talking about. And then they call us back. They go, you know, the characteristics of the individuals coming in the case characteristics, kind of pre-COVID to now is different. And so we're finding clientele coming in has many more needs, and so the cost of the case are so much greater. And they hadn't realized it until they went back in. They just knew something was going on with the people, but they didn't understand what. So by going back and saying, hey, you got to look at this other side of the house and really analyze what's happening. It will give you the full picture. And then what is playing into what's happening over here on the fiscal side of the house. So I think for, you know, we've all said it, the data is super important. I just want to underscore that. So Theresa, tell us a little bit about your journey with Order Selection in Indiana and your current picture what's happening?   Theresa: I echo the data conversation, that's critical, and you really have to justify the need for the order. So we did all of that really before we even probably got to that, that nine month runway that I spoke of. But from there, our next step was to get our internal leadership approval. And there were hesitancies, which is understandable. We really had to work to articulate and help them understand the challenges that we were facing. Again, justifying using that data that we were not able to provide the full range of services to everyone, while also meeting the range of other expectations, you know, timeliness, getting people in the door in a reasonable period of time. And we really had to work to articulate the negative impact of having these ongoing high caseload sizes and the cycle that we were in with staff turnover. It just felt like we were getting deeper and deeper into right into a hole and further and further away from optimal capacity. So ultimately, we presented the Order of Selection as one something that is federally required for our agencies, you know, not able to provide that full range of services. And then two, a lever of sorts that would enable us to maybe pause or slow some of that growth in participants, giving us the space to get out of that cycle to rebuild our foundation, which for us primarily at that time, was fixing our long standing staffing capacity challenges. But for those experiencing fiscal deficits, of course, that focus would look very different. Once we got leadership support, we moved as quickly as humanly possible. And now on the other side of it. I'm thrilled to share that we have now opened all of our priority categories. We released the last 200 or so from our waitlist just this past October, so we were in and out of the order in about a seven year period in Indiana.   Carol: I love that. I like that you said you want to project, you know, the ways to get kind of out of the order to open the categories and do that. I know for states that have contacted us, that's one of the pieces of advice I've been giving. I'm like, okay, you're thinking about the right now, but you also have to think about the future because that is everyone's biggest worry. You're going to do this thing and it's never going to go away. People are going to be in a waitlist forever. You're never putting strategies in place to come out on the other side of that. And I know for me in Minnesota, that was very much part of what I had to do. And given the circumstances we had at that time, I had this plan and I said, if you all can hang with me, I believe by about 2018 or so, end of 17-18, we're going to be on the other side of this, which actually ended up playing out and coming true. And so you've got to not only like react to your current situation, but you want to be thinking thoughtfully about what are those things that you can put in play so that you aren't just going to stay there? This is the lever we're pulling and we're going to be here forever. So I really like that you said that. I know, Theresa, when you and I talked earlier, Order selection can often be treated like a bad word in the VR world, and it is loaded with a lot of stigma and frustration. But at its core, you know, when you and I were chatting and, you know, you just boil it down, it really is a mechanism. It's a tool required by law to prioritize services when resources are limited. And so if we can't do everything for everyone, it's a system that outlines how to make those tough decisions. What are your thoughts about Order of Selection and how we can maybe shift the conversation to reduce the stigma and see it for what it is? It can be this necessary lever to balance fairness amongst those limited resources.   Theresa: Yeah, that's probably one of the trickiest parts in communication. Communication, right. Communication. Communicating with stakeholders about Order Selection will probably always be challenging. It's a challenging thing, but I think there's a couple of things that were really helpful. And one is sharing a game plan to address the underlying resource challenges. Is a helpful approach, right. Making sure that there's game plan. This isn't the end result, right? This is going to enable us to make this shift and again kind of get out of the cycle. We also found it helpful to share the federal requirements. So just very factually, if you can't serve all you have to prioritize certain populations first. And the Order of Selection is the prescribed process for complying with that. And I think it's a good process for doing that. It's effective at making sure the prioritization happens. Additionally, we also share data throughout our process on the percent of eligible individuals who were impacted. And what that showed is that the majority of individuals were actually not impacted. You know, relatively speaking, a pretty small percent of folks ultimately went on a wait list. And, you know, you could even argue, and I think we did a couple of times that for the majority of folks, they were maybe even having somewhat of a positive impact because we were able to get them processed, get them in sooner.   And, you know, there's obvious benefits that go along with lower case load sizes. So we often relay that only about 10% of eligible individuals were going on a wait list, and 90% were meeting that criteria for those with a most significant disability, which was our open category for a good bit of our seven years. I will say people were a little wary of that stat. They kind of had a hard time believing that, and I think that it's because that term MSD or most significant disabilities, it definitely has meaning. But also we found it could be a little bit misleading. You know, people thought, oh, to be MSD, someone must look like this, right? And we actually found that those meeting that MSD criteria were really a more inclusive group than maybe that term people would perceive that term to imply. And that was just another educational opportunity for our stakeholders and our referral sources.   Carol: I like that you talked about the communication piece around all this, because that really is important. It's almost as important as all of the plans you're putting in place. All the things that Chris told us about that need to go in developing that communication plan, that goes along with how you discuss this out amongst all the stakeholders and such, is super important. I know, Chris, do you have any insights on this part, on the stigma or anything you wanted to share?   Chris: I guess I just had a couple thoughts on like the element of fairness that you talked about in dealing with fairness and at the same time limited resources. So I guess I would just say that order of selection is only one of the cost containment measures afforded to VR agencies through the law and through regulations. And there are other things, too, that VR agencies may want to consider, and that's comparable services and benefits. How we inform people and refer them to other workforce development programs. Those may be our partners or others. How we balance what VR Agencies by in terms of services and what we provide in-house in the cost kind of associated with both strategies. One of the other things that RSA often considers VR agencies to look at when we're talking about implementing an order is kind of carefully evaluating the need to require additional assessments when the law allows and promotes the use of existing information. So sort of not overdoing that eligibility determination process because that often comes with cost. Right. And then finally VR agencies should also be reassessing sort of their routine practices and policies that result in increased cost. That may not always be necessary. So we're really looking at kind of the entire fiscal picture of the program, not just those VR service costs that are provided to eligible individuals.   Carol: That's good. I'm glad you brought all of that up, because we often do talk about these other factors. And I asked people, are you also looking at what are you getting bang for your buck? And not that we're trying to bang on vendor communities, but do you have vendors where people never like they're never done with service, they never graduate, they never get to the end? I mean, maybe it's looking back at that and going are the ways in which their training really working for your clientele? Maybe not. Maybe you need to circle back and work with them or have a parting of the ways and think about that. I also like the thinking about really leveraging our partners. I mean, the whole rehab act, when it was redone, you know, and we had the 2014 WIOA comes out of that. We always had partners, but I don't think we were very good at leveraging what things are they doing. And I feel like some of this stuff is duplicative. You know, why are we offering these same sort of trainings that are now at the one stop that people can access and go to those courses or whatever, you know, types of things that they're offering. So it does force you to take a look at that and really actually live in to WIOA and leveraging the partnerships and the funds across all these systems. I like that. Thank you Chris, for saying that. Order Selection also has to be a super thoughtful process. And so, Chris, I know you talked about the data points that folks should look at. Theresa, what are the data points you look at regularly? And I like it because some directors talk about kind of they're reading the tea leaves to complete your fiscal forecasting, or there's some other things that you like to do.   Theresa: Oh gosh, yeah, We could talk all day on fiscal forecasting. But to just kind of be brief, you have to look beyond just what did we spend last year and apply that and assume that. And I think if you don't have programs talking to fiscal sometimes that is the fiscal assumption. Right. By fiscal staff being made. So with the pendulum swings that we tend to see in VR, which of course are highly driven by trends and applicant and participant counts, you really need to have a very layered approach to forecasting. This is where, again, that program knowledge and fiscal knowledge, it's essential that they're paired up. Just a few things to consider would be beyond the basics right. What is your data show? What are your trends? Show. But what's in your state plan? What are the goals? What are the initiatives that you have in place? There may be a fiscal impact to those, right? There may be a staff resource impact to those. So for instance, a very obvious example in our state plan, we have some goals around increasing enrollment in post-secondary training. There's some fiscal impact there. We need to know what that is, how to apply that, and then really have an understanding of our ability to sustain that goal into the subsequent years.   Again, the applicant and participant growth trends are super important. So keep your eye on and then any impact of any other outreach or collaborative partnerships that might be contributing to some of that program growth. You know, more people served generally is going to mean more expenses. And then just quickly, from kind of a fiscal standpoint, something that might be a little bit unique beyond, again, all the basic essentials of fiscal forecasting is we really have to account for carrying over a certain portion of our dollars. And that really comes down to making sure we don't have, you know, disruptions and services and can comply with this period of performance requirements. So we find in Indiana that, you know, carrying over like 20 to 25% works well for us, ensures that we can continue authorizations past 9/30 and not have that challenge of waiting until ten/1, you know, to encumber new funds. And that just keeps the flow of services going. So I'll just add that as maybe a nuance that others aren't always thinking about.   Carol: Yeah, I appreciate that because I think that having that strategy I did too, as a director, wanting you have your sweet spot of what you like to have in that carry over, because it really does promote that consistency when you have that hard start and stop, and especially in an era of continuing resolutions, you know your whole strategy with how you're flowing into the next year and how all that's going to work. You need to think about that piece for sure. Now, I know a big problem has existed around priority categories and the most significant disability designation. And many programs have three categories, but almost 90% of the customers are in category one, which makes it difficult, you know, when you're implementing an Order of Selection. How did you address that in Indiana?   Theresa: Yeah, that's exactly what we saw. And we balanced this by a couple of key strategies. One is that we did not release anyone from the waitlist until a little over two years into our process. That's  kind of how we, how bad of a cycle we were in. And again, it's a lever. It's  that dial. We had some targets like caseload sizes, retention rate that we were tracking as a gauge to when we could start moving people off that waitlist. So just for example, average caseload size is getting to under 100, turnover being less than 20%. So those were some indicators to watch to start releasing folks. Another strategy that was really helpful is that we opted to do larger releases each quarter instead of kind of smaller, more frequent releases. And this gave us the opportunity to really have our staff know that it was coming the same time each quarter. They could carve out time because it is a lift on top of the day to day, right? You've got to reach out to folks multiple times. You've got to schedule them for meetings. You've got to get IPEs in place. And then with those reviews of the, you know, again, we might look at like 2 to 300 people to see, can we take 300? Can we take 200? Is it somewhere in the middle? How does that break down across your 26 offices? And inevitably each quarter, one office got hit with a high number. And then there were a few that had very little. So we also had to weigh that and see where we could balance our resources to make those work. You know, at the end of the day, you ultimately have to release more people from the waitlist than new people who came in as eligible that quarter in order to get ahead of it. So that was another data point that we looked at.   Carol: Did you find that actually learning kind of through Covid, a lesson, you know, with working remotely and all of that, did that help as you're looking at distributing across the 26 areas? Because you can I mean, and I've talked to other directors about this now you can work with people. Maybe you're in this part of the state, but you can work with other folks as well to keep them moving. So maybe there isn't this huge one off, it's just got 200 people and the other offices get one, you know, they don't have any. Did you find some ability to flex that around the state?   Theresa: Absolutely. That's exactly what we did. So those offices that were hit hard, of course, they were also the offices with the highest number of vacancies. It just seemed to be how it fell every quarter. So absolutely, our region managers really did it. We have five of those five regions. They really did an excellent job troubleshooting that, you know, we helped where needed. But they for sure did that looking across offices in their region and even across the state. We also have about 7 or 8 working lead counselors, kind of floater counselors. So we were able to deploy them to the areas with the highest need. And then as we progressed through the order, we had a pretty robust outreach process. As we were getting ready to release folks, we ended up centralizing that a little bit to take some of that load off of our field staff as well. So, you know, you kind of have to adjust as you go. Move your resources where you can. But absolutely, we found that to be a great strategy.   Carol: Chris, you have any thoughts on that about the priority categories and the most significant disability? I just wondered because I know folks struggle with that. You were looking contemplative, so I thought maybe you might have something to add.   Chris: My philosophy with a lot of things, Carol, has always been less is more. And you mentioned that most of our agencies have three priority categories. And if I were able to say this is a requirement, that would probably be what I would say. But, you know, VR agencies have flexibility to develop more than three. I would just caution that as you get more complicated, things get more complicated for applicants to understand and for VR counselors to implement. So again, I would just say that the law requires that the significant disability category be identical to what's in the rehab act and the regs, and that that most significant category needs to build upon that. So we often see agencies talking about more functional limitations, more services being needed, more time needed to help the person reach their employment goal. So the more specificity there, the better is. I think that helps VR counselors kind of understand where to place people when they're determined eligible.   Carol: Yeah, that's really good advice. Now I know, Theresa, also, you have talked about wanting to bust the myth that nobody gets off the waitlist. And how can we better do that?   Theresa: I can't tell you how many times I've heard that in Indiana, and that was part of the a lot of the grief is that there was this thought that we'll never get out. So we know that's not true. The facts are there. You know, there are many states. And Chris shared, you know, 25% down to less than ten. So less than ten states. So we know it happens. There are states who've done it. I don't know if we do enough to highlight that to kind of our stakeholders, you know, at large and celebrate that. So maybe that's part of the answer. You know, we have those actual examples. That's an important part of the communication to internal and external stakeholders. The other piece here is outlining the conditions that need to be in place to progress, to opening more categories, to ending the order, and then people can see you hitting those target milestones. They may start believing that, oh wow, there's some actual notable objective progress here. We are getting closer to the end. This does seem doable.   Carol: Yeah, I think going back to that communication strategy for sure can help. I know with our SRC, and I had laid out the plan like I had all these points that we needed to do to kind of get through our struggle. And as things were met or we were able to achieve other savings in certain areas without impacting, you know, a quality of a service. Man ,it was great. Like no stone was unturned as we did that. But I wanted to be super transparent. Here's all the things. And I kept a little chart, like, here was this savings, or here we met this thing so people could see we were actively working a process all the way through, versus okay, we are pulling the lever and the lever is just staying closed down. That's it. They don't see the other end. All that work that's being done behind. So what is your best advice for state directors contemplating pulling the lever?   Theresa: Well, we definitely looked at it as that lever or that dial, and we felt that that gave us an opportunity. We really would not otherwise have had to take action on addressing a really significant foundation or core issue while slowing down that incoming train a little bit and refocusing our resources, staffing and fiscal building adequate resources and capacity. It's an ongoing effort. It never ends. It's one of the more difficult things, probably, that we do, but it's so critical to carrying out services in general, let alone good quality services. And it requires a very thoughtful plan and a lot of simultaneous strategies. You know, all the strategies we implemented from salary adjustments to, you know, creating those working lead counselors I mentioned, we developed a layer of case coordinators to take on some of the case management aspects. I think some states call them rehab techs. Lots of gaining of technology, you know, modernization and efficiencies and then some. Right. It ultimately helped us with two really big systemic needs. And one was getting cancer caseload sizes to manageable levels and reducing our VRC turnover. I mean, those things are gold when it comes to staff capacity.   Carol: Now, Chris, I don't want to steal your thunder, but what I'm going to say to folks too is call RSA. Like, reach out to your liaison and talk to them about your situation. You want to start those conversations because the worst thing I would think is you're a state liaison at RSA and you just get this boom, we want to do it. We need to go on March 1st and today is January, you know, 24th. You want to have that partnership all the way along. And I know, Chris, you can speak a little more to that for sure.   Chris: Carol, you know, we often talk about with clients early and sustained engagement. And I would encourage VR agencies to take the same approach with us at RSA. Reach out early and keep that conversation going. The order of selection approval process is going to be iterative. In 99% of times, RSA will have feedback and will have questions, and we'll want to see justifications be made as strong as possible. So to your point, Carol, our ability to approve orders of selection overnight is not possible. Theresa talked about sort of a nine month on ramp. I wouldn't say it's going to take that long on our end, but it will take at least a couple of weeks. And the stronger the justification we receive, the better. Again, I would just say that consider all of the flexibilities that the Rehab Act offers to VR agencies when it comes to managing the program, in addition to implementing an order. And we talked about some of those before, but they could mean cost containment from financial participation to preferences to instate services, to looking at the administrative costs that you might pay for providing services, your staffing capacity, and really leveraging the ability of your SRC. To advocate for the program, we often talk about the return on investment of the VR program, and it really is unlimited. Our program offers a lot of flexibility to be creative, to help people meet their career goals, and that's kind of the best thing we have going for us to argue for the sustainability of the program moving forward.   Carol: Yeah. Excellent points. The SRC can do so much more than we can do, really, and a lot of venues and have a different voice and a seat with the governor. You know, they're appointed by the governor. They have a different mode of communication that they can use that we cannot. So we definitely don't want to forget about them. All right guys, so we're coming to a conclusion. Any last parting thoughts from either of you for our listeners?   Theresa: Well, I'll just add, I think we've touched on a lot of great lessons learned in communication. Number one, really important. And we've hit on some ideas and strategies around that. And then the second, having that game plan, it's  critical so that we're all viewing Order of selection, not as that end result right, or that indefinite status, but as that lever or that dial that can be adjusted to address the situation at hand and then get back on track, get out of the order, be able to serve everyone who needs those services.   Carol: Awesome. I really appreciate you both and appreciate having this conversation. And for our listeners who were taking notes, because I know you guys read the transcript because that will help you with all of that. You can go back through and highlight the things you need to do. Thanks so much for being here today. Appreciate you.   Theresa: Thank you.   Chris: Thanks, Carol.   {Music} Outro Voice: Conversations powered by VR, one manager at a time, one minute at a time, brought to you by the VR TAC for Quality Management. Catch all of our podcast episodes by subscribing on Apple Podcasts, Google Podcasts or wherever you listen to podcasts. Thanks for listening!

ENGLISH TRANSCRIPT BELOWEn este episodio, mi entrevistado es Cesar Pineda, sociólogo por la Universidad Autónoma Metropolitana. Obtuvo el Doctorado en Ciencias Políticas y Sociales y la Maestría en Estudios Latinoamericanos, ambos con mención honorífica en la UNAM. Realizó estancias posdoctorales en el Instituto de Investigaciones Económicas y en la Universidad Autónoma Metropolitana Azcapotzalco. Su investigación se centra en la contradicción del capital en la naturaleza, los movimientos sociales, la autonomía, el Estado y la comunidad. Investigador Nivel I en el Sistema Nacional de Investigadores, es profesor de asignatura en la Facultad de Ciencias Políticas y Sociales de la UNAM. A partir de 2024 es profesor-investigador de tiempo completo en el Instituto de Investigaciones José María Luis Mora. Es activista y acompañante en múltiples movimientos sociales.Notas del Episodio* La teoria y proceso del capital como metabolismo social* Biomercantilizacion* El problema de clase* Consecuencias escondidas del ecoturismo* Limites* Autoregulacion de las comunidades* Construyendo comunidad en la ciudad* Autonomia es la clave* Un mundo donde quepan muchos mundosTareaPagina profesional César Enrique Pineda (Ensayos, Libros, Proyectos)Twitter de CesarFacebook de CesarTranscripcion en EspanolChris: [00:00:00] Bienvenido César, al podcast El Fin del Turismo. Muchas gracias por estar dispuesto a hablar conmigo hoy. Me gustaría comenzar preguntándote, ¿Dónde te encuentros hoy y cómo se ve el mundo para ti allá? Cesar: Yo habito en Ciudad de México. Desde hace tiempo estoy haciendo una investigación, de nuevo, la continuidad del proceso del proceso del aeropuerto. Entonces estoy yendo muchas veces hacia Texcoco hacia el oriente de la ciudad, hacia el viejo lago de Texcoco, entonces tengo una doble mirada, la mirada urbana tradicional donde vivo y donde doy clases, que es en la UNAM y en el Mora, y por el otro lado, los pueblos, la comunidad y el el sistema lacustre al que estoy yendo cotidianamente.Chris: Y cómo va eso en Texcoco, si te puedo preguntar?Cesar: Va bien, creo que el frente de pueblos en defensa de la tierra ha tenido un nuevo triunfo. Y creo que es un nuevo avance, es un movimiento un poco anómalo en México porque [00:01:00] prácticamente ha ganado todas sus batallas, ha detenido los dos aeropuertos, ha liberado a sus presos y ahora ha logrado proteger el territorio.Y hoy se encuentran frente a un nuevo reto que es ser gobierno local, no? Entonces, en todas ha triunfado al final, a pesar de los costos enormes, pues que ha sufrido por la represión, por la persecución, por la precariedad también por la que viven muchos de sus miembros. Pero creo que van muy bien.Chris: Claro, wow, pues, qué bueno, qué hermosa resultado no? Cesar, parece, que mucho de tu trabajo, se basa en lo que podemos llamar la conversión de la naturaleza en capital, o al menos así es como los teóricos lo han descrito tradicionalmente. Me gustaría preguntar, ¿Cómo ves que eso sucede en el mundo del turismo, la conversión de naturaleza en capital para, para empezar, para darnos un [00:02:00] base de seguir? Cesar: Sí, bueno, hay que decir que lo que he tratado de también estudiar o teorizar. Cuando teorizamos hacemos generalizaciones. La teoría es una generalización para poder dialogar en contextos distintos, en casos distintos, sino cada caso por supuesto, es totalmente distinto que el otro por su historicidad, por su localidad, por su particularidad.Cuando teorizamos tratamos de hacer una generalización válida para muchos casos. Entonces, y eso nos permite a dialogar y pensar a muchos con una misma forma de nombrar y conceptualizar. Entonces, ese trabajo de conceptualización y teorización lo he hecho en la idea de cómo intentar comprender, se despliega efectivamente el capital territorialmente. Generalmente pensamos al capital solo como relaciones dinerarias, como inversiones y como ganancias, de hecho, compensamos el capital como, la [00:03:00] cosa, el dinero, en todo caso, como riqueza material, mercancías, puede ser ropa, puede ser autos, pero en general, el capital es un proceso. Que es lo que plantea a Marx, y el proceso es cómo la gente se organiza, organiza el trabajo, unos trabajan para otros y cómo toman efectivamente de la naturaleza lo que necesitan para producir nuevas mercancías o nuevos valores de uso, que es lo que, la utilidad que es lo que le llama Marx.En ese sentido, producir muchos valores de uso requiere necesariamente, de algún vínculo con la naturaleza. Ese vínculo Marx le llama metabolismo social porque es un vínculo, no solo, porque tomas lo que necesitas, los materiales, por decir así, algunos les llaman recursos en la economía. Generalmente en la ecología política o en la agro ecología les llamamos bienes [00:04:00] naturales. Porque no son cosas para simplemente recursos que están ahí disponibles para gastarse. Y ese vínculo que hoy se ha desarrollado todavía más con algunos teóricos de que han seguido la idea de metabolismo social de Marx, plantean siguiendo también algunas ideas de Marx, que es la forma de organizarnos, de organizar el trabajo. El trabajo es el vínculo con la naturaleza y ese vínculo es a la vez un intercambio de materia y de energía con los ecosistemas locales. Ese intercambio este más le llama metabolismo. Entonces, digo todo esto porque es muy importante pensar como lo que le llamamos la economía, desarrolla ciertas formas de actividad, de trabajo material y no solo de intercambios dinerarios y monetarios, porque a veces parece que una actividad da muchas ganancias y podría estar, tomando, por ejemplo, de la naturaleza, [00:05:00] demasiados bienes naturales, aunque produzca en realidad muchas ganancias, monetarias.Y en ese sentido, lo que he estado estudiando es precisamente cómo se despliegue el capital, buscando por decir así, lo que necesita de los ecosistemas, pero de los ecosistemas no necesita todo a veces, en ocasiones, si necesita todo el ecosistema, que eso es lo que voy a explicar, rapidísimo ahorita.Pero en otras ocasiones, necesita solo uno de los bienes naturales, necesita tierra para cultivar y entonces acapara sea comprando, sea despojando, sea rentando la tierra. Por el otro lado, puede no necesitar el suelo para producir, no solo es la tierra para producir, sino que además necesita que esa tierra tenga climas.Esto parece, no tan de sentido común. Lo tienen mucho más claro todos los campesinos, pero es evidente que en ciertas zonas se dan ciertas, [00:06:00] especies y en otras, por ejemplo en lugares fríos, se dan más pues la producción boscosa y por tanto, la producción, se cultiva pino y eucalipto. Y en los trópicos se cultivan frutas.Entonces las inversiones económicas que le podríamos llamar el capital, pero ese capital es un proceso como he dicho, reorganiza los trabajadores, a las trabajadoras. Organiza también la relación con la naturaleza o la reorganiza. Entonces, doy estos ejemplos siempre porque son muy ilustrativos de lo que sucede, por ejemplo, si hay más inversiones para cultivar, para producción maderera. La producción, obviamente los quien invierte requiere su ganancia rápido. Entonces tienes que invertir y tener ganancias. Tienes que invertir y vender rápidamente la madera, por ejemplo. Por tanto, pues, se cultivan las especies que crezcan más [00:07:00] rápido.Y por como crecen más rápido, necesitan más agua. Si necesitan más agua, agotan los mantos acuíferos. Aquí tenemos una consecuencia directa de la organización humana en la naturaleza, en como reorganizarla porque va sustituyendo el bosque nativo y lo sustituyes por especies que solo son las que se pueden vender, en este caso, pino y eucalipto.Ahí está claro, como entonces, se reorganiza el tiempo, a los trabajadores, por ejemplo. Si hay todos los trabajadores de la industria forestal que les ofrecen un tipo de trabajo y la relación con el agua, con los ecosistemas locales y con las especies que cultivas, ahí está todo el circuito de lo que organiza.Entonces, cuando pensamos en inversiones, no estamos pensando generalmente en lo que hay detrás. Así podríamos seguir la producción de un auto, la producción de algodón para nuestra ropa, la producción de cristal, la producción de hierro, de plásticos, todo se puede, pensar así. Y también dentro [00:08:00] de las formas de despliegue de la naturaleza, he pensado que haya en ocasiones, hay otra forma que le llamo bio mercantilización turística, que es acaparar ecosistemas completos para ponerlos, por decir así, poner a las ballenas, poner a los caimanes a trabajar, que es una forma de decirlo en el sentido de la renta de la tierra, la renta de los ecosistemas y sobre todo, la gran industria que se construye alrededor de los enclaves turísticos.Todo esto constituye una nueva relación con la naturaleza que es, creo la que vamos a estar conversando en tu programa, porque no modifica o no solo se le ha visto generalmente al turismo como una industria benévola porque no tiene chimeneas. Es muy distinta, por ejemplo, de pues de la industria petrolera, que es la que generalmente pensamos que es la única sucia.Pero la industria turística es [00:09:00] una industria. Lo que pasa es que es una industria de servicios. Es una industria también global. También es monopólica. O sea que está concentrada en pocas corporaciones y cambia, por supuesto, la forma de organizarnos alrededor de los ecosistemas.Chris: Wow. Me ha dejado pensar mucho en como las cosas que parecen como tours o recorridos, quizás podrían estar promocionados como ecológicas o ecológicas, caminatas en el bosque o igual esos recorridos en el mar, en el Yucatán o aquí en Oaxaca para ir a solo ver las las ballenas o tortugas, etc. ¿Es un poco así de lo que estás hablando, no? Cesar: Sí. Ahora hay que decir que estos servicios que tú mencionas generalmente que a veces les ponen el nombre eco turístico, son las de menor [00:10:00] producción de valor o mejor dicho, no producen valor, sino solo hay intercambio dinerario. Pero las que tienen mayor producción de valor son la enorme infraestructura global, los hoteles y las aerolíneas. Y estos son controlados evidentemente por las grandes corporaciones y tienen un impacto gigantesco. Es decir, cuando nosotros pensamos que vamos a hacer una actividad también en Oaxaca, por ejemplo, como tú mismo dices, y que estamos viendo una actividad muy linda de reproducción de la vida de las tortugas. No estamos pensando en toda la cadena de mercancías que es una cadena de servicios que también no solo tiene nuestra huella ecológica, sino de cómo reordenan las inversiones los territorios.En México, por ejemplo, pasamos en alrededor de principios del siglo XXI, de 7 millones de turistas internacionales a 30 o 35 millones.Es decir, en 20 años, prácticamente se ha triplicado el [00:11:00] volumen de, turistas. Ahora, esos turistas no, además, siempre pensamos incluso los gobiernos, incluso el último gobierno ha promovido todavía más el turismo, porque se supone que eso es totalmente benéfico, porque obviamente traen una derrama económica para lugares generalmente también que son pobres.Pero el problema de esta percepción es que no estamos, quizá a veces teniendo una perspectiva crítica donde evidentemente se va formando también una división del trabajo social y una división de la naturaleza y quién accede a ella y para qué. Son las elites mundiales, es decir, también los trabajadores asalariados del norte, que tienen mayor recursos y mayor seguridad económica, los que tienen más tiempo libre y también más recursos para acceder al ocio y la diversión.Las clases bajas no. Entonces hay una división de entrada por el [00:12:00] dinero, por el acceso, quien puede acceder al primero, al tiempo libre. Pero no todo mundo que tenga tiempo libre tiene acceso a los servicios de ocio, diversión y turísticos. Entonces, aquí hay una doble división, una división de clase, ya viéndolo así, vamos viendo que entonces los ecosistemas no se usan simplemente, por todos, de manera igualitaria, sino que unos tienen más acceso y otros no. O unos más tienen acceso de manera paulatina y otros mucho más esporádicamente que es esa división de clase. Pero la otra división que es muy importante es el consumo, es decir, convertir, por eso le llamo bio mercantilización, en el sentido de convertir a los ecosistemas en una mercancía que vender, esa mercancía no te la puedes llevar como, como otras, que si se producen con la mano humana, sino ecosistemas que están puestos al [00:13:00] servicio de la renta, pero también a un nuevo control. Y esto es importante, un nuevo control, del ecosistema.Generalmente casi todos los ecosistemas del mundo tienen una gestión hasta hace muy poco tenían una gestión comunitaria. Esta gestión no es solo, que la gente comparta los bienes naturales, sino que hay reglas para compartir los bienes naturales. La premio Nobel de economía Ostrom descubrió curiosamente, se viene a descubrir en las ciencias sociales algo que en realidad los pueblos y las comunidades realizan desde hace cientos de años. O sea, para ellos no es un descubrimiento, es su forma de vida. Que es, que hay un sistema de autorregulación donde, por ejemplo, para no agotar los bienes naturales, hay sistemas de rotación. Hay sanciones para quien viole sistema de rotación, límites, por ejemplo, para [00:14:00] pescar, límites para hacer, para poner a pastar a las vacas, límites para, por ejemplo, en algunas especies que saben que si se recolecta demasiado, pueden provocar la caída de un banco, por ejemplo, de moluscos.En fin, hay muchísimos saberes de los pueblos, donde saben cómo no agotar los bienes naturales. No quiere decir que todos los pueblos tienen sistemas de autorregulación que les llaman comunes. Pero significa que muchos pueblos sí los tienen. Cuando llega un enclave turístico, cambia este tipo de relación y cambia la gestión de puede ser de un manglar, puede ser de una laguna, puede ser de un río, puede ser de un bosque. Y se orienta hacia la venta de servicios, cambiando a veces de manera armónica con esa regulación comunitaria, a veces desplazando por completo a esa regulación comunitaria y convirtiendolos en [00:15:00] trabajadores de los servicios turísticos.Estos dos cambios ya deberían hablarnos el tanto la perspectiva de clase como la perspectiva comunitaria, de dos formas muy violentas en realidad de desorganizar y volver a organizar, pero ya con la base de querer generar ganancias tanto a los trabajadores como a las comunidades. Y junto con las comunidades, los ecosistemas locales.Chris: Wow. Pues sí, inmediatamente hablando de la cuestión comunitaria. Y esos cambios me ha pensado en la milpa y también como, eso fue mucho parte de la vida cotidiana de la gente. Y también pensando en la milpa, o sea ese sistema de agricultura que hay en Mesoamérica. He pensado también en esa cosa de ciertas ciudades o pueblos antiguos mesoamericanos que, fueran [00:16:00] supuestamente abandonados, pero pensando en la milpa, la necesidad de poner límites en el uso del suelo que también quizás eso tenía un lugar en el contexto de una sociedad, o al menos ciudad, o al menos pueblo entero como ya es el tiempo para dejar este lugar a su tiempo. Pero esa cosa es algo que que ha surgido muchísimo en el podcast sobre los años, con esa cuestión de sacar límites, que el turismo es una industria que destruyen los límites. Y pues, mencionaste al principio de Marx y también mencionamos de un poco de la ecología y has escrito un poco de marxismo ecológico. Y quería preguntarte si marxismo ecológico es solo una manera de medir y definir lo que [00:17:00] está pasando o también como reaccionar, responder, evaluar quizás. Cesar: Yo diría que el marxismo ecológico es solo una de las tradiciones de los nuevos ambientalismos, y de las tradiciones teóricas. Porque, deberíamos separar los saberes bioculturales de los pueblos. Es decir, la forma efectivamente que son, saberes sobre la flora, la fauna, los suelos, el clima, la producción, el consumo y el desecho que las comunidades tienen. Otra vez, no todas las comunidades tienen un sistema auto regulado en torno de todo esto. Algunas si los mantienen. Otras se han, mantienen partes y otras más han perdido buena parte de su organización, y entonces empiezan a producir lo que yo llamo una perturbación metabólica. "Perturbación" viene de la teoría de sistemas, por ejemplo, nos explicaban los que se dedican a [00:18:00] eso, especialmente por ejemplo, en los ecosistemas acuíferos que, por ejemplo, cuando hay un cambio bioquímico en las aguas, por ejemplo un contaminante está entrando rápidamente, pues evidentemente, porque en una laguna muy grande, pues no se nota ese contaminante no? Es decir, pareciera que lo puede diluir. Es tanta la cantidad de agua que diluye los contaminantes, no?Pero si hay de pronto una derrama muy importante de un contaminante. Por ejemplo, puede cambiar de color o puede cambiar, repentinamente. Esa capacidad de ilusión o de resistencia, por ejemplo, para mantener su color o mantener ciertas formas, es lo que se le ha llamado resiliencia. Y, la transformación abrupta sería una perturbación en el sistema como tal. Entonces, pensando yo en Marx y pensando en esta teoría de sistemas, pensé [00:19:00] que la idea de que tenemos este vínculo, de la organización social con la naturaleza, pensé en la idea de que la perturbación metabólica podía ser un cambio abrupto de la relación con el ecosistema.Que no necesariamente es porque se le quita la tierra a la gente, por ejemplo, pienso en que los campesinos mismos para poder competir en el mercado, como el mercado está acaparado por grandes corporaciones que producen muy rápido, ellos tienen que empezar a comprar los paquetes tecnológicos, básicamente agrotóxicos, para producir más rápido. Entonces eso, aunque ellos tuvieran una relación más o menos, sostenible, más o menos armónica con su milpa al meter un agro tóxico, empiezan a cambiar su relación metabólica con el ecosistema, aunque no haya llegado la corporación a obligarlos, sino que ellos toman la decisión porque cada vez su producto en el mercado vale [00:20:00] menos.Entonces tienen que producir más. Esa perturbación, por ejemplo, y esos, están organizados alrededor también de ciertos saberes. Entonces, por un lado, tenemos los saberes de las comunidades que pueden perderse, que pueden desestabilizarse o que puede cambiar, como he dicho, y por eso me refería a la perturbación metabólica comunitaria, cambia abruptamente y puede ser muy dañino para sus ecosistemas.Y por el otro lado, tenemos una serie de saberes científicos de una, y de una serie de saberes teóricos, que podría reunirse en varias tendencias, y una de ellas es el marxismo ecológico. Hay una serie de autores, que han regresado a la lectura de Marx pensando que nos puede decir en términos ecológicos y en los textos publicados, los que Marx si quiso publicar, hay una enorme cantidad de referencias y una visión [00:21:00] que, al contrario de lo que se había pensado hasta hace poco, Marx siempre está pensando en la naturaleza.Pero también hay un paquete de notas y de cuadernos de investigación que son los que han dado, por decir así, nuevos descubrimientos. Hasta hoy no se ha publicado todo lo que Marx escribió. Aunque muchas de esas eran notas, no eran textos como los que se conocen como Los Grundrisse o como El Capital.Estas notas están siendo revisadas por muchos expertos, y uno de ellos, por ejemplo, dos de ellos, John Bellamy Foster, ya hace ya 20 años y Kohei Saito de Japón han encontrado en las notas de Marx que él estaba cada vez más preocupado por como la industria capitalista, la industria de la agricultura agotaba los suelos.Entonces, resulta que Marx estaba estudiando precisamente química, estaba estudiando todo la la geología de los suelos, la composición y estaba [00:22:00] muy interesado en lo que iba a producir el capital y estaba convencido al final de su vida, solo que ya no produjo un texto para publicar, estaba muy preocupado por el descubrimiento que el mismo había pensado de que el capital agota las bases de su propia renovación. Agota, es una forma de relación social, aunque pensamos que solo económica, pero es una relación económico-social que agota los bienes naturales. Aunque eso sí lo publicó, Marx dice literalmente, el capital socava a las dos fuentes de la riqueza. Dice, "el trabajo y la naturaleza." Y esa visión doble me parece muy importante al nombrarla en una serie de académicos que han mantenido esta investigación a partir de ciertas ideas marxistas y han seguido avanzando.Son una veintena de ecologistas marxistas que están discutiendo hoy el cambio climático [00:23:00] que están discutiendo hoy la crisis ambiental a partir de la crítica al capitalismo. Chris: wow.Ye wow. Entonces, mi próxima pregunta viene un poco de la capacidad de considerar esas crisis que mencionaste, dentro de otras aperturas de ecología. Entonces, pues, en la segunda temporada del podcast entrevisté a Pedro UC de Muuch Xiinbal en el Yucatán, sobre la situación el mal llamado tren maya y también con un grupo del pueblo Wixarika que hablaba sobre los invernaderos que estaban invadiendo a su región, así como sobre los cazadores furtivos de pepeyote, los turistas espirituales estaban también causando daño a sus tierras, a sus [00:24:00] relaciones, no solo económicas, pero también culturales. Quizás podemos decir espirituales. Entonces, en este contexto, a menudo se dan dos tipos de extractivismo a la vez, la transformación de la tierra en mercancía y el intento de adquisición de conocimiento o poder espiritual.Cesar: Entonces, tengo curiosidad por saber cómo ves que estos dos mundos interactúan tanto en México como en otras partes de Latinoamérica, en esta cuestión de que la ecología también incluye la cultura y la religióna de la gente. Sí, bueno, el capital, como relación social, tiende a mercantilizar todo. Hay que recordar, por ejemplo, yo también doy siempre como ejemplo que el maquillaje de las mujeres en realidad era, que está feminizado era el maquillaje de los pueblos. Era el embellecimiento. Todas las [00:25:00] culturas, todas, todas las civilizaciones tribales hasta grandes civilizaciones de agricultura, ya basadas en los ríos, las grandes culturas en todos los tiempos, solemos embellecer nuestros cuerpos. Solemos decorarles de muy distintas maneras, de muy distintas formas. Generalmente ligadas al proceso cultural local. El capital lo ha vuelto una mercancía. Cesar: Es decir, en vez, si lo pensamos, antes pues todas las culturas, las tribales podían embellecer sus cuerpos, sus pieles, de múltiples maneras, sabían la técnica para hacerlo, utilizar los materiales para hacerlo, o forjar sus propias joyas, y hacer su propio vestido. Todo lo que acabo de decir, el capital lo ha convertido en una mercancía y despojado, por decir así, de los saberes.No sabemos hoy la gente [00:26:00] que vivimos en las ciudades urbanas, modernas, totalmente capitalizadas. No sabemos hacer esas cosas. No sabemos embellecer nuestro cuerpo, o lo sabemos a partir de los materiales y las mercancías que nos vende una industria. Entonces el capital utiliza nuestras necesidades y la necesidad de embellecernos no es una frivolidad. Lo que pasa es que se convierte en una frivolidad cuando se produce en masa mercancías que efectivamente son para el embellecimiento y traen junto con ellas un marketing de embellecimiento de ciertas formas, además de belleza hegemónica. Entonces, por qué digo este ejemplo que parece muy lejano a nuestra conversación sobre la naturaleza, porque el capital puede convertir en servicio y por tanto, en un servicio que de ganancias prácticamente cualquier forma [00:27:00] etno cultural que le llaman, cualquier forma etno turística, cualquier forma eco turística, es decir, generar ganancias a partir de los servicios de conocer, de divertirse, del ocio, de incluso del contacto social que le llaman turismo de contacto social. Es decir que busca una experiencia alternativa que puede ser gran diversión, estas máquinas que te elevan con el agua en el mar con un técnico que te acompaña, o simplemente las motonetas que en lugar, en lugares boscosos, es decir, puede ser cualquier tipo de servicio turístico que esté acompañado, acompañando a vivir una experiencia en un ecosistema que generalmente está fuera de tu ciudad. Pero además, esta división, ciudad y lo rural o ciudad, enclave turístico o ciudad [00:28:00] también lugar del Edén, lugar paradisíaco. Esta división se ha producido, pues por la concentración de capital en las ciudades y por la concentración del trabajo en la ciudad. Entonces, lo que esta división internacional del trabajo que produce entonces ciudades que trabajan y lugares de descanso y, por tanto, trabajadores y trabajadoras que te tienen que atender para tu descanso, pues es lógico que es una división internacional que también hace que haya países productores de servicios turísticos y países consumidores o ciudades consumidoras de servicios turísticos también. ¿Porque también planteo esta enorme división? Porque, la extracción de bienes naturales es muy conocida del sur al norte y tiene que ver efectivamente también con los enclaves turísticos y la infraestructura turística que se construye.[00:29:00] Los gustos y las necesidades de la, el turista de élite de clase media y de clase alta, requiere ciertas comodidades que no necesariamente son producidas en el ecosistema local. Entonces hay que traer, por decir así, si el turista de élite quiere fresas y luego un pan con aguacate, bueno, hay que traer fresas desde el otro lado del país, incluso del mundo, y hay que traer aguacate que que es... ¿Por qué digo estas dos? Porque la primera se produce bajo ciertas formas de explotación de jornaleros, por ejemplo, en el norte de México. Y hay que llevarlos hasta la península. Si dijéramos en el tren maya en un lugar que aparentemente podría ser, eco friendly, es decir, podría producir, intentar producir orgánicamente, no gastar agua o gastar [00:30:00] menos, o tener ciertos servicios en su localidad. Bueno, hay que traer fresas desde el otro lado, hay que traer aguacate que tiene un gran consumo de agua. Esto es muy importante, hay ciertas especies, lo que tú decías, de no hay límites. No hay límites. Si el turista quiere aguacate hay que tener aguacate y, por tanto, hay que traerlo de Michoacán, que agota también los mantos acuíferos y se expande como monocultivo.Ahí está esta relación extractiva, no sólo del sur al norte, también de las ciudades, frente a lo rural y de los enclaves turísticos frente a los ecosistemas en general. Entonces este tipo de relaciones no son sostenibles. Este extractivismo, entonces no solo es, puede ser cultural, evidentemente, que volver mercancía, relaciones sociales, relaciones culturales que en general no eran, no entraban a la esfera de las mercancías. Por eso también llamo bio mercantilización, porque es incluir en [00:31:00] esferas de los bienes naturales, esferas de los ecosistemas al área de las mercancías, cuando antes no lo eran, generalmente es el agua lo que pensamos. Antes no era una mercancía. Ahora, cada vez más, hay un intento, porque lo sea.Entonces, en este doble sentido de extractivismo, me parece muy importante hacer la claridad de que los enclaves turísticos son también una forma de extracción y de descampesinización. Otra vez, hace una perturbación metabólica porque el campesino que no puede acceder con la propia venta de su producto, ve como una opción el trabajar en un hotel, ve como una opción abandonar la tierra. Y si se abandona la tierra, entonces se puede rentar para otras cosas, o se puede deforestar o se puede urbanizar esa tierra si el campesino... la mejor forma de cuidar la tierra es que el campesino la siga cultivando. Pero si [00:32:00] la abandona, le puede suceder cualquier cosa a la tierra. Y terminamos efectivamente con un enclave turístico que incluso puede tener, insisto, una perspectiva verde, decir que está produciendo, que tiene comida orgánica o que recicla las aguas o que hace este tipo de acciones que son evidentemente muy positivas, pero en comparación con el cambio metabólico que va a producir en los campesinos del ecosistema local, abandonando la tierra y considerando el enorme consumo que tiene que llevar de otras partes del país y del mundo para el consumo de élite, pues parece que es insuficiente reciclar el agua, no dar popotes o tener una dieta vegetariana en un hotel. Es decir, la perturbación del ecosistema y la extracción de bienes naturales de otros lugares y el más importante, el agua, [00:33:00] simplemente no son cambios mitigables, no son cambios que se pueden comparar con las pequeñas acciones de cuidado ecológico que, por supuesto, todos tenemos que hacer, y todos tenemos que educarnos en ellas, pero a nivel estructural, por supuesto, el enclave turístico es más destructor, enclave corporativa, enclave industrial, enclave de oligopolios, enclave de gran consumo. Que estas acciones que mencionan.Chris: Gracias César. Pues una cosa que solo pude entender cuando ya he empezado trabajando en la industria turística, era de como cada lugar que fui a visitar en el mundo antes, aunque si me quedé una semana, dos semanas, un mes o igual como tres, seis meses, [00:34:00] no me quedé suficientemente tiempo para entender la consecuencia de mis movimientos allá.Y entonces creo que eso se queda muy fuerte, que los turistas tienen una responsabilidad que está totalmente, no totalmente, pero casi totalmente alejado de su capacidad para saberlo, para entenderlo, y, pero cuando hablamos del poblador campesino, que no solo tiene como ciertas fuerzas económicas, pero también siento que deseos culturales, o sea, como ese sueño americano, que ahora es un sueño global y eso. Pero por ejemplo, me quedé pensando los pueblos de Oaxaca que hacen ecoturismo, y ecoturismo basado en el municipio, en la asamblea, como una manera de quedarse la gente en el pueblo, generar ingresos y quizás también entrarse [00:35:00] con un vínculo y relación de hospitalidad que va más allá de la industria turística, por ejemplo, pero también la mera presencia del extranjero, extranjera en un lugar así cambia, lo que existía en el pueblo antes . Y en muchos pueblos, si hay gente que dicen, pues no, "fue un error." Y hay otros que dicen "no, o sea, está alimentando, muy bien, el pueblo." Entonces quería preguntarte qué piensas de esas, no necesariamente contradicciones, pero distintas reflexiones y consideraciones.Cesar: Yo creo que es una alternativa, efectivamente, cuando viene como proyecto de los propios pueblos. Y cuando los pueblos tienen un proceso organizativo que les permite, afrontar el reto de una empresa comunitaria, de una cooperativa comunitaria [00:36:00] de servicios comunitarios y establecer efectivamente las reglas, y las formas de regulación de visitar, sea una comunidad, un ecosistema, en fin. Es decir, creo que cuando viene desde abajo, es una verdadera alternativa, aunque yo diría que es indispensable combinar con las formas de producción campesina que, insisto, se deterioran y se deteriora todos los ecosistemas.Entonces, creo que sería una forma desde abajo. El problema es cuando se impone desde arriba. Como en el tren en maya, donde se abren zonas hacia el turismo, donde formalmente se va a cuidar, discursivamente se va a cuidar estos elementos, pero hemos visto cómo la captura, por ejemplo, de las playas, cómo la captura y espacialización de los negocios con gran [00:37:00] inversión, acaparan por ejemplo, el comercio, acaparan el acceso a las playas, acaparan incluso la forma de urbanización. No son combinables, es que hay gente que piensa que lo comunitario puede combinarse armónicamente con las grandes inversiones del gran capital y con el gran capital corporativo turístico.Pero pues tienen lógicas distintas. No es que sea una buena y una mala no es una cuestión de moral, es una cuestión de organización social. Si el turista está de acuerdo, por ejemplo, en adecuarse a una dieta que localmente tenga una menor huella ecológica, y además se puede programar los límites como tú también destacabas de la capacidad de visita y la carga que puede tener la visita hacia el lugar en específico, puede ser perfectamente una alternativa, aunque [00:38:00] hay que decirlo, lo que pasa es que si cambiamos de escala, no es viable que mil millones de europeos y norteamericanos estén viajando todo el mundo. No no pueden producir tanto Co2, es decir, no pueden, entonces tenemos y hasta ahora no hay una discusión global sobre esto.Está en la discusión sobre los jets de los multimillonarios porque de por sí, un vuelo es muy contaminante, pero los jets son todavía más porque están dedicados al confort y para viajes que no son indispensables, sino de lujo. Entonces, si pensamos en la, en lo que habría que no solo regular, sino prohibir, los vuelos en jet, en la explosión gigantesca de las aerolíneas a nivel internacional, incluso en vuelos comerciales y no privados es insostenible.La industria de las aerolíneas dice que ellos solo producen el 1% [00:39:00] del Co2 mundial. Si, pero así cada industria dice no es que yo solo produzco el 2% o el 5%, o el 0.5%. Claro, entonces, al final, nadie es responsable de la producción de Co2, porque cada uno puede decir yo soy tan poco responsable que no me regulen, pero no es viable.Entonces, creo que tendríamos que pensar en turismo local, con acortar las cadenas de mercancías de producción de servicios turísticos. Es decir, pensando en que son los nacionales, los conacionales y los internacionales tienen que ser regulados. Bueno, incluso que tú conocerás más, yo conozco mucho más el turismo comunitario y los impactos comunitarios y menos el impacto del turismo barrial y urbano que viven varias ciudades europeas y que prácticamente está fuera de control en París, en Barcelona, está fuera de control y junto con Airbnb o otras [00:40:00] plataformas que permiten la llegada masiva de gente o incluso la visita permanente de extranjeros que no tiene que ver con su nacionalidad, no es una cosa xenofóbica, sino en el sentido del desplazamiento que no lo quieren los extranjeros, por ejemplo, en México, no es que sean malos, no es que sean, que sean extranjeros. Insisto, no es una cuestión ni racial ni xenofóbica, sino en el sentido de que los extranjeros en México, en la ciudad de México, no en una comunidad, no en un ecosistema todavía, protegido en un ecosistema, digamos más armónico que el de la ciudad, está siendo desplazada a la gente porque la capacidad dineraria, la capacidad de ingreso, la capacidad de clase desplaza la habitación en las colonias como Roma y Condesa. Entonces, por eso es muy importante que, cuando pensamos las alternativas, creo que tenemos que mirar todas estas [00:41:00] escalas, para la comunidad por supuesto, creo si, insisto si, si viene desde la comunidad como proyecto comunitario. Yo creo que es un proyecto que puede fortalecer el proceso, puede seguir manteniendo ciertos equilibrios ambientales y puede ser una alternativa económica de ingreso para las comunidades. Si lo vemos como estructura internacional, el turismo comunitario se queda muy corto para la capacidad de que, que los últimos 40 años de neoliberalismo han creado en infraestructura. Es decir, si hoy se puede viajar a cualquier lugar del mundo también a menor precio es porque hay más aerolíneas, es porque hay más infraestructura, porque hay más competencia, porque hay paquetes de crédito. Es decir, hay una mega industria, porque hay una enorme marketing para venderte vuelos, para ofrecerte, vuele ahora y pague después. Esa industria gigantesca mundial es insostenible, no puede viajar tanta gente al mundo, lo vamos [00:42:00] a reventar. Bueno, lo estamos reventando, estamos reventando al mundo con la movilidad turística internacional que cada vez es más incontrolable, y por el número. Otra vez, los turistas no son malos. El problema es la enorme cantidad de turistas que, efectivamente, por cantidad agotan el peyote en el norte, dejan sucia las playas, consumen más agua, requieren más energía eléctrica.Es decir, la industria en su forma corporativa e industrial internacional es insostenible. Creo que hay que pensar cómo se podría reducir los impactos hacia un turismo comunitario controlado por los propios pueblos. Y ahí, yo creo que esa es la alternativa. Chris: Mm. Mm. Gracias, César. Y pues, por lo que he leído, parece te metes mucho en la cuestión de autonomía y la emancipación de los pueblos. [00:43:00] Así como me gustaría preguntarte también, como crees que esos entendimientos puede ayudar a la gente urbana también para construir comunidad, comunalidad y solidaridad.Es algo que pensamos mucho como ah, pues ellos allá tienen la respuesta porque terreno y territorio, pero nosotros, como inquilinos, etcétera, que pues quizás jamás en nuestras vidas van a tener casa o territorio o terreno.Cesar: Bueno, primero mi interés es porque, en general, hasta 1989 hubo 200 años de una promesa, encabezada por la izquierda política. Y cuando me refiero a la izquierda política, no me refiero solo a los partidos, me refiero a un proyecto de superación de organización de la sociedad que prometió libertad, igualdad, fraternidad. El proceso por el cual, se [00:44:00] deterioraron los proyectos y los horizontes de transformación es muy grave, o sea, se ha pensado, hoy estamos, prácticamente resignados, resignadas, aunque hay millones que no, pero parece que si ese es el espíritu, el mood dirían los jóvenes, el mood de la época es que no hay una alternativa que, como han planteado Fredric Jameson o Žižek, es más fácil, pensar en el fin de la humanidad que en el fin del capitalismo, o en el fin del mundo que el fin del capitalismo. Entonces, estoy muy preocupado por pensar alternativas, y pensar efectivamente horizontes políticos, insisto político en un sentido amplio, no político partidario, sino político como la capacidad que tenemos, como incluso como especie para ponernos de acuerdo y tener horizontes de que queremos hacer, qué vida queremos, qué vida, qué proyecto de vida también deseamos y podemos [00:45:00] construir. De hecho, eso es lo que nos define como especie, que nos damos nuestra propia forma organizativa. Es la especie que puede tener una forma en China y otra forma en los Andes, y otra forma en Norteamérica, y otra forma en Sudáfrica. Cesar: Es decir, distintas formas de organización social que reproducen la vida y reproducir la vida, puede hacerse de manera muy despótica o de manera mucho más libre. Y en ese sentido, me he involucrado, si tengo muchísimo tiempo, quizá década y media o dos décadas, pensando entonces, cuáles han sido los elementos emancipatorios que ha habido en esos proyectos. Y en realidad lo que pensamos que fue el socialismo o el comunismo, que fueron en realidad experiencias autoritarias de partidos únicos y de élites, tenían en su germen otras ideas que era que el poder de los trabajadores, la autogestión de los trabajadores fuera la [00:46:00] nueva forma de organización social. Es decir, que los trabajadores tomaran las decisiones de la producción.Lo que yo veo en América Latina, donde hay un movimiento obrero menos importante, o menos grande, como lo fue el movimiento obrero en Europa, también en Estados Unidos, es que las formas originales no capitalistas permiten también reproducir la vida de otros modos, de modos comunitarios y de otros modos.Estos dos elementos en el norte de Europa, el poder de los trabajadores para controlar reproducción, los pueblos originarios controlando sus propios ecosistemas locales. Me parece que nos dan lecciones de otras formas de organización social. Acabo de publicar un texto, un libro, que habla de la producción de comunidad en las ciudades. Es una investigación en ciudad de México, donde un movimiento [00:47:00] masivo... es decir que generalmente también pensamos la comunidad como una cincuentena de personas, poquitas.Esas son miles de familias que han podido constituir, construir comunidades urbanas de la nada. No, no eran pueblos originarios que se desplazaron a la urbe, a la periferia como si ha sucedido, por ejemplo, en El Alto en Bolivia, sino clases populares, con muy bajos ingresos, que en la búsqueda de vivienda encontraron que no solo querían vivienda, sino también querían mejorar y dignificar su propia vida. Insisto de clases populares muy precarias. Y lo que han c onstruido, Raúl Zibechi, uno de los periodistas, intelectuales más conocidos de América Latina porque ha estado en prácticamente todos los movimientos sociales del continente. Desde el cono sur hasta México, desde la Araucanía de Chile hasta la Selva Lacandona en México. Lo llevamos [00:48:00] a que visitara esta experiencia aquí en Ciudad de México y dijo esta es la autonomía urbana más importante de América latina. Y concluyo diciendo en el tema de la autonomía. Entonces estoy muy interesado en no por estudiarlas desde la ciencia social como un objeto de estudio, sólo para saber cómo funcionan, sino porque al comprender cómo funcionan, nos dan alternativas a quienes no estamos en esas comunidades.Entonces, estoy muy interesado en conocer esas experiencias, rastrearlas históricamente, estudiarlas y entenderlas, y comprenderlas y aprender de ellas. Es decir, yo lo que quiero es que ese aprendizaje que han producido esas comunidades podamos comprenderlos otros que no vivimos en comunidad. Y, por último, un aprendizaje que de una noción que ha surgido después de la caída del muro de Berlín ha sido precisamente la autonomía, porque frente a las experiencias autoritarias de Europa del este, pues pareciera que [00:49:00] nadie queremos repetir una experiencia que, aunque rechazamos las formas capitalistas y liberales de la política, no queremos tampoco una experiencia autoritaria y centralizadora, y mucho menos totalitaria de un partido único que es el que decide todo. Lo que hemos encontrado a tanto teórica como en estos casos empíricos es que la autonomía, la capacidad de darse sus propias leyes, eso significa autonomía, pero más allá de las leyes, es gobernarse a sí mismo. En realidad es la emancipación. Emancipación significa quitarse de encima la mano del señor. ¿Qué señor? Era el señor feudal, así se creó más o menos la palabra desde, o del esclavo desde hace muchísimo tiempo. Quitarse de encima la mano del amo o del amo o del señor feudal, es decir que no te mande alguien más.Eso es vivir también en libertad, pero las comunidades viven en colectivo y para emanciparse requieren quitarse [00:50:00] ahora de una mano que es invisible, la mano del mercado, la mano del capital. Entonces, como nos emancipamos también en colectivo y la autonomía. Gobernarse a si mismo, significa también poner un freno a las decisiones de estados que generalmente en América Latina han tenido una perspectiva colonial en relación a los pueblos indígenas, o neocolonial, o también de colonialismo interno, como decía don Pablo González Casanova.Ahora, por último, la autonomía, entonces la considero, es el elemento central, incluso más allá del igualitarismo económico. Son dos proyectos distintos. Es decir, cuando la gente logra dignificar su vida, creo que es muy positivo, creo que todos quienes tenemos una perspectiva crítica emancipatoria o incluso de izquierda, queremos que la gente en general vivamos dignamente, no con grandes lujos, pero tampoco con una enorme precaridad donde a veces, pues si muchas comunidades viven en una enorme precaridad. [00:51:00] Pero lo que es más interesante es que sean los propios pueblos los que decidan como vivir y que decidan que es pobreza y que decidan que es dignificar, y que no se decida desde el estado, ni desde la academia, ni desde los estudiosos de el igualitarismo.Qué es lo que necesitan sus vidas, y cuando los pueblos logran controlar sus vidas, nos enseñan, otra forma de libertad. En ese sentido creo que estas experiencias también son reunidas para precisamente seguir la discusión de cómo sociedades que ya no tenemos organización comunitaria, que no tenemos una trama de organización tampoco en la fábrica, podríamos emular, replicar algunas de las prácticas, algunas de las formas organizativas para vivir efectivamente y regular la sociedad de una manera a otra, una manera más libre, una manera más igualitaria. Ese es un poco también el trabajo que he estado haciendo, que tiene que ver con [00:52:00] esta preocupación de, yo creo que hay mucho, muchísimas alternativas, pero ya no hay una alternativa que llame a todos, , que fue lo que movilizó en el siglo XX a muchísimos a muchísimas, a millones y millones de personas que incluso dieron su vida por hacer un cambio, un cambio que llamaban revolucionario. Y me parece que hoy, a pesar de que tenemos muchas más experiencias alternativas de base de los pueblos, de alternativas agroecológicas, de alternativas comunicacionales, de formas de regulación, de nuevas formas de establecer las relaciones de género, tenemos múltiples alternativas y múltiples teorías. Hoy pareciera que no, no los podemos, articular, digamos, en un proyecto común y a lo mejor necesitamos algunos elementos comunes, no para crear una sociedad que toda sea igual, sino al contrario, como decían, como dicen los zapatistas, un mundo donde quepan muchos mundos, muchas alternativas, pero [00:53:00] pensadas en muchas formas también de, de relación social comunal, igualitaria, libre y emancipadas.Chris: Mm. Sí, pues a través de ese comentario sobre la autonomía y la dignidad, y la diversidad que puede venir cuando tenemos esa libertad, quería preguntarte si podrías imaginar de un futuro sin turismo como lo estamos criticando el día de hoy, quizás un tipo de ocio, o viaje, o interculturalidad, que podrías imaginar, ¿Qué planteas en la conversación para la gente antes de terminamos aquí? Cesar: Si, primero, sobre esto del turismo, creo que deberíamos pensar que el mundo está terminando tal y como lo conocíamos. No hay ya condiciones, nos [00:54:00] dirigimos efectivamente, a un posible colapso sistémico si seguimos consumiendo energía y materia al ritmo que lo estamos haciendo. Y cuando digo al ritmo que lo estamos haciendo, reconociendo que los pobres consumen menos agua, por ejemplo, hay un estudio de familias del agua en ciudad de México donde algunas familias, las más pobres de la ciudad, consumen solo unos 50 litros, y en cambio, las más ricas o las más adineradas consumen más de 1000 litros al día, una sola familia.Entonces, me parece muy importante, entender estas diferencias de clase vinculadas a, la naturaleza y por el otro lado, pensar que todos, que hemos vivido, lo decía un empresario en un documental, dice, estamos volando un momento de la historia donde parece muy lindo porque hemos tenido una serie de comodidades que ninguna civilización pudo tener.Es decir, conocer el [00:55:00] planeta entero porque tenemos esa oportunidad cuando tenemos un poco de dinero, incluso aunque no seamos ricos, tenemos la capacidad, por la infraestructura, por las fuerzas productivas, porque efectivamente hay una red mundial que lo permite. Pero esto es insostenible, como son insostenibles muchos de los lujos.Es muy lamentable tener que pensar que ese lujo turístico debe terminar. Quizá en una sociedad donde pudiéramos decidir que preferiríamos. Pues, por supuesto, en mi caso, yo decidiría también conocer muchos lugares y reducir mi huella ecológica en muchísimas otras cosas que no son indispensables, pero eso solo sería posible, es decir, mantener el turismo. No bajo la forma corporativa que tenemos hoy. Si pudiéramos reducir nuestro consumo, por ejemplo, en el vestido, nuestro consumo eléctrico, nuestro consumo, por supuesto de carbono, entre muchos otros contaminantes y consumo de materia y energía. Entonces creo que [00:56:00] habría que pensar que en la nueva sociedad, que se tiene que construir, y a veces la gente lo ve a uno como loco, como diciendo, pero cómo, eso no va a suceder. El capitalismo está funcionando perfectamente. Pero estamos en un memento ya de transición, estamos, lo que sucedió con el huracán el año pasado aquí en México, en Acapulco, lo que sucedió en Valencia, son solo las primeras señales de muchísimas más que hay que no son conocidas. Estas fueron tragedias humanas y por tanto, se conocieron más. Pero ya vivimos una transición en términos del sistema tierra, que no sabemos qué va a suceder y debemos prepararnos para eso. Entonces, creo que debemos pensar más bien en cómo sería una sociedad alternativa donde el turismo comunitario y el turismo a baja escala, y el turismo controlado, o mejor dicho, regulado con bajo impacto de huella ecológica fuera posible, pensando en toda su cadena de mercancías, toda su cadena de servicios.[00:57:00] Creo que ese es el horizonte que deberíamos trazar en torno del turismo. Y mientras tanto, seguir apoyando las alternativas de los pueblos por controlar sus ecosistemas cuando deciden efectivamente, abrirlos al turismo, en cualquiera de sus formas.Y por el otro lado, y para cerrar efectivamente, hay decenas de aprendizajes de lo que donde yo me he acercado, y me he acercado también, precisamente porque he visto no solo esperanza, sino formas alternativas de relación social. Digo algunas, se puede crear comunidad urbana. Las clases populares tienen una capacidad política propia que se tiene que desarrollar, no es automática, no está ahí por su esencia popular, sino que puede generar sus propias formas políticas en un largo proceso de aprendizaje que permite entender que la comunidad es también una forma de ejercicio del [00:58:00] poder, una forma que regula también las posiciones, actitudes egoístas y las posiciones que se aprovechan de los otros, y las reprime, las suprime, pero también permite la producción de comunes, de beneficio común y la producción de nuevas relaciones sociales que satisfacen a todos y a todas, porque no son solo relaciones materiales, sino relaciones también emocionales, vínculos afectivos, satisfacción por servir a otros. Es decir, la comunidad si puede reproducirse en las ciudades, a diferencia de nuestra noción, de que solo en las comunidades rurales puede producirse, o en el ámbito rural puede producirse comunidad.Estos elementos son muy importantes. Por el otro lado, que la enorme riqueza biocultural de los pueblos, a pesar del deterioro ecosistémico, a pesar del avance de la urbanización, a pesar del deterioro de [00:59:00] los campesinos como clase social, a pesar del cambio climático, los pueblos siguen resistiendo. Ya han encontrado formas maravillosas para mantener cohesionadas sus comunidades, para reorganizarse, para tener sus propios horizontes político-comunitarios, sus autonomías y los saberes bio culturales que guardan, que ahora lo estoy precisamente investigando, como decía yo, en el caso de Texcoco, que es aprender de su relación con las otras especies, con las algas, las algas del lago de Texcoco, con las aves, con los suelos, suelos que no eran fértiles o que tienen una producción diferencial en en el maíz, en las otras especies que cultivan, sus propios saberes del cultivo, la combinación de cultivo, su relación con la tierra. Hablan de un, digamos de un cúmulo civilizatorio de ellos, pero de toda la humanidad. [01:00:00] Pues que nos da esperanza porque esos conocimientos, yo siempre les digo a mis estudiantes, imaginen en cuánto tiempo pasó para que pudiéramos aprender cuál hongo era comestible, cuál era alucinógeno y cuál no es comestible. Es un aprendizaje vital, no por, solo por los hongos, sino pero lo podemos reproducir en todos, el maíz, las frutas, las verduras, las hierbas medicinales.Es un conocimiento que no es de nadie. Es un común. Está abierto para todos y con ese podemos sobrevivir, los conocimientos sobre las semillas, sobre las aguas, sobre los ecosistemas locales. Y ese, los pueblos además están compartiendo esos saberes.Creo que con la idea de que la comunidad puede ser producida en la ciudad y que los saberes bio culturales no solo son de los pueblos locales, sino son los saberes de las grandes civilizaciones humanas, creo que tenemos dos herramientas para afrontar el enorme peligro que tenemos hoy frente al cambio [01:01:00] climático y los otros problemas ambientales que tenemos hoy, especialmente la sexta extinción masiva de las especies, la sedificación de los océanos, entre otros elementos. Pero tenemos dos grandes cúmulos de conocimiento humano que es milenario, y que ese nos puede permitir sobrevivir aquí y ahora, y hacia el futuro, que va a ser difícil, pero la organización de los pueblos, la organización de las clases populares, las alternativas que están ya instaladas en al menos las que yo conozco en toda América Latina, dan muestra que podemos tener alternativas viables, más libres, más horizontales, más democráticas, más emancipatorias.Chris: Mmm, vaya. Pues gracias, gracias César, por esos dos champiñones, lo comestible y de lo que está pasando en el día de hoy y también lo alucinógenico, lo que podemos imaginar en [01:02:00] otros mundos. Fue un gran gusto y honor para pasar este tiempo contigo. Entonces, me gustaría agradecerte, en el nombre de nuestros oyentes también.Y antes de terminar, solo me gustaría preguntarte si hay alguna manera de que los oyentes puedan seguir tu trabajo, ponerse en contacto contigo, leer tus libros, etcétera. Cesar: Sí, la forma más fácil es, utilizo X. . Que nombre tan horrible , pero es @cesarpinedar, con r al final, @cesarpinedar. Y también en mi página, enriquepineda.info, ahí en realidad están todos mis textos.Publico muchísimo en redes sociales, especialmente en X. Yo le sigo diciendo Twitter porque el verbo Twittear es mejor. ¿Cómo se dice ahora con X cuando publicas algo? Entonces, supongo, pero es más aburrido. En fin, les invito, agradecerte a ti mucho tus preguntas y esta conversación y esta [01:03:00] posibilidad de difundir un poquito de lo que sabemos y un poquito también de nuestro saber, que es un saber también entre muchos otros, muy diversos y legítimos y válidos todos.Entonces, agradecerte también por esta conversaciónChris: Gracias, César. ENGLISH TRANSCRIPT - Ecological Marxism w/ Cesar PinedaChris: [00:00:00] Welcome Cesar, to the podcast The End of Tourism. Thank you very much for being willing to talk to me today. I'd like to start by asking you, where are you today and what does the world look like for you there?Cesar: I live in Mexico City. For some time now I have been doing research, again, on the continuity of the airport process. So I often go to Texcoco, towards the east of the city, towards the old Texcoco lake, so I have a double view, the traditional urban view where I live and where I teach, which is at UNAM and Mora, and on the other hand, the towns, the community and the lake system that I visit daily.Chris: And how is that going in Texcoco, if I may ask?Cesar: It's going well, I think the people's front in defense of the land has had a new victory. And I think it's a new advance, it's a somewhat anomalous movement in Mexico because [00:01:00] it has practically won all its battles, it has stopped the two airports, it has freed its prisoners and now it has managed to protect the territory.And today they are faced with a new challenge, which is to be a local government, right? So, in all of them they have triumphed in the end, despite the enormous costs, because they have suffered from repression, from persecution, from the precariousness in which many of their members live. But I think they are doing very well.Chris: Yeah, wow, well, what a great, what a beautiful result, right? Cesar, it seems that a lot of your work is based on what we can call the conversion of nature into capital, or at least that's how theorists have traditionally described it. I'd like to ask, how do you see that happening in the world of tourism, the conversion of nature into capital to, to start with, to give us a [00:02:00] basis to follow?Cesar: Yes, well, I have to say that I have also tried to study or theorize. When we theorize, we make generalizations. Theory is a generalization in order to be able to dialogue in different contexts, in different cases, otherwise each case of course is totally different from the other due to its historicity, its locality, its particularity.When we theorize, we try to make a generalization that is valid for many cases. So, and that allows us to dialogue and think about many with the same way of naming and conceptualizing. So, I have done this work of conceptualization and theorization in the idea of how to try to understand how capital is effectively deployed territorially. Generally, we think of capital only as monetary relations, as investments and as profits, in fact, we compensate capital as, the [00:03:00] thing, money, in any case, as material wealth, merchandise, it can be clothes, it can be cars, but in general, capital is a process. That is what Marx proposes, and the process is how people organize themselves, organize work, some work for others and how they effectively take from nature what they need to produce new merchandise or new use values, which is what, utility is what Marx calls it.In this sense, producing many use values necessarily requires some connection with nature. Marx calls this connection social metabolism because it is a connection not only because you take what you need, the materials, so to speak, some call them resources in economics. Generally in political ecology or in agroecology we call them natural goods [00:04:00] . Because they are not things but simply resources that are there available to be spent. And this connection, which has been developed even further today by some theorists who have followed Marx's idea of social metabolism, propose, following also some ideas of Marx, that it is the way to organize ourselves, to organize work.Work is the link with nature and this link is at the same time an exchange of matter and energy with local ecosystems. This exchange is more commonly called metabolism.So, I say all this because it is very important to think about how what we call the economy develops certain forms of activity, of material work and not only of monetary and monetary exchanges, because sometimes it seems that an activity gives a lot of profits and it could be, taking, for example, from nature, [00:05:00] too many natural goods, even though it actually produces a lot of monetary profits.And in that sense, what I have been studying is precisely how capital is deployed, looking, so to speak, for what it needs from ecosystems, but sometimes it does not need everything from ecosystems, sometimes it does need the entire ecosystem, which is what I am going to explain very quickly now.But in other cases, he needs only one of the natural resources, he needs land to cultivate and then he monopolizes it either by buying, or by dispossessing, or by renting the land. On the other hand, he may not need the soil to produce, not only does he need the land to produce, but he also needs that land to have a climate.This seems to be not so common sense. All farmers are much clearer about it, but it is clear that in certain areas certain species are found and in others, for example in cold places, they are found more because forest production and therefore production, pine and eucalyptus are grown. And in the tropics, fruits are grown .So economic investments that we could call capital, but that capital is a process as I said, reorganizes the workers, the workers. It also organizes the relationship with nature or reorganizes it. So, I always give these examples because they are very illustrative of what happens, for example, if there are more investments to cultivate, for wood production. Production, obviously, those who invest require their profit quickly. So you have to invest and have profits. You have to invest and sell the wood quickly, for example. Therefore, the species that grow the fastest are cultivated .And because they grow faster, they need more water. If they need more water, they deplete the aquifers. Here we have a direct consequence of human organisation in nature, in how to reorganise it because it replaces the native forest and replaces it with species that can only be sold, in this case, pine and eucalyptus.It is clear that, as in the past, time is reorganized, for example, for workers. If there are all the workers in the forestry industry who are offered a type of work and the relationship with water, with local ecosystems and with the species that are cultivated, there is the whole circuit of what is organized.So when we think about investments, we are not generally thinking about what is behind them. So we could follow the production of a car, the production of cotton for our clothes, the production of glass, the production of iron, of plastics, everything can be thought of like that. And also within [00:08:00] Of the forms of deployment of nature, I have thought that there is sometimes, there is another form that I call tourist bio-commodification, which is monopolizing entire ecosystems to put them, so to speak, to put whales, to put alligators to work, which is a way of saying it in the sense of land rent, ecosystem rent and above all, the great industry that is built around tourist enclaves.All of this constitutes a new relationship with nature, which is, I think, what we are going to be discussing in your program, because it does not modify or not only has tourism been generally seen as a benevolent industry because it does not have chimneys. It is very different, for example, from the oil industry, which is the one we generally think is the only dirty one.But the tourism industry is [00:09:00] an industry. The thing is that it is a service industry. It is also a global industry. It is also monopolistic. In other words, it is concentrated in a few corporations and it changes, of course, the way we organize ourselves around ecosystems.Chris: Wow. It's gotten me thinking a lot about how things that seem like tours could perhaps be promoted as ecological or eco-friendly, like hikes in the forest or even those tours on the sea, in the Yucatan or here in Oaxaca to go just to see the whales or turtles, etc. Is that kind of what you're talking about?Cesar: Yes. Now it must be said that these services that you generally mention, which are sometimes called eco-tourism, are those with the lowest [00:10:00] production of value or rather, they do not produce value, but rather there is only monetary exchange.But the ones that have the greatest value production are the enormous global infrastructure, the hotels and the airlines. And these are obviously controlled by the big corporations and have a gigantic impact. That is, when we think that we are going to do an activity in Oaxaca, for example, as you say, and that we are seeing a very nice activity of reproduction of the life of turtles. We are not thinking about the whole chain of goods, which is a chain of services that also has not only our ecological footprint, but also how investments reorder the territories.In Mexico, for example, around the beginning of the 21st century, we went from 7 million international tourists to 30 or 35 million.That is, in 20 years, it has practically tripled [00:11:00] volume of tourists. Now, these tourists don't, in addition, we always think that even governments , even the last government, have promoted tourism even more, because it is supposed to be totally beneficial, because obviously they bring an economic spillover to places that are generally also poor.But the problem with this perception is that we are not, perhaps sometimes, having a critical perspective where a division of social labor and a division of nature and who has access to it and for what purpose is evidently also being formed. It is the global elites, that is, also the salaried workers of the north, who have greater resources and greater economic security , who have more free time and also more resources to access leisure and entertainment.The lower classes do not. So there is an entry division by the [00:12:00] money, for access, who can access the first, free time. But not everyone who has free time has access to leisure, entertainment and tourist services. So, there is a double division here, a class division, Now, looking at it this way, we see that ecosystems are not simply used by everyone in an equal way, but that some have more access and others do not. Or some have more access. gradually and others much more sporadically, whic

How do toys shape who we become? Today, I sit down with a fascinating toy historian Chris Byrne who reveals the hidden power of play - from how different toys develop everything from relationship skills to problem - solving abilities.    We explore why true play isn't about reaching an end goal, but about embracing the pure joy of the journey. Whether you're looking to understand the art of playing alongside your kids or giving them space to explore independently, this episode will transform how you think about playtime. Join us for a rich conversation about rediscovering the magic that happens when we give ourselves permission to simply play.   After exploring the art of play with our toy historian today, I want to share something powerful with you. My book Fertile Imagination tackles a crucial truth: we can't guide our children toward imagination if we've lost touch with our own. I'll show you the exact framework I used to reawaken and strengthen this superpower – the same one that transformed both my life and my three sons'. If you're ready to rediscover your creativity and childlike zest for life, grab your copy now: https://bit.ly/fertilebook     In this episode, you will hear:    Play is a process, not a means to an end, and embracing it can reduce stress. Imagination influences every decision we make. Playing with toys helps kids develop problem-solving and relationship skills. Adults benefit from play too—it fosters creativity, joy, and innovation. Letting children lead playtime strengthens their confidence and creativity. Kids learn by doing, and unstructured play is vital for their development. In corporate settings, a playful mindset can unlock new ideas and innovation. Fear of failure limits creativity—kids don't judge play, and neither should we.   This episode is brought to you by:    Fertile Imagination: A Guide For Stretching Every Mom's Superpower For Maximum Impact – My book is available as a hard cover, paperback, and also as an audiobook. If you are on the go and wish to quickly jot down where you can purchase the book then head to: https://bit.ly/fertilebook.    If however you want to grab the audio version then head to the show notes to click the direct Amazon link: https://www.amazon.com/Fertile-Imagination-Stretching-Superpower-Maximum/dp/B0CK2ZSMLB   About Chris Bryne   Chris Byrne has spent over 35 years in the toy industry, holding major marketing and creative roles before launching Byrne Communications, a consultancy specializing in product development, strategic planning, and marketing. A passionate advocate for the power of play, he has studied its impact on child development and creativity across industries. He has appeared on major media outlets worldwide, sharing insights on toys, play, and innovation. He also co-hosts The Playground Podcast, diving deep into the toy industry's past, present, and future.   SHARE this episode with fellow moms and entrepreneurs who want to bring more creativity into their lives! Chris's insights on play, imagination, and innovation are a must-listen for anyone balancing motherhood and career growth. Let's embrace play, rediscover joy, and inspire the next generation! Supporting Resources:   Website: https://www.thetoyguy.com/  Instagram: https://www.instagram.com/thetoyguy/  Facebook: https://www.facebook.com/thetoyguyofficial/ The Playground Podcast: Spotify & Apple Podcasts Subscribe and Review   Have you subscribed to my podcast for new moms who are entrepreneurs, founders, and creators?  I'd love for you to subscribe if you haven't yet.    I'd love it even more if you could drop a review or 5-star rating over on Apple Podcasts. Simply select “Ratings and Reviews” and “Write a Review” then a quick line with your favorite part of the episode. It only takes a second and it helps spread the word about the podcast for writer moms. About Fertile Imagination   You can be a great mom without giving up, shrinking, or hiding your dreams. There's flexibility in how you pursue anything – your role, your lifestyle, and your personal and professional goals. The limitations on your dreams are waiting to be shattered. It's time to see and seize what's beyond your gaze. Let's bridge your childhood daydreams with your grown-up realities. Imagine skipping with your kids along any path – you, surpassing your milestones while your kids are reaching theirs. There's only one superpower versatile enough to stretch your thinking beyond what's been done before: a Fertile Imagination. It's like kryptonite for impostor syndrome and feeling stuck when it's alert!    In Fertile Imagination, you will awaken your sleeping source of creative solutions. If you can wake up a toddler or a groggy middle schooler, then together with the stories in this book – featuring 25 guests from my podcast Unimaginable Wellness, proven tools, and personal anecdotes – we will wake up your former playmate: your imagination!  Advance Praise    “You'll find reality-based strategies for imagining your own imperfect, fulfilling life in this book!” —MARTHA HENNESSEY, former NH State Senator    “Melissa invites the reader into a personal and deep journey about topics that are crucially important to uncover what would make a mom (and dad too) truly happy to work on…even after the kids are in bed.” —KEN HONDA, best-selling author of Happy Money    “This book is a great purchase for moms in every stage of life. Melissa is like a great friend, honest and wise and funny, telling you about her life and asking you to reflect on yours.” —MAUREEN TURNER CAREY, librarian in Austin, TX           TRANSCRIPT 00:00:00 Chris: I really believe is what we play with as kids really becomes, we become a lot of that. And we had a basement in our house that had a room in it, that had a window in it. And my brothers and I would create puppet shows. And we would do that. And we would just go round up all the kids in the neighborhood and say, you have to watch this puppet show. And they did. I mean, they were good. But it was really about storytelling. It was about connection. It was about making things up and just feeling very alive in that moment, feeling very connected to who I was at that time and being able to share that with other people. 00:00:43 Melissa: Welcome to the Mom Founder Imagination Hub, your weekly podcast to inspire you to dream bigger. Plan out how you're going to get to that next level in business, find the energy to keep going, and make sure your creative juices are flowing so that this way you get what you really want rather than having to settle. Get ready to discover how mom founders have reimagined entrepreneurship and motherhood. Ever wonder how they do it? Tune in to find out. 00:01:09 Melissa: And stretch yourself by also learning from diverse entrepreneurs who might not be moms, but who have lessons you can tailor about how you can disrupt industries and step way outside of your comfort zone. I believe every mom's superpower is her imagination. In this podcast, I'm gonna give you the mindset, methods, and tools to unleash yours. Sounds good? Then keep listening. 00:01:36 Melissa: So how do toys shape who we become? Have you ever asked yourself that question as you are giving your child a toy? If that toy is going to influence their career choices ahead or the way that they are, their character. Today, I sat down with a fascinating toy historian, Chris Byrne. 00:02:04 Melissa: Now he is a 35 year plus veteran of the toy industry. He's held major marketing and creative positions earlier in his life. And he's appeared on TV talking about toys and play in the US and around the world. He's even been on the Live with Kelly and Mark show as a regular guest. And he has his own podcast, by the way, the Playground Podcast. 00:02:29 Melissa: So, Chris reveals today the hidden power of play, from how different toys develop everything from relationship skills to problem-solving abilities. We also explore why true play isn't about reaching an end goal, it's about embracing the pure joy of the journey. So, whether you're looking to understand the art of playing alongside your kids or giving them some space to explore independently, this episode is going to change how you think about playtime. So I encourage you to join us for this rich conversation about rediscovering the magic that happens when we give ourselves permission to just play. 00:03:10 Melissa: Okay, so before we jump into the conversation, I wanna just let you know that after the conversation, I would invite you to explore the art of play with my book, Fertile Imagination. Why is that relevant to you as a mom? Here's what I want you to know. It's really hard to guide our kids toward imagination if we've secretly lost touch with our own. So in my book, Fertile Imagination, I share with you the exact framework that I used in order to reawaken my imagination, play with my imagination, stretch my imagination, and strengthen what I believe to be our greatest superpower. 00:03:56 Melissa: So this framework is super simple to follow. It is guided and it is also provided in lots of really cool journaling question prompts in the book. And it's gonna be the same exact process that I used in order to really get back in touch with that little childlike spirit that all of us has, but maybe we forgot we have held quite tightly close to our hearts. 00:04:22 Melissa: So, I invite you to go ahead, rediscover your creativity, and see if you can find your childlike zest for life. Because I really believe that it's hard to teach our kids things that we may have forgotten are natural to us, and maybe came naturally to us when we were younger. So enjoy the conversation. The link to the book is available in the show notes where you're listening to this. Let me read the actual link so that you can learn more about my book, Fertile Imagination. 00:04:53 Melissa: It is a bit.ly link. So it is bit.ly/fertilebook. You can absolutely grab a copy right there of Fertile Imagination. If you wanted the audio version that is available exclusively via Amazon. So go ahead and check out the show notes for that link. Thank you again. And I hope you enjoy the conversation and let me know what you think at the end, I will share with you my top three takeaways that you can apply to your immediate mom life. Thank you so much. 00:05:28 Melissa: Chris Byrne. I am so excited to have you here on the Mom Founder Imagination Hub. How are you? 00:05:35 Chris: I am very well. I'm so excited to be with you. Thank you so much for the invitation. 00:05:40 Melissa: I couldn't get enough of your TED Talk. I was like, oh my gosh, he's not just a toy historian. He's like a toy psychologist. I loved it. I loved it. So welcome to the show. Chris, I want to just start with the big, big question on my mind. Help me understand from your perspective, decades in the industry, learning about the art of play, like what is an imagination to you and do you consider it a superpower? 00:06:12 Chris: Well, I absolutely consider our imagination our superpower. It is the one thing that, really one of the many things that really define us as human beings. Nothing happens in our world that doesn't start in the imagination. It can be, what do I want for lunch? Or what do I want to be when I grow up? Or should I marry this person? Or should I have children? 00:06:34 Chris: Or whatever it is because we begin in the imagination and other kinds of animals, you just put food in front of them and they eat, it's instinctual. But for us, it's not- as humans, it's not just instinctual. We literally create our worlds on a daily basis and that starts in the imagination. 00:06:54 Melissa: I agree. And it's interesting because as a fully grown adult, I would say that when I was writing my book, Fertile Imagination, and I see it as like a superpower for moms who are technically adults. I feel like it's a topic that is seldom discussed amongst adults. Like, is this something that you are noticing? Or maybe, you know, people that have that childlike quality because of your industry? What's your take on imagination, the art of play, and being an adult? 00:07:30 Chris: Well, I think all of those are really critical to who we are, because play is really the act of asking a question, what if? What if I do this? What if I, you know, as an adult in can be, what if do whatever? For me, as a kid is like, what if I jump off this wall? What's gonna happen? You know, but we grow up and we have a little bit more, more adult kind of perceptions, if you will, for that. And it really is like trying to spin out a scenario. 00:08:06 Chris: So if I am going to take a new job, for example, what is that gonna be like? Who am I gonna be working with? And we begin to develop stories around things in our imagination. And those stories are very important because we really can't take action to make things real until we've imagined them as a concept. 00:08:28 Melissa: Yeah. And so, okay. So this is something that I'm struggling with right now. This is like real time, I need some help, get me unclogged sort of stuff. So this idea of having a story in my mind and having a vision I want to make real, the vision side of it is so hard right now for me to see, mainly because it's like, there's things that I've envisioned in the past, but I haven't made happen. So I don't know kind of like how to play myself to a solution or a vision or just kind of like, think with a little less of like the past, you know, like hindering this vision. 00:09:15 Chris: Right. It's a great, it's a great thing. I mean, I'm sorry you're going through that, but I think that if you look at how a child plays, right, when they get an idea and they don't sit there and think, well, if I just do this or I do this or I do that, it's going to be fun, right? They come, that's not fun. I'm done. I'm on to the next thing. And I think as adults, we should do that too. If something is becoming too much effort, if it's not working, then we just drop it and go on to the next thing. 00:09:47 Chris: And I don't think there's any harm or foul in that. And I think that when you look at a kid who is imagining and playing, they're not judging the play as they're doing it. They're looking at well, where did this take me and where should I go next from it? And it's a much freer, kind of more peaceful way to go through the world. 00:10:08 Chris: I mean, I talk about things that I've done that turned out to be mistakes. And I call them I said, well, that was a once in a lifetime experience. As in I don't have to do that again. I learned the lesson. 00:10:20 Melissa: Yeah. And I think, you know, approaching any problem from that perspective releases that pressure to get it right the first time. And it gives you like the levity to get back up and just be like, okay, let's go at it again. And I imagine like, cause I noticed also, and I know that this side of it might be a little bit more conventional thinking, but like, you actually bring these ideas into corporate settings, you know, the art of play. 00:10:51 Melissa: And I'm like, if I think about the different environments where it's not okay to play. It's not okay to make mistakes. Like how do you sell that idea of we're just playing right now and don't get frustrated if it works or not in like a corporate setting, you know? 00:11:11 Chris: Well, one of the things that's so interesting in a corporate setting is people come into a meeting or a brainstorming and they're focused on one specific outcome, right? So if you're focused on an outcome, you kind of end-run the process of play because play is a process. Play is asking, what if, you know, let's go down this road and let's go down this road and see what it is. So I always encourage people to be as off the wall as possible. I will give you an example that almost got me fired. 00:11:43 Melissa: This is a good one, okay. 00:11:44 Chris: And nobody will like it, but I was working with Ideal, with Ideal Toy Company and we had the Shirley Temple doll. And nobody, we had these porcelain $400 Shirley Temple dolls and Shirley Temple dolls were huge in the '30s and still with doll collectors, but nobody was buying them. And we thought, how do we get rid of them? And I said, well, why don't we put them on the QE2 and use them as skeet? Like people can launch the doll. 00:12:11 Chris: So the brand manager got really mad at me. And told me I was inappropriate. But as we talked more, we ended up doing a doll collecting event with Cunard that actually turned out to be good. So the idea is, go out there and play off the wall in a safe environment, obviously. So the idea of creating an environment where it's safe to play, where it's safe to have that sort of impulsive childish response to a situation is okay. 00:12:45 Chris: We would never have promoted that in a corporate sense. But the idea that we were just playing with ideas and being silly. That opens the pathway to being really creative and to seeing what could actually work. And then once you get that, you put the action steps in place to get to the next step. 00:13:05 Melissa: Yeah, I think just, you know, going crazy and just really trying to break out of conventional thinking and our very logical pathways in our mind, it's like first we do this, that, the other. It's almost like some sentences, right? And the way we like greet each other, it's so like rehearsed that to come up with something like, oh my gosh, I love your outfit. You know, it reminds me of like a toy soldier or something. It would be like way off, but it would start rapport, I think. Rapport or like, you know, people would be like, kind of weirded out. But I've always tried that. How can I not weird people out? 00:13:44 Chris: Well, it's, right, well, that's always a question, but I don't really worry about that too much. But I think that one of the things, again, as I was saying about process, but also getting over fear, right? As adults, we think, well, what if I get it wrong? Children, when they play, if you watch them play, they don't worry about getting it wrong. They just think, well, that didn't work. That didn't do what I wanted it to do. Let me do something else. They haven't built a hierarchy of judgment and really being unkind to themselves about doing something wrong. 00:14:19 Chris: And if you embrace play, there's really no kind of, you can't be wrong when you're playing, right? Some things may be practical, but there's imagination and there's spinning things out, things that might never become real, but then things that actually could practically become real. And the process of getting to that point is actually pretty joyful. 00:14:42 Melissa: And I think we could all use some more joy these days, that's for sure. Adults and children alike. So let's see, let's go back in time. So let's go back to the time where you recall maybe playing with a toy and feeling like an insane amount of joy. If you can think about, you know, your one moment or one of the moments, I'm curious to hear your perspective. 00:15:06 Chris: Well, it's really interesting because one of the things that I really believe is what we play with as kids really becomes, we become a lot of that. And we had a basement in our house that had a room in it. They had a window in it. And my brothers and I would create puppet shows. And we would do that. And we would just go round up all the kids in the neighborhood and say, you have to watch this puppet show. And they did. They were good. But it was really about storytelling. It was about connection. It was about making things up and just feeling very alive in that moment, feeling very connected to who I was at that time and being able to share that with other people. 00:15:52 Melissa: Wow, so that's interesting. So it's funny because I feel like maybe I was, because I was an only child for most of my upbringing, like a lot of the things I did were just on my own and I had to really figure out how to make something out of what was around me. So let me share like this one thing that I would do to just pass the time. And of course, like in the background, like there was like maybe Magnum P.I. playing or, you know, name- Hawaii Five-0, whatever my mom was into. 00:16:25 Melissa: So I would go to the closet and I would take out a shoebox. And I would proceed to create like a scene. So they're called dioramas. I looked it up because I was like, this is a weird thing that I just kept doing all the time. And then I would create little figurines and put like little slots, you know, on the sides and move the little carboards in and out, you know. And I was like, okay, I have to ask Chris, like, what does that say about me? I have no idea. 00:16:56 Chris: Well, I mean, I would say it sort of starts you as a storyteller, which is what you're doing today. You're telling stories and you're facilitating other people telling stories. But it's also, I mean, especially for children at that age, it's about trying to make sense of the world and the stories they tell us, like trying to make sense of relationships. I'll tell you another story. 00:17:18 Chris: Years ago, we were playing with some kids with Barbie dolls. And they had all these different Barbie dolls. And one kid took all the blonde Barbie dolls and they were making fun of the brunette Barbie doll. And we were just watching this and going, yeah, this is somebody who is working out a reality in their life. 00:17:38 Chris: And that is really what play is, because even as she, in this case it was a girl, became powerful in that situation, was able to stand up for herself, you're giving your brain the sense that you can actually do this. If you do it vicariously, you've already had that experience on some level. So that when you confront that in real life, it might be easier, or you might have a solution. 00:18:03 Chris: I mean, how many times do you go into a situation, an interview or whatever, and you've rehearsed what you're gonna say? And your brain already knows that. It's like visual, what they talk about in sports about visualizing, you know, the outcome. You know, you're already having that experience, which is so cool. Cause our brain doesn't know the difference sometimes between reality and what we imagine. 00:18:24 Melissa: I love that. I love that. And so, yeah, who knows what I was trying to work out? There are a lot of things going on in my home. I'll tell you that much. But yeah, I think, you know, that idea though, just like trying to work things out that, you know, maybe you don't have that first person experience with, but like doing it through the use of a toy. Have you noticed at a curiosity any sort of changes with the dynamics between toys and kids now that there's like AI sort of toys out there? 00:19:01 Chris: There are so many different types of play experiences. What we were just talking about is more traditional doll or action figure or stuffed animal kind of play where a child is really doing that. Some of the other stuff with AI or licensed space like Star Wars, Marvel, all of that is beginning to understand yourself as a capable human being. 00:19:23 Chris: So for example, if I'm a superhero, I can feel. I can have the feeling of what it's like to be a superhero. And I always say, if your life is all about mom is in control, eat your peas, get in the minivan, do your homework, suddenly if you're a superhero, that's very empowering. And then empowering as an individual to be able to confront the world in a different way because you're empowered. So it's very classical, the kind of totemistic idea that we take on the powers of the superheroes. 00:19:59 Chris: And even though we're not gonna fly, we're not gonna lift, we're not gonna pick up a truck, we're not gonna do that, you have the emotional sense of capability, which is really what it's all about. 00:20:10 Melissa: That's interesting. I think, I mean, I don't know. Now that I think about my kids, for example, their toy experiences these days is really YouTube videos and playing video games and things like that. And I wonder if that's also along the same thread of what you just said, feeling the different capabilities like running fast or jumping high, things like that. 00:20:37 Chris: I think definitely. I mean, it's, you know, YouTube videos are like today's cartoons, right, on some level. You know, I grew up watching cartoons and, and it was- so they're looking at who are my role models and who are, you know, somebody's doing something. Oh, I'd like to try that. And, you know, or oh, wow, they tried that, I'm not gonna do that, but what would it be like if I did this kind of thing? 00:21:03 Chris: So I think that it's a window on the world and people are always concerned about screen time and I'm never concerned about screen time so much as I'm concerned about what's on the screen. So that is what's being modeled through the YouTube things, things that you as a mom or a parent want your child to be consuming because it can be very supportive or it can be kind of dangerous depending on what kids have access to. 00:21:30 Melissa: Yeah. And it's so interesting what you're sharing right now, because I mean, I had Saturday morning cartoons, for example, and I ate a lot of cereals with all the dyes and all these other things. And my kids literally tell me, they're like, oh, we want to have Saturday morning cartoons just like you. But of course, it is that YouTube thing. And I limit it to SpongeBob. Like, that's appropriate for their ages right now. 00:21:54 Melissa: But I think that's so interesting, this whole idea of rehearsal and visualization and imagination. I wonder because when it comes to toys and just the way that they've changed through the years, how did, for example, Tickle Me Elmo, how did that support people in terms of capabilities or anything? I'm curious. 00:22:22 Chris: Well, Tickle Me Elmo was kind of an outlier in that, you know, in terms of classical play. Tickle Me Elmo became a fad, right? And fads take on a life of their own. They kind of jump the shark or jump from the toy industry because Tickle Me Elmo started as an entertaining little preschool doll for preschoolers, infants and preschoolers. Suddenly it becomes this whole cultural phenomenon that everybody has to have. 00:22:50 Chris: It becomes, so it's a fad, so it becomes kind of a marker in time. So if you were around for Tickle Me Elmo, and you remember that, it's sort of a springboard to your memories of what the latter part of 1996 was about, because that's when Tickle Me Elmo was really huge. So that's not really kind of play in the way that I talk about it a lot. That becomes a cultural event. And my other joke about Tickle Me Elmo, Tickle Me Elmo was $40 really, basically, or more. You know, you can have a Tickle Me Elmo and be really cool for a lot less than you can have a Birkin bag. 00:23:26 Melissa: Wow, yeah, that's true. That is true. It's so funny, this conversation just takes me down the whole nostalgic route. Like I'm thinking about my Steve Urkel joke pull doll. Do you remember that one? 00:23:39 Chris: Yeah, yeah, of course. 00:23:41 Melissa: Yeah, so anyways, I'm totally like aging myself right now. I'm like, oh, I had Steve Urkel and I had Popples and all the like. What do you think, you know, nostalgia? Let's talk about that. Because I feel like a lot of marketers use that, you know, in order to kind of like pull forth a certain generation, let's say. And I even feel like at a supermarket, like I'm like, I think they know who their shoppers are with the music. But let's talk about nostalgia. 00:24:09 Melissa: Like, and again, thinking about more quote unquote modern toys, you know, like. And back to like these like electronics, like do you think that it'll be the same sort of calling card, I think is the right phrase? Like when someone starts saying, oh, like, let's say 10 years from now, you know, what's the name of the- Stumble Guys? Like, do you think that people will say like a certain like thing on video games and it'll have the same emotional pull as like Tickle Me Elmo, Popples, or Cabbage Patch? 00:24:41 Chris: It's hard to know. The thing about nostalgia is it's really for adults, right? Nostalgia is for people looking back. When you're three and four, you're not nostalgic for much. You're not remembering much. Maybe you remember your pull ups, right? When you had your pull ups. But you don't, you're not really nostalgic for something because you haven't been around that much. 00:25:03 Chris: The challenge from a toy marketing standpoint is relying on nostalgia to sell toys. Because I mean, yes, there's a certain level of you as a mom had My Little Pony or Littlest Pet Shop or any of those huge hits, Masters of the Universe. And you want to share those with your child. But for it to engage your child's imagination, there has to be something authentic to them. It's not just, mom liked this, so I'm going to like it too. That doesn't really work. 00:25:31 Chris: Look at Barbie and how Barbie's been redefined over the years, because Barbie always reflects the culture at any given time. So in 1959, she could be a fashion model or a bride, right? Pretty much, those are the Barbie options. Today, there are hundreds of careers and there's hundreds of abilities. And Barbie, the Barbie line looks like the world kids are growing up in, just as it did in 1959. It's just a more diverse and broader world with more possibility for girls and women today than it was in 1959. 00:26:08 Melissa: So when it comes to the toy industry, who's actually using their imagination to come up with like what to make for the future? Like, is it a combination of kids and adults? Is it like who's actually imagining like right now, like in the Mattels, et cetera, you know, what's coming down the line like 10 years from now? It's going to be hot and cool. And like, how do you how do you imagine something like that? 00:26:36 Chris: Well, it's hard. I mean, I think I think it's like, you know, my crystal ball usually needs a shot of Windex so I could get a clearer sense. But it's more an art than a science, that's for sure. And it's looking at trends. It's looking at how are kids playing, how are they interacting, how are they socializing, what is fun to them, and what's going on in the culture at large. Because the toy industry always reflects the culture. 00:27:03 Chris: We're always reflecting, because kids, you know, most healthy kids, they aspire to being big. They wanna grow up and they want the things like their parents have. So back in the, you know, in the early 2000s when cell phones came out, you saw tons of preschool cell phones, right? You don't see that so much anymore because the preschoolers have a real cellphone. 00:27:25 Chris: But you see things that will allow them to feel like they are part of the culture and they are growing up into it and that they are older and perhaps more capable than they really are because that's an important imaginative tool to help in the maturation process. 00:27:41 Melissa: That's fascinating. So that's true. It was definitely a lot of like, I don't know, mommy and me things. Like you see them with like a cash register or like a Target cart, right? The plastic little one, right? Cause their parent is shopping at Target. And so I wonder because it's like, there's some habits that as a parent, like maybe we wanna shake off ourselves, but we're inadvertently doing a lot. 00:28:06 Melissa: So like the cellphone one, I'm like, oh God, yeah, mommy has a cellphone and now her child does too. And it's like, how can I stop? And it's a reinforcement, but I'm wondering, okay, so in terms of the future and in terms of toys, have you ever done or seen any sort of things where the mom was playing with the child versus the child was playing by themselves? Like any differences there? 00:28:31 Melissa: Because I would love to just kind of inspire a listener right now to consider the fact that actually getting lost in play with their child can be even more beneficial than just having your child play with a toy to the side and you're doing something completely different. 00:28:52 Chris: I think that is critically important. One of the things that we're talking to parents of Gen Z and Gen Alpha kids. And Gen Alpha was born 2010 to this year. And one of the things that parents talk about is some of the best part of their day is when they're playing with kids. And what I always suggest is that if you're playing with your kid, especially if they're a preschooler, let the child run the play and you respond. Don't tell them, oh, look at this, oh, do that. 00:29:24 Chris: And you don't have to teach, it doesn't have to teach them anything, right? It doesn't have to teach. Kids are going to learn. So really letting that child's imagination drive the experience because, you know, I think every parent has had the experience where your child comes up with something and you go where did that come from? 00:29:45 Melissa: 100%. All the time. 00:29:47 Chris: And it's because they're sponges and they're listening to their absorbing everything and then they're processing it to their childlike brains or their childish brains. So I think that letting the child do that, but being there and being in communication is really important. 00:30:02 Chris: When I was growing up and maybe when you were too, we had three different worlds. We had kid world where no adults came in and the kids were doing that. We had adult world where we weren't allowed, where the parents would do that. And then there was family world, which is dinner and vacations and being yelled at about your grades or whatever that was. 00:30:21 Chris: But those three worlds don't really seem to exist anymore. And parents and kids are much more integrated in one another's lives. I think that's an outcome of COVID. It's actually a very positive outcome from COVID. Because you as mom and dad, have fun with your kids. Come on. It's, again, back to the idea of process rather than outcome. They don't have to become an expert ball player. They don't have to become an expert thing at times. They can actually just learn and play and discover the world and share those discoveries with you. 00:30:51 Melissa: Yeah, I love that. And I think it's an opportunity for someone that has to think a lot in life and feels the stresses of life to kind of let go and just stop thinking and just going with what is. Be present. You know, be totally present. 00:31:12 Chris: Be totally present and just be open to what it is. It's trying not to, as I was saying, it doesn't have to have a definitive outcome. And the one thing I think we've lost track of, often in our culture right now, is the idea of embracing process. It's really okay to make mistakes. It's really okay to try something, as long as you get up and start again. 00:31:36 Chris: I mean, how many times have you, I was talking about, for me, I learned to ski late. And I'm a really mediocre skier. I'm enthusiastic, but I'm not good. And I had somebody who was teaching me and he said, Chris, eventually I was scared. Eventually you're gonna have to point your skis down the hill. So I did it, I fell a lot, I did that, but I was so eager to learn that I'd fall and get up again. 00:32:04 Chris: I had to learn how to get up, but that's the thing that I think is, you know, if you have an idea of where you'd like to go but embrace the process on the way there because who knows what you're going to learn and what you're going to discover. 00:32:16 Melissa: Yeah, I definitely agree with that. I think that's the key to any goal. It's just you have to really fall in love with the process as you head towards the vision the goal, you know, whatever it is that you're trying to accomplish. And I also love the fact that, you know, as with play it's like there's something that's so pure about it, you know, when left on unmanipulated. 00:32:40 Melissa: It's like as a parent, we might have this desire to like educate our kids up to wazoo with regards to like every educational toy out there and every moment with we're with them, we're teaching them another language or coding or something. But I think, you know, just being open to a little bit, you know, unstructured play and that time with your child has so many benefits. And I think, you know, Chris, the work that you're doing just stay connected to like play as just being fun and okay and positive is is really helpful. Thank you so much for the work that you've done. 00:33:18 Chris: Thanks. I mean, I really do think that it as I mentioned, joy before it really does open the door to being joyful and going, oh, wow, that's fun, you know? I mean, when was the last time you said, oh, wow, that's really fun. 00:33:31 Melissa: 100%. Yeah, for sure. Thank you so much, Chris. So where can listeners continue to learn about their favorite toys, about you, about what's up ahead in the toy industry? 00:33:42 Chris: You can come see the toyguy.com. That's probably the best way. And then on Instagram, I'm thetoyguy. So, yeah. And I post a lot of pictures from things like toy fairs and different things and things that are fun for me and that make me giggle. 00:33:58 Melissa: Thank you so much, Chris. Have an awesome one. 00:34:01 Chris: Thank you. 00:34:03 Melissa: My three takeaways for this conversation that you can absolutely take to the bank and apply in your home are, first, this idea that playing with our kids has benefits for our kids, but also for us, especially if you're a super busy mom. It helps put you in the immediate present moment. So that's a big, big perk right there. 00:34:25 Melissa: Second is this idea that it's all about the process as opposed to the final answer. And that's something that I know is hard to think about when you're constantly thinking about what's next in your life. So thinking about play as something that you're doing and it's a process instead of to put together that Lego piece might be a great shift in your thinking and could relieve you of the stress and pressure of getting things right. 00:34:54 Melissa: Second, no, actually my third point here, my third point would be that in terms of the benefits of playing, I hadn't realized how psychologically deep some of these toys touch the minds of our kids. So the simple fact that we are thinking about, you know, working out relationships when you're doing a diorama, which may have been the case for me personally or maybe you're thinking about whether or not you have skills like a superhero, which was something that Chris shared, I just never thought about how psychologically interesting playing with a toy could be. 00:35:32 Melissa: So you might want to reconsider this idea that playing with a toy is just a way to distract your child or keep them focused on something other than breaking things. There could be real psychological value and also something for you to just consider psychological opportunity when it comes to the choices behind the toys we put in front of our kids. 00:36:00 Melissa: So I hope you enjoyed this conversation. Again, this episode was brought to you by my book, Fertile Imagination. I am excited about it. It's a guide for stretching every mom's superpower for maximum impact. Your imagination is your superpower. That is why I had Chris on the show today. I encourage you to check out the show notes where you could actually purchase the book and let me know that you did. I am always available for conversation and any questions. Thank you so much and I appreciate you. And until next Tuesday.

In this episode of Building Texas Business, I chat with Renee Morris, Chief Curl Officer at Uncle Funky's Daughter. We explore her path from management consultant to leading a national hair care brand. Renee shares her approach to maintaining business control by relying on personal savings and family support rather than external investors. She discusses forming partnerships with major retailers like Target and Walgreens while building a creative team to drive innovation. I learned how she tackles recruitment challenges and ensures brand visibility at a national level. Looking ahead, Renee explains her vision to expand into skincare and education, and serving communities of color in new ways. SHOW HIGHLIGHTS Renee Morris discusses her journey from management consultant to Chief Curl Officer at Uncle Funky's Daughter, emphasizing her desire to balance career ambitions with family life. We explore Renee's decision to purchase an existing company rather than starting from scratch, leveraging her experience in sales and marketing strategy within the consumer products sector. Renee highlights the importance of having a financial safety net when transitioning to entrepreneurship, sharing her personal experience of not drawing a salary for years and relying on her husband's support. We talk about Renee's strategic decision to avoid third-party investors to maintain control over her business, focusing on conservative growth and solving customer problems. Renee explains her approach to forming strategic partnerships with major retailers like Target and Walgreens, discussing the role of distributors in helping small brands enter national markets. We discuss the challenges of recruiting and nurturing talent, emphasizing the importance of fostering a collaborative environment that encourages innovation and creative thinking. Renee outlines her vision for expanding the brand into adjacent areas such as skincare and education, aiming to serve the community of color more broadly. We explore Renee's leadership style, focusing on adaptability and learning from failures as she considers new business ventures. Renee shares personal insights from her early career and hiring experiences, emphasizing the importance of trusting one's instincts during the recruitment process. We examine the role of social media and influencers in maintaining customer confidence and visibility during brand transitions, particularly when changes are made to product packaging. LINKSShow Notes Previous Episodes About BoyarMiller About Uncle Funky's Daughter GUESTS Renee MorrisAbout Renee TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode you will meet Renee Morris, chief Curl Officer at Uncle Funky's Daughter. Renee shares her passion for helping curly girls solve their hair problems with unique and innovative natural hair products. Renee, I want to thank you for coming on Building Texas Business. It's so glad, happy to have you as a guest. Renee: Thank you, I'm excited to be here. Chris: Okay, so you won the award so far for having the coolest and, I would say, funky, but that would be. Renee: Play on words Right. Chris: But as far as a name for a company, uncle Funky's Daughter, yes. Okay, tell us what is your company known for and what do you do? Renee: So Uncle Funky's Daughter is a hair products company. We're based here in Houston, texas. I bought the company, so the parent company is Rotenmore's Consumer Group. But I bought the brand Uncle Funky's Daughter 10 years ago from a husband and wife team. So Uncle Funky's Daughter curates natural hair products for women, men and children who choose to wear their hair naturally, and so that's shampoos, conditioners, curl definers, moisturizers, stylers, finishers. Shampoos, conditioners, curl definers, moisturizers, stylers, finishers you name it, we make it. We also have a thermal protection line for women who want to blow dry and style their hair with heat, and we're distributed nationally Target, walgreens, kroger, cvs, heb, locally, so you name it, other than Walmart, we're there. Chris: Beauty Easy to find, easy to find, easy to find well, I have to ask this because I have daughters. I mean Sephora or Ulta. Renee: No, Sephora or Ulta. Yet we've been working that line. We can talk about that as part of this deep dive, but we've been working that line and but no land in Sephora or Ulta just yet okay, very good. Chris: So how did you find your way into the hair care product world? Because you didn't start there. Renee: No, I am a former management consultant 20 years management consulting, advising clients multi-billion dollar companies on how to drive revenue growth and through sales and marketing. And I was a mother of three kids. At the time my son was probably three or four, my daughters were two and I was flying back and forth between Houston and New York for a client. And I had this realization that I didn't want to do that as a mom. I needed to be home, but I still wanted to be a career person. So I knew I am not built to be a stay-at-home mother. That is not who I am, and COVID taught me that with isolation. And so what I started deciding was I wanted to figure out what I wanted to do next and I realized I had some options. Right, it's that fork in the road that you go through. You start to look inwardly every time you have that fork in the road and I did that and I said okay, your option A is to go find a company based in Houston and be a VP or senior VP of some operation. Option B is you find a small company and you're like a big fish in a small pond kind of thing. Option C is you just go do your own thing. And after I kind of went through it, I realized I worked for the Coca-Colas, like in GE Capitals of the world, in my past. I didn't want to go work for a big company. I didn't think I wanted to work for a small company because of my personality style, right, um. And so I decided I wanted to go buy something and then or have my own company. And so then the question becomes do you build or do you buy my? I'm a management consultant by heart, so it's always go buy something. Why? Because I can take it, I can fix it and I can grow it. And so then it became all right, well, what are you going to go buy? And so, like most people out there, they're thinking about buying a company. I started reaching out to brokers, I started doing some networking, calling attorneys, people that work on deals, that kind of stuff, just putting my name out there, and I got all the things that you normally get when you're looking to buy a company the gym, the dry cleaner, the storage facility, the gas station, all the things that I didn't want to buy because I didn't have a passion for them. And so, also, for background, my consulting experience in sales and marketing strategy has been predominantly in consumer products. So I know consumer products, I know revenue growth, I know marketing strategy. So I was like okay, so I kept looking and I used this hair product called Uncle Funky's Daughter. I found it when I first moved here in 2000. Like all curly girls out there back then, that was almost 20 years ago, my goodness. But 15 years ago back then there weren't a lot of natural hair products out there for women of color and women of curly hair with curly hair specifically. And so I googled when I first moved here natural hair products, curly hair, houston and Uncle Funky Stoddard came up. I've never heard of this company right. So I go to rice village and buy this product and I start using it. Extra butter, start using it. And for those out there that are, you know, african American descent, you know thick, curly hair, we do this thing called two strand twists to what. I love it. Two strand twist. Chris: Okay. Renee: So, you take your hair and you twist it in like instead, instead of braiding it, you put it in twists, and there are single twists all over my head right. So that's how I would style my hair wear it, rock a two strand twist. Those out there will understand that, look it up and then Google it and then and so that worked on my hair really well. And so, again, for those with tight, curly hair, finding the right hair product that works for your hair is tough. It is not easy, as you know. One of your team members, courtney, was talking about. She's gone through all the products Because you go through this product journey trying to find something that works for you right. So found Extra Butter, worked, loved it, and then I would stop using it while I'm traveling because I would forget it right at home sure. I would go back to some other competitive brand and it didn't work for my hair. So I'm like, okay, uncle Funky's daughter is the only thing that works for my hair. So I go in to get my Uncle Funky's daughter one day, after I, you know, had braids and wash them out. And yada, yada, yada. I'm going in, I'm getting my extra butter and this guy behind the counter who I bought hair products from for the past at this point, five years, says yeah, my wife and I are going through a divorce and I'm like, oh, so I do have an MBA right. I'm not some, you know, trying to sound like a shark, but my MBA said distressed asset might be willing to sell stress asset might be willing to sell. Like literally, that is the voice that went in my head. And so I was like, oh really. So I stood there in that store and I just chatted with him for hours and about the company, you know what, you know personally what he was going through, because divorce, you know, for those that may have gone through it, can be an emotional, you know troubling time. So I was a listening ear. But as I'm listening, I'm also thinking about like, okay, what's the story behind the brand? Is this going to resonate? And I'm also watching people come in and out, right. And so I said, well, if you guys are you guys thinking about selling it? And he gives me a story about you know what's happening with the sell and cell and I said, well, if you're ever thinking about selling it, let me know. So I walk out, I Google, because you know this is horrible to say, but divorces are public right right. Chris: Is it filed in state court? Renee: it's a public record so I'm figuring out what's happening with the divorce and I find out that the company is in receivership. And for those who don't know, because I did not know at the time what a receivership was, a receivership happens when a divorce is happening and the husband and wife aren't operating, behaving appropriately. Chris: Well, they can't agree on the direction of the company and it can be not in a divorce. But basically, owners cannot agree and a court may appoint a receiver to run the company. Renee: Exactly. Thank you, that's why you're the attorney and a court may appoint a receiver to run the company Exactly. Chris: Thank you. That's why you're the attorney. Renee: Have a little experience with that yes, so the judge had appointed this guy to be the receiver. I reached out to the gentleman and I said I'm interested in the sale of Uncle Funky's daughter, if that so happens to be the case. And so the one thing I did learn and you can probably expound on this is oftentimes in a divorce, when the receiver comes in, at that point that receiver is really thinking about how to get rid of this asset. And so those are all the things that I learned during this process, and I was like, okay, so he wants to sell because he wants to get paid and he knows nothing about this business. Chris: He was, you know no offense, no emotional tie to it, for sure no emotional tie. Renee: He's an older white gentleman who knows nothing about black hair products and so I was like, okay, so he doesn't know, he doesn't have an appreciation for the value of the company. And so I reached out and I said, okay, here's a number. You wouldn't believe the number I gave him and he counted with some minor you, some minor adjustment, and we bought this company for less than $100,000. And they had a revenue at the time. When I saw their tax returns, I think it was maybe a million or so that they claimed in revenue. At some point they said, but at least for sure I think our first year of revenue was probably around and it was a partial year. Probably a quarter million dollars is what revenue they generated, and so we really, if you talk about a multiple of sales, we bought it on a tremendous it's a heck of a deal the deal. Okay, I can't find those deals these days. If anybody has one of those deals, you come let me know and so. So that's how we ended up buying this company ten years ago and shortly thereafter, target comes knocking at the door and says, hey, we were having this discussion with the owners about, you know, potentially launching. Would you be interested? And I'm like, absolutely. And it was because they were going through this divorce that they couldn't get over the finish line, right? And so shortly after we buy, we're launching in target. But before I did that, one of the first things I did was because, if you ever, if any, it's probably so old you can't find it. But the label. When I first bought the company, when I was buying it, it was this woman's face with a big afro on the front and it had a cute little 70s vibe on it and it was in this white hdpe bottle which, by the way, those aren't recyclable. So I said first, we need to change this, we got to change the packaging, we got to upgrade the label, we need to make it universally appealing to all curly girls, because if I look at a woman with a big afro, I think tight, curly hair like mine right and our products work across the spectrum from wavy, like Courtney, to really tight, like Renee, and that wasn't representative on the label okay so we redesigned the label, changed the bottle from an HDPE bottle to a PET bottle, which is recyclable, and then just upgraded this packaging to what I consider a sleeker new look. Chris: Very good, Great story, Thank you. So back up a little bit, share a little bit, because so you go from big corporate consulting job some comfort in there probably. You mentioned travel and you did mention the mom aspect playing a role. But let's talk a little bit about actually getting the courage to take that leap out of the big corporate role into. I'm going to buy something that's all on me now to either make it or break it. Yeah, that had to be scary. Renee: It was, and I am fortunate in that. You're right. I had comfort. We have financial security. I had a husband who was, who still is, who's a senior executive in medical devices has nothing to do with anything about consumer products, but you know, we have the luxury for him to say I can carry this load, financial load, and I think that's the big mix, right? I tell people all the time if you're going to take that leap, you got to make sure you've got cash flow, because for not only for your, you know, for the company, but for you personally, right? Because there were several years where my husband called my business a hobby Because I was contributing nothing to the financial plan. Chris: In fact, you were probably taken away. Yeah, I was taken away. Renee: So every year I mean. So I wasn't drawing a salary. I didn't draw a salary for a couple of years after I, I didn't draw a salary until our tax accountant said you have to draw a salary because we're changing you from whatever tax to an S-corp. And I was like oh, wow, really Okay. So what am I going to pay myself? Okay, and then he goes Well, you have, and it has to be reasonable. So for probably three or four years after I bought the company, I didn't draw a salary. I was paying my employees but I wasn't paying myself. And so I think and I say all that to say yes, it takes a leap, but it also takes the ability and the willingness to take that financial hit Right. So were there things that we probably wanted to do as a family that we didn't do? Probably so. Chris: Yeah. Renee: Because I'm growing this brand and was there times I went to my husband like I need another thirty thousand dollars? Probably so. And because one of the things I specifically had chosen is I did not want, and I currently still don't want, to pull in private equity, vc any type of third party investor funding. That is a personal decision I've made and it's because I am a former accountant and I'm extremely financially conservative and I also don't want different incentives to help influence how I run my business, different incentives to help influence how I run my business, and what I mean by that is I personally just didn't want to have a PE company saying you need to do these three things because your multi, your EBITDA needs to look like this and your revenue growth needs to look like that. Right, so I could have we could have easily grown really fast, like a lot of brands do, and grown themselves out of business, or, but I chose the path to grow really conservatively Now, and so I think I say all that to say I think, yes, financially speaking, having the bandwidth to be able to float yourself and your company for a while is critical, and so don't take the leap if you're still, if you're at your job today, living paycheck to paycheck right, you have to have a cushion. Your job today, living paycheck to paycheck right, you have to have a cushion. So what that means is, maybe if you're trying to start the company, then you're running your business while you're living paycheck to paycheck and oh, by the way, you gotta stop living paycheck to paycheck because you got to start to build that cushion, right. So some of the you got to make sacrifices and I think that's the hard thing. Not everyone's willing to make the financial sacrifice that it takes to really run and grow a business without third party support. Now, in today's world, you can go get bc capital funding and you know money is flowing, or at least it was, you know but there, but there's sacrifices, but there's sacrifices with that, and so, yeah, that's great advice, you know. Chris: The other thing that you mentioned, as you were evaluating companies is one of my favorite words when it comes to business is passion. You passed on a ton of things because you weren't passionate about it. Renee: Yeah. Chris: You found something you were passionate about, and I think that's a lesson for people too, right Is? It's not easy to do. As you mentioned. Sacrifices have to be made. So if you're not really passionate about that decision to go be an entrepreneur, start your own business. It's going to be tough. Renee: Yeah, it's going to be tough, and so, because I have to wake up every day, I my passion is really helping people solve problems, and I do that through hair, because hair is a problem in the curly hair community. How do I maintain frizz? How do I keep it under control? How do I keep it healthy so it doesn't break? How do I keep it healthy so it can grow? How do I stop the scalp irritation? There's so many problems that happen in hair and so I what I think about. Like literally yesterday I was with my marketing team and we're talking about a campaign for the next month for products etc. Or really November, and I said, OK, what problem are we helping her solve? And that's literally the way I think about stuff what problem are we helping her solve? Because if we're not helping her solve a problem, then I don't have anything to talk about. Chris: Ok, Right, yeah, it's not going to move off the shelf. Renee: It's not going to move off the shelf thing to talk about. Chris: Okay, right, yeah, it's not going to move off the shelf. It's not going to move off the shelf. So another thing that you kind of alluded to, you went through somewhat. It sounds like a kind of transforming the business that you took over, right? You mentioned the product label and packaging. Let's talk. What else did you, you know, in taking that business over, did you find yourself having to change, and how did you go about making those decisions? Are either prioritizing them and you know we can't do it all- at once yeah, so what walk? us through some of the learning you went through that well, you know what's interesting is. Renee: So it wasn't much of a transformation, but it was. If you think about learning from a marketing standpoint, if you're going to buy a business, especially a consumer product company, and you buy it in today's world where we're so used to knowing who the owner is the first people don't like change. So one of the first things I had to do was convince our current customers that nothing had changed other than the label. The minute your package changes and it looks different, they're like the formulas have changed, it's not the same be the same. It's not the same product. So the first thing I had to do was convince them that this is the same product. In fact, I brought back discontinued SKUs that the receiver had stopped selling because they were slow moving. **Chris: How did you go about convincing the existing customer base? Nothing changed. Renee: So news articles, facebook articles, facebook social ads, like having live conversations, going live on social media all of those were things that I had to go in and dispute or Dubuque being like I was the person respond. There was no team, it was me and one other person. The first person I hired was a social media person. Okay, wasn't a warehouse person, it was a social media person because I knew being the being in the face of the customer was so important. So being live and answering questions online, answering the phone and people would call they will go. I heard that this wasn't the same formula. No, ma'am, it's the same formula. And actually having those, it was me having those live, one-on-one conversations. And so I think really touching the customer and being personal with her was the key to our success in in gaining that confidence. And we also you know this was early in the days of influencers we also had to partner with people to be able to talk about. Like it's the same stuff, guys, this is the bottle. This is the old bottle. This is the new bottle. This is both sides of my hair, no change. Chris: Okay, okay, very smart to especially, like you said, I mean so many people now the social media influencers have such impact on what products get picked up in the mainstream. 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. Chris:So let's move forward a little bit. Part of changing things new products. There's a level. You mentioned your marketing meeting yesterday. What do you do within the company to help kind of foster innovation and inspire your people to be innovative about the products? Renee: That's a tough one because it's hard. Here's the challenge that we have as a small company. As a small company, it's hard for me to afford to pay me like the equivalent of a me right. The woman or a man with the MBA in marketing who's got, you know, 10 years at Coca-Cola. I am oftentimes recruiting talent, that's learning and I'm teaching, as they, you know, grow up in our company and so innovation is really. You know, I'm usually in that meeting asking the provocative question Like do these assets, does this story come together like cohesively, what problems are we helping them solve? Like, I am there helping them think through and push their thinking a little bit forward. We'll sit and we just do brainstorming with, you know, little toys in the room and stuff to play with, but it's really just helping them kind of. All right, just toss some ideas out there. Let's just throw like what is this, what does this mean? What's her brand voice? What does she sound like? What does she look like? Like asking those questions to help them just kind of think outside of the box. Now, if she looks like this, so what kind of tone is she going to have? All right, so what would she say then? Okay, so let's talk about, like how then that manifests itself and how it shows up creatively, and so just helping them kind of drill down to the so what is really kind of the role I like to play. It's the role I'm playing right now because I'm looking for a marketing director. Chris: Okay, yeah, anybody listening out there. Renee: Anybody listening out there? Submit resumes. Chris: So you talked about some major players as partners that you have right, yeah. Target and Walgreens and CVS, et cetera. So let's talk a little bit about that. How did you go about? You kind of you told a little bit about Target, but what have you done and what have you found to be successful? And maybe strategies that weren't successful in forming those relationships, but maybe, even more importantly, fostering and maintaining those relationships. Renee: So forming on the forming side retailers. For those who may or may not know the space, they want to come to you in one of two ways either direct or indirect through a distributor. For a small brand like mine, it's usually hey, I don't want to service direct, I want you to go through a distributor. And usually it's because when you first launch, you're going to be in a handful of their stores not full distribution is what they call it so not in all 1700 Target stores, but I think we started out in a hundred and so we had to go through a third-party distributor, and so that distributor then opened the door to other national retailers for us. So if you're thinking about launching into a national retail partner and you're a small company like mine, your best route to market is finding a distributor that represents your category in a national retailer. So whether that's peanut butter, hair products, lotions, flat tires, whatever, so you have to go and find that distributor. So that was step one. Once we got that relationship, our job is to grow it by driving traffic through the stores and getting that sell through. If it's not generating units per store per week, it gets pulled right. So one person wisely said a retail shelf space is like real estate. Once you buy your home, you don't want to lose it to foreclosure. So once you've got that slot, my job is to defend those two slots. And when I say we're national retailers, we're not like a P&G where P&G dominates the shelf. We've got sometimes two slots, sometimes four, but we're not, we don't have 10. So our slots are really important for us at a retailer and so for me, maintaining the relationship comes back to driving the traffic to the store. But, more importantly, supply chain. So when I talked about growing too fast for some brands and having measured growth, it was very important for me because I understood I came from a consulting company, although I did did sales and marketing most of what we did as an organization was supply chain. I wasn't the supply chain person, but I like to say I knew enough to be dangerous when I bought Uncle Plunky's daughter. So because I understood supply chain, I knew that not, we could not risk. We needed to have safety stock, we need to have inventory levels that look like x, and so that's why I did what I called measured growth. And so you know the distributor may come to me and go. I can get you into Kroger, walmart. Nope, we're going to do one retailer a year, one big guy a year, because I need to make sure I can scale, I need to make sure my contract manufacturers can scale, I need to make sure my team knows what to do and they know how to execute and fulfill the requirements of that specific retailer and so that we are successful. So that was the way that we grew and that's kind of the way we've continued to grow. Chris: That's so smart, that discipline right. It's easier said than done, because you just start a company and you go a couple years not making any money, or what you do make you put back in the company and then you got all these great opportunities. Come at you once. Renee: It's easy to say yes yes, yes, yes and yes, but you can't fulfill those promises, no one will come back. And there are horror stories where brands have been like yes, I'll go into Target, walmart, kroger, heb, cvs and Walgreens all at the same time and they can't meet the demand or they launch and they don't have enough awareness in the consumer market to be able to support and drive the traffic in all of those stores. So you really have to focus on how you're going to grow, where you're going to grow, and how you're going to drive traffic into these markets and into those stores. Chris: I mean any details you can put behind that, just as some examples to make it a little more tangible of things that you did, things that you thought about. Okay, we have to get this right to kind of prove that we can go to the next level. Renee: Yes. So for Target we did a lot of in-store events, so we took Target. So imagine if I was doing replicating this across like five different retailers. But for Target back in the day, for social media was much more organic and less pay-per-play than it is now, right, so we would do like it's a 10-day countdown. You know, to Target we're launching in 10, 9, 8, like on social media, it was like running ads. Then we did a find us in the Target, so we would do these fun games on social media and our followers would have to find us in their local Target and if they found us and they won a gift card, so we were doing anything we could. We would do in-store events where we would just have a table popped up where you can try products, give away products, get coupons, you name it. We were doing it. Gotcha, we were doing events outside the store. Inside the store. I was rogue because I didn't have permission from Target to do this. I mean because that would have cost me tens of thousand dollars, right, Target, I hope you're not listening and so we would literally just grab a camera and kind of come in and we would kind of sneak our little basket through the store down the hall and we would sit in there and the manager would come like, oh, we're just doing some footage, and I would say I just launched and I'm really trying to help my business and they would get it because you know, their local store manager, and so they would allow us to do like a little bit of a, a little bit of a pop-up shop kind of thing, and they would allow it. Now, today they probably wouldn't allow it because we're probably a lot more disciplined, but 15 years ago, 10 years ago, they would allow it and so, yeah, so those are the things that we had to do. So imagine if I was doing that for sally, for walmart, for kro, all in the same year, and I'm still trying to drive the traffic right, because we were still a small brand. Chris: Sure. Renee: I still call us a small brand because you know, if I go to you and I say, have you heard of Uncle Funky's Daughter? And your answer is no, then I'm a small brand, right. If I say you cause, everybody's heard of Clorox, coca-cola, pepsi, all the things, right, lacroix, you name it, they've heard of it, they haven't heard of Uncle Funky's Daughter. And so we're still in constant mode of brand awareness, and so trying to build that brand awareness and drive demand in every retail shelf at the same time would have been a daunting task for a brand like ours. Chris: Sure, do you still have the Rice Village? No, okay, shut that down we shut it down. Renee: I shut it down when I bought the company. That was the condition of the acquisition, because the day that I went and discovered who the owner was of the brand and I was sitting there chatting up the guy, in about a four hour period that I was there, maybe three people walked into that door okay so that you know, my brain said all right, that's a like a revenue killer. I'm not, you're not driving revenue right you need to focus on driving traffic on the retail shelf, and so are. We have no physical retail store now. Will we once again one day, maybe in a different format? Right, because now you, my friends? Other people have said you guys should open up a salon, and I'm like so maybe we'll open up a salon where the products are available and featured, but a retail store exclusively focused on our products will not be in a timeline. Chris: Okay. So there's an example right of an idea from friends. Maybe you thought about it, of branching out from what's core to your business. So far you've said no because you haven't done it. Maybe it's still out there. Why have you not done that? And I guess what could you counsel some listeners if they're faced with that? Or maybe they've done it and trying to make it work Again. That's another danger point, right Before you kind of branch into something different. Renee: So there are two things what I think about. Again. I always go from management consultant first right when I think about my business. I don't think about it personally, right, I think about it objectively. So I can go deep in my vertical or I can go wide horizontally, and I can do both. And so right now, where we are as a brand, honestly, is we need to go deeper in R&D and innovation. So we have not had an opportunity to launch a new product since COVID, and so we're in the process of developing a new product, so that's my primary focus. A new product line so we're developing a new product line, so that's my front focus. New product line so we're developing a new product line, so that's my front focus. Then, as I start to think about adjacency, about how do we take our core and expand and pivot beyond. Do you go to Skin next and stay in consumer products and go into Skin? Do you go in the two places that I'm more actively looking at Skin is out there as a product extension, but that's still core to Uncle Funky's Daughter. Do you go and do you buy another small company within Rote Morris Consumer Group and now you build a portfolio of brands? Because that's, really what I wanted to do when I started Rote Morris Consumer Group. My vision is to have a portfolio of consumer goods brands that meet the needs of the community of color, whether it's beauty, so for beauty. So that could be hair, that could be skin, it could be makeup, it could be a variety of different things that help her solve her problems every day. So that's really the vision. And then I bought this building a couple years ago and we have this wonderful, amazing space, and so and I open up this space I'm looking around. What are we gonna do with the rest of this space? We have this whole first floor, we have a whole second floor that's unoccupied, and even before I bought the building, this idea of building talent and a pipeline of funky junkies is what we call our followers funky junkies yeah that's what we call our followers, our customers. But how do you start to build not only a pipeline of loyal customers but a pipeline of loyal users? And so I started thinking about what if you actually had a trade school? What if you actually started? What if you were the next Paul Mitchell for African-American hair products, right when there's a Paul Mitchell school and you're teaching natural hair instead of you know other treatments that they do, and those exist outside of Texas. There's one that exists in Houston, but not focused on natural hair, but focused on beauty school. And so for those people out there who choose to have a different path in life and not go to college, but they're looking for a vocation or trade school and they want to be a hairstylist or barber, do you create a space for them to be able to do that? So that's the second adjacency. And then the third adjacency is then do you go the other end? So I know how to do hair, I'm learning how to do hair, I've got hair products, I'm doing hair on the other side and that's where the salon comes in. So in all both ends of the spectrum, I am a deep analytical person, so it's understanding what's happening in the market. So in the salon side, you look and you have to figure out and this is for anyone right. You never take a leap in adjacencies just because you think you have the money, the capability, the resources, whatever. You have to understand what's happening in the market because you're not smarter than the whole market. You might be smarter than a couple people in the market, but not the whole market. And so when I look at the hair salon space, I knew of several people in the Houston market that had launched salons and they had failed. They had failed within a three-year cycle and they had failed because the type of offering service offering that they wanted to provide was challenging. And that's the same service offering that we would need to provide as a brand. Chris: Right. Renee: And resources and talent. Going back to this other end of the pipeline I was talking about, in the supply chain, those can be sometimes challenging resources to recruit and retain in a salon side, and so when I do the analysis, it's looking at the risk versus reward. How am I smarter than the next person? How do I learn from those failures and ensure that I can recruit talent where I'm not? I don't have a high degree of turnover. I can create brand consistency. I can create service levels that meet the needs of not only what I want to offer, but what our customers expect. I need to exceed it, and so, because I haven't gotten that magic formula yet, we're leaving the salon right here in the marketplace. Chris: It's still on the drawing board right. Still on the drawing board, I like. I like it well, as it should be, until you figure it out, right? Yeah well, so let's turn a little bit and talk a little more about you yeah in leadership. How would you describe your leadership style? How do you think that's changed or evolved in the last 10 years? Renee: so I am a type a, hardcore type a. I am a driver and I know that about myself. But I also know that one of my weaknesses as a leader is I don't micromanage. What I have learned to evolve because of my consulting background, right In a consulting world you know 20 plus years is how I was trained. I'm a former salesperson. You just go get it done right, you know. So that is that's kind of like my bread and butter, and you have a team of type A's that are pretty much driven just like you are. So when you guys have a clear plan and you've got the end goal, all you're doing is managing the type A's to make sure that they get to the goal right at a very high level. No one needs to. You set meetings to review the spreadsheet and the spreadshe's done right. Fast forward to Uncle Funky's daughter. You set meetings to review the spreadsheet and it's like, oh, I wasn't sure what I wanted to do, what you wanted me to do, so it requires much more. What I'm learning is it requires me to evolve my leadership style from one that's hands off, that's a little bit more hands-on, to make sure that my team understands where the bar of excellence is what our customers want from us, what the implications are when we miss deadlines, what the implications are if we ship the wrong product to the wrong customer, and so showing them and teaching them is where I've kind of learned. That's where my role is as a leader, really helping them really understand the implications of behaviors. And so I've evolved to from a leader that's I'm still. I still tell my team hey, I don't micromanage. If I have to, if I know it before you do, that's probably a problem, and so so they understand that, and so I think I'm still evolving my leadership style to adapt to a smaller company with a different team that thinks differently from the type A consultants with the MBAs that I'm used to working with, to the ones who you know maybe they don't have the MBA or maybe they're going to get it, or maybe they have a desire to get there, and so it really has required. It's a growth opportunity for me that I'm still learning to grow in, to be able to shift my mental mindset away from I got a team of driven people to I got a team that needs to be inspired, you know. Chris: Yeah, that's great. So what have you done to try to help you in the hiring process? Make sure you're making the best decision you can make about who you're bringing on your team? Renee: You know it's the hire slow, fire quick. Chris: Yes, another easier said than done. Renee: Easier said than done and that's where I am right now. Even in this open marketing director job that I'm looking for, it's really making sure I've gone through I go through so many, I go through all the resumes. My assistant will filter out the trash. But once she's filtered out the trash, I'm looking at those resumes going okay, is this someone who's going to? Because I'll openly say the reason I'm looking for a marketing director. I'll tell you this story. So I hire this person and she's from Adidas. She comes from Adidas background in marketing and she's Under Armour in marketing and she was in Latin America director of Latin America markets and she's just moved from Houston. So I'm thinking I've got a Latina because it's part of my demographic. That's awesome. She's got this global brand experience that's awesome. All in athleisure but transferable skills. It's marketing. She quits three months later, found another job in athleisure. So I interviewed, interviewed and found this one and this woman, you know, sold me on. I mean we had multiple conversations. I was like you know, sold me on. I mean, we had multiple conversations. I was like you know, hey. Chris: I'm really concerned about whether or not you know you can migrate from big company to this small company Cause it is a very valid concern. Renee: It's a big change. Right, you don't have a team. Your team is a team of three, not a team of 20. Right, and so your role really changes. And so she. You know, she convinced me that, but the lesson learned was that you know my spidey senses. I didn't listen to them. Like my spidey senses said, she may not stay. Like there were little things that happened along the way you get enamored with all the other stuff. Right, but I was so hungry to have a big company, someone to come in to show my team other than me, for them to hear it from someone other than me that this is what marketing looks like, Right, this is the marketing discipline that we need to have. And so she came in. She brought some marketing discipline. She heard that, you know she brought some value in the three months, but it was. It's been really a painful learning process, right, because now I'm short of marketing director, I'm stepping in, yeah, yeah. Chris: Well, what you alluded to there, right, is just the cost hard cost and soft cost when you make a bad hiring decision yeah Because you know you're having to fill the role or someone else. Renee: Yep, so that distracts, you, it's me right now. Chris: It distracts you from doing your full-time else. Yep, so that distracts you. It's me right now. It distracts you from doing your full-time job. Yep, you're now spending time going through resumes and going to be interviewing and you wasted, if you will, all the time on the one that only lasted three months. Yeah, so there's a lot of cost there. There's a lot of cost there. Renee: And then you're sitting there and knowing I've got to restart this whole process, I've got to try to maintain the momentum within my team this is the second marketing person they've had in the past year so and so how do you start to just kind of manage through that and so, instead of and when you get burned, that one time, as I'm looking at resumes, I'm looking at people with deep experience in a particular industry and I'm going oh nope. Chris: Learn, that is, that there's that bias creep right you're. You have to not let yourself penalize these people you've never met, just as they might look the same on paper yeah, as the one bad actor in the group. Renee: Yeah, and so you and you're right, and so I'm going well, and I'm having these conversations and then yeah, so it's just. Yeah, I think that's like one hiring, firing, hiring slow, firing quick. Chris: Sometimes, even when you hire slow, you still get I tell people it's part science, it's part art and it's the more process I think you can put in place and follow the better. But you're never going to be 100 right and I think figuring out the characteristics that work in your organization is something that you can incorporate into your hiring process and know that this is the kind of background traits, characteristics that thrive here. Renee: Yeah, and even and I would also say, listening to that, you know, those spidey senses that are coming with those thoughts creep in like, and they were coming like there were things, there were triggers that happened through the hiring process. Then I was like I'm not sure she's going to be a good fit. Like you know, for example, she called and said hey, can I work from home? I was like no, you cannot work from home. So that was like that was. Oh, renee, we're gonna do a whole episode on work from home. Oh yeah, oh yeah. And so those were the triggers of like, okay, she might not be the good fit. And when those were the when that happens to you, you got to listen to it and like and be okay with backing out. But I didn't listen to the trigger because we were so far down in the negotiation and I should have just said, you know, I don't think this is going to work out Right, and rescinded the offer. But I had already extended the offer, right, and I didn't want to have egg on my face. Chris:Sure. Renee: So I mean I, what I should have done is just let my ego go, rescinded the offer and continue to look. Chris: Yeah, or at least be upfront about this is starting to give me concerns. Here's why. Renee: Yeah. But I you know you know it's which I did that I did that okay, she covered it up she covered that up. She told me exactly what I wanted to hear, but still the those doubts were in my head and I should have listened to my gut. And that gut is a powerful thing. You know that, maxwell Galt, maxwell Galt Gladwell, it's a powerful thing. And if, when you listen to it, you're usually right, 100%. Yeah, 100%. Chris: Renee, this has been a fascinating conversation. Just to wrap it up, I have a few just personal things. I always like to ask yeah, what was your first job as a kid? Renee: Newspaper. I was a newspaper girl. You had a newspaper route? Yes, Absolutely I did. I'll be darned. My sister got up in the morning and helped me through my newspapers. Chris: You're not the first guest. That was their first job it was fairly common. Renee: You had to make me dig deep for that one. Chris: Okay, you made me dig deeper on this one. Sometimes people say this is the hardest question. Yeah, do you prefer Tex-Mex or barbecue? Renee: Barbecue no sauce Seasoned, very well seasoned, no hesitation. Chris: No, no hesitation and the woman knows what she wants. Yes, right. Renee: Don't bring me brisket with sauce on it. No. Chris: No sauce Extra seasoned. Renee: I want seasoned brisket, the moist kind. Okay, and, by the way, I'm not a Texan, but I moved to Texas and now I've been here 15 years and now it's like brisket barbecue. It's the only thing that I eat. Chris: I eat it's the only thing I want to eat. I might die of a heart attack, but it's the only thing I want to eat. I love it All right. So because you have four kids and I know your life's running crazy, this will be more of a fantasy. Renee: Yeah, if you could take. Chris: If you could take a 30 day sabbatical, where would you go? What would you do? Renee: Oh, I would be somewhere, probably in South Africa, in the, probably on a safari. I would tour safaris. I would go South Africa, kenya. I want to see the migration of animals. I would do that. Chris: I love it. Renee: That's where I would be. Chris: Renee, thank you so much for being on. This has been just a pleasure getting to know you and hear your story. Renee: Thank you. This is awesome. I listened to NPR how I built this. So this is like my. I feel like I'm excited. I've kind of done the NPR check. I like the how I built this check. Do you listen to that? Chris: I do, I do, I love it. I love that analogy. Renee: Yeah, it's great. Chris: Thanks again. Renee: Thanks for doing this. Special Guest: Renee Morris.

In this episode of Building Texas Business, I sit down with serial entrepreneur Steve Reynolds for his perspectives on innovation in corporate travel tech. As CSO of Embers Inc., Steve shares his journey developing TripBam, an early pioneer utilizing algorithms and robotics to optimize hotel rates. He explains TripBam's strategic transformation from consumer to enterprise software, strengthening the company and positioning it for seamless integration under Embers. Steve offers valuable lessons on championing passion within high-performing teams. The importance of actively engaging customers and development staff to creativity solve problems is emphasized. We discuss the challenges of maintaining innovation at scale versus smaller startups. Steve's experiences navigating acquisitions and a turbulent industry offer cautionary advice. A theme emerges—embracing flexibility positions leaders to overcome challenges and achieve lasting impact. SHOW HIGHLIGHTS In this episode, I spoke with Steve Reynolds, Chief Strategy Officer at Emburse Inc., about his journey in corporate travel technology and entrepreneurship. Steve discussed the origins and evolution of TripBam, a platform he founded that uses algorithms and robotics for hotel rate monitoring, which eventually pivoted from a consumer-focused to a B2B model. Steve shared insights on navigating the challenges posed by the COVID-19 pandemic, emphasizing the strategic decisions that helped TripBam emerge stronger, including cost optimizations and product enhancements. We explored the importance of fostering a passionate and innovative team, highlighting the value of listening to customers and involving development teams directly in problem-solving. Steve explained the critical difference between passionate programmers and those who are merely formally trained, and how assembling a team that shares the company's vision and offering equity can drive success. The episode delved into strategies for managing company growth and financial stability, such as quick decision-making in right-sizing staff and optimizing operational costs through cloud environments. We discussed the benefits of subscription-based pricing models over transaction-based ones, particularly during economic downturns, and how this approach helped maintain cash flow during the pandemic. Steve reflected on the evolution of workplace environments and leadership styles, noting the shift from rigid, traditional settings to more flexible, results-oriented cultures. We talked about the challenges of maintaining innovation in large companies, contrasting startup environments with big company mindsets, and the importance of hiring the right people for each setting. Finally, Steve shared his thoughts on the future of the travel industry and the innovative approaches that have set new standards in modern practices. LINKSShow Notes Previous Episodes About BoyarMiller About Emburse GUESTS Steve ReynoldsAbout Steve TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In this episode you will meet Steve Reynolds, chief Strategy Officer for Emburse Inc. Steve has built his career in corporate travel technology and in starting various companies over the four-decade career. Steve looks for opportunities to be disruptive. Steve, thanks for coming on the podcast. It's a pleasure to meet you and appreciate you taking the time. Steve: You bet Chris Glad to be here. Chris: So you know there's a lot that I'd love to get into with you. I know that you know currently you're with a company called M-Burst Travel, but that you started a company before that called TripBam. Tell us a little bit about, I guess, those companies and what they do. What is the business they're known for? Steve: Okay, and just to back up a little bit further, I guess what you could call a serial entrepreneur. Tripbam was my third or fourth venture kind of lost count, but I've been in the corporate travel tech space for 40 some odd years. And TripBam when we started 10 years ago, we recognized that hotel rates change a lot more often than people actually realize. If you were to create some robotics that went out and grabbed the rate at a particular hotel for a certain date in the future, you'd see that rate changes just about every hour and what we found is if you just keep watching it, eventually it's going to drop, especially as you get closer to check-in. So we created some algorithms, robotics, whatever you want to call it that said okay, I've got a rate of $2.99 at the Grand Hyatt in New York. I'm arriving on the first and departing on the third. I want you to just let me know when it drops and if it does, I want you to rebook it for me If everything is the same room, same bed, same cancel policy, blah, blah, blah. So that's what we did. We originally invented it for the consumer market. We put out a website and we got mentions in the Wall Street Journal and USA Today and so on. But sort of my corporate travel buddies called up and said, hey, Steve, we really need you to apply this to corporate travel. And they started writing some pretty significant checks. We followed the money, we pivoted and went all B2B at that point. And so the company grew 40% year over year for the first six years, cashflow positive within just a couple of months. I mean it was great. It was great. And then COVID came along and kind of took our knees out from under us for a bit. Chris: COVID kind of wiped out the fundamental business model for at least a little bit. Steve: At least for a little bit. But fortunately a lot of our customers were paying us subscription fees rather than transaction fees, so we were to stay afloat. We got through COVID and we actually came out on the backside of COVID in a much stronger position, both financially and you name it, because we were able to do a lot of just cost improvements, right-sizing the organization. We kind of got a little bit ahead of our skis, I think, in some areas and created some new products, just all kinds of things, pushed everything out to the cloud and such that dramatically reduced our costs and just were firing all cylinders. Chris: And then we worked out a deal with Emburse in July last year to buy the company. Okay, how does I guess what TripBand does fit within the Emburse excuse me, overall, maybe suite of products or company strategy. Steve: Yeah. So Emburse provides travel and expense to the largest of companies, to the smallest of companies, and what I mean by that? Everybody. When you go, you have kind of a booking tool to start with. Most folks are familiar with Concur. We have our own. The reservation gets created. It then needs to be watched, monitored, audited, improved upon. That's kind of where we fit in. So before the money is spent we actually see if we can actually do better than what the traveler did on their own. Travelers are not going to check the hotel rate every day. They're not going to check their airfare every hour. They're not potentially going to book the preferred property within a particular city. We fix all that before the money's actually spent. We then push all that to mobile. So you've got a companion app in your pocket where the traveler gets a ton of destination content specific to that company. So I'm going to New York, I'm staying at headquarters, what hotel should I stay in? I need to go take a client to dinner, what restaurants do you recommend? All kinds of other stuff, including safety and security perspective and so on. Then the data is all captured and fed into an expense report so that your expense report if the traveler is compliant. It's kind of pre-created and pre-approved, so the traveler in a lot of cases doesn't have to do anything and if they're compliant all the way throughout, they could actually kind of be paid as soon as their plane hits the ground. Then it all feeds into reporting and analytics so that we can improve your travel program, identify additional savings opportunities, find some fraud issues, detect all kinds of other stuff that might be a problem. We also offer a card product if you don't have one, and that's kind of the travel plus expense ecosystem that we provide. Chris: That's fascinating. I obviously wasn't aware that something like that existed, but I can see how large companies with a lot of employees traveling could see the benefit and realize a lot of savings from those services. Steve: Yeah, when you combine travel with expense, some kind of magic happens in that we have enough data and insight to be able to start pre-filling out that expense report. Otherwise, all we're counting on is card transactions and receipts, and that's really not going to do the trick. But if we can get that card information augmented with the receipt scanning and everything else that we do now, we can really do a nice job of pre-filling out that expense report. So really all you have to do is add mileage, hit, click and you're submitted. Chris: So you mentioned that you've been in this industry for 40 plus years. I'm curious how did you first get started in the corporate travel tech space 40 years ago? Steve: It was just by happenstance, I guess you could say. I was originally started as a programmer for Texas Instruments, got accepted into their executive program, which meant I could go off and get an MBA and then come back to TI, but quickly realized that the consulting firms were paying a lot more. So I ended up with Ernst Winnie, at the time with Ernst Young and my first assignment was with a travel agency in Houston, Texas, called LifeGo Travel, which doesn't exist anymore. The owner of that company hired us to come in and build some technology. It really put him on the map and he got tired of paying the bills and seeing the hourly checks that we were charging. And so he approached and said, hey, you know, do you want to come work for us? And I'm like, well, that never thought about working for a travel agency. That doesn't sound all that exciting. But he said look what if we created a company, We'll spin it off and we'll give you some equity. And I'm like, okay, now you're talking. So we left, we started up a company called Competitive Technologies and all of it was bought by American Express Travel two years later. Chris: Oh, wow. So unquestionably you had a little bit of an entrepreneurial spirit going way back then to see an opportunity. Put you in it. Steve: And a lot of it is just kind of, I guess, my personal. I don't do well at big companies. I really struggle because I get so frustrated at just the lack of progress or the lack of innovation or the speed at which things happen, so I tend to sort of find an excuse to hit the exit button, usually within a year or two. Chris: Right. So you said something in that response that I want to talk to you about, and that's innovation. I think that's there's such a common theme, I think, with entrepreneurs about. You know, and innovation can mean so many things. What do you think that you've done, as you've built several companies, as you mentioned, to create or foster and nurture a spirit and environment of innovation? Steve: You know a lot of it is just becoming a really good listener to the buyer, to whoever the customer is. And then when they say things, there are certain kernels that are aspects of what they say that you just go oh, wait a minute, okay, can we go back to that? That sounds important. You know this level of frustration. Why does that frustrate you? And if you have engineering and development in the room when those things are said, oftentimes some real magic starts to happen and we just the creativity, the innovation just comes out naturally as wow, we can solve that problem. That's not that hard, you know, let's go do that. So that's on the B2B side. That's kind of the formula, that conversation. Something falls out as far as a new feature, product, something like that, that we can start working on the B2C side. Chris: Go ahead. Well, it sounds like there's a function there of asking the right questions and really listening. Steve: Well, and just most big companies or companies they try to protect the dev engineering. They're like oh, we're not going to let you talk to customers. You guys sit over here in the back room and we'll come to you with sort of a priority or roadmap of what we think is needed. And I feel like that's just the wrong way to do it. You've got to get the dev and the engineers and the programmers in the room to hear the story, otherwise you get this telephone tag of what actually gets built isn't quite what the customer wants or was even asking for. And for most companies that's really hard. I don't know why, but they just. It's like we can't allow that to happen, but that's just not the way I operate. Chris: Well, I mean, it makes sense that people you're asking to solve the problem probably need to hear what the problem is firsthand, right? Steve: Exactly. And then it's oftentimes the dev guys are like they're coming up with much more creative solutions. If you just hand them a requirement sheet or spec sheet, they're like, oh okay, this is going to take a month. But when they're involved with the client and they actually hear what the true problem is, oftentimes they're like, oh, I can knock this out overnight, I'll have a solution to you by tomorrow. It's just a night and day sort of sense of urgency or sort of the emotion around creating the solution. They're bought in. At that point, when they hear it directly from the client, they can be the hero. Chris: Well, when you think about kind of that and getting the right developers and the right kind of team together, what have you found to be successful as far as what to look for in building the right team and then keeping the team together? Steve: Yeah. So fortunately for me I mean through all of these different companies that I've started I've been able to kind of get the band back together multiple times. A because I, you know, I'm a big believer in sharing the equity. You know, let's get everybody, if not equity, at least options, so that when there is an exit, everybody benefits, and they've all seen that so far today, knock on wood, I haven't had an unsuccessful exit where we've had to, you know, turn out the lights or whatever. My shareholders have all made money, you know, typically around 5x to 10x on their investment, which has been great. So it's easy to get the bad back together. But what I also have found out is there are certain programmers that are passionate about programming and others that are just taught programming, and there's a night and day difference on the result. If they're passionate about it, the results come out quick. I get creative solutions that nobody would think of. They're usually extremely low cost and it's just so much better than if I have someone that's college taught. I'm doing this because it's a paycheck and I took this degree because that's what somebody told me to and I was good enough to get a B in college on all my programming courses, but at the end of the day, if their heart's not in it and they're spending their time, you know, just on the side weekends and nights learning new stuff, they're not going to be very good. So give me one or two of those that are passionate and I'll put them against 10 to 20 of those that are school taught and will kick their ass every time. Chris: So yeah, well again, I think that transcends all industries and disciplines, the key being passion. Right, I think you, as the leader, are the one that has to start with the passion and then find people that share that passion to get to where you're talking about, where there's that flow within the organization. Steve: Yeah, I think development's a little bit different. I mean, you're not going to find anybody super excited about accounting or I don't know the other aspects of it, but with development there's guys that just get so into it. You know they're programming on the side. They get into hackathons, they want to prove that you know they're smarter than the guy next to them and just constantly looking for the next challenge and just coming up with those creative solutions. I don't know of any other discipline that really has that level of it, but there might be. I mean, I could be wrong. Chris: So, just going back and maybe not the first venture where you and the travel agency in Houston started, but maybe I'm just curious to know as you began some of these startups, maybe sharing some of the lessons learned through some of the challenges you found in starting that venture, whether it be raising capital as an example, or any other challenges that may come about, but I think that capital raise can be one in the startup that some entrepreneurs find daunting and maybe can't solve and never get anything off the ground. Steve: Yeah Well, I think, first off, just wait as long as possible to raise capital. You know most of them kind of build an MVP which just kind of barely works and then go out and try to raise money on it. And whenever you go down that path you just end up way undervaluing what you have. And I know people get in certain situations where they just need to have a check, you know, or it's you know, lights out. But if you can wait until you actually have a client actually generating revenue, actually having positive cash flow, whatever, and then you can show someone, look, we just need to add fuel to the fire here. This is not about keeping the lights on, this is about generating growth You're going to have a dramatically better outcome. The other thing I found out is when you take the big check too early, you start making really stupid decisions. You start hiring attorneys that are expensive, you hire a CFO before you need it, you have a head of HR, all kinds of stuff and overhead that's just not necessary and over time it makes you less and less nimble because you're so worried about payroll, you know, and less focused on just delivering a product that has a you know, a bunch of value. Keep your day job, keep working nights and weekends, wait as long as possible. I mean, I always said, look, cash is like oxygen. If you run out you're going to die. So hang on to it with both hands first. I mean beg, borrow and steal from friends and family and whatever to just get stuff. If you need a contract, go out on the web and search for a capolar plate contract. It'll be good enough to get you started. Or find someone that's a buddy, that's a lawyer, that's willing to do some pro bono work in return, maybe for a little bit of equity stuff like that. Just hang on to that cash as much as you can, for as long as you can. Chris: Well, I think there's a lot there that someone can learn from. Obviously, speaking as a chairman of a law firm, I can't endorse legal Zoom for the startup, but I understand your point. We talk to clients a lot about especially know, especially in the startup phase. Maybe you know helping them get going, but you know and being smart about how they spend their money. But make it an investment in getting at least a sound structure and they may not need right the full-blown set of legal documents, but I can promise you I've seen people start on legal Zoom and wish they hadn't, you know, a couple of years later when things were getting a little tight. But I understand your point there. But conserving cash is important to get off the ground. Steve: Yeah, I mean you don't need to come right out of the gate being in an Inc. You know and incorporated in Delaware and pay all the fees, whatever to make that happen. I mean, just start out as a low-cost LLC and then, when you're ready to sort of raise capital and become a real company, you know you use part of that capital to convert at that time. Chris: So you had mentioned earlier, you know just, I guess, going back to kind of trip BAM COVID having, at least initially, a pretty profound impact but then turning it into a positive, and I'm kind of want to take you back to that time and you maybe dig in a little bit deeper. I think it's a beautiful lesson of something where you know a lot of people just throwing up their hands because travel stopped, et cetera, which decimates your business specifically to you. But then you said we actually learned from that and became a better, stronger company because of it. And you've mentioned right-sizing, the organization stuff. But could you share a little more detail and some stories from that our listeners can learn from if and when their business faces something similar? Steve: Yeah, I think, first off, being fairly quick. You know you can always hire people back, you know. But if you keep them on the payroll and you start burning up cash just way too fast or you're starting to trend towards in the red, you just got to pull the trigger. Nobody wants to, nobody likes to do it, but it's really nobody's fault. It's just something as an executive or CEO you have to do, or a founder. So that's one. Second is, as companies grow, you kind of make stupid mistakes along the way. You get kind of inefficient. You don't anticipate the level of growth that might have been reality. So going back and saying, all right, take a step back, let's catch our breath. You know, what should we have done to kind of handle the scale better? And so, for example, just moving everything to a cloud environment, you know, putting it out to bid, switching from one cloud provider to another, whatever it is, you know you can just generate or reduce your costs dramatically. You know, rather quickly, if you just focus the time on it. Everybody gets so white hot, focused on growth and the next client and the revenue they forget to look at the rear view mirror about. You know there was a lot of costs we could have taken out, you know, which could generate even more cash going forward. 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 BoyerMiller. com and thanks for listening to the show. So we pulled the trigger pretty quick. We right-sized the staff. We had a pretty good and, fortunately for us, this is the other. We kind of lucked into this. Our customers, for whatever reason, decided they wanted to pay a subscription fee rather than maybe a percentage of the savings or a transaction fee, to where what they were going to spend would fluctuate month over month. By paying a subscription fee, they could budget it and they were going to get a better return on investment. So we did most of our deals that way and thank God we did, because when COVID and everything went into toilet in April of 2020, we still had cash coming in the door. So we were actually stayed cashflow positive because we kind of right-sized the staff fairly quickly. And then, coming out of COVID, as the revenue started to ramp back up and our sales started to continue, we were just on a much better platform that would scale after it because it was just all right-sized and efficient and whatever, and at the same time we added new products. So we had a two-year kind of all right, just keep the lights on, market will come back around. We added an air reshopping solution. We added a bunch of analytics to audit contracts and to benchmark performance, so that we had a whole bunch more to sell coming out of COVID than going in, and so that caused another year of kind of explosive growth as a result. Chris: That's great. So, yeah, obviously part of that is give some deep thought to how you price what your product right. So that subscription-based versus transaction for you sounds like a very. Maybe it didn't seem as meaningful at the time you made it, but it turned out to be. Steve: You know that's a tough one If the ROI of your product is pretty clear, like reshopping. If you've got a rate of $2.99, I drop it to $ to $250. I've got $49 per night in savings If you pay me a couple of bucks. Okay, here's the ROI. And we could run some pilots and all kinds of stuff to prove that out. So that makes it really simple and we try to hit look, I need a ROI that when they take it to their boss the guy that's doing the budgets, you know, won't cause all kinds of frustration and concern. So four to one is usually the minimum. A lot of our customers, the larger ones, are getting eight to one, 10 to one, you know. So you could say like you've probably underpriced it. But that's okay, you know we'll claw back some of that. You know, over time when it's a product that's the ROI is a bit fuzzier. You just got to somehow convince the client that this is the potential savings. They're going to guesstimate and then from there work backwards to a price which kind of gets you back to that four to one ROI. So if I think I'm going to save you five bucks a transaction, I'm probably going to charge you a dollar to $1.50 is what I'm going to aim for. Again, to get to that four to one kind of savings estimate for Relagate. Again to get to that four to one kind of savings estimate. Chris: So part of that goes, I think, in building that customer base, really focusing on strong relationships. Talk a little bit about that and what you've done, because it sounds like over the course of the various businesses, you've done a good job of creating some very good partnerships and alliances. What are some of the things you think that have helped you foster that and keep those for so many years? Steve: I think one is you know you got to under promise and over deliver. So if they're going to sign up, you know, don't make them look bad or stupid to their boss. The other one is identifying the influencers in the market. So I'm sure every industry has some individuals that are kind of on the bleeding edge, willing to try new things. And if they do and it works, they've got the microphone or the megaphone to tell a whole bunch of others. So fortunately for me, I've been able to identify who those influencers are. I've got a reputation for just delivering as promised. So when they sign up they have confidence and then they tell their peers and a lot of our sales in the large enterprise market are peer-to-peer networking. It's not from email campaigns or other stuff that we do. Chris: The kind of part of that, the old adage of just do what you say you committed to do when you said you committed to do it right. Steve: It's just delivering as promised. Don't sell me a can of goods and all this great wonderful thing. And then when the reality is just not there, you know, don't make them look stupid. You know that's the key one. I mean, these are after 40 years they become. We have some pretty tight relationships with these folks and I want them to keep their job and we want them all promoted and moving on to the next big role, because when that happens they just take us with them and we just keep getting bigger and bigger. Chris: So you mentioned that about kind of keeping this, your words, the band back together. You've been able to do that, hiring some of the right people and incentivizing the right way. Any insights into. You know what people could think about when they're looking at their team one, trying to, I guess, evaluate whether they have the right people and then finding the right ways to incentivize them to kind of keep that core group together. Steve: To me it's if they feel like they're a part of a team and they understand the value they're providing to the customer and they see that customer's appreciation. You know they're in the conversation with the client, you know, and that's easy to do at a small company, because who else are they going to talk to? Right, you got to bring the dev and engineering. But when you start layering and bifurcating and have people you know in engineering back there in the back room, kind of stuff that don't talk to clients, that's when it gets a lot harder. But when you get them into the conversation and that sense of this is my company, this is my reputation. I'm a part of something here, you know, that's growing and doing well and whatever. It's not that hard, it's really not that difficult at all. It's just everybody wants to be appreciated and feel like they're, you know, part of a team. So that's the formula, right, I mean I could throw money at them. But I ask my employees I mean I am not the guy that's writing big checks to hire people right? I'm like look, we're going to pay a reasonable salary. You know this is not, you're not going to be broke, but you know we're in it for the long term game, and so we want to keep the cash in the company so that we don't have to go do another capital raise which is going to dilute all of us, and so your equity just keeps getting smaller, you know, over time, and the guys that actually make the money, or the investors this needs to be a collaborative team effort so they get that. Chris: I think that transparent communications is key right. So they again they understand their role on the team, they understand what the goal of the organization is and how they can help further that. Steve: You know it's always been kind of fire slow, fire quick as well. You know the people, everybody makes hiring mistakes. It happens all the time. And you know when you hire someone within like a couple of days you're like this is not feeling right. You know, don't let it just sit, don't let it be two years later when you actually kind of work them out. You have to kind of pull the trigger fairly quick because it messes up the whole culture of the company. Oftentimes, especially at a small company, it can create some real problems. Chris: Yeah, I mean that may be the most sage advice and, I think, maybe the most consistent that I hear from entrepreneurs and business owners. It's been my own experience too, that that kind of fire, you know, don't be slow to fire when you know you made a mistake and it's the hardest, maybe one of the hardest ones to do because you're dealing with people. I spoke to someone yesterday and they were like hired, someone had some uncertainty and literally what I learned was to trust my gut because on day one that they started in a conversation went oh my God, this is a huge mistake. Tried to play it out, tried to make it work and guess what? It didn't. Steve: Yeah, the thing is I don't believe resumes anymore and I don't believe LinkedIn pages at all, especially when it comes to higher dev and engineering. It's just anybody can put whatever language they want and say they've got a ton of experience. You've got to figure out a way to validate Most of our hires. There's kind of referrals and peer-to-peer sort of networking. If I find someone, I can usually find someone they know, especially in the Dallas market where we are, that's worked with them at a prior company. That sort of thing and do some back-channel checking is what really pays off for us. And we know the rock stars. We know the rock stars. We know the rock stars, but they're not that hard to kind of pick out. It's the ones that are kind of questionable. That you know. You just got to do your homework and don't count on the resume. Chris: That's a really good point. It's a hard thing to do, though, and it may be easier in programmers. But, to you know, I totally agree with resumes, and profiles can be, you know, massaged, but it's sifting through and kind of through the smoke to really get to what's behind the curtain. Steve: Yeah, yeah, yeah, I mean. And Zoom calls, I mean people hire on Zoom calls or whatever. Like dude, you got to get them in the office face to face, go to lunch, have a couple of face to face interactions before you actually bring this person on board. You know, make them pass a coding test or something. You know something tangible. Don't just look, they're very nice people. You know they all have a. You know look great on a phone call or Zoom call, whatever, but that doesn't cut it. Chris: Yeah, I mean no substitute for personal interaction and seeing how people show up. Right. Steve: Yeah, the other thing is, since we're, you know, on a startup mode where everybody's looking at kind of the potential for equity, I'm like, look, if you're as great as you are, why don't you come on board for a month on a contract basis? Let's see how it works out, you know, and we'll go from there All right, and you really get a feel for someone and how well they're going to. We try it, we like to try it, before we buy. Let's put it that way. That's one way to do it. Chris: just talk about you know specific kind of leadership styles and and how you would describe your leadership style, and maybe how you would describe it today versus maybe 20 years ago as you you were emerging as a leader, and how you think it's changed oh, my god, it's night and day. Steve: so first company way back when. Maybe it comes as a surprise or not, but it was a coat and tie environment. Okay, guys, we've got to put on the ties and whatever. That was just so stupid. Checking office hours and all that crap and tracking vacation time just seems so silly. Now, if you can get the job done, I don't care what you wear, I don't care what you look like, I don't care what you wear, I don't care what you look like, I don't care where you do the work, I don't care if you have to take vacation on a pretty regular basis for whatever reason. I don't care if you're going off and disappearing to watch your kid play soccer, I do not care anymore. Just here's the job. Here's kind of an expectation. You know, as long as I understand, you're trying hard to get it done as quick as possible. We are good. You know, it's kind of a thing. So all that other stuff was just noise. That was just stupid, anyway it's. I mean back when I started in this, I mean programming and development and all that and the whole tech world was fairly new, so nobody knew what they were doing or how to manage these folks and it evolved over time, but fairly quickly. I mean, by company two, ties were gone. By company three, office was gone. I mean I've been virtual for 25 years. Unfortunately, we had offices but we just I think they were a waste of money but we did it for optics more than anything. Chris: Yeah, so it sounds like more kind of a traditional and somewhat of a command and control, starting out to now a little more, much more flexible and providing autonomy as long as people deliver on the expectations that they're communicated with. Steve: Which comes down to you just hire the right people, right, if you can get kind of get that sense for what the kind of folks that are going to do well. So, for example, if I see, if you can get kind of get that sense for what are the kind of folks that are going to do well. So, for example, if I see that you've got you spent 20 years at a really big company, you are not going to do well at a startup. I could guarantee you You're used to other people doing work for you. You know you're just kind of the sit back in your office and sort of you know, tell folks what to do. That ain't going to happen. You need to get your hands dirty. You might have to write code. You got to do PowerPoints, you got to do Word docs all that stuff yourself. Big company folks just tend to lose that ability, let's say, or it's beneath them and that's not going to work. Chris: Yeah, I mean it's almost. Yeah, that's not in my role. Mentality versus everything is in everyone's role. Mentality, right, it's almost. Yeah, that's not in my role. Mentality versus everything is in everyone's role. Mentality right, it's about getting a job done, no matter what it takes. Steve: And I think that drives me crazy at a big company because, you know, unfortunately for others, I tend to poke my nose into others' lanes and I get told a lot Steve, stay in your lane. Nothing bugs me more, you know, than to hear that. But that's the big company way. Chris: So you've gone through a few companies and you're now, I guess, inside of a larger company. Now Are you finding it easy to kind of have that mentality of flexible leadership and innovative environment? Steve: In the new company? Yes, I would have to say no, it's kind of as I expected. You know, with other acquisitions you start. You know, this kind of here's how it happens. However, embers, I believe, is trying hard to carve out a role where I can exist, let's put it that way. So my title right now is Chief Strategy Officer, and it's a bit nebulous, kind of by design. I can sort of make it what I want and as a result of being chief strategy officer, I can get outside of my lane and people can question it. I'm like everybody needs strategy. That's my title, I'm going to get in your lane, kind of stuff you know. So I tend to kind of bounce around to lots of different projects, objectives so on. I kind of help make sure that it's cohesive, you know, across this travel and expense story, you know. But at the same time I don't have a lot of direct reports, which is great. That usually doesn't go too well either. So so far, so good. Chris: Fingers crossed, that's great, yeah, we we kind of covered kind of the challenges of COVID If you think back prior to that, any other challenges along the way with the first two or three companies, everybody, yeah, yeah, I think people some of those are the best lessons we learned or some of the challenges we go through. I'm just curious to know any kind of lessons from a challenge that you could share with the listeners that might help them when they face something similar. Steve: Oh my God. I mean everybody's made mistakes and if they got lucky along the way and if they don't admit that they're lying, I mean some of the bigger ones. 9-11, we had a solution that was processing about 80% of all corporate travel reservations made in the US. 9-11 hit and we went to zero within about 24 hours, so that was kind of a gut check. Fortunately, travel bounced back fairly quickly, but it made us take a step back and realize how nimble we were If something like that were going to happen again. So that's one, and you know, and there's all the kind of day-to-day stuff. I mean there's fraud, there's employee HR issues that happen. You know there's. I'm not going to get into details on that, but you know you just kind of all right, let's deal with this. You know, don't just look the other way and take care of it. I think the latest I mean the big one right now is just, you know, the whole third party hacking and getting into your network and holding you hostage, stuff like that. You know that's made everybody just super anxious and nervous and to the point where companies are kind of shutting down their network so much that individuals can't do the job. You know, which is causing concern and it's what else are you going to do? I mean, if some employee can click on a link and bring down your network, do? Chris: you just turn off email. You're right, it's creating such a challenge. Everybody, all companies, are being attacked every day from all kinds of angles, and it just takes one and but you also? You can't operate out of fear and you can't let it stop you from doing your business. Steve: Well, they say there's two kinds of companies out there. There's those that have been hacked and those that don't know they've been hacked. So just kind of keep that in mind and I think it's fairly true. I think, you know, it's just almost too easy to get into someone's network and poke around and kind of see what's going on these days. Chris: It's so scary, but I thought you were going to say those who have been hacked and those that will be hacked, but I guess already have you, just don't know it. Well, see, I really loved hearing your story. It's a fascinating industry, and one that you don't really hear much about, but you definitely. It sounds like for 40 years you've been crushing it at it, so congratulations to that. Well, thanks for that. Steve: But also the one thing people don't know about corporate travel is that it sits on a backbone of legacy technology that's probably 40 years old. That has not changed. The GDSs are antiquated, the travel agency systems are antiquated. It's not that hard to come up with something innovative and new in this environment. So I just got lucky to where I got into it and I'm like this thing is so bad. I mean anything you do is going to be innovative. And so we just started coming up with new stuff solving clients' problems and it just kept evolving from there. Like this thing is so bad. I mean anything you do is going to be innovative. And so we just started coming up with new stuff solving clients' problems, and it just kept evolving from there. Chris: Yeah, that's really. You know so many entrepreneurs I've talked to. It's what you just said solving the customer or client's problem. Because what I said earlier, it goes back to asking the questions and listening and then trying to solve that problem. Steve: So many great ideas that come from that across so many industries. Yeah, and just to set up a little process to where you talk with your customers on a regular basis or a group of clients or people you trust and it just happens naturally, it's really not that difficult. Chris: Well, let's turn to a little bit on the lighter side before we wrap this up. I always like to ask people like yourself what was your first job? Steve: oh, my first job, let's see. Uh, I worked at a pet store at junior high. Well, actually first job was mowing yards, right? So everybody every kid did that just to get my allowance money. Then I worked at a pet store in junior high for a short period but fairly quickly realized waiting tables made a lot more money. So I told a guy I was 18, when actually I was 16, and they never really checked. They hired me as a waiter. I was actually kind of a part-time bartender, so I was serving liquor in Houston the strawberry patch I'll probably get them in trouble back when I was 16 years old and just made a ton of money as a, you know, a high schooler. So that was kind of the first. And then, you know, got into computers and writing code at a very early age. I was part of a program at Shell where they gave us mainframe time to go in and kind of play around and then went off to Baylor for computer science and then went to TI and then went to A&M for grad school. Very good, very good. Chris: So okay. So, being a native Texan, do you prefer Tex-Mex or barbecue? Steve: That is not a fair question, because both are pretty dang awesome, but, being in Texas, I think we've got some of the best barbecue on the planet. So Pecan Lodge here in Dallas is, I think, kind of the best, and there's a lot of Tex-Mex, though that's really good as well, yeah, I agree on all points. Chris: I haven't heard of Pecan Lodge before, so I'll have to check that one out. Steve: Yeah, it's in Deep Ellum, so next time you fly in, go in out of Love Field, and it's not too far, it's a 10-minute drive from there. Chris: Deal Noted. And then last thing is you know you've made early in the career, probably never did this and maybe have done since. But if you could take a 30 day sabbatical, where would you go and what would you do? Steve: I actually got a 30 day sabbatical. So a guy hired me or not hired me, but when he brought me on board to run a company he said hey, you know, I threw in there. Just, I read it in a magazine that it was the hot thing for techies to ask for, so I threw it in there and they accepted it. I guess they thought I'd never make it to my five-year anniversary. Anyway, I did and I took the kids and family, went all the way throughout through Europe. So we went to Italy, paris, france, austria, switzerland, whatever you know, just really unplugged for that 30 days. Actually it was a 90 day sabbatical. That's what I took. Wow, so I got a little bit more time. Yeah, it was great, it was great. So if that were to happen today, I'd probably look to do something similar, but nowadays if I want to take 90 days, I probably could just got to ask for it. Chris: Very good, very good. Well, steve, thanks again for taking the time to come on and love hearing your story and all the innovation you brought to the travel industry. Steve: All right. Well, thanks for having me, chris, I really enjoyed it. Good conversation. Chris: Thanks, well, we'll talk soon. Steve: Okay, you bet. Special Guest: Steve Reynolds.

What is it about podcasting that makes it one of the most impactful mediums for building deep, meaningful relationships?   In this episode, Colin Gray, a seasoned podcaster and the founder of The Podcast Host and Alitu, delves into the profound impact that podcasting can have on both creators and listeners. Colin shares his journey into podcasting, highlighting the pivotal relationships that shaped his career. The conversation reveals how the human voice can create deep connections, turning listeners into loyal fans, and how podcasting has the potential to exponentially grow one's impact by facilitating relationships that lead to collaborative successes.     [00:01 - 06:44] Colin's Introduction to Podcasting Colin's career pivoted upon discovering podcasting His passion for podcasting is rooted in personal experience Podcasts excel in conveying personality and deep content   [06:45 - 12:31] The Rewarding Experience of Podcasting Podcasting has been Kevin's most rewarding venture It's a powerful tool for building audience trust Podcasting allows creators to focus on conversations, not tech   [12:32 - 18:14] The Relationship Catalyst A key relationship launched Colin's teaching career in podcasting Teaching deepened Colin's expertise in podcasting Helping educators had a multiplying effect on students   [18:15 - 23:28] Overcoming Fears and Expanding Impact Public speaking opportunities boosted Colin's confidence These experiences expanded his influence in podcasting Teaching and speaking engagements broadened his reach   [23:29 - 27:39] The Collaborative Power of Podcasting Podcasting thrives on collaboration and chemistry Conversations lead to meaningful content for listeners Loyal audiences are drawn to the relationships in podcasts       Key Quotes:   "There's no better medium for growing trust than podcasting." – Colin Gray   "Podcasting is all about relationships and chemistry." – Colin Gray       Connect with Colin:   Website: https://www.thepodcasthost.com  LinkedIn: https://www.linkedin.com/in/colinmcgray       Honoring: Keith and Chris     Thanks for tuning in!   If you liked my show, please LEAVE A 5-STAR REVIEW, like, and subscribe!    Find me on the following streaming platforms:   Apple Spotify Google Podcasts IHeart Radio Stitcher

Shownotes:Most people would agree that sustainability is a much-abused word. It has become a catch call phrase for individuals and businesses keen on asserting their ‘good for society/good for planet credentials'. As we hurtle towards 2030, the reality is that the private sector has a pivotal role to play in helping to meet the SDGs. Cynicism aside, behind the rhetoric and noise, there is serious effort by some businesses to integrate it into their business strategy.A couple of weeks back, I spoke with Chris Argent, Head of Sustainability for AMEA at Syngenta (A leader in agricultural innovation) to understand the role of the private sector in global food security (SDG 2), on innovations that can catalyse change and help improve the lives and livelihoods of farmers (especially marginal farmers). According to the World Economic Forum, ‘the global food security challenge is straightforward: by 2050 the world must feed two billion people more and the demand for food will be 56% greater than 2010.' The sector also accounts for a whopping 30% of greenhouse gas emissions and 70% of freshwater withdrawals, so there is also the need for adoption of innovative practices to be more sustainable.What is the private sector doing to address SDG 2? How are businesses transforming and innovating for sustainable development? Chris covered some of the issues during our conversation

In today's episode of Building Texas Business, join me as I welcome Corey Harlock of Key Hire Solutions to discuss his transformational journey transitioning from hospitality management to revolutionizing small business recruitment strategies. We explore Corey's grassroots experience and how reflecting on skills and networking empowered changes benefiting businesses, employees, and communities. From precision management to respectful rejection, Corey shares recruitment nuances and emphasizes reputation's role in success over time. As remote options demand adaptation, Corey relates relatable career anecdotes and perspective-shaping reads. His insights illuminate relationship-building, timing, and vision for seizing opportunities in fluctuating job markets. SHOW HIGHLIGHTS Corey discusses his transition from the hospitality industry to recruitment, highlighting the impact of hiring on small business owners' lives and the broader community. We explore the importance of reflecting on skills and the value of networking in Corey's journey to founding Key Hire Solutions. I emphasize the significance of managing the entire recruitment process to improve hiring success rates for small businesses. Corey explains the importance of treating candidates with respect throughout the recruitment process, including providing clear communication in cases of rejection. We examine the current job market trends, including the scarcity of candidates and the rise of remote and hybrid work arrangements. Corey advises on the critical nature of timely decision-making in the hiring process to secure top talent. We discuss how to hire for future growth, highlighting the need to find candidates who can scale with the company and align with its values and culture. Corey shares personal anecdotes about his early career, his move to Texas, and his reading preferences, such as "The Energy Bus." I recount the importance of meaningful connections in business and how books like "Barbarians at the Gate" await on Corey's reading list for inspiration. Corey offers advice to business owners on upgrading their hiring standards to attract professionals with the capacity to significantly grow their business. LINKSShow Notes Previous Episodes About BoyarMiller About Keyhire.solutions GUESTS Corey HarlockAbout Corey TRANSCRIPT (AI transcript provided as supporting material and may contain errors) Chris: In today's episode you will meet Corey Harlock, founder of Key Hire Solutions. Corey's goal at Key Hire is to improve the lives of business owners by improving the talent they hire, so they can focus on what is important to them. Corey, I want to thank you for taking time to join me here on Building Texas Business. Corey: Oh, great to be here. Yeah, good, good. Chris: So you're the founder of Key Hire Solutions. Tell us a little bit about what Key Hire is and what it's known for. Corey: Key Hire is. It's a business solution for small business owners. So we really target those small business owners five to twenty five million dollars and the reason we kind of the goal and mission of Key Hire is to make the lives of the business owners better by improving the talent and the capacity and the experience inside their business so they have time to focus on the things they want to focus on Whether that's getting a better night's sleep, spending more time with their family, going out and getting more sales, improving their business. And we can improve the lives of the business owners. They can be more focused and more happy at their business. It in turn improves the lives of their people in their business who then can go out and be more successful in their personal and professional lives and in turn that reflects on the community. So we really do see a holistic hesitate to use the word global because it's really community focus. But if we can do right by the business owner, they can do right by their people who can then go out and do right by their community and their families and their surroundings. Chris: It kind of builds each segment, kind of builds on the other right, correct. And when you tell a story that way, it emphasizes how connected it all is. Corey: Has to be yeah. Chris: So how did you get started with this, or what was a little bit about your background led you through your journey to get to Key High? Corey: Sure, yeah, I'm a recovering hospitality guy. I worked in restaurants for years and years. I did high-end, fine dining in boutique hotels out in Banff, alberta, canada, in the Rocky Mountains for years and years. That's where I met my wife and one day I came to the conclusion I was. I didn't want to be in that game anymore, and so I went through this kind of reflection process and said what skills do I have? And I kind of came out with three areas, three things I thought I could, that would could transition from the hospitality world into other worlds, and one of them was marketing, one of them was sales and one of them was recruiting. And at that time I was working six days a week and I had one day off a week and I made a promise to myself I would have coffee with anyone on that one day off a week and for about three, three months I just had coffee with. You know, you send out a help notice to your network, right? I'm looking at making a change. Here's what I think I can do. Does anyone know anyone I should talk to? And people get back to you. So I started having coffee and I ended up with this guy named Bob Scott who was a partner in a company called Questus recruitment in Calgary, alberta, and told him about my hospitality experience and in hospitality, a large part of what you do because of high turnover you do a lot of hiring. So I thought I was pretty good I thought I was good at it and he told me about how they had this great hospitality program at recruitment. He then also went on to tell me that none of us know anything about hospitality. So they hired me to build at this hospitality program and so that was my foray into recruiting and that was agency recruiting and I was with them for a number of years and it progressed that the main owner was a guy named Morgan Art and so eventually I created a company within a company called Questus hospitality recruitment and then Morgan and I partnered in that and then I bought him out, went out on my own and changed the name of the company of the hospitality recruitment network and did that for a couple years and then we got transferred to Houston. So I closed the doors and came down here. But I never liked the agency model. I mean it works for some people, but for me it just didn't, because it was so transactional and oftentimes you would work with business owners or corporations and you could see the problem they had or the disconnects or how they could be better. But as a transactional agency recruiter they just find you people right and don't bore me with that, just give me some. Chris: Yeah, I don't want to be better. Corey: I just need people. So you know, oftentimes you're putting people into a situation where you kind of didn't know how it was gonna work out and there's a lot of big failure rate in that type of recruiting and key hire. I wanted to create it to work with those little guys on a long way around. But I wanted to create it to work with the small business owners to really help them and impact them and work side by side with them and allow them to leverage that experience and improve their experience and their business and then their lives of their people and their lives of the community people in the community yeah. Chris: So I mean, I think one of the things that employers maybe don't realize on the front end, but certainly at some point come to realize how expensive recruiting can be for your business, from not just dollars out the pocket for a recruiting fee but you spend time away from your business doing the recruiting, sure, you have the onboarding, you have all these things until someone can be highly productive and, quite frankly, from the the hiring side, you know the transactional agency model. Sometimes you don't think they really care, like said, they just want to place them once they get a fee. Corey: So there's this bad taste about even having to engage in the process and I think where I never aligned with that is when my motivation is to get paid and your motivation as a business owner is to make your business better. Those don't line up in the big picture right. There's a big disconnect in there and what do you do then, I guess? Chris: or what have you done? Key hire to you know. Bring that right in the line yeah, that and that's the question. Corey: So when I built the business, the three kind of core values I wanted to that I thought were important were the value of the time of the small business owner, because, exactly what you said, I don't think anyone starts a small business or starts a business because they love to hire people. They have a passion and something they love to do and part of growing a business is hiring right. Chris:Well, I can promise you everyone that's come on this podcast, as a business owner has said, how important it is to have good people, and right means hiring good people, not missing. So, to your point, though, they think about the passion, the idea that's the core to the business, but they all acknowledge down the road that hiring good people is the key to success yeah, and so I agree with that. Corey: And you golf, I do so. I haven't golfed in a while, but I used to golf quite a bit. I was never very good and I've probably hit tens of thousands of golf balls. Could I be an instructor, golf instructor? no, because I probably hit 10,000 golf balls wrong yeah right, and just because we hire every day doesn't mean we are experts at hiring. It means we've hired because we've had to and so we wanted to honor people's time. We wanted to impact their business through kind of experience and talent. But we also wanted to create a pricing model that was fair and equitable for both sides. And that was the biggest key for me was, you know, not having huge fees, not have a business owner feel like man, I paid up a lot or I've invested a lot in trying to get someone and the results were me yeah so we, the model of key hire is, you know, we get paid for the work we do, but we guarantee the hire and the work we do is a lot more exhaustive than what a traditional agency might do. And so, if I break down those three criteria, on average our clients pay less than 15% per hire, if you wanted to compare it to the agency model. Right, sometimes they're less than 10% and I think that's great because I want them to get value and we show up as a fixed cost on the P&L. There's no surprises, there's no gotchas, it is what it is. You can budget for what we do and we have monthly fees that are very affordable for the business. But the second piece of that is, you know, making sure that we're valuing their time. We dive into the business and we spend, you know, 8, 10, 12 hours inside a business before we do anything. We want to create an action plan for that business owner. You know we're an in-sourced solution, so we become their fractional department of talent. So we want to make sure we understand the business almost as well as they do before we go to work for them, so we can tell their story in the marketplace, right? Chris: Correct and be looking for the right fit from a cultural standpoint, mindset standpoint for that company right. Corey: Exactly. And then the you just touched on something really important, right? There's the kind of three things we want to break down. We want to break down the experience they need in their business. We want to break down the culture fit, because that is super important. If you have a small business, if you have 20 employees and we're bringing someone in, that's 5% of your culture. And if that's not aligned or we always like to say, if we're going to put someone on your bus, we want to put them at the front so all the people behind you are saying, wow, that's a really great, they're really good at what they do and they're a really good fit. I need to raise my game right. Rising tide raises all boats, so we want to make sure we're doing that. The third and most important and overlooked element is capacity. So many people hire for their current needs because they're in this kind of fire drill. I just need someone and they look good enough, right, reactionary, correct. So we want to get in there and build capacity in the business. One of our favorite phrases is we're not hiring someone to run your $10 million business. We're hiring someone to run your $50 million business, currently doing 10. So we want someone who can bring the experience and the capacity to build process and procedure and has leadership capabilities to scale. Chris: Well, I, you know, full disclosure for everyone out there. I can speak from experience. Have them work with you now for the better part of 2023. It's a totally different experience, in a good way and dealing with the hiring and recruiting and acquisition of talent, Love the investments you made in learning our firm and our business, and how can't imagine how much time I didn't see you put in behind the scenes to make sure you were bringing us the right candidates and cutting out the first two rounds of interviews, just to you know. It is a huge time savings, you know, for us. Corey: Yeah, well, I think we put two people in here, and, if my memory serves me, you guys have conducted a total of four interviews to hire those two people. Chris: Yeah. Corey: And I bet you the total man hours on that would be two, four, probably in the neighborhood of 12 total man hours to make those two hires from Boyer Miller. Yeah, I would say max. Chris: Yeah, so it does seem like. Well, obviously there's a model that I think has value you know talk about. Maybe. I guess you know what led you to that. Because in my mind, what you're doing in the hiring process is innovative. I don't know anyone else that really does this. What? Corey: was it. Chris: I guess, based on your experience, that kind of led you to this. What feedback did you get? You know, would you draw upon? Corey: The agency model is kind of go out, hunt, kill, throw it over the fence and then turn it over to a company who may or may not have a really effective interview hiring process. So, selfishly, I thought if I can control everything from beginning to end and understand the needs of the business and the needs of the candidate and manage those expectations, you would have a bit of better success rate and you can learn from what's happening. You know, a lot of times we'll go through the process with someone, like we did with you for the first role, and we didn't get it right the first time. But because I was there and managing the process and a part of it, I could hear the feedback, I could learn about your company more so that I could be better at going into the market, telling your story and identifying who's right for your business. So I think what's different is if we're going to work with you, it's required that we manage the whole process. We will never when people say well, look, you just bring us the people and we'll take it from there. That's a hard no for me, because for me to do all that work you know you talked about stuff behind the scenes For us to do the 10, 12, 15 hours of work behind the scenes before you give us an hour of your time. It doesn't make sense, right To just say here, I've done all this work, here's what it is Now, give it to you and then be blind about why didn't it work? Why was it a fit? Why was it a fit? Chris: Right. I guess it prevents you from learning and adapting and getting to that success point, because you said you earlier, you guaranteed the hire. Corey: Yeah, and I can't guarantee someone I was an involved with from the beginning to the end. And the other thing is we keep people on time. Yeah, because timing is a big issue in terms of getting people on board in this marketplace. So if we're driving that process and kind of, you know, tapping our clients saying, hey, I need to hear from you, we need to get this done, and they expect that right, if that wasn't part of the agreement and I'm just this pushy guy who don't worry about it, you've done your part, we'll let us handle the rest, it doesn't make sense. So we just want to control the process, because this is all key hire dots. We just do talent strategy acquisition and develop processes for hiring. This is what we're expert in. So in our process, the data says the process works pretty good. Right, we have a 90% success rate in terms of putting people into companies and getting them to their six months and beyond. We have some people that have been working. I have a client the second client I ever signed seven years ago, the person I put in one of the first people I ever put in a business as operations manager, is now the VP of operations seven years later and the owner is still aesthetic with that person. Chris: That's awesome, so it brings up a good point. You clearly have built your business off of key relationships, partnerships with companies and others. What's some advice you can give to other business hours out there about how to go about building those relationships so that they're sustainable and help kind of grow your business from them? Corey: And when you say relationships, you're meaning just within their own markets. Chris: We're both, I think, within your own market and maybe beyond. You've done that to kind of grow your business off of relationships, so what? Are some of the things that you would say you found to be successful in helping you do that. Corey: Well doing. Whatever your product or service is, you have to deliver it well. Right, and I think that's the goal of every business that gets set up. But I think one of the more overlooked things is reputation is one of your biggest recruiting tools. Your reputation in the market, your reputation amongst your peers, reputation cross market who other people might interact with you but the big one is the reputation you have with people who have applied to your company and whether they were hired, interviewed or not. And let me give you an example of what I'm talking about. We don't post jobs, but I know a lot of business owners do, and that's kind of what you have to do as a business owner to try to attract people. So you post a job and 50 people apply to that job and 49 of them don't hear anything ever from you in return for that application. Those 49 people are three or four times more likely to never reapply to your company, even if you get successful and become a big company, they have a bad taste in their mouth and they will not apply to your company and they will tell people I mean, I applied to those guys and they never even come back to me. That's reputation in a really important market, the candidate market. Now, if you were to create a template that just said hey, thank you for your application, your experience looks really good. Unfortunately, I don't think it aligns with the job we have right now and I wouldn't want to put you in a situation where you weren't going to be successful. But I would love to keep your information here on file and reach out. If something more suitable does come open in our company, all the best. What's that person going to say now? Chris: You're definitely going to feel like you cared enough to reach back out. Corey: And you'll be one of the one in a hundred that took the time to reach back out. I can tell you this I've interviewed people and I believe in the good, the bad and the ugly. So throughout the interview process I might come to the conclusion they're not the right fit, and I'll have a conversation with them at the conclusion of our conversation and say here's where I land on this. I don't think this one's a fit, and here's why. You're obviously very good at what you do and I get that, but what we're looking for is really specific and I don't doubt you could figure it out. My challenge is we don't have time for you to figure it out and I would not want you to start a new role where the expectations are super high and you're disappointed and we're disappointed. I don't want to do that too. And man, I bet you 99% of people say you know, corey, that makes a lot of sense. Thank you for being honest with me. Then some of them and I might say 10% or less will follow up with this. I get it. I'm not right for me, but I have someone you should talk to. I've just told them they're not getting the job, but because I took the time to be honest and respectful and clear about why they say you sound like a good guy. Let me help you. Chris: That's amazing yeah. I can see how that would be right. So let's, talk a little bit about just what you're seeing out there in the job market. I mean, you know. Corey: I was talking a minute ago, you know, here we are, and you know, kind of starting a new year. Chris: What are some of the things you think employers should be looking for? And then maybe the other as a candidate, you know what kind of things. What should the expectations be Right, because I think a lot has changed even in the last 12 months about you know those two topics. Corey: Sure, a couple of things. The unemployment claims are going up slowly and they've been talking. I think we're supposed to be going into recession what for about 18, 24 months now. So if it's going to happen or not, it's still unknown. It feels like we're dipping a bit, but what's important to remember is, even in our current market, which feels a little softer than it was, there are still fewer people available than there are jobs open. And I think that number sits around like 0.7, 0.8 people per open job, really Okay. So we're going to be the thick of it and now that the people coming up in the system, there are fewer of them, right, Like we're past the baby boomers and there are just fewer people and there are more open jobs. So even if we get into a bit of a recession, there's never going to be that well, there's going to be so many people apply for this role that we'll just pick right. We are, for now, an imperfectity in a situation where it's a candidate driven market and they can be choosy. So that's something worth knowing. Chris: And just to kind of tag on that, I would have to believe that some of the flexibility and work remote has contributed to that as well. Correct? Corey: Yeah, so I'll touch on that in just a second. So we understand we have fewer people that are going to apply or we're going to be competing for people. If you're excited, I always tell my clients if we're excited about someone, I can promise you someone else's too, because they didn't just apply here. But that's one of the advantages using like a key hire, because we kind of go out and get people, even if they're not looking, and we can kind of get in the rear and have a conversation and engage with them. Chris: That makes sense. I mean it's a competitive. Corey: But if someone has decided to make a move, they're not just talking to you, and if they're good, more companies than yours will be excited about them. So speed matters right. It's the, I think, the stat is. Most candidates, when they start looking for or interviewing for jobs, are off the market in two weeks. So you have 10 business days to get it done. Chris: That's not a lot of time. Corey: But it can be done, right, when we do. That's part of the process that we have, because that's one of those key elements and landing that, those people you want. So then you touched on so we have fewer people and now we have these classifications of schedule that didn't exist what three years ago? Right, we have remote, we have hybrid and we have in-office schedules. Now, they always existed, but they were never prominent and they're the remote. People were told they weren't able. We can't afford to have you working at home, we're not set up for that. Then overnight was like hey, go work at home, we were set up for that. So, people, you we hear this right like, well, I've always wanted to do this and I was told I couldn't. And now the big companies are calling people back, they're starting to. So there's a movement back to the office. But there's also a movement amongst individuals and people out there saying, well, I don't need to go back to the office because I know there are other jobs out there that will let me work in the office, and so this is a conversation we have with our clients a lot. I think I had this with you guys. Chris: Thanks. Corey: It was about the. So if we have an in-office role, we need to target people that are, if argument's safe, in a 10 10 mile diameter from our office for make the commute, have the commute make sense. Now, if there are a hundred people in that diameter or radius or a diameter, right, that's the whole. So there are 100 people that can do our job in that diameter 10 10 mile diameter. There's only about 20 of them, 20% that are willing to come to the office. So we've taken our candidate pool and chiseled it at down to 20 out of 100. Now we have to have those 20 people. We have to a find them, be, make sure they have the skills we need and See, make sure they're even open to a new role. Right, 10 of those people are probably gonna say, no, I'm not even interested. Right now we're down to 10 people. If we move to a hybrid and I think I need to practice by saying there are two types of roles there's flexible and inflexible roles. So if I'm at a machine Turning a metal part, I can't do that remotely. That's not a flexible role, sure. But if I am in in accounting or an administrative function or sales, those are flexible and we can allow people to have that flexibility. So if we move to a hybrid role, we can expand that diameter a little bit, say to 20 miles, because if people only have to come to the office Two or three times a week, they might drive a little longer. But we also might increase our talent pool by 3x. Now we maybe have 300 people and we have 80% of 300 to draw from, because there's 20% of those are like I only want remote. But the people that are in office and the people that want hybrid will look at increases. Yeah, right, the interest correct. So now we're at 80% of 300. We're at 240 people versus the 20. Now if we go remote within the city say look at, I want someone remote, but I need them here in Houston because I want to bring him into the office once a month or twice a month to do whatever. Now we have, you know, 10x. Now we have a thousand people and the people that like being in the office won't be interested. So we have 80% of a thousand people. Yeah, so it's just a. For me it's working, the probabilities of it and whatever you choose to do is fine, man, I think what I'm hearing a lot about hybrid is. People are saying things to me like this a lot more. I'm happy to go in the office, but I want the flexibility if I have a doctor's appointment, just to work from home that day, so I can go to the doctor and come back and I don't have to drive all the way in the office and all the way back. So people are looking for Hybrid is starting to take on a bit of a different. If I could get a like one day or two days from home, or have the option like, if I have stuff going on, if my son has an early game on Thursday, if I could just work from home that day so I can just like get my work done, not be stuck in traffic, and then go see my child's game or performance or whatever. Chris: Up to 30 minutes for game time instead of hour and a half. Corey: Right, because they can you. So I think Hybrid, the definition of hybrid, is shifting and changing a bit. I am hearing more people saying yeah, man, I just want to. I'd really like to be back in an office. I like being around people. This remote thing just doesn't work for me. It's not going to go back to the way it was, but I think it's going to normalize here a bit. Chris: So let me ask you this from a company standpoint. I think from what I've experienced talking to friends, you know, read it in Wall Street Journal or whatever the companies are saying. Look at this, the fully remote Maybe or hybrid, that bias towards remote is a roadie. Our company culture because our people aren't too bad, there is much. What are you hearing from employees and the candidates about their view of Building culture or fostering culture and the need to either be any office some versus Really think it can be done fully remote. What's the kind of the censure getting in the candidate pool on that topic? Corey: I think it's easier to do in a smaller company. You know, I have a client now. They're 20 people, but every morning they have. They're all remote, but every morning they have a video call and they talk about who's working on one and what, who needs to interact with who and so. So they do it that way. In a larger company, I see it being harder. Chris: Yeah, it's just yeah, and there's just. Corey: There's more moving pieces and more departments and more people that have to get connected. And trying to get 500 people on a video call every morning would be hard, sure, but I do think and it might boil down to the person, chris, you know, some people are at home and they just do what they do and those I always say these employees, the people that just want to go work in a in their office and close their door and say, yeah, please don't bother me, I don't want to talk to anyone. They're super valuable people. If you have them in the right role and if they're working remotely, that might be just fine. But then there are some more Dynamic roles in the company where you do need that interaction and I think that's where that hybrid piece is Important to say, hey, we do need you in the office and I know your company culture here is really built around human interaction and keeping people close together. And, yeah, it's important to be able to walk down the hall and knock on someone's door. So I think that's where the hybrid model if you can pull someone in instead of a fully remote to a hybrid and kind of transition them there, you're gonna get that kind of dynamic Interaction and you're gonna foster culture more and people get to know each other and kind of on a personal level as well as a professional level. But it's, I don't know that there's a One answer, because every company needs to figure out Every company's per. I always say every role is perfect for someone. We just need to be honest and really define what that role is and what the company is and what the culture is, and then find the Person who's looking and craving that Right, and so I think a lot of what a lot of people will do is Find people and tell them what they want to hear and then when they get in the door they kind of think well, maybe I don't know if they told me the truth here. Yeah and then they start that relationship off a little bumpy. But if you're clear, like you guys are, about what you are and who you are and how you, you see the people interacting. People are either gonna love that or they're not. But that's all you want, right? The bet getting a hell yeah or a hell no, that's, that's a gift. There's value in both, right. I mean hell knows as valuable as a hell yeah, because you're not gonna waste any more time if you put it up front, say this is who we are and what we do, and if that excites you, let's talk more. If that doesn't sound exciting to you, probably not, for you. Chris: There's another place. It's right for you. Corey: Yeah, for sure there is. That's what I told you all the time. That make you bad person. Chris: There's just no different places they're gonna fit yeah that's exactly it. Corey: I think we do get a little people get a little hurt or whatever when they get rejected by someone, but sometimes that's Best thing that could to get happen. Chris: Yeah, any. You just thinking about the business owner out there, make you know, with the pressure of making some hires or filling some roles, trends, that you're seeing any pointers you might add you know, provide, say you know if you're gonna, if you find yourself in the need, you know hiring. Here's some things to focus on to make sure you get it right. Corey: Yeah, so what? The business owners I deal with? And I love working with business owners as they're always passionate, smart, driven people and they're all different personalities and I love speaking with them and learning from them. That's kind of that the secret behind why I started key hire to? Because Hang out with business owners is a really Awesome experience, just to hear how they think and what they do and why they do it. I love hearing the stories and I love be able to take those stories out and tell people about them, the if I could give them a piece of advice and I'm speaking to small business owners here right. But so we're always looking to bring people in with capacity. So don't hire for current needs. Hire for what you need five years from now. That's number one, right? Remember the phrase we're not hiring you to run our business currently. We're looking for you to run our business 5x Currently doing with our current revenues. So if you do that, you'll redefine what good looks like. And I have a client in Birmingham. His name is Edgar and he runs one of the coolest food manufacturing businesses in Birmingham. I worked with him four years ago and he wanted he had a role within his business that he thought he needed and after we did our diligence and spending time, I flew it to Birmingham, spent two days with them. I said I think you're too small on this. You know, we got a dream bigger and so we redefined the role. We found an amazing guy and put him in there and Edgar loves him and he's now his director of operations. Right, he wanted him to do this kind of smaller role, but I said no, we need to hire someone with the capacity to take over your whole operation. So I'm working with Edgar again, but I asked them this question. I said when we talked four years ago, you thought you had a really great team and then we put this new person in there, a professional, someone who had more experience than you needed today and was a true professional at what they do. Did that change your definition of what a good employee looks like? And he didn't even hesitate. He said absolutely, and I could see it in them. The way he viewed his hiring was different. The people he had hired since we worked together were Different. They were. They were just bigger, better, more capacity. They had that level of professionalism. And I guess what I want to stress is you have to grow your business a certain way, right. You hire your friends, your relatives, your neighbors your relatives are your neighbors and you hire a team that you hope can get it done. And if you're successful here's the paradox if you're successful, your business will outgrow the ability of all the people how who helped you get where you want to go. That sucks, because now you want to grow and all the people that helped you get to this level of success Don't have the jam, they don't have the capacity, they don't have the experience, the draw upon To help you get to the next level. And it's a horrible position for a business owner to be in it. And I've said to them all. I said the hardest. I don't care how long you've had your business and what you've gone through. The hardest decision you will ever have to make is looking across the table from someone who helped you get where you are today and telling them Thank you for everything you've done, but I don't think you can get me where I want to go from here. Chris: Yeah, it's. I've seen it happen time and time again Company out grows their capacity. Corey: Yeah, they just, and they're not. They're great people doing the best job they can. They just don't have. You know, the busiest business They've ever worked in is your business today. The business business they will ever work in is your business tomorrow, and they don't have anything beyond that to say, oh, this process is broken, or here's where our constraints are, or here's what we need to change. When your only input becomes ours, you've run into that wall where you think, okay, we need to upgrade process procedure, we need to include automation if people don't understand how to do. That's kind of your real limiting factor, that's your biggest constraint. So if I were to give business owners advice, it's that right, understand what 2.0 looks like in terms of your talent and capacity and experience. And I never advocate for like abandoning those people who got you where you are. You have to treat them well, but there will become a point where they could turn into a constraint to your growth and I've had lots and lots. I mean that's the other part of what we do, right, we sit with business owners and we walk them through these, like how to have these conversations with someone, and we can help them leave the company gracefully. We can reposition them within the company. There's lots of things we can do, but we always want to make sure we're treating them with respect, because they've probably given you blood, sweat and tears to get where you are and you just don't want to. I don't think I've ever come across a business owner who's like yeah, I just need to get them out of here. They're like it tears them up. It's a hard decision to make. Chris: Yeah, no, I can see that. That is great advice, though, for anyone that's out there running a business about to start one that you got to you know. There's another analogy and you're a hockey guy, I'm not, but I've told us before it's kind of the same to business. Is you look to where the keep your eyes on, where the pucks going not? Corey: where it is right. Chris: That's it, yeah, so they're always looking forward and what do you need to be doing to drive forward? And talent, your talent's the key to that. Corey: Well, I don't know how much time we have, but I can give you a kind of a quick walk through in terms of the kind of growth through a business that we've identified. Let's do that and then we'll wrap it up. Okay, so we've identified kind of five stages of growth through a business owner, and so the first one we've identified is what we call the paralyzed business owner. Right, it's a fire drill. They need instant relief. If you use a car analogy, the wheels have fallen off the machine. Right they're. If you look at their org chart, they're sitting in five, six, seven different seats because everyone's trying to do everything and they're at this. My only input is time, right. And so their mindset is I just need help. And they often think if I can just hire the right person, my life will be better. But obviously that's not how it works. But if you can hire the right person, you can take a little pressure out of the tire. Right, give them back a little time. You know, maybe they can have one dinner at home with the family versus zero, and then from there, from this kind of paralyzed state, they move. Then they move into the unsure state. So you put a really good professional person in the business, whether it's operations or in the administration or in the sales department, and they go oh, that's what good looks like, this person's really helping me. So they transition into this unsure and they start thinking, well, what else could I do? I know I have other problems in the business, but I don't know what they are right. So we call this the wobbly wheel. Now the car is kind of it's. They're on the road but they're wobbling down the road right. And so they know they have some constraints in their business, but they're not at the point yet where they can put their finger on and say that's a problem. So then you put kind of another professional in there to kind of take a little more pressure out of their tire, and they go oh, now they have a little more time to focus on important things. They have some professionals, some transformational talent in key places. So now they transition and this is a big transition where they go into the curious owner where else can I make upgrades in my business? And this is where they start looking. Now they can say I think this leader is a problem. You know, I've expected. I've asked them to, told them here are some deliverables. I need them done by this timeline. They're missing them. I think that is a problem there. So they're starting to now understand where the problems are. And this is where we say you know, you have a flat tire right. You just need to put some air in that tire and you can get back up on the road. And then they transition into a growing company. So now we're kind of putting professional, transformational talent in key roles and now they're at the point where they move to a growing company where you know, before they were paralyzed, then they were kind of walking, and now they're kind of in a growing like. They're moving forward, they're confident in their team. And growing company is now we're adding new talent. I need new layers, new levels, new roles we never thought about. So we're creating a lot of new roles and we're really kind of bolstering the company with the talent and the capacity and experience they need to continue growth. And then the final transition is they become strategic. That's just like we know exactly what we need, just start filling in the spots and let's roll right. So that's kind of the progression we take our people through and that how we identify where people are and that kind of okay. Chris: Yeah, I love it. Yeah, it's a great, almost visual, as you, you know, describe it and walk through it right. Corey: And so if you do the wheels right, so the curious person has the flat tire, so you go from wheels off the machine to a wobbly wheel to a maybe a flat tire. And then the growing guys like we just upgraded the wheels, gave them low profile, new rims, the whole deal right. And then it's strategic, is like we're adding wheels on the car, on the machine, because it's just flying down the road. Chris: Awesome, yeah well, court, thank you for coming on and sharing this. Let's let's talk a little bit on the personal side, sure? What was your first job? My? Corey: first job was a dishwasher at a restaurant called Casey's Roadhouse in Oshawa, ontario all right. Yeah, I started literally in hospitality that was probably why I stayed with it, because when I was 14 I was washing dishes. The unintended consequences of that job is I met two guys that I went to school with. That I didn't really know very well actually, I didn't go to school with them at that time. I was, I think I was, maybe I did. I didn't know them very well, but you know, fast forward 40 years later and one of them still a good friend of mine and I was able to hang it with them last summer and so made some lasting friendships out of that very. I mean, it was a horrible job, right the right of all the service coming in, all the cool people like you're 14 and there's all these 18, 19, 20, 21 year old cool kids coming in, throwing slop at you and yelling at you and making your life miserable. But yeah, built character. Chris: I guess yeah, okay, so you know from Canada, newer to Texas, but do you prefer Tex-Mex or barbecue? Oh man, that's tough okay, tex-mex yeah any books you read you or read recently you recommend. Corey: I just listened to the energy bus that was recommended by Bart Pitcock in my Vistage group. Okay, it's kind of a fable that's along the lines of the home man who sold his Ferrari oh, mongu sold his Ferrari by Robin Sharma. It's just kind of this fable about kind of changing your mindset, which is cool, and I have barbarians at the gate sitting on my desk right now, which I'm about to get into. Chris: Okay, a little holiday reading well again, corey, I really appreciate your time. I think what you're doing at Keiher is great. I certainly appreciate the relationship and the friendship yeah, I mean thanks for having me on. Corey: I think you guys are doing a great job too. I love this company and can't say enough nice things about the way you run your business. You guys are clear on what you do, you're in a great organization and I'm super happy to be helping you. Oh, thank you. We appreciate it. Take care, thank you.

This is a new show type we're experimenting with called "Rabbit Trails" where Brandon and I pull back the current, and essentially record a convo between he and I. We don't come with a pre-determined theme or topic, and we see where the Muse leads us. Then we name the theme at the end. Today's session turned into a rad conversation that ultimately kept us coming back to mindset. Let us know if you like this more impromptu show style. We plan to make this a regular show type that we mix in. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight AnswerForce transforms the restoration industry by providing round-the-clock answering solutions. Their skilled team ensures no call goes unanswered, capturing and qualifying leads, scheduling appointments, and enhancing customer satisfaction. Benefit from industry expertise, scalability, and customized scripting while saving costs compared to in-house solutions. With AnswerForce, your business growth potential becomes limitless. https://www.answerforce.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com

In this episode, Brian is joined by Chris Osaka, CEO of Tomu. Tomu is a sustainability-focused hospitality development company that designs and builds hotel guest rooms and rental properties using its proprietary modular building system. Their prefabricated units include turnkey and customizable options to help operators of all sizes speed development times and construct more sustainable travel accommodations. Tune in to hear who Chris Thanks for helping him along the way.

In this episode, Chris and Brandon break down the value of the Restoration Checklist Meeting that our project managers conducted with homeowners and the value it had to our process, profitability and overall client experience on the recon side of the best. How do we get more proactive and strategic with the ways we solve problems in our business, and optimize our process? Check out the conversation and share it with your team! - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight AnswerForce transforms the restoration industry by providing round-the-clock answering solutions. Their skilled team ensures no call goes unanswered, capturing and qualifying leads, scheduling appointments, and enhancing customer satisfaction. Benefit from industry expertise, scalability, and customized scripting while saving costs compared to in-house solutions. With AnswerForce, your business growth potential becomes limitless. https://www.answerforce.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com Floodlight Consulting Group provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all of them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners

Join Brandon and I for our first "Owner Chat" shows where we interview an operator. Our first guest is Trish Wall. She and her husband Jim were Servpro Franchise of the Year recipients for 2022, and one of the fastest-growing Servpro operations in the United States. We talk about the head stories that often plague us as owners and leaders, as well as the huge demand on us to grow personally, in order to continue leading our people as the scale of our businesses grows. Trish is incredibly transparent and relatable. This show is one that you'll likely want to forward on to your other owner friends. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight AnswerForce transforms the restoration industry by providing round-the-clock answering solutions. Their skilled team ensures no call goes unanswered, capturing and qualifying leads, scheduling appointments, and enhancing customer satisfaction. Benefit from industry expertise, scalability, and customized scripting while saving costs compared to in-house solutions. With AnswerForce, your business growth potential becomes limitless. https://www.answerforce.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com Floodlight Consulting Group provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all of them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners

Hey friends, this is a special recast from the Blue Collar Nation podcast. We've been doing a monthly book club with them for the last few months and here's the latest installment- The Dichotomy of Leadership by Jocko Willink. Awesome leadership discussion was had by all- check out the episode and let us know what you think. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight AnswerForce transforms the restoration industry by providing round-the-clock answering solutions. Their skilled team ensures no call goes unanswered, capturing and qualifying leads, scheduling appointments, and enhancing customer satisfaction. Benefit from industry expertise, scalability, and customized scripting while saving costs compared to in-house solutions. With AnswerForce, your business growth potential becomes limitless. https://www.answerforce.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com Floodlight Consulting Group provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all of them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners

Joining me today is Chris Jago for the second part of our conversation. Chris originally hails from Toxteth in Liverpool however he has lived in Los Angeles for the last 20 years. Chris has a remarkable story in the world of drumming and music in general, he has played for the likes of the legendary Neil Diamond, Alan Cumming, Boy George, Barclay James Harvest and many more....... but wait there is more, Chris is hugely respected in the musical theatre / Broadway world with a whole other CV in his back pocket including Wicked, Rent (Live on Fox) We Will Rock You, Frozen the musical plus he has written the drum book for Paradise Square and his new musical Shucked. Join Chris and myself as we talk through his incredible career so far from his beginnings in Toxteth through to heading to London to hopefully take his career further and how he found himself in accidentally in a Musical thinking that the audition for a touring band! we talk about all the twists and turns that lead Chris to where he is now, an incredibly busy drummer with many plates to juggle including his own Shabby Road Studio where Chris is constantly recording drum parts for many clients around the world. Todays Episode includes the INCREDIBLE Neil Diamond story, you need to listen to it, im not giving it away! Chris - Thanks so much for giving up your time, cant tell you how much i enjoyed it. www.chrisjago.com

Joining me today is Chris Jago. Chris originally hails from Toxteth in Liverpool however he has lived in Los Angeles for the last 20  years. Chris has a remarkable story in the world of drumming and music in general, he has played for the likes of the legendary Neil Diamond, Alan Cumming, Boy George, Barclay James Harvest and many more....... but wait there is more, Chris is hugely respected in the musical theatre / Broadway world with a whole other CV in his back pocket including Wicked, Rent (Live on Fox) We Will Rock You, Frozen the musical plus he has written the drum book for Paradise Square and his new musical Shucked. Join Chris and myself as we talk through his incredible career so far from his beginnings in Toxteth through to heading to London to hopefully take his career further and how he found himself in accidentally in a Musical thinking that the audition for a touring band! we talk about all the twists and turns that lead Chris to where he is now, an incredibly busy drummer with many plates to juggle including his own Shabby Road Studio where Chris is constantly recording drum parts for many clients around the world. We had such an enjoyable conversation it went on a bit longer than they usually do so i have decided to put this out as 2 parts, Part 2 contains the most incredible story about Chris's run up to actually playing with Neil Diamond.....DONT MISS IT!! Chris - Thanks so much for giving up your time, cant tell you how much i enjoyed it.www.chrisjago.com

Brandon and I had a rad convo with Zach G of Liftify- our plan was to talk AI, ChatGPT, google reviews and SEO. We did that too, but Zach also dished out some great marriage wisdom. Listen in to learn about the latest in AI for Google Reviews, and some nuggets you can maybe apply to your marriage and family. Check it out and let us know your takeaways. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com Floodlight Consulting Group provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all of them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners

With June 1st marking the industry's first day of Hurricane Season, Brandon and I take the opportunity to dive into a conversation about Emergency Response Plans and pre-storm planning conversations. How do we take our pre-storm planning with clients and prospects to a different level and not just close more sales this season, but level up our service delivery and customer relationships? Jump in for an equally strategic and tactical convo that you will no doubt want to share with folks on your team. The storms are coming! Let's make the most of whatever time we have left before they hit. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com Floodlight Consulting Group provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all of them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners

On today's show, Brandon and I talk about parenting. The good, the bad, and the ugly- and all the crossover with leadership. If you're a parent, I think you'll find a lot to relate to, and hopefully some insight and inspiration. If you're not a parent, but a business owner or leader, I think you'll still find a lot to relate to. Let us know what you think about the show by sending us a DM on LinkedIn or via our website, www.floodlightgrp.com Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you sponsors! Liftify is for restorers who are looking to accelerate their online reviews. Consistent and fresh Google Reviews are critical to growing your online presence and establishing trust with your brand. Don't leave it to chance, partner with Liftify and let them capture the feedback your team has earned. https://www.liftify.com/floodlight C&R Magazine is the industry's oldest and longest running media outlet. The team brings restorers all the current news, developments, education and resources that impact our business and the teams we lead. From print media to podcasts, C&R ensures the industry news you need is accessible from anywhere. https://candrmagazine.com Floodlight Consulting Group provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all of them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners

Episode SummaryChris Farris, Cloud Security Nerd at Turbot, joins Corey on Screaming in the Cloud to discuss the latest events in cloud security, which leads to an interesting analysis from Chris on how legal departments obscure valuable information that could lead to fewer security failures in the name of protecting company liability, and what the future of accountability for security failures looks like. Chris and Corey also discuss the newest dangers in cloud security and billing practices, and Chris describes his upcoming cloud security conference, fwd:cloudsec. About ChrisChris Farris has been in the IT field since 1994 primarily focused on Linux, networking, and security. For the last 8 years, he has focused on public-cloud and public-cloud security. He has built and evolved multiple cloud security programs for major media companies, focusing on enabling the broader security team's objectives of secure design, incident response and vulnerability management. He has developed cloud security standards and baselines to provide risk-based guidance to development and operations teams. As a practitioner, he's architected and implemented multiple serverless and traditional cloud applications focused on deployment, security, operations, and financial modeling.Chris now does cloud security research for Turbot and evangelizes for the open source tool Steampipe. He is one of the organizers of the fwd:cloudsec conference (https://fwdcloudsec.org) and has given multiple presentations at AWS conferences and BSides events.When not building things with AWS's building blocks, he enjoys building Legos with his kid and figuring out what interesting part of the globe to travel to next. He opines on security and technology on Mastodon, Twitter and his website https://www.chrisfarris.comLinks Referenced: Turbot: https://turbot.com/ fwd:cloudsec: https://fwdcloudsec.org/ Mastodon: https://infosec.exchange/@jcfarris Personal website: https://chrisfarris.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn and we are here today to learn exciting things, steal exciting secrets, and make big trouble for Moose and Squirrel. Maybe that's the podcast; maybe that's the KGB, we're not entirely sure. But I am joined once again by Chris Farris, cloud security nerd at Turbot, which I will insist on pronouncing as ‘Turbo.' Chris, thanks for coming back.Chris: Thanks for having me.Corey: So, it's been a little while and it's been an uneventful time in cloud security with nothing particularly noteworthy happening, not a whole lot of things to point out, and honestly, we're just sort of scraping the bottom of the barrel for news… is what I wish I could say, but it isn't true. Instead, it's, “Oh, let's see what disastrous tire fire we have encountered this week.” What's top of mind for you as we record this?Chris: I think the most interesting one I thought was, you know, going back and seeing the guilty plea from Nickolas Sharp, who formerly was an employee at Ubiquiti and apparently had, like, complete access to everything there and then ran amok with it.Corey: Mm-hm.Chris: The details that were buried at the time in the indictment, but came out in the press releases were he was leveraging root keys, he was leveraging lifecycle policies to suppress the CloudTrail logs. And then of course, you know, just doing dumb things like exfiltrating all of this data from his home IP address, or exfiltrating it from his home through a VPN, which have accidentally dropped and then exposed his home IP address. Oops.Corey: There's so much to dive into there because I am not in any way shape or form, saying that what he did was good, or I endorse any of those things. And yeah, I think he belongs in prison for what he did; let's be very clear on this. But I personally did not have a business relationship with him. I am, however, Ubiquiti's customer. And after—whether it was an insider threat or whether it was someone external breaching them, Krebs On Security wound up doing a whole write-up on this and was single-sourcing some stuff from the person who it turned out, did this.And they made a lot of hay about this. They sued him at one point via some terrible law firm that's entire brand is suing media companies. And yeah, just wonderful, wonderful optics there and brilliant plan. But I don't care about the sourcing. I don't care about the exact accuracy of the reporting because what I'm seeing here is that what is not disputed is this person, who whether they were an employee or not was beside the point, deleted all of the audit logs and then as a customer of Ubiquiti, I received an email saying, “We have no indication or evidence that any customer data was misappropriated.” Yeah, you just turn off your logs and yeah, you could say that always and forever and save money on logging costs. [unintelligible 00:03:28] best practice just dropped, I guess. Clowns.Chris: So, yeah. And there's definitely, like, compliance and standards and everything else that say you turn on your logs and you protect your logs, and service control policies should have been able to detect that. If they had a security operations center, you know, the fact that somebody was using root keys should have been setting off red flags and causing escalations to occur. And that wasn't happening.Corey: My business partner and I have access to our AWS org, and when I was setting this stuff up for what we do here, at a very small company, neither of us can log in with root credentials without alarms going off that alert the other. Not that I don't trust the man; let's be very clear here. We both own the company.Chris: In business together. Yes.Corey: Ri—exactly. It is, in many ways, like a marriage in that one of us can absolutely ruin the other without a whole lot of effort. But there's still the idea of separation of duties, visibility into what's going on, and we don't use root API keys. Let me further point out that we are not pushing anything that requires you to send data to us. We're not providing a service that is software powered to people, much less one that is built around security. So, how is it that I have a better security posture than Ubiquiti?Chris: You understand AWS and in-depth cloud better. You know, it really comes down to how do you, as an AWS customer, understand all of the moving parts, all of the security tooling, all of the different ways that something can happen. And Amazon will say, “Well, it's in the documentation,” but you know, they have, what, 357 services? Are you reading the security pages of all of those? So, user education, I agree, you should have, and I have on all of my accounts, if anything pops up, if any IAM change happens, I'm getting text messages. Which is great if my account got compromised, but is really annoying when I'm actually making a change and my phone is blowing up.Corey: Yeah. It's worth pointing out as well that yes, Ubiquiti is publicly traded—that is understood and accepted—however, 93% of it is owned by their CEO-founder god-king. So, it is effectively one person's personal fiefdom. And I tend to take a very dim view as a direct result. When you're in cloud and you have suffered a breach, you have severely screwed something up somewhere. These breaches are never, “Someone stole a whole bunch of drives out of an AWS data center.” You have misconfigured something somewhere. And lashing out at people who reported on it is just a bad look.Chris: Definitely. Only error—now, of course, part of the problem here is that our legal system encourages people to not come forward and say, “I screwed up. Here's how I screwed up. Everybody come learn from my mistakes.” The legal professions are also there to manage risk for the company and they're like, “Don't say anything. Don't say anything. Don't even tell the government. Don't say anything.”Whereas we all need to learn from these errors. Which is why I think every time I do see a breach or I do see an indictment, I start diving into it to learn more. I did a blog post on some of the things that happened with Drizly and GitHub, and you know, I think the most interesting thing that came out of Drizly case was the ex-CEO of Drizly, who was CEO at the time of the breach, now has following him, for the rest of his life, an FTC order that says he must implement a security program wherever he goes and works. You know, I don't know what happens when he becomes a Starbucks barista or whatever, but that is on him. That is not on the company; that is on him.And I do think that, you know, we will start seeing more and more chief executive officers, chief security or information security officers becoming accountable to—or for the breaches and being personally accountable or professionally accountable for it. I think we kind of need it, even though, you know, there's only so much a CISO can do.Corey: One of the things that I did when I started consulting independently on AWS bills back in 2016 was, while I was looking at customer environments, I also would do a quick check for a few security baseline things. And I stopped doing it because I kept encountering a bunch of things that needed attention and it completely derailed the entire stated purpose of the engagement. And, frankly, I don't want to be running a security consultancy. There's a reason I focus on AWS bills. And people think I'm kidding, but I swear to you I'm not, when I say that the reason is in part because no one has a middle-of-the-night billing emergency. It is strictly a business-hours problem. Whereas with security, wake up.In fact, the one time I have been woken up in the middle of the night by a customer phone call, they were freaking out because it was a security incident and their bill had just pegged through the stratosphere. It's, “Cool. Fix the security problem first, then we'll worry about the bill during business hours. Bye.” And then I stopped leaving my phone off of Do Not Disturb at night.Chris: Your AWS bill is one of your indicators of compromise. Keep an eye on it.Corey: Oh, absolutely. We've had multiple engagements discover security issues on that. “So, what are these instances in Australia doing?” “We don't have anything there.” “I believe you're being sincere when you say this.”Chris: Yes.Corey: However.Chris: “Last month, you're at $1,000 and this month, you're at $50,000. And oh, by the way, it's the ninth, so you might want to go look at that.”Corey: Here's the problem that you start seeing in large-scale companies though. You or I wind up posting our IAM credentials on GitHub somewhere in public—and I do this from time to time, intentionally with absolutely no permissions attached to a thing—and I started look at the timeline of, “Okay 3, 2, 1, go,” with the push and now I start counting. What happens? At what time does the quarantine policy apply? When do I get an email alert? When do people start trying to exploit it? From where are they trying to exploit it?It's a really interesting thing to look into, just from the position of how this stuff all fits together and works. And that's great, but there's a whole ‘nother piece to it where if you or I were to do such a thing and actually give it admin credentials, okay, my, I don't know, what, $50, $100 a month account that I use for a lot of my test stuff now starts getting charged enormous piles of money that winds up looking like a mortgage in San Francisco, I'm going to notice that. But if you have a company that spending, I don't know, between ten and $20 million a month, do you have any idea how much Bitcoin you've got to be mining in that account to even make a slight dent in the overall trajectory of those accounts?Chris: In the overall bill, a lot. And in a particularly mismanaged account, my experience is you will notice it if you're monitoring billing anomalies on a per-account basis. I think it's important to note, you talked about that quarantine policy. If you look at what actually Amazon drops a deny on, it's effectively start EC2 instances and change IAM policies. It doesn't prevent anybody from listing all your buckets and exfiltrating all your data. It doesn't prevent anybody from firing up Lambdas and other less commonly used resources. Don't assume oh, Amazon dropped the quarantine policy. I'm safe.Corey: I was talking to somebody who spends $4 a month on S3 and they wound up suddenly getting $60 grand a day and Lambda charges, because max out the Lambda concurrency in every region and set it to mine crypto for 15 minutes apiece, yeah, you'll spend $60,000 a day to get, what $500 in crypto. But it's super economical as long as it's in someone else's account. And then Amazon hits them with a straight face on these things, where, “Please pay the bill.” Which is horrifying when there's several orders of magnitude difference between your normal bill and what happens post-breach. But what I did my whole post on “17 Ways to Run Containers on AWS,” followed by “17 More Ways to Run Containers on AWS,” and [unintelligible 00:12:00] about three services away from having a third one ready to go on that, the point is not, “Too many ways to run containers,” because yes, that is true and it's also amusing to me—less so to the containers team at AWS which does not have a sense of humor or sense of self-awareness of which they have been alerted—and fine, but every time you're running a container, it is a way to turn it into a crypto mining operation, in some way shape or form, which means there are almost 40-some-odd services now that can reasonably be used to spin up cryptocurrency mining. And that is the best-case breach scenario in a bunch of ways. It costs a bunch of money and things to clean up, but ‘we lost customer data.' That can destroy companies.Chris: Here's the worst part. Crypto mining is no longer profitable even when I've got stolen API keys because bitcoin's in the toilet. So, now they are going after different things. Actually, the most recent one is they look to see if your account is out of the SCS sandbox and if so, they go back to the tried-and-true way of doing internet scams, which is email spam.Corey: For me, having worked in operations for a very long time, I've been in situations where I worked at Expensify and had access to customer data there. I have worked in other finance companies—I worked at Blackrock. Where I work now, I have access to customer billing data. And let me be serious here for a second, I take all of these things seriously, but I also in all of those roles slept pretty well at night. The one that kept me up was a brief stint I did as the Director of Tech Ops at Grindr over ten years ago because unlike the stuff where I'm spending the rest of my career and my time now, it's not just money anymore.Whereas today, if I get popped, someone can get access to what a bunch of companies are paying AWS. It's scandalous, and I will be sued into oblivion and my company will not exist anymore and I will have a cloud hanging over my head forever. So, I have to be serious about it—Chris: But nobody will die.Corey: Nobody dies. Whereas, “Oh, this person is on Grindr and they're not out publicly,” or they live in a jurisdiction where that is punishable by imprisonment or death, you have blood on your hands, on some level, and I have never wanted that kind of responsibility.Chris: Yeah. It's reasonably scary. I've always been happy to say that, you know, the worst thing that I had to do was keep the Russians off CNN and my friends from downloading Rick and Morty.Corey: Exactly. It's, “Oh, heavens, you're winding up costing some giant conglomerate somewhere theoretical money on streaming subscriptions.” It's not material to the state of the world. And part of it, too, is—what's always informed my approach to things is, I'm not a data hoarder in the way that it seems our entire industry is. For the Last Week in AWS newsletter, the data that I collect and track is pretty freaking small.It's, “You want to sign up for the lastweekinaws.com newsletter. Great, I need your email address.” I don't need your name, I don't need the company you work at. You want to give me a tagged email address? Fine. You want to give me some special address that goes through some anonymizing thing? Terrific. I need to know where I'm sending the newsletter. And then I run a query on that for metrics sometimes, which is this really sophisticated database query called a count. How many subscribers do I have at any given point because that matters to our sponsors. But can we get—you give us any demographic? No, I cannot. I can't. I have people who [unintelligible 00:15:43] follow up surveys sometimes and that's it.Chris: And you're able to make money doing that. You don't have to collect, okay, you know, Chris's zip code is this and Bob's zip code is that and Frank's zip code is the other thing.Corey: Exactly.Chris: Or job titles, or you know, our mother's maiden name or anything else like that.Corey: I talk about what's going on in the world of AWS, so it sort of seems to me that if you're reading this stuff every week, either because of the humor or in spite of the humor, you probably are in a position where services and goods tied to that ecosystem would be well-received by you or one of the other 32,000 people who happen to be reading the newsletter or listening to the podcast or et cetera, et cetera, et cetera. It's an old-timey business model. It's okay, I want to wind up selling, I don't know, expensive wristwatches. Well, maybe I'll advertise in a magazine that caters to people who have an interest in wristwatches, or caters to a demographic that traditionally buys those wristwatches. And okay, we'll run an ad campaign and see if it works.Chris: It's been traditional advertising, not the micro-targeting stuff. And you know, television was the same way back in the broadcast era, you know? You watched a particular show, people of that demographic who watched that particular show had certain advertisers they wanted.Corey: That part of the challenge I've seen too, from sponsors of this show, for example, is they know it works, but they're trying to figure out how to do any form of attribution on this. And my answer—which sounds self-serving, but it's true—is, there's no effective way to do it because every time you try, like, “Enter this coupon code,” yeah, I assure you, some of these things wind up costing millions of dollars to deploy at large companies at scale and they provide value for doing it. No one's going to punch in a coupon code to get 10% off or something like that. Procurement is going to negotiate custom contracts and it's going to be brought up maybe by someone who heard the podcast ad. Maybe it just sits in the back of their mind until they hear something and it just winds of contributing to a growing awareness of these things.You're never going to do attribution that works on things like that. People try sometimes to, “Oh, you'll get $25 in credit,” or, “We'll give you a free t-shirt if you fill out the form.” Yeah, but now you're biasing for people who find that a material motivator. When I'm debating what security suite I'm going to roll out at my enterprise I don't want a free t-shirt for that. In fact, if I get a free t-shirt and I wear that shirt from the vendor around the office while I'm trying to champion bringing that thing in, I look a little compromised.Chris: Yeah. Yeah, I am—[laugh] I got no response to that [laugh].Corey: No, no. I hear you. One thing I do want to talk about is the last time we spoke, you mentioned you were involved in getting fwd:cloudsec—a conference—off the ground. Like all good cloud security conferences, it's named after an email subject line.It is co-located with re:Inforce this year in Anaheim, California. Somewhat ominously enough, I used to live a block-and-a-half away from the venue. But I don't anymore and in fact, because nobody checks the global event list when they schedule these things, I will be on the other side of the world officiating a wedding the same day. So, yet again, I will not be at re:Inforce.Chris: That is a shame because I think you would have made an excellent person to contribute to our call for papers and attend. So yes, fwd:cloudsec is deliberately actually named after a subject line because all of the other Amazon conferences seem to be that way. And we didn't want to be going backwards and thinking, you know, past tense. We were looking forward to our conference. Yeah, so we're effectively a vendor-neutral cloud security conference. We liked the idea of being able to take the talks that Amazon PR would never allow on stage at re:Inforce and run with it.Corey: I would question that. I do want to call that out because I gave a talk at re:Invent one year about a vulnerability I found and reported, with the help of two other people, Scott Piper and Brandon Sherman, to the AWS security team. And we were able to talk about that on stage with Zack Glick, who at the time, was one of basically God's own prototypes, working over in the AWS environment next to Dan [Erson 00:19:56]. Now, Dan remains the salt of the earth, and if he ever leaves basically just short the entire US economy. It's easier. He is amazing. I digress. The point being is that they were very open about talking about an awful lot of stuff that I would never have expected that they would be okay with.Chris: And last year at re:Inforce, they had an excellent, excellent chalk talk—but it was a chalk talk, not recorded—on how ransomware attacks operate. And they actually, like, revealed some internal, very anonymized patterns of how attacks are working. So, they're starting to realize what we've been saying in the cloud security community for a while, which is, we need more legitimate threat intelligence. On the other hand, they don't want to call it threat intelligence because the word threat is threatening, and therefore, you know, we're going to just call it, you know, patterns or whatever. And our conference is, again, also multi-cloud, a concept that until recently, AWS, you know, didn't really want to acknowledge that there were other clouds and that people would use both of them [crosstalk 00:21:01]—Corey: Multi-cloud security is a nightmare. It's just awful.Chris: Yeah, I don't like multi-cloud, but I've come to realize that it is a thing. That you will either start at a company that says, “We're AWS and we're uni-cloud,” and then next thing, you know, either some rogue developer out there has gone and spun up an Azure subscription or your acquire somebody who's in GCP, or heaven forbid, you have to go into some, you know, tinhorn dictator's jurisdiction and they require you to be on-prem or leverage Oracle Cloud or something. And suddenly, congratulations, you're now multi-cloud. So yes, our goal is really to be the things that aren't necessarily onstage or aren't all just, “It's great.” Even your talk was how great the incident response and vulnerability remediation process was.Corey: How great my experience with it was at the time, to be clear. Because I also have gotten to a point where I am very aware that, in many cases when dealing with AWS, my reputation precedes me. So, when I wind up tweeting about a problem or opening a support case, I do not accept as a given that my experience is what everyone is going to experience. But a lot of the things they did made a lot of sense and I was frankly, impressed that they were willing to just talk about anything that they did internally. Because previously that had not been a thing that they did in open forums like that.Chris: But you go back to the Glue incident where somebody found a bug and they literally went and went to every single CloudTrail event going back to the dawn of the service to validate that, okay, the, only two times we ever saw this happen were between the two researcher's accounts who disclosed it. And so, kudos to them for that level of forward communication to their customers because yeah, I think we still haven't heard anything out of Azure for last year's—or a year-and-a-half ago's Wiz findings.Corey: Well, they did do a broad blog post about this that they put out, which I thought, “Okay, that was great. More of this please.” Because until they start talking about security issues and culture and the remediation thereof, I don't give a shit what they have to say about almost anything else because it all comes back to security. The only things I use Azure for, which admittedly has some great stuff; their computer vision API? Brilliant—but the things I use them for are things that I start from a premise of security is not important to that service.The thing I use it for on the soon-to-be-pivoted to Mastodon Twitter thread client that I built, it writes alt-text for images that are about to be put out publicly. Yeah, there's no security issue from that perspective. I am very hard-pressed to imagine a scenario in which that were not true.Chris: I can come up with a couple, but you know—Corey: It feels really contrived. And honestly, that's the thing that concerns me, too: the fact that I finally read, somewhat recently, an AWS white paper talking about—was it a white paper or was it blog post? I forget the exact media that it took. But it was about how they are seeing ransomware attacks on S3, which was huge because before that, I assumed it was something that was being made up by vendors to sell me something.Chris: So, that was the chalk talk.Corey: Yes.Chris: They finally got the chalk talk from re:Inforce, they gave it again at re:Invent because it was so well received and now they have it as a blog post out there, so that, you know, it's not just for people who show up in the room, they can hear it; it's actually now documented out there. And so, kudos to the Amazon security team for really getting that sort of threat intelligence out there to the community.Corey: Now, it's in writing, and that's something that I can cite as opposed to, “Well, I was at re:Invent and I heard—” Yeah, we saw the drink tab. We know what you might have thought you heard or saw at re:Invent. Give us something we can take to the board.Chris: There were a lot of us on that bar tab, so it's not all you.Corey: Exactly. And it was my pleasure to do it, to be clear. But getting back to fwd:cloudsec, I'm going to do you a favor. Whether it's an actual favor or the word favor belongs in quotes, the way that I submit CFPs, or conference talks, is optimized because I don't want to build a talk that is never going to get picked up. Why bother to go through all the work until I have to give it somewhere?So, I start with a catchy title and then three to five sentences. And if people accept it, great, then I get to build the talk. This is a forcing function in some ways because if you get a little delayed, they will not move the conference for you. I've checked. But the title of a talk that I think someone should submit for fwd:cloudsec is, “I Am Smarter Than You, so Cloud Security is Easy.”And the format and the conceit of the talk is present it with sort of a stand-it-up-to-take-it-down level of approach where you are over-confident in the fact that you are smarter than everyone else and best practices don't apply to you and so much of this stuff is just security theater designed as a revenue extraction mechanism as opposed to something you should actually be doing. And talk about why none of these things matter because you use good security and you know, it's good because you came up with it and there's no way that you could come up with something that you couldn't break because you're smart. It says so right in the title and you're on stage and you have a microphone. They don't. Turn that into something. I feel like there's a great way to turn that in a bunch of different directions. I'd love to see someone give that talk.Chris: I think Nickolas Sharp thought that too.Corey: [laugh]. Exactly. In fact, that will be a great way to bring it back around at the end. And it's like, “And that's why I'm better at security than you are. If you have any questions beyond this, you can reach me at whatever correctional institute I go in on Thursday.” Exactly. There's ways to make it fun and engaging. Because from my perspective, talks have to be entertaining or people don't pay attention.Chris: They're either entertaining, or they're so new and advanced. We're definitely an advanced cloud security practice thing. They were 500 levels. Not to brag or anything, but you know, you want the two to 300-level stuff, you can go CCJ up the street. We're hitting and going above and beyond what a lot of the [unintelligible 00:27:18]—Corey: I am not as advanced on that path as you are; I want to be very clear on this. You speak, I listen. You're one of those people when it comes to security. Because again, no one's life is hanging in the balance with respect to what I do. I am confident in our security posture here, but nothing's perfect. Everything is exploitable, on some level.It's also not my core area of focus. It is yours. And if you are not better than I am at this, then I have done something sort of strange, or so of you, in the same way that it is a near certainty—but not absolute—that I am better at optimizing AWS bills than you are. Specialists exist for a reason and to discount that expertise is the peak of hubris. Put that in your talk.Chris: Yeah. So, one talk I really want to see, and I've been threatening to give it for a while, is okay, if there's seventeen ways—or sorry, seventeen times two, soon to be seventeen times three ways to run containers in AWS, there's that many ways to exfiltrate credentials from those containers. What are all of those things? Do we have a holistic way of understanding, this is how credentials can be exfiltrated so that we then as defenders can go figure out, okay, how do we build detections and mitigations for this?Corey: Yeah. I'm a huge fan of Canarytokens myself, for that exact purpose. There are many devices I have where the only credentials in plain text on disk are things that as soon as they get used, I wind up with a bunch of things screaming at me that there's been a problem and telling me where it is. I'm not saying that my posture is impenetrable. Far from it. But you're going to have to work for it a little bit harder than running some random off-the-shelf security scanner against my AWS account and finding, oops, I forgot to turn on a bucket protection.Chris: And the other area that I think is getting really interesting is, all of the things that have credentials into your Cloud account, whether it's something like CircleCI or GitHub. I was having a conversation with somebody just this morning and we were talking about Roles Anywhere, and I was like, “Roles Anywhere is great if you've got a good strong PKI solution and can keep that private certificate or that certificate you need safe.” If you just put it on a disk, like, you would have put your AKIA and secret on a desk, congratulations, you haven't really improved security. You've just gotten rid of the IAM users that are being flagged in your CSPM tool, and congratulations, you have, in fact, achieved security theater.Corey: It's obnoxious, on some level. And part of the problem is cost and security are aligned and that people care about them right after they really should have cared about them. The difference is you can beg, cry, whine, et cetera to AWS for concessions, you can raise another round of funding; there have solutions with money. But security? That ship has already sailed.Chris: Yeah. Once the data is out, the data is out. Now, I will say on the bill, you get reminded of it every month, about three or four days after. It's like, “Oh. Crap, yeah, I should have turned off that EC2 instance. I just burned $100.” Or, “Oh hey, we didn't turn off that application. I just burned $100,000.” That doesn't happen on security. Security events tend to be few and far between; they're just much bigger when they happen.Corey: I really want to thank you for taking the time to chat with me. I'm sure I'll have you back on between now and re:Inforce slash fwd:cloudsec or anything else we come up with that resembles an email subject line. If people want to learn more and follow along with your adventures—as they should—where's the best place for him to find you these days?Chris: So, I am now pretty much living on Mastodon on the InfoSec Exchange. And my website, chrisfarris.com is where you can find the link to that because it's not just at, you know, whatever. You have to give the whole big long URL in Mastodon. It's no longer—Corey: Yeah. It's like a full-on email address with weird domains.Chris: Exactly, yeah. So, find me at http colon slash slash infosec dot exchange slash at jcfarris. Or just hit Chris Farris and follow the links. For fwd:cloudsec, we are conveniently located at fwdcloudsec.org, which is F-W-D cloud sec dot org. No colons because I don't think those are valid in whois.Corey: Excellent choice. And of course, links to that go in the [show notes 00:31:32], so click the button. It's easier. Thanks again for your time. I really appreciate it.Chris: Thank you.Corey: Chris Farris, Cloud Security Nerd at Turbot slash Turbo. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that resembles a lawsuit being filed, and then have it processed-served to me because presumably, you work at Ubiquiti.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

In this episode, Brandon and I meet with Marcie Richardson, the Director of HR and Safety for Guarantee Restoration. She's a charismatic and passionate leader and had some awesome insight and stories to share with us. We talk about employee onboarding, employee one on ones, and practical ways that we can care for our employees as they do the do the dirty work of our industry. Check it out and let us know what you think!- Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

In this episode, we are talking about the emotional toll of OCD.  Kim: Welcome back, everybody. This week is going to include three of some of my most favorite people on this entire planet. We have the amazing Chris Trondsen, Alegra Kastens, and Jessica Serber—all dear friends of mine—on the podcast. This is the first time I've done an episode with more than one guest.  Now, this was actually a presentation that the four of us did at multiple IOCDF conferences. It was a highly requested topic. We were talking a lot about trauma and OCD, shame and OCD, the stigma of OCD, guilt and OCD, and the depression and grief that goes with OCD. After we presented it, it actually got accepted to multiple different conferences, so we all agreed, after doing it multiple times and having such an amazing turnout, that we should re-record the entire conversation and have it on the podcast. I'm so grateful for the three of them. They all actually join me on Super Bowl Sunday—I might add—to record this episode. I am going to really encourage you to drop down into your vulnerable self and listen to what they have to say, and note the validation and acknowledgment that they give throughout the episode. It is a deep breath. That's what this episode is.  Before we get into this show, let me just remind you again that we are recording live the Overcoming Depression course this weekend. On March 11th, March 18th, and March 25th, at 9:00 AM Pacific Standard Time, I will be recording the Overcoming Depression course. I am doing it live this time. If you're interested in coming on live as I record it, you can ask your questions, you can work along with me. There'll be workbooks. I'll be giving you a lot of strategies and a lot of tools to help you overcome depression.  If you're interested, go to CBTSchool.com/depression. We will be meeting again, three dates in March, starting tomorrow, the 11th of March, at 9:00 AM Pacific Time. You will need to sign up ahead of time. But if for any reason you miss one of them, you can watch the replay. The replays will be uploaded. You'll have unlimited on-demand access to any of them. You'll get to hear me answering people's questions. This is the first time I've ever recorded a course live. I really felt it was so important to do it live because I knew people would have questions and I wanted to address them step by step in a manageable, bite-sized way. Again, CBTSchool.com/depression, and I will see you there. Let's get over to this incredible episode.  Again, thank you, Chris Trondsen. Thank you, Alegra Kastens. Thank you, Jessica Serber. It is an honor to call you my friend and my colleague. Enjoy everybody.  Kim: Welcome. This has been long, long. I've been waiting so long to do this and I'm so thrilled. This is my first time having multiple guests at once. I have three amazing guests. I'm going to let them introduce themselves. Jessica, would you like to go first? Jessica: I'm Jessica Serber. I'm a licensed marriage and family therapist, and I have a practice specializing in the treatment of OCD and related anxiety and obsessive-compulsive spectrum disorders in Los Angeles. I'm super passionate about working with OCD because my sister has OCD and I saw her get her life back through treatment. So, I have so much hope for everyone in this treatment process. Kim: Fantastic. So happy to have you. Chris? Chris: Hi everyone. My name is Chris Trondsen. I am also a licensed marriage family therapist here in Orange County, California at a private group practice. Besides being a therapist, I also have OCD myself and body dysmorphic disorder, both of which I specialize in treatment. Because of that, I'm passionate about advocacy. I am one of the lead advocates for the International OCD Foundation, as well as on their board and the board of OCD Southern California, as well as some leadership on some of their special interest groups. Kind of full circle for me, have OCD and now treat it. Kim: Amazing. Alegra? Alegra: My name is Alegra Kastens and I am a licensed therapist in the states of California and New York. I'm the founder of the Center for OCD, Anxiety and Eating Disorders. Like Chris, I have lived experience with OCD, anxiety, eating disorders, and basically everything, so I'm very passionate. We got a lot going on up here. I'm really passionate about treating OCD, educating, advocating for the disorder, and that is what propelled me to pursue a career as a therapist and then also to build my online platform, @obsessivelyeverafter on Instagram. GRIEF AND OCD Kim: Amazing. We have done this presentation before, actually, multiple times over the years. I feel like an area that I want to drop into as deeply as we can today to really look at the emotional toll of having and experiencing and recovering from OCD. We're going to have a real conversation style here. But first, we'll follow the format that we've used in the past. Let's first talk about grief and OCD because I think that that seems to be a lot of the reason we all came together to present on this. Alegra, would you talk specifically about some of the losses that result from having OCD? I know this actually was inspired by an Instagram post that you had put out on Instagram, so do you want to share a little bit about what those emotional losses are?  Alegra: For sure. I think that number one, what a lot of people with OCD experience is what feels like a loss of identity. When OCD really attacks your values, attacks your core as a human being, whether it's pedophile obsession, sexual orientation obsessions, harm obsessions, you really start to grieve the person that you once thought you were. Of course, nothing has actually changed about you, but because of OCD, it really feels like it has. In addition to identity, there's lost relationships, there's lost time, lost experiences. For me, I dropped out of my bachelor's degree and I didn't get the four years of undergrad that a lot of people experienced. I mean, living with OCD is one of the most debilitating, difficult things to do. And that means, if you're fighting this battle and trying to survive, you probably are missing out on life and developmental milestones. Kim: Right. Was that the case for you too, Chris? Chris: Yeah. I actually host a free support group for families and one of the persons with OCD was speaking yesterday talking about how having OCD was single-handedly the most negatively impactful experience in his life. He is dealt with a lot of loss. I feel the same way. It's just not something you could shake off and recover from in the sense of just pretending nothing happened. I know for me, the grief was hard. I mean, I had mapped out what I thought my life was going to look like. I think my first stage of grief, because I think it became two stages, my first, like Alegra said, was about the loss. I always wanted to go to college and be around people in my senior year, like make friends and things like that. It's just my life became smaller and smaller. I became housebound. I missed out on normal activities, and six years of my life were pretty much spent alone.  I think what Alegra also alluded to, which was the second layer of grief, was less about the things that I lost, but who I became. I didn't recognize myself in those years with OCD. I think it's hard to explain to somebody else what it's like to literally not live as yourself. I let things happen to me or I did things that I would never do in the mind state that I am in now. I was always such a brave and go-for-it kind of person and confident and I just became a shell of myself. I grieve a lot of the years lost, a lot of the things I always wanted to do, and places I wanted to go. And then I grieve the person I became because it was nothing I ever thought I could become. Kim: Jessica, will you speak also to just the events that people miss out on? I don't know if you want to speak about what you see with your clients or even with your sibling, like just the milestones that they missed and the events they missed. Jessica: Yeah, absolutely. My sister was really struggling the most with her OCD during middle school and high school. Those are such formative years, to begin with. I would say, she was on the fortunate end of the spectrum of being diagnosed relatively early on in her life. I mean, she definitely had symptoms from a very, very young age, but still, getting that diagnosis in middle school is so much before a lot of people get that. I mean, I work with people who aren't diagnosed until their twenties, thirties, and sometimes even later. Different things that most adolescents would go through she didn't.  Speaking to the identity piece that Alegra brought up, a big part of her identity was being a sports fan. She was a diehard Clippers fan, and that's how everyone knew her. It was like her claim to fame. She didn't even want to go to Clippers games. My dad was trying to get tickets to try to get her excited about something to get out of the house. She missed certain events in high school because it was too anxiety-provoking to go and it was more comforting to know she could stay in the safety of the home. Their experiences all throughout the lifespan, I think that can be impacted. Even if you're not missing out on them entirely, a lot of people talk about remembering those experiences as tainted by the memories of OCD, even if they got to go experience them. Kim: Right. For me, as a clinician, I often hear two things. One is the client will say something to the likes of, “I've lost my way. I was going in this direction and I've completely lost the path I was supposed to go on.” I think that is a full grief process. I think we've associated grief with the death of people, but it's not. It's deeper than that and it's about like you're talking about, identity and events and occasions.  The other thing that I hear is—actually, we can go totally off script here in terms of we've talked about this in the past separately—people think that once they're recovered, they will live a really happy life and that they'll feel happy now. Like, “Oh, the relief is here, I've recovered.”  But I think there is a whole stage of grief that follows during recovery and then after recovery. Do you have any thoughts on that, anybody?  Alegra: Well, yeah. I think it reminds me a lot of even my own experience, but my client's experiences of when you recover, there tends to be grief about life before OCD. If I'm being perfectly honest, my life will just never be what it was before OCD, and it's different and wonderful in so many ways that maybe it wouldn't be if I didn't have OCD. But I'm laughing because when you were like, “I'm going to mark my calendar in July because you're probably going to have a relapse,” then I have to deal with it every six months. My brain just goes off for like two weeks. I don't know why it happens. It's just my OCD brain, and there's grief associated with that. I can go for six months and I have some intrusive thoughts, but it doesn't really do anything to me to write back in it for two weeks. That's something I have to deal with and I have to get to that acceptance place in the grieving process. I'm not going to have the brain that I did before OCD when I didn't have a single unwanted sexual thought. That just isn't happening. I think we think that we're going to get to this place after recovery, and it's like game over, I forget everything that happened in the past, but we have to remember that OCD can be traumatizing for people. Trauma is stored in the body. The brain is impacted and I think that we can carry that with us afterwards. Kim: Right. Chris: Yeah. I mean, everything that Alegra was saying—I'll never forget. I always joke, but I thought when treatment was done, rainbows were going to shoot out and butterflies. I was going to jump on my very own unicorn and ride off to the sunset. But it was like a bomb had gone off and I had survived the blast, but everything around me was completely pulverized. I just remember thinking, what do I do now? I remember going on social media to look up some of my friends from high school because my OCD got really, really bad after high school. I just remember everybody was starting to date or marry or travel and move on and I'm like, “Great, I live in my grandma's basement. I don't have anything on my calendar. I'm not dating, I don't have any friends. What do I do?” I was just completely like, “Okay, I don't even know where to begin.” I felt so lost. Anything I did just didn't feel right. Like Alegra said, there was so much aftermath that I had to deal with. I had to deal with the fact that I was lost and confused and I was angry and I had all these emotions. I had these memories of just driving around.  As part of my OCD, I had multiple subtypes—sexual intrusive thoughts, harm thoughts. I remember contamination, stores around me would get dirty, so I'd be driving hours to buy products from non-dirty stores at 4:00 or 5:00 in the morning, crying outside of a store because they were closed or didn't have the product I need, getting home and then my checking would kick in. You left something at the store, driving back. You just put yourself through all these different things that are just not what you would ever experience.  I see it with my clients. One client sticks in mind who was in his eighties and after treatment, getting better. He wasn't happy and he is like, “I'm so happy, Chris. You helped me put OCD in remission. But I now realize that I never got married because I was scared of change. I never left the house that I hated in the city I didn't really like because I was afraid of what would happen if I moved.” He's like, “I basically lived my OCD according to OCD'S rules and I'm just really depressed about that.” I know we're going to talk about the positive sides and how to heal in the second half, but this is just really what OCD can ravish on our lives. Kim: Right.  Jessica: If I can add one thing too really quickly, something I really think is a common experience too is that once healing happens, even if people do get certain parts of their lives back and feel like they can function again in the ways that they want to, there's always this sense of foreboding joy, that it feels good and I'm happy, but I'm just waiting for the other shoe to drop all the time. Or what if I go back to how I was and I lose all my progress? Even when there are those periods of joy and happiness and fulfillment, they might also be accompanied with some anxiety and some what-ifs. Of course, we can work on that and should work on that in treatment too because we want to maximize those periods of joy as much as we can. But that's something that I commonly see, that the anxiety sticks around just in different ways. OCD, SHAME, & GUILT Kim: Yeah, for sure. I see that very commonly too. Let's talk now about OCD, shame, and guilt. I'll actually go straight to you, Jessica, because I remember you speaking about this beautifully. Can you explain the difference between shame and guilt specifically related to how it may show up with OCD?  Jessica: Yeah. I mean, they're definitely related feelings but they are different. I think the simplest way to define the difference is guilt says, “I did something bad,” whereas shame says, “I am bad.” Shame is really an identity-based emotion and we see a lot of shame with any theme of OCD. It can show up in lots of different ways, but definitely with some of the themes that are typically classified as Pure O—the sexual intrusive thoughts or unwanted harm thoughts, scrupulosity, blasphemous thoughts. There can be a lot of shame around a person really identifying with their thoughts and what it means about them. Attaching that, meaning about what it means about them. And then of course, there can also be guilt, which I think feels terrible as well, but it's like a shame light where it's like, “I did something wrong by having this thought,” or just guilt for maybe something that they've thought or a compulsion that they've done because of their OCD.  Kim: Yeah. I've actually also experienced a lot of clients saying they feel guilty because of the impact their OCD has had on their loved ones too. They're suffering to the biggest degree, but they're also carrying the guilt of like, “I've caused suffering to my family,” or “I'm a financial burden to my parents with the therapy and the psychiatrist.” I think that there's that secondary guilt that shows up for a lot of people as well, which we can clump in as an outcome or a consequence or an experience of having OCD. Chris: Yeah. I mean, right before you said this, Kim, I was thinking for me personally, that was literally what I was going to say. I have a younger sister. She's a couple of years younger than me and I just put her through hell. She was one of the first people that just felt the OCD's wrath because I was so stressed out. She and I shared a lot of the same spaces in the home, so we'd have a lot of fights. Also, when I was younger, because she looks nothing like me—she actually looks more like you, Kim, blonde hair, blue eyes—people didn't know we were related. People would always say things like, “Oh, is that your girlfriend?” So then I'd have a lot of ancestral intrusive thoughts that caused a lot of harm to me, so I'd get mad at her. Because I was young, I didn't know better. And then just the hell I put my mom through.  I always think about just like, wow, once again, that's not who Chris is. I would jump in front of eight bullets for both my mom and my sister. I remember one time I needed something because I felt dirty, and my mom hit our spending money so that if there was an emergency. My sister knew where it was and she wouldn't give it to me. I remember taking a lighter and lighting it and being like, “I'll burn your hair if you don't give me the money,” because I was so desperate to buy it because that's how intense the OCD was. I remember she and I talking about that and it just feels like a different human. Once again, it's more than just guilt. It's shame of who I had become because of it and not even recognizing the boy I was now compared to the man I am now, way than man now. OCD AND ANGER Kim: One thing we haven't talked a lot about, but Chris, you just spoke to it, and I've actually been thinking about this a lot. Let's talk about OCD and anger because I think that is another emotional toll of OCD. A lot of clients I've had—even just recently, I've been thinking about this a lot—sometimes instead of doing compulsions, they have an anger outburst or maybe as well as compulsions. Does anyone want to speak to those waves of frustration and anger that go around these thoughts that we have or intrusive whatever obsessions in any way, but in addition, the compulsions you feel you have to do when you have OCD? Alegra: I feel like sometimes there can be maybe a deeper, more painful emotion that's underneath that anger, which can be shame or it can be guilt, but it feels like anger is maybe easier to express. But also, there just is inherent anger that comes up with having to live with this. I remember one time in my own personal therapy, my therapist was trying to relate and she pulled out this picture that she had like an, I don't know, eight-year-old client with OCD and was like, “She taps herself a lot.” I screamed at her at that moment. I was like, “Put that fucking picture away, and don't ever show that to me again. I do not want to be compared to an eight-year-old who taps himself, like I will tap myself all day fucking long, so long as I don't have these sexually unwanted thoughts about children.” I was so angry at that moment because it just felt like what I was dealing with was so much more taboo and shameful. I was angry a lot of the time. I don't think we can answer the question of, why? Why did I have to experience this? Why did someone else not have to experience this? And that anger is valid.  The other thing that I want to add is that anger does not necessarily mean that we are now going to act on our obsessions because I think clients get very afraid of that. I remember one time I was so fucking pissed at my coworker. He was obnoxious when I worked in PR, and I was so mad at him, I had to walk outside and regulate. And then instantly, of course, my brain went, “You want his kid to die?” or whatever it was. I felt like, oh my God, I must really want this to happen because I'm mad at him. In terms of anger, we can both feel angry and not align with unwanted thoughts that arise. CAN OCD CAUSE ANGER ISSUES?  Kim: Right. OCD can attack the emotions that you experience, like turn it back on you. It's funny, I was doing a little bit of research for this and I typed in ‘OCD in anger.' I was looking to see what was out there. What was so fascinating to me is, you know when you type something in on Google, it shows all of the other things that are commonly typed in. At the very top was ‘Can OCD cause anger issues?' I was like, that is so interesting, that obviously, loved ones or people with OCD are searching for this because it's so normal, I think, to have a large degree of just absolute rage over what you've been through, how much you've suffered, just the torment and what's been lost, as we've already talked about. I just thought that was really fascinating to see, that that's obviously something that people are struggling with.  Chris: When you think about it, when we're struggling with OCD, the parts of our brain that are trying to protect us are on fire or on high alert. If you always think about that, I always think of a feral dog. If you're trying to get him help, then he starts to bite. That's how I honestly felt. My anger was mostly before I was diagnosed, and once again, like I said, breaking things at home, screaming, yelling at my family, intimidating them, and stuff. I know that once again, that wasn't who I am at the course. When I finally got a diagnosis, I know for me, the anger dissipated. I was still angry, but the outbursts and the rage, and I think the saddest thing I hear from a lot of my clients is they tell me, I think people think I'm this selfish and spoiled and bratty and angry person. I'm not. I just cannot get a break.  I always remind parents that as your loved one or spouses, et cetera—as your loved one gets better, that anger will subside. It won't vanish, it won't disappear, it may change into different emotions, like Alegra was saying, to guilt and to shame and loss of identity. But that rage a lot of times is because we just don't know what to do and we feel attacked constantly with OCD.  Kim: Yeah. Jessica: I also want to validate the piece that anger is a really natural and normal stage of grief. I like that you're differentiating, Chris, between the rage that a lot of people experience in it versus maybe just a different type of anger that can show up after when you recognize how—I think, Alegra, you brought up—we can't answer the question of, why did this happen to me? Or “I missed out on all these times or years of my life that I can't get back.” Anger is not a problem. It's not an issue when it shows up like that. It's actually a very healthy natural part of grief. We want to obviously process it in ways that really honor that feeling and tend to that feeling in a helpful way. I just wanted to point out that part as well. DO YOU CONSIDER HAVING OCD A TRAUMATIC EVENT?    Kim: Yeah, very, very helpful. This is for everybody and you can chime in, but I wanted to just get a poll even. Alegra spoke on this a little bit already. Do you consider having OCD a traumatic event? Alegra: A hundred thousand percent. I'm obviously not going to trauma dump on all of you all, but boy, would I love to. I have had quite a few of what's classified as big T traumas, which I even hate the differentiation of big T, sexual assault, abuse, whatever. I have had quite a bit of big T traumas and I have to say that OCD has been the most traumatizing thing I have been through and I think we'll ever go through. It bothers me how much I think gatekeeping can happen in our community. Like, no, it's only trauma if you've been assaulted, it's only trauma if X, Y, and Z. I have a lot of big T trauma and I'm here to say that OCD hands down, like I would go through all of that big T trauma 15 times over to not have OCD, 100%. I think Chris can just add cherries to the cake, whatever that phrase is. Chris: Yeah. This is actually how the title, the Emotional Toll of OCD, came about. We had really talked about this. I was really inspired mainly by Alegra talking about the trauma of OCD and I was like, finally, someone put the right word because I always felt that other words didn't really speak to my personal experience and the experience I see with clients. We had submitted it for a talk and it got denied. I remember they liked it so much that they literally had a meeting with you and I, Kim, and we're like, “We actually really love this. We just got to figure out a way to change it.” Like Alegra was saying, a lot of the people that were part of a trauma special interest group just said, “Look, we can't be using the word ‘trauma' like this.” But we had a good talk about it. It's like, I do believe it's trauma. I always feel weird talking about him because sometimes he listens to my stuff, but still, I'll say it anyways. But my dad will hopefully be the first to admit it. But there were a lot of physical altercations between he and I that were inappropriate—physical abuse, emotional abuse, yelling, screaming. Like Alegra said, I would relive that tenfold than go through the depths of my OCD again where I attempted suicide, where I isolated, where I didn't even recognize myself.  If ‘trauma' isn't the correct word, we only watered it down to emotional toll just to make DSM-5 folks happy. But if ‘trauma' isn't the word, I don't know what is, because like I said, trauma was okay to describe the pain I went through childhood, but in my personal experience, it failed in comparison to the trauma that I went through with OCD.  Alegra: I also want to add something. Maybe I'm wrong, but if I'm thinking about the DSM definition, I think it's defining post-traumatic stress disorder. I don't think it's describing trauma specifically. Maybe I'm wrong, but it's criteria for PTSD. I will be the first to say and none of you have to agree. I think that you can have PTSD from living with OCD. DSM-wise diagnostically, you can't. But I think when people are like, “Well, that's not the definition of trauma in the DSM,” no, they're defining PTSD. It's like, yeah, some people have anxiety and don't have an anxiety disorder. You can experience trauma and not have full-blown PTSD. That's my understanding of it. Kim: Yeah. It's funny because I don't have OCD, so I am an observer to it. What I think is really interesting is I can be an observer to someone who's been through, like you've talked about, a physical assault or a sexual assault and so forth, and they may report I'm having memories of the event and wake up with the physiology of my heart beating and thoughts racing. But then I'll have clients with OCD who will have these vivid memories of having to wash their hands and the absolute chaos of, “I can't touch this. Oh my God, please don't splash the water on me,” Memories of that and nightmares of that and those physiological experiences. They're remembering the events that they felt so controlled and so stuck in. That's where for me, I was, with Chris, really advocating for. These moments imprint our brain right in such a deep way. Alegra: Yeah. I'm reading this book, not to tell everyone to buy this book, but it's by Dr. Bruce Perry and he does a bunch of research on trauma and the brain. Basically, the way that he describes it is like when we experience something and it gets associated. Let's say, for instance, there are stores that I could go to and I could still feel that very visceral feeling that I did when I was suffering. Part of that is how trauma is stored in the brain. Even if you logically know I'm not in that experience now, I'm not in the war zone or I'm not in the depths of my OCD suffering, just the store, let's say, being processed through the lower part of your brain can bring up all of those associations. So, it does do something to the brain. Kim: Right.  Chris: Absolutely. I was part of a documentary and it was the first time I went back to the home that I had attempted suicide, and the police got called the hospital and all that. It was a bad choice. They didn't push me into it. It was my idea because I haven't gone back there, had no clue how I'd react and I broke down. I mean, broke down in a dry heaving way that I never knew I could and we had to stop filming and we left. Where I was at my worst of OCD was there and also at my grandma's house because that's where I moved right after the suicide attempt. I'd have people around me, and still going down to the basement area that I lived in. It is very hard. I rarely do it. So, I have a reaction. To me, it was like, if that isn't once again trauma, I don't know what is. Alegra: It is.  Chris: Exactly. I'll never forget there was a woman that was part of a support group I ran. She was in her seventies and she had gone through cancer twice. I remember her telling the group that she's like, “I'll go through cancer a third time before I'll ever go back to my worst of OCD.” Obviously, we're not downplaying these other experiences—PTSD, trauma, cancer, horrible things, abuse, et cetera. What we're saying is that OCD takes a lasting imprint and it's something that I have not been able to shake. I've done so much advocacy, so much therapy, so much as a therapist and I don't still struggle, but the havoc it has on my life, that's something I think is going to be imprinted for life. Alegra: Forever. Jessica: Also, part of the definition of trauma is having a life-threatening experience. What you're speaking to, Chris, you had a suicide attempt during that time. Suicidality is common with OCD. Suicidal ideation, it's changing your life. I think Alegra, you said, “I'll never have the life or the brain that I had before OCD.” These things that maybe it's not, well, some of them are actually about real confrontation with death, but these real life-changing, life-altering experiences that potentially also drive some people to have thoughts or feelings about wanting to not be alive anymore. I just think that element is there. Alegra: That's so brilliant, Jessica, because that is so true. If we're thinking about it being life-threatening and life-altering, it was life-threatening for me. I got to the point where I was like, “If something doesn't change, I will kill myself. I will.” That is life-threatening to a person. I would be driving on the freeway like, “Do I just turn the car? Do I just turn it now? Because I was so just fucking done with what was happening in my brain.” Kim: It feels crisis. Alegra: Yeah. Kim: It's like you're experiencing a crisis in that moment, and I think that that's absolutely valid. Alegra: It's an extended crisis. For me, it was a crisis of three to four years. I never had a break. Not when I was sleeping. I mean, never. Chris: I was just going to add that I hear in session almost daily, people are like, “If I just don't wake up tomorrow, I'm fine. I'd never do anything, but if I just don't wake up tomorrow, I'm fine.” We know this is the norm. The DSM talks about 50% of individuals with OCD have suicidal ideation, 25% will attempt. This is what people are going through as they enter treatment or before treatment. They just feel like, “If I just don't wake up or if something were to happen to me, I'd actually be at peace with it.” It's a really alarming number. THE EMOTIONAL TOLL OF OCD TREATMENT Kim: Right. Let's move. I love everything that you guys are saying and I feel like we've really acknowledged the emotional toll really, the many ways that it universally impacts a person emotionally and in all areas of their lives. I'm wondering if you guys could each, one at a time or bounce it off each other, share what you believe are some core ways in which we can manage these emotional tolls, bruises left, or scars left from having OCD? Jessica, do you want to go first?  Jessica: Sure. I guess the first thing that comes to mind is—I'll speak from the therapist perspective—if you're a therapist specializing in treating OCD, make sure you leave room to talk about these feelings that we're bringing up. Of course, doing ERP and doing all of the things to treat OCD is paramount and we want to do that first and foremost if possible. But if you're not also leaving room for your client to process this grief, process through and challenge their shame, just hold space for the anger and maybe talk about it. Let your client have that anger experience in a safe space. We're missing a huge, huge part of that person's healing if we're leaving that out. Maybe I'll piggyback on what you two say, but that's just the baseline that I wanted to put out there. Chris: I could go next. I would say the first thing is what Jess said. We have to treat the whole person. I think it's great when a client's Y-BOCS score has gone down and symptomology is not a daily impact. However, all the things that we talked about, we aren't unicorns. This is what many of our clients are going through and there has to be space for the therapist to validate, to address, and to help heal. I would say the biggest thing that I believe moves you past where we've been talking about is re-identity formation. We just don't recognize until you get better how nearly every single decision we make is based off of our OCD fears, that some way or another, what we listen to, how we speak, what direction we drive, what we buy. I mean, everything we do is, will the OCD be okay with this? Will this harm me, et cetera?  One of the things I do with all my clients before I complete treatment is I start to help them figure out who they are. I say, “Let's knock everything we know. What are the parts of yourself that you organically feel are you and you love? Let's flourish those. Let's water those. Let's help those grow. What are some other things that you would be doing if OCD hadn't completely ransacked your life? Do you spend time with family? Are you somebody that wants to give back to communities? What things do you like to do when you're alone?” I help clients and it was something I did after my own treatment, like re-fall in love and be impressed with yourself and start to rebuild. I tell clients, one of the things that helped me flip it and I try to do it with them is instead of looking at it like, “This is hard, this is tough,” look at it as an opportunity. We get to take that pause, reconnect with ourselves and start to go in a direction that is absolutely going to move as far away from the OCD selves as possible, but also to go to the direction of who we are. Obviously, for me, becoming a therapist and advocate is what's helped me heal, and not everybody will go that route. But when they're five months, six months, a year after the hard part of their treatment and they're doing the things they always picture they could do and reconnecting with the people that they love, I start to see their light grow again and the OCD starts to fade. That's really the goal.  Alegra: I think something that I'll add—again, I don't want to be the controversial one, but maybe I will be—is there might be, yes. Can I get canceled after this in the community? There might be some kind of trauma work that somebody might need to do after OCD treatment, after symptoms are managed, and this is where we need to find nuance. Obviously, treatments like EMDR are not evidence-based for OCD, but if somebody has been really traumatized by OCD, maybe there is some kind of somatic experience, some kind of EMDR, or some kind of whatever it might be to really help work on that emotional impact that might still be affecting the person. It's important of course to find a therapist who understands OCD, who isn't reassuring you and you're falling back into your symptoms. But I have had clients successfully go through trauma therapy for the emotional impact OCD had and said it was tremendously helpful. That might be something to consider as well. If you do all the behavioral work and you still feel like, “I am really in the trenches emotionally,” we might need to add something else in. Chris: I actually don't think that's controversial, Alegra. I think that what you're speaking-- Alegra: I don't either, but a lot of clinicians do. Jessica: No, I agree. I think a lot of people will, and it's been a part of my recovery. I don't talk about a lot for that very reason. But after I was done with treatment, I didn't feel like I needed an OCD therapist anymore. I was doing extremely well, but all the emotions we'd been talking about, I was still experiencing. I found a clinician nearby because I was going on a four-hour round trip for treatment. I just couldn't go back to my therapist because of that. She actually worked with a lot of people that lost their lifestyle because of gambling. I went to her and I said, “What really spoke to me is how you help people rebuild their lives. I don't need to talk about OCD. If I need to, I'll go back to my old therapist. I need to figure out how to rebuild my life.” That's really what she did. She helped me work through a lot of the trauma with my dad and even got my dad to come to a session and work through that. We worked through living in the closet for my sexual orientation for so long and how hard coming out was because I came out while I was in the midst of OCD. It was a pretty horrible coming out experience. She helped me really work through that, work through the time lost and feeling behind my peers and I felt like a whole person leaving. I decided, as a clinician, I have to do that for my clients. I can't let my clients leave like I felt I left. It was no foul to my therapist. We just didn't talk about these other things.  Now what I'll say as a clinician is, if I'm working with a client and I feel like I could be the one to help them, I'll keep them with me. I also know my limitations. Like Alegra was saying, if they had the OCD went down so other traumas came to surface and they've dealt with molestation or something like that, I know my limitations, but what I will make sure to do is refer to a clinician that I think can help them because once again, I think treating the whole client is so important.  Kim: Yeah. There's two things I'll bring up in addition because I agree with everything you're saying. I don't think it's controversial. In fact, I often will say to my staff who see a lot of my clients, we want to either be doing, like Jessica said, some of the processing as we go or really offer after ERPs. “Do you need more support in this process of going back to the person you want?” That's a second level of treatment that I think can be super beautiful. As you're going too with exposures and so forth, you're asking yourself those questions like, what do I value? Take away OCD, what would I do? A lot of times, people are like, “I have no idea. I have really no idea,” like Chris then. I think that you can do it during treatment. You can also do it after, whichever feels best for you and your clinician.  The other thing that I find shows up for my patients the most is they'll bring up the shame and the guilt, or they'll bring up the anger, they'll bring up the grief. And then there's this heavy layer of some judgment for having it. There's this heavy layer as if they don't deserve to have these emotions. Probably, the thing I say the most is, “It makes complete sense that you feel that way.” I think that we have to remember that. That every emotion that is so strong and almost dysregulating, it makes complete sense that you feel that way given what you're going through.  I would just additionally say, be super compassionate and non-judgmental for these emotional waves that you're going to have to ride. I mean, think about the grief. This is the other thing. We don't go in and then process the grief and then often you're running. It's a wave. It's a process. It's a journey. It's going to keep coming and going. I think it's this readjustment on our thinking, like this is the life goal, the long-term practice now. It's not a one-and-done. Do you guys have thoughts? Jessica: I think as clinicians, validating that these are absolutely normal experiences and you deserve to be feeling this way is important because I think that sometimes, I don't think there's ill intent, but clinicians might gaslight their clients in a certain way by saying, “This isn't traumatic. This is not trauma. You can feel sad, but it is absolutely not a trauma,” and not validating that for a person can be really painful. I think as clinicians, we need to be open to the emotional impact that OCD has on a person and validate that so we're not sitting there saying, “Sorry, you can't use that word. This is not your experience. You can be sad, you can be whatever, but it's not trauma,” because I have seen that happen. Kim: Or a clinician saying, “It's not grief because no one died.” Jessica: Yeah. It was just hard. That was it. Get over it.  Kim: Or look at how far you've come. Even that, it's a positive thing to say. It's a positive thing to say, but I think what we're all saying is, very much, it makes complete sense. What were you going to say, Jessica? Sorry. Jessica: No. I just wanted to point out this one nuance that I see come up and that I think is important to catch, which is that sometimes there can be grief or shame or all these emotions that we're talking about, but sometimes those emotions can also become the compulsion themselves at times. Shala Nicely has a really, really good article about this, about how depression itself can become a compulsion, or I've seen clients engage in what I refer to as stewing in guilt or excessive guilt or self-punishment. What we want to differentiate is, punishing yourself by stewing in guilt is actually providing some form of covert reassurance about the obsessions. Sometimes we need to process the true emotional experiences that are happening as a result of OCD, but we also want to make sure that we're on the lookout for self-punishment compulsions and things like that that can mask, or I don't know. That can come out in response to those feelings, but ultimately are feeding the OCD still. I just wanted to point out that nuance, that if someone feels like, “I'm doing all this processing of my feelings with my therapist, but I'm not getting any better or I'm actually feeling worse,” we want to look at, is there a sneaky compulsion happening there?  Chris: I was just going to quickly add two things. One, I think what you were saying, Kim, with your clients, I see all the time. “I shouldn't feel this way. It's not okay for me to feel this way. There's people out there that are going through bigger traumas.” For some reason, I feel society gives a hierarchy of like, “Oh, if you're going through this you can grieve for this much, but we're going to grief police you if you're going through this. That's much down here.” So, my clients will feel guilty. My brother lost an arm when he was younger. How dare I feel bad about the time lost with OCD? I always tell my clients, there's no such thing as grief police and your experience is yours. We don't need to compare or contrast it to others because society already does that. And then second, I'm going to throw in a little plug for Kim. I feel as a clinician, it's my responsibility to keep absorbing things that I think will help my client. Your book that really talks about the self-compassion component, I read that from cover to cover. One thing that I've used when we're dealing with this with my clients is saying like, “We got to change our internal voice. Your internal voice has been one that's been frightened, small, scared, angry for so long. We got to change that internal voice to one that roots for you that has you get up each day and tackle the day.” If a client is sitting there saying that they shouldn't feel okay, I always ask them, “What kind of voice would you use to your younger brother or sister that you feel protective about? Would you knock down their experience? No, you would hold that space for them. What if we did that for you? It may feel odd, but this is something that I feel you need at this time.” Typically, when they start using a more self-compassionate tone, they start to feel like they're healing. So, that's something that we got to make sure they're doing as well. OCD AND DEPRESSION Kim: Yeah. Thank you for saying that. One thing we haven't touched on, and I will just quickly bring it up too, is I think secondary depression is a normal part of having OCD as well and is a part of the emotional toll. Sometimes either that depression can impact your ability to recover, or once you've gone through treatment, you're still not hopeful about the future. You're still feeling hopeless and helpless about the way the world is and the way that your brain functions in certain stresses. I would say if that is the case, also don't be afraid to bring up to your clinician. Like, I actually am concerned. I might have some depression if they haven't picked up on it. Because as clinicians, we know there's an emotional toll, we forget to assess for depression. That's something else just to consider. Chris: Yeah. I'm a stats nerd and I think it's 68% of the DSM, people with OCD have a depressive disorder, and 76% have an anxiety disorder. I always wonder, how can you have OCD and not be depressed? I was extremely depressed when my OCD was going on, and I think it's because of how it ravishes your life and takes you away from the things you care about the most. And then the things that would make you happy to get you out of the depression, obviously, you can't do. I will say the nice thing is, typically, what I see, whether it's through medication or not medication, but the treatment itself—what I see is that as people get better from OCD, if their depression did come from having OCD, a lot of it lifts, especially as they start to re-engage in life. Kim: All right. I'm looking at the time and I am loving everything you say. I'd love if you could each go around, tell us where we can hear more about you. If there's any final word that you want to say, I'm more than happy for you to take the mic. Jessica? Jessica: I'll start. I think I said in the introduction, but I have a private practice in Los Angeles. It's called Mindful CBT California. My website is MindfulCBTCalifornia.com. You can find some blogs and a contact page for me there. I hope to see a lot of you at the IOCDF conference this year. I love attending those, so I'll be there. That's it for me. Kim: Chris? Alegra: Like I said, if you're in the Southern California area, make sure to check out OCD SoCal. I am on the board of that or the International OCD Foundation, I'm on the board. I'm always connected at events through that. You can find me on my social media, which is just my name, @ChrisTrondsen. I currently work at the Gateway Institute in Orange County, California, so you can definitely find me there. My email is just my name, ChrisTrondsen@GatewayOCD.com. I would say the final thought that I want to leave, first and foremost, is just what I hope you got from this podcast is that all those other mixed bags of emotions that you're experiencing are normal. We just want to normalize that for you, and make sure as you're going through your recovery journey that you and your clinician address them, because I feel much more like a whole person because I was able to address those. You're not alone. Hopefully, you got from that you're not alone. Kim: Alegra? Alegra: You can find me @obsessivelyeverafter on Instagram. I also have a website, AlegraKastens.com, where you can find my contact info. You can find my Ask Alegra workshop series that I do once a month. I also just started a podcast called Sad Girls Who Read, so you can find me there with my co-host Erin Kommor, who also has OCD. My final words would probably be, I know we talked about a lot of really dark stuff today and how painful OCD can be, but it absolutely can get so much better. I would say that I am 95% better than I was when I first started suffering. It's brilliant and it's beautiful, and I never thought that would be the case. Yes, you'll hear from me in July, Kim, but other than that, I feel like I do have a very-- Kim's like, “Oh, will I?” Kim: I've scheduled you in. Alegra: She's like, “I have seven months to prep for this.” But other than that, I would say that my life is like, I never would've dreamed that I could be here, so it is really possible. Kim: Yeah. Chris: Amen. Of that. Kim: Yeah. Thank you all so much. This has been so meaningful for me to have you guys on. I'm really grateful for your time and your advocacy. Thank you. Chris: Thanks, Kim. Thanks for having us.  Alegra: Thanks, Kim.

In this show, Brandon and I discuss what it really means to be customer-centric in how we're delivering service, in particular to commercial clients. Do you feel like you're running a customer-centric business? What happens when a client wants you to deviate from your process or standards? Is there room in your process for that? Do you take time to be curious about why the customer is making certain requests or demands? It's easy for us to get so married to our internal process and so religious about our convictions when it comes to IICRC standards, that we fail to honor the relationship with our client. What they need and/or want, may require us to adapt or modify our process. It's possible to do that, while still maintaining our integrity as a team and produce the margins we need to remain healthy as a business. Check out the convo and let us know what you think- Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

Hear about Brandon's near-brawl in the Denver airport on a recent trip. And join us for a conversation about leading change, why people's "story in their head" makes it hard, and what behaviors leaders can commit to in order to more effectively lead change within their business. There are specific strategies that make change less painful/scary for our people. Join in and let us know what you think- Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

Thanks for your patience!  Winter is tough. ______________________________________________ This episode includes graphic violence, archiac psychiatric attitudes and terminology, gaslighting, and misogyny.  It was written intentionally to emulate the style of Italian "GIALLO" thriller films of the 1970s and 80s. ______________________________________________ Hot chicks in peril, black leather-gloved killer, faces through plate glass, badly-dubbed voices, and lots and lots of the red stuff! Written and produced by Julie Hoverson Cast List Dr. Silver - Anthony D.P. Mann Jessica - Julie Hoverson Adrienne - Robyn Keyes Dana - Kate Waterous Chris - Tanja Milojevic Inspector Gules - Glen Hallstrom Manager - Dru Williams Voice on Phone - Lord Blood-Rah Cop1 - Desmond Reddick (Dread Media) Cop2 - Miguel Guerreiro (FearShop.com) Coroner - Jack Kincaid (Edict Zero) Detective - Caretaker (Graveyard Show) Music:  Professor Kliq Editing and Sound:   Julie Hoverson Cover: Brett Coulstock "What kind of a place is it?  Why it's a psychiatrist's office, can't you tell?" ________________________________________   WHEN YELLOW CASTS A CRIMSON SHADOW Cast: [Opening credits - Olivia] Jessica Dr. Silver Dana Adrienne Chris Detective Gules Manager Voice Cop1 Cop2 Detective Coroner OLIVIA      Did you have any trouble finding it?  What do you mean, what kind of a place is it?  Why, it's a psychiatrist's office, can't you tell?  MUSIC SOUND      LOW MUSIC PLAYS SOUND     DOOR OPENS JESSICA     Dr. Silver? SILVER Ah, you must be Jessica. Come in!  Come in.  Your father has spoken of you often. JESSICA     Mm.  He told me to come to you if I.... needed anything. SILVER Come in! Sit down!  I can't tactfully say I am pleased to see you, but I can heartily say I am most happy to make your acquaintance. JESSICA     Oh.  Yeah.  Thanks. SOUND     DOOR SHUTS QUIETLY, SHE CROSSES ROOM AND SITS SILVER There. Now tell me what I can do for you. JESSICA     Since I moved to Florence, I've - I've been doing really well.  Sleeping.  Even without the drugs. SILVER You haven't been taking your prescriptions? JESSICA     My doctor back home said I could cut back some - once I started feeling better. SILVER Your doctor--? JESSICA     Dr. Gelb.  Joan Gelb? SILVER Ah, yes, I am familiar with some of her work. Go on. JESSICA     Go... on? SILVER You had a reason for coming to me, didn't you? JESSICA     Oh!  Yes.  [very down] The dreams. SILVER [after a beat] Yes? JESSICA     Well, I came here to attend university.  And be closer to my father. SILVER He is not in the United States? JESSICA     No.  He's on diplomatic attachment in the Netherlands - [amused] but I don't understand any Dutch. SILVER [chuckles] JESSICA     So I found a room with three other girls from the college.  They're all models.  To pay for their classes.  Well, except Dana - she just models for fun...  Sorry.  That's probably not important.  SILVER Don't let it worry you. Go at your own pace. JESSICA     Can I have a piece of paper? SILVER You want to take notes? [teasing]  That's really my job. JESSICA     No, no!  It helps me concentrate.  Please? SOUND     PAPER RIPPED FROM NOTEBOOK, PASSED OVER JESSICA     Thank you. SOUND     PAPER FOLDED, TORN - UNDER THROUGHOUT JESSICA     So, Dana, Chris, and Adrienne - are all gorgeous.  I'm the mouse.  [heavy sigh] Don't get me wrong - they're all very nice. SILVER But you are a bit jealous? JESSICA     They've all got legs all the way up to their shoulders! SILVER [musing] A woman with legs up to her shoulders might be missing a heart. JESSICA     [startled, laughs, relaxes a bit]  I like that.  But, they're nice - really nice. SILVER You're lucky. Good friends are hard to find. JESSICA     Yes... [trails off, sighs, then absently]  The dream. SILVER Whenever you're ready. JESSICA     You're going to think I'm horrible! SILVER Nonsense. Dreams are primarily symbolic, and everyone dreams about things they are embarrassed by.  I promise not to judge you. JESSICA     [gulps, long breath] In the dream, I come home.  Our apartment is on the top floor, so I walk up and up the endless stairs.  It's the type that goes round and round an open space.  [her voice slowly picks up an echo, as if in a stairwell] You know, where you can look all the way down to the ground floor - as long as you don't have to worry about vertigo? SOUND [under]      FOOTSTEPS ECHOING UP THE STAIRWELL SILVER Mm. JESSICA     And the door was ... open. JESSICA [under] Hello? JESSICA     I pushed it the rest of the way, and went in.  And everything was red.  Red on the walls.  I couldn't understand.  All I could think was - did we repaint? SILVER Yes? JESSICA     And then I looked up and saw the light fixture.  It was red too.  Red and dripping.  [slowly] Slowly dripping. SILVER [after a pause] Is that when you woke? JESSICA     [hollow, numb] No.  [coming back]  Can I have another piece of paper?  I'll trade you. SILVER A crane? Very nice. JESSICA     It was... part of my therapy. SOUND     PAPER RIPS, PASSED OVER, MORE FOLDING BEGINS SILVER Still... very nice. JESSICA     Thanks.  [deep breath]  I went into the next room.  [half a chuckle]  Out of the foyer into the frying pan.  [lame laugh]  You must think I'm awful, to be able to joke at a time like this! SILVER No. Humor is a very common way to deal with painful circumstances.  Don't concern yourself with what I think. JESSICA     Adrienne was in the sitting room.  [trying not to choke up]  Dead.  She was - all cut up, and the mirror next to the kitchen door was smashed and bloody.  I could see my reflection in the shards ....sticking ...out of her ...eyes. JESSICA [tinny] [screams] SILVER [after a short moment] Was that where the dream ended? JESSICA     [trying to be chipper]  Yes.  Just that.  Just... seeing her dead. SILVER I'd... like to venture an interpretation of this dream that might help you... come to terms with it. JESSICA     Yes? SILVER It's a manifestation of a deep-seated jealousy. JESSICA     I'm not jealous! SILVER It's normal - don't worry. She's a beautiful model and you want to see yourself in her eyes as she appears to yours.  JESSICA     [brightening] Really?  But it was so bloody. SILVER Symbolism again. Red is the color of jealousy and passion.  Nothing more. MUSIC SOUND     HER FOOTSTEPS ECHO UP ENDLESS STAIRWAY SOUND     HEAVY FOOTSTEPS BELOW SOUND     HER FOOTSTEPS STOP SOUND     A COUPLE OF HEAVY FOOTSTEPS, APPROACHING SOUND     HER FOOTSTEPS, RUNNING UP THE STAIRS SOUND     SHE PAUSES AGAIN JESSICA     [heavy breathing, trying to be quiet and listen] SOUND     NO FOOTSTEPS SOUND     THUMPING SOUNDS APPROACH - SETS OF FOUR SOUND     TURNS OUT TO BE A BALL COMING DOWN THE STAIRS SOUND     SHE CATCHES THE BALL JESSICA     [sigh, chuckle] CHILD     [strangely bland] My ball! JESSICA     [gasp, almost a scream]  Oh!  [more normal] I've got it. SOUND     HER STEPS BEGIN AGAIN MUSIC SOUND     DOOR OPENS DANA     [lecturing] I only eat chocolate off a man. JESSICA     [gasp] CHRIS     Ha!  What a line to come in on!  Dana was just explaining her perfect diet plan. ADRIENNE     It makes perfect sense - work up a sweat, then have all the chocolate you want! JESSICA     You girls. DANA     Don't tell me you wouldn't, if you had a chance? JESSICA     Well... CHRIS     Maybe she doesn't like chocolate! ADRIENNE     Maybe she doesn't like men. JESSICA     I like chocolate!  My father sent me some cocoa - the good Dutch kind. DANA     I'm surprised you like men any more, Adrienne, after all that bastard Alberto put you through. ADRIENNE     Don't get me started.  [beat]  You should really be allowed to shoot men when you're through with them.  CHRIS     I'd have a trail of bodies stretching to the sunset. JESSICA     Are there any more of those apples? DANA     Catch! SOUND      CATCHING AN APPLE CHRIS     What would we do when we run out of men? ADRIENNE     [bitter, haunted] Not all men, just the ones who want to track you down and torment you. DANA     He didn't! CHRIS     Again? JESSICA     [bites into apple, then chewing]  What? DANA      You should tell her. ADRIENNE     It makes me sound like such a victim. DANA     Why do you think she never does bikini shots? CHRIS     She's moved three times in the past year - but he always finds her. DANA     She's got the scars to prove it. MUSIC SOUND     SOFT MUSIC PLAYS SOUND     DOOR SLAMS OPEN, HURRIED FEET ENTER JESSICA     It  happened again! SILVER Calm down, Jessica. JESSICA     I'm - I'm so sorry to burst in here like this-- SILVER Sit down. JESSICA     But I - I can't concentrate on anything today-- SOUND     PAPER RIPPING FROM NOTEBOOK SILVER Here. Now sit. SOUND     SHE SNATCHES THE PAPER, FLAPS IT JESSICA     Thank you.  Are you sure it's ok? SILVER I've got plenty of paper. JESSICA     [chuckles] No, I mean-- [sighs] Thank you. SOUND     SHE SITS, BEGINS FOLDING JESSICA     I feel like such a fool. SILVER It obviously upset you. Sharing will make you feel better.  You had another dream? JESSICA     No!  That's the weird part - it was the same dream! SILVER The same? JESSICA     Well, it started the same.  Going up the stairs, and the blood on the light, and ... [almost a whisper] Adrienne. SILVER And...? JESSICA     It was all the same - except the ending.  SILVER How did it end, then? JESSICA     It didn't.  I mean - it went on, from where I woke up before.  SILVER Hmm. JESSICA     I was staring at myself in the mirror shards - but then I realized it wasn't me.  Not Jessica.  Not this time - that was different.  SILVER Who was in the reflection? JESSICA     I think it was.... the killer! [NOTE - now the voices in the consulting room are tinny, as the scene plays out underneath] SOUND     [repeat of Jessica's scream from the first dream, which trails off into a weird noise of breathing] SOUND     FOOTSTEPS WALK SLOWLY THROUGH SQUISHY BLOODY PUDDLE SILVER Be as specific as you want. You won't shock me.  You can give me every detail. JESSICA      I can smell the blood.  It's everywhere.  SILVER It's quite a distinctive smell. JESSICA      Yes. SOUND     DOOR PUSHED SLOWLY OPEN, FOOTSTEPS MOVE INTO DRY SPACE SOUND     SQUEAK AS KNIFE IS CLEANED OFF - LEATHER AGAINST METAL SOUND     FOUR TAPS OF KNIFE AGAINST WOOD JESSICA      It was Dana's room.  And she was sleeping. SILVER So this was nighttime? JESSICA      [slightly confused] I don't know.  Dana sleeps late.  SILVER Jessica - in the dream, are you Jessica, or are you the killer? JESSICA      I - I'm not sure.  I'm not... thinking in the dream, just seeing and feeling... and smelling.  I can't see a face - even in the mirrors - I just knew it was the killer looking back at me, but I couldn't tell you what he...I...looked like. SILVER [too interested] What are you wearing? JESSICA      Boots.  Black.  Leather gloves.  I move toward Dana's bed... SOUND     CREAK OF THE LEATHER GLOVES SILVER Do you stab her too? JESSICA      [offhand] Oh, Adrienne wasn't stabbed - at least... that wasn't how she died.  She was strangled.  SOUND     CREAK OF LEATHER DANA     [gasps, awakens, tries to breathe] SOUND     CLAWING AT LEATHER, SHAKING OF BED, POUNDING SILVER And then she died? JESSICA      Oh, no.  That would be too quick.  I let up just in time - she's out. SILVER [licks his lips] Do you tie her up? JESSICA      Yes.  I tie her to the bed frame.  Up and down. SILVER What is she wearing? JESSICA      A scarlet negligee.  She got it after one of her modeling shoots - the picture is on the wall over the bed.  Huge.  Her.  Posed in red.  Enticing. SOUND     [tinny] CRUMPLE OF PAPER SILVER And then...? JESSICA      [coming out of it]  I-I- can I have another piece of paper? SILVER [breathing a bit heavily, trying to calm down] Of course. SOUND     PAPER TORN RATHER CLUMSILY OUT OF NOTEBOOK - RIPS IN HALF SILVER Damn. What will you make? SOUND     TEARS ANOTHER PIECE, SHE SNATCHES IT AWAY FROM HIM, BEGINS FOLDING JESSICA      A box.  I feel like I'm in a box. SILVER Perhaps you should make something more... open. Something you can get out of. JESSICA      Maybe next time. SILVER All right. Was there more to the dream? JESSICA      A little.  After Dana woke up.  SILVER [trying to hide his excitement] What happened? JESSICA      [evasive] I just... killed her. MUSIC ESCALATES SOUND     STABBING - SETS OF FOUR DANA     [Screaming, begging, gurgling] SOUND     SPLATTER DANA     [gurgling] SOUND     A COUPLE MORE KNIFE STABS DANA     [death rattle] SOUND     DRIPPING SOUND     WIPING KNIFE WITH GLOVES AGAIN MUSIC SOUND     FOOTSTEPS IN STAIRWELL, STOP FOR A SECOND SOUND     FAR AWAY, DOOR OPENS JESSICA     [sigh] SOUND     TWO STEPS SOUND     DOOR NEARBY SLAMS OPEN SOUND     FEROCIOUS DOG!!!!! JESSICA     [screams, then smothers it] SOUND     SCRABBLING OF DOG NAILS ON TILE FLOOR JESSICA     Mrs. Amarelo!  Mrs. Amarelo!  Please! MUSIC SOUND     TEAPOT WHISTLING, TAKEN OFF, WATER POURS JESSICA     [talking loudly to someone in another room] She really needs to keep that dog on a shorter leash.  She's lucky I didn't jump back and fall down the stairs. SOUND     DOOR OPENS, SLIPPERED FEET IN DANA     [half awake]  Mm.  Coffee? JESSICA     [silly!] Cocoa.  [gasp] Oh! DANA     You don't like it?  It's imported French lace. JESSICA     I'm just not used to-- DANA     And red is such a good color on me. ADRIENNE     [calling from the other room] --she's just shy. SOUND     FOOTSTEPS COME IN ADRIENNE     [close] Haven't you ever wondered, Jessica? JESSICA     [disturbed]  Wondered... what? SOUND     A COUPLE OF STEPS DANA     Mmm? ADRIENNE     What it would be like with a woman? JESSICA     [disturbed] Um - no.  Uh, I don't even know anyone who does-- ADRIENNE     Anyone who you KNOW does, anyway. JESSICA     Um... I guess. SOUND     DOOR SLAMS OPEN CHRIS     [freaking out, out of breath] Oh, god!  SOUND     DOOR SLAMS SHUT, BODY THUMPS AGAINST IT ADRIENNE     What's wrong?  Sit down! SOUND     DOOR LOCKS JESSICA     Cocoa? CHRIS     Thanks!  [sips, then shudders in a breath] ADRIENNE     What happened? CHRIS     [gasping it out] On the street.  A gun! It was so loud!  DANA     Someone was shot?  I'm phoning the police. ADRIENNE     Give her a minute!  She's nearly hysterical! CHRIS     No!  No!  Call them!  The sooner I tell, the sooner he'll be caught! JESSICA     Did you see the guy? CHRIS     Uh-huh! [yes] MUSIC SOUND     LOW MUSIC PLAYS SOUND     PAPER FOLDING JESSICA     I have this awful feeling-- SILVER Yes? JESSICA     That this is all... some kind of premonition. SILVER You think you're seeing something that might happen in the future? JESSICA     It would make so much sense. SILVER Is there anything in the dream that makes you think it will happen? JESSICA     Like what? SILVER Something with the date? A newspaper, perhaps? JESSICA     [concentrating]  Mmm, no.  None of us really reads the papers.  Magazines, yes, but they don't come out that often.  [beat] And they all kind of look the same. SILVER Have you ever had a dream - any dream - come true in the past? JESSICA     What?  [half a chuckle] No! SILVER Then I think you are safe. [teasing, fatherly] But make sure to lock your door. JESSICA     [laughs a bit] SILVER [getting back on track] So. The dream came back.  Again. JESSICA     [quiet, sad] Yes. SILVER And it was--? JESSICA     Longer. SILVER [avid] So once again, you saw your first two friends strangled and tortured and-- [swallows] mutilated. JESSICA     Yes.  SILVER And then? What about your third friend - what was her name? JESSICA     Chris.  [numb]  Chris was in the hall.  She must have heard the commotion with Dana.  I... feel like the killer was - ummmm - surprised.  Like he didn't expect her to be there. SILVER Why do you say that? JESSICA     I don't know.  Just that he - I - had to chase her down. SILVER Be specific. JESSICA     I came out of Dana's bedroom-- [office voices go tinny] SOUND     SQUISHING FOOTSTEPS, WIPE FEET AND STEP ONTO TILE SOUND     DOOR OPENS CHRIS     Dana?  What?  Oh, god!  [screams] JESSICA     I hesitate, stunned.  Just long enough for her to run back into her room. SOUND     DOOR SLAMS SOUND     HEAVY FEET RUN, SLAM INTO DOOR CHRIS     [muffled] No!  No! SOUND     SLAM INTO DOOR, WOOD CREAKS AND CRACKS JESSICA     There's such a - a rush as the door gives way. SILVER Where is Chris? JESSICA     She's pressed again the window, outlined in light from the pink and red neon across the street. SILVER Ahhhh. What is she wearing? JESSICA     Silk.  A blue slip-- SILVER Blue? Are you sure? JESSICA     Yes.  Why? SILVER The neon light - it might be deceptive. JESSICA     I saw it in the hall. SILVER Ahhh. What color is her hair?  JESSICA     Chris?  She has long straight blonde hair.  SILVER And very pretty. JESSICA     Yes. SILVER Mmmmm. SOUND     WINDOW SLAMS OPEN JESSICA     I raise the knife and she screams again, trying to climb out the window. SILVER Can she? JESSICA     We're six stories up.  That's why there's all those stairs. SILVER Do you... cut her? JESSICA     Better.  I set the knife aside again-- SOUND     LEATHER ON METAL JESSICA      --and take her by the throat.  The black leather of the gloves looks strange in the neon pink glow - especially against her pale white throat. SILVER Does she struggle? JESSICA     Like a fiend.  She strikes and kicks, but it is all in vain.  [coming out of it] The killer must be a man. SILVER [startled out] Um? Of course--  Um, [swallows, clears throat] The um - the killer in the dream. JESSICA     That's what I meant. SILVER Right. More paper? SOUND     RIPS PAPER OUT OF NOTEBOOK JESSICA     Thanks. SOUND     TAKES IT, STARTS FOLDING SILVER You've made me quite a little collection here. What's this one? JESSICA     A knife.  SILVER [amused] A paper knife. And this? JESSICA     A shrew. SILVER No more cranes? JESSICA     Cranes are peaceful.  I haven't been feeling very... peaceful. SILVER Do you want to continue? JESSICA     Don't you have another appointment? SILVER No. Your case is fascinating, so I cleared some extra time for you. JESSICA     Oh.  All right. SILVER At least follow the dream to the conclusion. JESSICA     Where was I? SILVER [too quick] You were strangling Chris. SOUND     STRANGLING NOISES UP AGAIN SOUND     HAND POUNDING AGAINST GLASS [voices go tinny again] JESSICA     Right.  Then she passed out. SOUND     STRUGGLE STOPS, SQUEAK OF HAND SLIDING DOWN PANE SILVER Gooood. SOUND     ROPE PASSING THROUGH HANDS SILVER And--? JESSICA     I took the cord from the blinds and wrapped it around her neck. SILVER Strangling her? Again?  Why? JESSICA     It wasn't tied that tight. SILVER Then, what? JESSICA     Then I cut her a little.  Not deep.  Just enough to see red - just enough for the blood to flow.  Shoulders.  Thighs.  Chest.  It took a long time for her to wake up again. SILVER Did you cut her blue slip off? JESSICA     It's not blue any more.  Now it's wet and dark in strange rivulet patterns.  So is the floor. SILVER And then? JESSICA     Her eyes open - and once again I see my own reflection twice in one face.  And this time I can almost make out who I am.  If it weren't for that darn pink neon, I might be able to. SILVER Does SHE recognize you? JESSICA     [dismissively] Maybe.  She tries to scream.  But I already gagged her.  [little sigh]  She was asleep a long time. SILVER Uh-huh? JESSICA     I pull her up by her hair - her long blonde lovely hair.  The word "tresses" pops into my mind. SILVER Tresses. That's a good word. JESSICA     She squirms and tries to escape.  Her eyes plead with me.  But I don't waver.  I show her the knife and she closes her eyes.  I run the hilt of the knife over her forehead and she squeals - when really all I want to do is press her eyelids open. SILVER She can't understand that, can she? JESSICA     I just want her to see.  She was always a big one for seeing things. SILVER See what? JESSICA     The window. SILVER Is there something outside? JESSICA     Not yet. SILVER Oh? JESSICA     As soon as her eyelids flutter open, I turn her toward the window and slam her face into it, shattering the glass.  Something breaks in her, too, and I hear her muffled agony. SILVER Her nose? JESSICA     I don't know, since as soon as the glass is gone, I push her out. SILVER On the cord? JESSICA     She dances so prettily.  SILVER Do the people outside see? JESSICA     No, the music from the club with the neon is very loud, and no one ever looks up. SILVER What about the blood? JESSICA     I don't know.  I woke up. SILVER [breathing heavily, calming down] JESSICA     What do you think? SILVER We definitely have some work to do. You'll see me each afternoon for a while - can you promise me you will? JESSICA     Of course, if you think it's important. SILVER Very. And here is my home number-- SOUND     SCRIBBLING ON A CARD SILVER --In case anything else comes to mind. JESSICA     You're sure you don't mind if I call you? SILVER No. Of course not.  In fact, I insist.  I am here for you. MUSIC AMB     STREET, NOT TOO MANY PEOPLE AROUND SOUND     JESSICA'S STEPS, HURRYING SOUND     A STRANGE TAPPING NOISE - SETS OF FOUR - GETTING CLOSER SOUNDS     SHE SPEEDS UP SOUND     THE TAPPING GETS CLOSER SOUND     SHE SPEEDS UP MORE JESSICA     [gasping] SOUND     GRAB AND FLING OPEN DOOR SOUND     FEET RUN INTO BUILDING SOUND     DOOR SLAMS SHUT JESSICA     [breathing heavily]  SOUND     TAPS GO PAST OUTSIDE JESSICA     [sighs, almost laughs] MANAGER     [off slightly] Scotomaphobia? JESSICA     [gasps] SOUND     THUMP AS SHE RECOILS JESSICA     What?  Mr. Cramoisie?  You - you startled me! SOUND     CIGARETTE CRUSHED OUT MANAGER     The fear of going blind. JESSICA     Huh? Me? MANAGER     I saw you run from the white stick.  [chuckles] And I don't know a word for fear of a blind man. MUSIC SOUND     DOOR OPENS TENTATIVELY JESSICA     [clearly worried] Hello? ADRIENNE     Jess?  Is there something wrong? JESSICA     [sigh of relief]  No.  Nothing.  Glad to be home. SOUNDS     STEPS COME IN, DOOR SHUTS SOUND     REMOVING COAT, ETC. DANA     I was just putting on some tea - want some? JESSICA     No, thanks.  Save me some water, though? ADRIENNE     You and your cocoa.  Come in here - we've got company. SOUND     A FEW SLOW STEPS JESSICA     Oh?  Hello. GULES     Ah.  This must be your other roommate.  Very pleased.  Four such lovely ladies, [slightly ominous] all alone. CHRIS     This is Detective Gules.  That is Jessica.  Sit down Jessie.  JESSICA     Detective? SOUND     CHAIR CREAKS AS SHE SITS CHRIS     He's investigating - um - [whispered] what I saw yesterday. GULES     We suspect the murder she witnessed was gangster-related, and are concerned for her safety.  Your safety, too.  This isn't a very secure building.  You don't even have grilles on the windows. DANA     Pssht!  We're six floors up!  Who needs grilles!  Here, Jess.  Water-- SOUND     MUG SET DOWN DANA     And your precious cocoa. SOUND     TIN SOUND     SPOON DROPPED INTO MUG DANA     [to the room, teasing] I wouldn't dare measure it for you. JESSICA     [laughs]  That's perfect, Dana, thanks.  SOUND     MIXES UP THE COCOA GULES     I'm trying to convince Chris to let me take her into protection.  [getting darker] We want to make sure she stays where we can put our hands on her. MUSIC SOUND     PHONE PICKED UP JESSICA     Hello?  VOICE     [harsh whisper]  Four girls.  Could be three.  Or one. JESSICA     Who is this?  You're scaring me. VOICE     Will it be you? JESSICA     I'm hanging up now! SOUND     PHONE SLAMMED DOWN DANA     [worried] Jess?  Who was that? JESSICA     A heavy breather.  You know the type. DANA     I didn't even hear the phone ring. JESSICA     Oh?  Umm... I must have picked it up just as it was starting.  Who did you think it was? DANA     Oh, Michel.  My brother.  He's been asking for money again.  JESSICA     What's wrong this time? DANA     Same old shit.  Someone's going to break his legs.  Someone's going to kill his dog.  [disgusted noise]  He ran through his half of the inheritance years ago. JESSICA     And you don't feel sorry for him? DANA     I felt one hundred thousand dollars sorry for him, and that was in the first month after he flushed all his cash down one toilet and another.  Since then.  [shrug]  Not so damn sorry. MUSIC SOUND     SNORING [Dr. Silver] SOUND     PHONE RINGS SOUND     PHONE PICKED UP SILVER [not awake] mmm Hello? JESSICA     [on phone, hysterical] Doctor?  Please?  Something terrible has happened! SILVER [snapping awake, but still groggy] Jessica? Wha-what's going on? JESSICA     [on phone] You have to come, Doctor!  I need help!  [backs off and screams] SOUND     [on phone] PHONE DROPS, THUMPS A FEW TIMES. SOUND     BED CLOTHES FLUNG OFF MUSIC SOUND     DOC'S FEET COMING UP THE STAIRS, QUICKLY SILVER [reading door numbers] 601... 602...? JESSICA     [moan]  SILVER Jessica? What has happened? JESSICA     D-doctor?  SILVER Come out here. My god - what--? JESSICA     A nosebleed.  I - I get them sometimes. SILVER With the dreams? JESSICA     Uh-huh. SILVER Why are you out here in the hall? JESSICA     I didn't want to wake anyone. SILVER They're your friends. They will surely understand.  Let's go inside.  [suave] Maybe have some of your famous cocoa? JESSICA     [small laugh]  That would be nice. SILVER Invite me in? SOUND     DOOR OPENS JESSICA     You're invited. SOUND     A COUPLE OF STEPS, A SLIGHT SQUISH SILVER [slight shock] What? MUSIC JESSICA     [sips, then] The dream was sooo bad this time. SILVER [grunt] JESSICA     Then I found these-- SOUND     SLAP OF LEATHER GLOVES JESSICA     And suddenly everything started to be so real.  But it can't be, can it? SILVER [grunt] JESSICA     I hoped I would wake up, and the gloves would be gone, but here they are. SOUND     GLOVES CREAK SILVER [agreeing grunt] JESSICA     It's really good isn't it?  Is it too hot for you? SILVER [slight overreaction negative grunt] JESSICA     My father sent it.  From the Netherlands.  He's always somewhere else.  I mean somewhere else from where I am, anyway.  Did I tell you how my mother died? SILVER [negative] JESSICA     She committed suicide when I was 5.  I found her.  Dr. Gelb says that's why I can't sleep.  She says I can never forget my mother's dead eyes.   SILVER Hmm? JESSICA     They looked at me, but they weren't really her any more, you know? SILVER Hmm. JESSICA     [briskly] But this is all beside the point.  I'm so glad the girls are heavy sleepers.  So we can talk. SILVER Mm-hmm. JESSICA     [very important]  I finally saw myself in the dream. SILVER Mmm? JESSICA     I mean, I, in the killer's eyes, saw me - Jessica.  Do you know how frightening that could be?  The idea that I could not only watch myself be butchered, but that I would somehow be behind the eyes of the one doing it? SILVER [sigh] JESSICA     [sips]  SOUND     SETS DOWN CUP, PICKS UP PIECE OF PAPER, STARTS FOLDING JESSICA     Somehow, when I have a piece of paper in my hands, the dream fades into something that might have been on the television. SILVER Hmm. JESSICA     [beat, then] Once Chris was dead, the killer must have pulled her back in.  She was on the bed, starred with glass in the dark.  Pink stars, catching the neon. SILVER Mmm. JESSICA     I watch his black gloved hand push open my own bedroom door.  I'm lying on the bed, tossing in my sleep.  SILVER Umm. JESSICA     The knife in my - his - hand leads me to the bed.  To the woman.  To me. SILVER Umm? JESSICA     [agreeing] I know.  SOUND     [off slightly]  DOOR SLAMS OPEN JESSICA     What? COP1     [off] Oh my god! COP2     [off] [trying not to hurl] SOUND     HER SQUISHY, STICKY BARE FOOTSTEPS JESSICA     [way too calm, calling]  Chris?  Did you call for the police?  [to the police] You should have knocked. COP1     What the hell?  What... the ... hell! COP2     Is all that...blood? JESSICA     What?  Oh, the nosebleed.  Sorry, I should have changed into something fresh.  Would you like some cocoa? COP1     [calling back over his shoulder] Watch where you step! MUSIC     SOUND     GURNEY AFTER GURNEY BEING WHEELED OUT BEHIND THEM SOUND     DOG BARKING DOWN THE HALL, KEEPS GOING COP1     It's bad, sir. COP2     You might want some shoe covers. DETECTIVE     Who could have done such an awful thing? COP2     Someone crazy.  Truly out of his mind. DETECTIVE     Or her mind. COP1     Do you have any reason to suspect a woman? DETECTIVE     [shrug] I suspect everyone.  How many bodies? CORONER     Four bodies.  And one clinging to life. DETECTIVE     And the smell? CORONER     Rotting flesh.  [long sniff]  Been lying here several days, if I don't miss my guess.  MUSIC end

This is our second chat with Joey, and it's just as epic as the first. In this show, we talk through the last 4 stages of customer onboarding. Every moment of this podcast is applicable to our restoration businesses, and most of it immediately actionable. We will definitely be having Joey back- his first episode has been one of our most downloaded episodes. Check it out and share it with your friends! - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/premier-partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

Hi All, this is a special episode. Brandon started sharing some thoughts on battlefield leadership from his military experience, and I thought, "Holy cow, I have to record this. We have to make this an episode." I pretty much just stayed out of the way. Brandon spits straight fire as he talks about the responsibility and mindset of a great leader, when everything's at stake. Check it out, and you'll probably want to pass it along to a friend. Have a friend who's running teams in Florida right now? They should probably hear it too! Let us know what you think of this special episode. Shoot me an email chris@floodlightgrp.com - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

In this episode Chris and Brandon dive inside the mind of a leader. What should we be focused on each day? How should we be thinking about our people, and the work we do? What disciplines and systems do we need to create and hold people accountable to in order to provide the kind of work environment that is essential for our people to thrive? This and more on today's episode. Check it out and share it with a friend- Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

In today's show, Brandon and I break down a new book Brandon' been reading by entrepreneur Ed Mylett. Maybe some of you have followed his work. His new book is called "The Power of One More" and we unpack some of the meaning for he and I, discuss how we can apply it to leadership and business development. It's an inspiring and ambitious chat. Check it out and let us know what you think of the concept. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

In Part 1, Brandon and Chris talk through the first two agreements- Be Impeccable with Your Word & Don't Take Anything Personally- and rap about them extensively both professionally and personally. The principles touch every aspect of our life if we're consciously living them out. In Part 2, we dive into the last two agreements- Don't Make Assumptions, and Always Do Your Best. It's another deep dive on a theme that is very important to Brandon and I- as leaders, we must first master leading ourselves before we can maximize our effectiveness leading others. Check out these agreements and let us know how it provokes or inspires you. Shoot us an email or a DM on LinkedIn! - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

Quiet quitting is a topic that's been all over business news headlines and people's LinkedIn feeds lately. In this episode, Chris and Brandon take the subject on and give their perspective on how it's showing up in the restoration industry, and what we can do to address it as leaders. Check out the show and let us know what you think-Shoot us a DM on LinkedIn. - Chris Thanks for listening! If you enjoy the podcast please be sure to leave a review, follow the show (don't forget to turn on your notifications!) and share with a friend. Your continued support is what makes this mission possible. Thank you partners! We love our listeners and want them to have access to the very best in tech and supporting service providers possible. We've vetted each of our partners and highly recommend all them as key assets to help ensure our listener's success. As a way to honor our listeners, each of them has provided competitive DISCOUNTS. Simply click on the link below and take advantage of our ongoing partnerships. https://www.floodlightgrp.com/partners Floodlight Consulting Group Equipping restoration business owners to establish processes, develop their teams, increase revenues and grow their profits. Floodlight Leadership Circles The Floodlight Leadership Circles are designed to empower restoration business owners and key leaders through education, training, coaching and community engagement. Monthly Sessions Open Office Hours Expanding Partnerships Of Industry Professionals Customer Segment Leaders Continually-Updated Content Library Rich Non-Market Competing Community https://www.floodlightgrp.com/leadershipcircles Individualized Operations Consulting and Training The Floodlight team provides customized consulting and training support for restoration companies looking to grow and scale their business. 100% Tailored to each client Formal consulting sessions for owners and key leaders Full one-on-one access to the Floodlight team and their network of industry experts https://www.floodlightgrp.com

It's Steph and Chris' last show. Steph found a game, and if you've been following the journey, all of the Test::Unit test files are now live in RSpec. JWTs really grind Chris' gears. They wrap up with things they've learned, takeaways they've had, and their proudest podcasting moments. They also thank all the folks who've helped make The Bike Shed happen. 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. Microservices (https://www.youtube.com/watch?v=y8OnoxKotPQ) Transcript: CHRIS: One more round of golden roads, our golden. So here we go. STEPH: Oh, one more round of golden roads. Okay, maybe that's going to get to me today. [laughs] CHRIS: [singing] Golden roads take me home to the place. STEPH: [singing] I belong. CHRIS: Yeah, there you 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 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, at least one more time. So with that [chuckles] as an intro, Steph, what would you say is new in your world? STEPH: Hey, Chris. Well, today is the big day. It is the day that you and I are recording our final Bike Shed episode, which we have all the feels about, and we will definitely dive into. But to ignore some of that for now, I have another small fun update I can provide about a new game that I found. So one of the things that's new in my world is I started playing a new board game with Tim; it's called Ticket to Ride. Have you heard of that? CHRIS: I have. I don't know if I've played it. I feel like it's a particularly popular one now. But I don't know if I've ever had the pleasure. STEPH: It's a very cute game, so we have the smaller version of it. For anyone that's not familiar, it's essentially a map. And then there's a bunch of spots where you can build trains and connect them, and then you get tickets. So your goal is that you're going to connect one location to another location. And then you get points and yada yada, but it's so much fun and especially the two-player version. It's like this perfect 20, maybe 30-minute game. I'll be honest; I'm not really a board game person. I always enjoy it. Once I get into it, then I'm like, this is great. I don't know why I was resistant to this. But every time someone's like, "Do you want to play a board game?" I'm like, "Not really." [laughs] I first have to get into it. But I have really enjoyed Ticket to Ride. That's been a really fun game to play. And it's been a nice way to, like, even during the day, we'll break for lunch and squeeze in a game. CHRIS: Well, I love good two-player games. They're hard to find. But when you find a good one, and it's got that easy pickup and play...I believe I'm going to now purchase this. And thank you for the tip. STEPH: Yeah, this is definitely one of those where it's easy to pick up, and then you can get the expanded board. So there's a two-player version, but then yeah, you can get one that's a map of the U.S. or a map of Europe. And I think it accommodates up to five players as the maximum, so not a huge group but definitely more than two. On a slightly more technical note, I have something that I'm very excited to share. It is a journey that you have been on with me, that everybody listening has been on this journey with me. And I'm very excited. I see you nodding your head, so I'm guessing that you're going to know where I'm headed with this. But I'm very excited to announce that all of the Test::Unit test files now live in RSpec. So that is a big win. I'm very, very excited for that to be a previous state of life and not an ongoing state of life. Because I have certainly developed too much niche knowledge around migrating these tests, and that became apparent to me when I was pairing with another developer that works with the client because they had offered...they had some time. They're like, "Hey, do you want help migrating a test file?" And I was like, "Sure." I was like, "But this is wonky enough, like, we should pair and work on this together because I just know some ins and outs. And I don't want you to have to learn a lot of the hard lessons that I've learned." And the test that we happened to pick up was very gnarly. It had a lot of mystery guests. And we spent, I think it was a good two hours. And we only migrated one of the tests, so not even a full file but one of the tests. And at the end of it, I was like, I know way too much about some of the oddities and quirkiness of this. And we got through it, but we decided that wasn't a good use of their time for them to go at this alone. So that's why I'm extra excited and relieved because I didn't want this task to carry on to someone else. So, hooray, we did it. CHRIS: Hooray. Just in time. You're Indiana Jones grabbing your hat right as you roll out and off to [laughs] be away from the project for a bit. So you stuck the landing. Well done, Steph. STEPH: Thank you. Thank you. So that's some great news. And then also, everything else in life is pretty much focused around getting ready for maternity leave. That's about to happen soon, and I am so ready. I have thoroughly enjoyed a lot of the things that I'm doing, [laughs] but goodness, being pregnant is hard. And I am very much ready for that leave. So also, a lot of the things that I'm doing right now are very focused on making sure everything's transitioned and communicated and that I just feel really good about that day of departure. That covers all the newness in my world other than the big thing that we're just not talking about yet. How about you? What's new in your world? CHRIS: Well, continuing to skirt the bigger topic that we will certainly get to in the episode, what is new in my world? I'm actually quite excited workwise right now. We have a much larger body of work that finally we got the clarity. All the pieces fell into place, and now we're sort of everybody rowing in the same direction. There's interesting, I think, really impactful code that we're writing for Sagewell right now. So that's really fantastic. We've got the whole team back together on the engineering side. And so we're, I think, in the strongest and most interesting point that I have experienced thus far. So that's all really fantastic. On a slight technical deep dive, you know what really grinds my gears? It's JWTs. JSON Web Tokens and I have never gotten along. It's never been a match made in heaven. And we have a webhook that comes from Plaid. Plaid is a vendor for connecting bank accounts and whatnot. And they have webhooks like many people do. So they can inform us when things change, lovely feature of how we build web apps these days. But often, there's a signature that says, "This is definitively from us, and you can trust us." And usually, it's some calculated signature, HMAC, or something like that. For some reason, Plaid's uses JWTs, and more than that, they use JWKs. So there's JWT which is the signature. That JWT itself is signed with a JWK. You have to fetch the JWK from their server based on the key ID in the header of the JWT. But how do you know if you can trust the JWT before you've gotten the JWK? All of this broke in a recent upgrade. We went from Heroku-20 to Heroku-22 to the new platform with Heroku, which bumped us to OpenSSL 3.0, and it turns out JWT doesn't work with it. And so that's sad. It's a no. It's going to be a no. It turns out the way that OpenSSL 3.0 works is incompatible with some of the code paths in JWT. And so I was like, wait, we just can't do this? And it's low-level cryptographic primitive stuff that I'm not comfortable messing around with. I'm not going to hop in there and roll up my sleeves. And even just getting to the point that I understood what was broken about this took like an hour and a half just to sort of like, wait, which is okay...so the JWT signs and encodes. And this will be a theme that we come back to later, but I think web development should be simpler. I think we should strive for simplicity. And this is a perfect example where I'm guessing Plaid uses JWTs and that approach to communicating security things often, but I've not seen it used much for signing webhooks. And, oof, it led to a complicated day. And it's unfixable now as far as I can tell. There is a commit on the JWT Ruby repo as of five days ago, but it doesn't build in our system. And it's not released. And it's just a mess. So yeah, engineering is complicated. I'm both wildly excited about what we're doing at Sagewell, and then today was this local minimum of like, oh, JWTs again. Again, we find ourselves battling. And you won today, but hopefully not for too long. STEPH: Oof, how did this manifest that you first noticed? So is it because a webhook suddenly stopped working, and that was like the error that rose up, and that's what helped you dive into it? CHRIS: Yeah, we have a little bit of code in the controller for where Plaid events come in. We calculate and verify the signature of the webhook to make sure that it's valid, and we reject it otherwise. And we alert ourselves via Sentry, and then we also have a Datadog scan that can show what's the status code of the response. Because these are incoming HTTP payloads or requests, and so we can see there were 200 up until this magical day when suddenly everything changed. And that was when we switched Heroku stacks. And then we can see it also in Sentry. So we're able to look at it, and we're like, why are none of the Plaid webhooks able to verify the signature anymore? That seems weird. And so then Datadog confirmed that it consistently was broken from this point in time. And then we were able to track that back. It was also pretty easy to guess because the error was "pkeys are immutable in OpenSSL 3.0," and that was the data. And I was like, oh, cool, that sounds fun. Let me go figure out what that means. STEPH: [laughs] Well, it's a nice use of Datadog. I remember in the past you were talking about adding it. And I was excited because I've never been at that point where a team has just introduced it; either a team doesn't have it, and they wish they had more insights, or they have it and don't use it. And nobody ever checks the board. So that's a nice anecdote for Datadog helping you out. Yeah, I'm not envious of your situation, friend. CHRIS: I do love the cup half full take [laughs] that you have on the overall situation, but that's nice how Datadog worked out for you. And you know what? It was. Thank you, Steph, for once again being that voice of positivity. STEPH: I appreciate that you enjoy it because there are times that when someone points it out to me that I do that, I have to be like, "I'm sorry, I'm not trying to be toxic positivity over here. [chuckles] That's just how my brain works." CHRIS: Oh, you are definitively not toxic positivity. That's a different thing. Because you ended with but also, I feel bad for you, and I'm glad that I'm not in your shoes. So you are the right level of positivity. I don't think I could have talked to you for three and a half years as co-host on a podcast if I didn't appreciate the level of positivity or the general approach that you bring to thinking about stuff. STEPH: Okay. Well, to borrow a phrase from Matt Sumner, who has been a guest on the show, cool, cool, cool, cool. I'm glad my positivity has been well calibrated. And I was about to say I'm interested to hear how this turns out for the team. [laughs] But we're in an awkward spot where I mean, you and I, we can still totally chat. But listeners won't get to hear the rest of that particular saga. I mean, you can share. I mean, you do you. I'm setting all sorts of boundaries for you right now. Okay. And now I'm just rambling, and I'm getting weird with it. Because the truth is that, you know, we won't be back. And this is our final episode together. So I think let's just go ahead and rip off the Band-Aid. Let's dive into it. Let's talk about it. Given that it's our last episode that we are recording, we thought of a couple of things that we'd like to talk about. You brought up a great idea that I'm excited to dive into. Do you want to lead us in? CHRIS: Sure. Well, if we go back all the way to Episode 172, that is the first episode that you came on as a guest. I actually continue to really love the title of that episode, which is What I Believe About Software. And it both captured that conversation really well, but also, more generally, it's actually become the tagline of the show when we do our little introduction. What do we believe about building great software? Et cetera. And I think that's been the throughline of the conversations that we've had is what remains true. What are the themes? Not necessarily the specific technologies, although we certainly talk about that. But what do we believe about building great software? And so today, I thought it would be fun for us to talk about what do we still believe about building great software? It's roughly three and a half years or so that we've been doing this. What's still true? STEPH: Oh, well, I have the first unequivocal one, the thing that I still believe about building great software, and that's you should hire thoughtbot. That's definitely the way to go. We'll help you get it done, not that I'm biased in any way. CHRIS: No. I'd say collectively between us; there's zero bias with regard to thoughtbot or any other web development shop out there. But thoughtbot is the best. STEPH: All right, perfect. So we've got the first one, the clutch one of hire thoughtbot. And then I also really like this topic. And I still think back to that first episode that I recorded with you and how much fun that was and how that really got me to start thinking about this. Because it was something that, at the time, I didn't really reflect on a lot in terms of what does it take to build great software? I was often just doing the day-to-day actions but then not really going high-level think about it. So I'm excited this is one of the topics that we're revisiting. So for the next one, this one is, I don't know, maybe it's a little cutesy, but I was trying to think of an alliteration that I enjoyed. And so this one is be an assumption assassin. So what assumptions are you making? And then how can you validate or disprove them? And that is something that I find myself doing constantly. And it always yields better work, better questions, better software, better code, better code reviews. And that's my first one is be an assumption assassin and identify what assumptions you have. And I had a really good example come up today while I was having a conversation with Joël about something that I was looking to merge. But I was a little hesitant about it because there are some oddities that I won't dig in too deeply. But essentially, there's a test that I migrated that highlights an existing concern in the code. And I was like, should I go ahead and merge this test that documents it, or should I wait to fix that concern and address it? And he brought up a good point. And he's like, "Well, we're assuming it's a bug and an issue, but it may not actually be depending on how the software is being used." And so then he was encouraging me to reevaluate that assumption that I had where I'm like, oh, this is definitely a problem to, like, I don't know, is it a problem? Let's ask somebody. CHRIS: First off, I love that as a theme, as one of the things that you still believe about software. Second, I believe you correctly said that you were looking for an alliteration, but my brain heard acronym. STEPH: [laughs] CHRIS: And so then I was like, B-A-A-A. Is it BAAA? What are you going for there? Oh, you just wanted a bunch of As. Okay, I got it now. Secondly or thirdly, I think I'm on my third now. Apparently, within Sagewell team culture, one of the things that I'm most known for is... there are two phrases: one is just to name it, and the other is to be clear. And these are the two things that I do apparently constantly so much that it's become a meme within the team. It's just like, okay, everybody's been talking. But I just want to make sure we're on the same page here. So just to be clear, or just to name it, here's what I'm seeing. But I agree; I think taking those things...what are the implicit bits? What are the assumptions? And making them more explicit. Our job as developers is just to yell at computers all the time and make them try and do human stuff. And there's so much room for lossy conversions at every point in that conversation chain. And so yeah, being very clear, getting rid of assumptions, love it. It's all great stuff. Actually, in a very related note, the first on my list is that code is for humans to read. This is one of the things that I believe most deeply and most impacts the way that I write software. Any given piece of functionality that we want to author in our code feels like 10, 20, 50, frankly, almost infinite different versions of the code that would produce nearly identical functionality. So at the end of the day, the actual symbols and strings of text that we bring together to write the code is all about other humans, other people on your team, you five months from now, you a week from now, frankly, or me. I'm going to say me, me a week from now. I want to do future me and everyone else on the team a solid and spend that extra 10% of okay, I have something that works now, but let me try and push it around and try and massage it into a shape that is a little more representative of how we're actually thinking about the code, how we talk about it as an organization. Is that the word that we use to describe that domain concept? Maybe we could change that just a little bit. Can I push more of this into the private API? What actually needs to be known here? And I think that's where I'm happiest is in those moments because that's where all of the parts of the job come together, the bit where I trick a computer into doing what I want and simultaneously making it so that that code is revisitable, clear, expressive, all of those things. So yeah, code is for humans. And that's true across every language, and framework, and domain that I have worked in. And I've only believed it more and more so over time. So yeah, that's mine. STEPH: Yeah, I love that one. That's one of the things that comes to mind when people talk about disliking code reviews. And I can imagine there are a number of reasons that people may have had a poor experience with a code review process. But at the end of the day, if you're not getting that feedback or validation from fellow humans, then how do you know that you've been successful, that you've written something that other people can follow up on? Which goes back to the assumptions in terms of like, you're assuming that you have written something that your future self or that other people are going to be able to read and maintain down the road. So yeah, I love that one. One of the other things that I still hold really true to building great software is prioritize early and often. So always be checking in to understand with your users, with your tech concerns, with data that you may have, new insights, and then just confirm that yes, you and the team are constantly working on the thing that has been prioritized and that is the most important. And also, be ready to let go. That can be really hard. I have definitely had those moments in my career where I've spent two weeks working really hard on something. And then we've realized that the thing that we were pursuing isn't that valuable, or it's something that users don't need or actually want. And so it was better to let go of it than to pursue it and ship it anyways. So that's one of my other mantras that I have adopted now is prioritize, prioritize, prioritize. CHRIS: Unsurprisingly, I agree wholeheartedly with all of that. We're still searching for that thing, that core thing that we disagree on other than Pop-Tarts and IPAs. But I don't know that today is the episode that we're actually going to find that. But yeah, prioritizing is such a critical activity. And it is this interesting collaboration point. It gets different groups together. It's this trade-off. It's this balance. And it's a way to focus on and make explicit the choices that we're making. And we're always making choices. We're always making trade-offs. And so being more explicit, being more connected and collaborative around those I believe in so, so, so much. So love that that was something on your list. Let's see, next up on my list is reduce complexity, just sort of as an adage, just always be reducing complexity. It is amazing to me in my time, particularly as a consultant, but even now, this is something that I hold very true is just it's so easy to grow a system in anticipation of future complexity or imagine that the performance concerns that we're going to run into will be so large that we must switch from Postgres and a nice, simple atomic database into a sharded, clustered Kafka queue adventure. And there are absolutely cases that make sense for that sort of thing. But at a minimum, I beg of you, anyone starting a new system, don't start with microservices. Don't start with an event queue-based system. These are wildly complex versions of what often can be done with so much simpler of an application. And this scales through to everything. What's the complexity of an API? Do we need caching in that API layer? Or can we just be a little bit inefficient for a little while and avoid the complexity and the overhead of caching? Turns out caching is a tricky thing to get right, just as an aside. And so the idea of like, oh, let's just sprinkle in a little bit of caching. It'll be easy, and then we'll get better performance, like, yeah, but did you get it right? Or did you introduce a subtle bug into your program that's going to be really hard to debug later? Because do you cache in development? Well, maybe, I'm not sure, could be. So over time, this is something that I've sort of always felt, but I've only ratcheted it up. It's only something that I've come to believe in more and to hold more firmly to. I think earlier in my career, it was something that I felt, but I would more easily be swayed by aspirational ideas of the staggering amounts of traffic that we would be getting soon or the nine different ways that the data model will expand. And so, we should code the current version in anticipation of that. And I have become somewhat the old man on his lawn yelling at the clouds like, "Nah, we don't need it yet. We can grow to that." And there's a certain category of things that are useful to try and get out in front of and don't introduce additional complexity, but they're a tiny, tiny list. And so, for most things, my stance is what's the simplest thing that we can get away with right now, that still provides a meaningful experience to our users, that doesn't compromise on security or robustness or correctness but just solves the problem we have right now? And over and over and over again, that has served me incredibly well. So yeah, keep that complexity at bay. STEPH: That is one that I've definitely struggled with. And frankly, it works in my favor, that idea of keeping things simple. Because I'm terrible when it comes to predicting the future or trying to build things in a way that I just don't have enough information to really drive the architecture or the application that I'm building. So anytime I'm trying to then stretch and reach for the future in those ways unless I really have a concrete understanding of I am building for these particular scenarios, it's really hard to do. So I very much like keeping it simple and not optimizing before you need to. And it reminds me of I think it's Mark Twain, who has a quote, "Worrying is like paying a debt that you don't owe." And that's something that comes to mind for me when also writing code and building features and software is that I tend to be someone who will worry about stuff. And I'm like, oh, is this going to be easy to extend? Is it going to be what it needs to be six months from now if we need to add more features to this and build on top of it? And I have to remind myself it's like, well, let's just wait. Let's wait till we get there and we know more. One of my other ideas that couples nicely with the one that you just shared in regards to keeping things simple and then waiting for those needs to arise is that mistakes are going to happen. They are a part of the process. As we are learning and growing and we're stretching our skills and trying things out, things are going to go wrong. We're going to introduce bugs. And to take those opportunities, that's when we start to use that feedback to then improve things like observability, like capturing logs, and how we handle error reporting or having a plan for emergencies. So maybe that's the part of worrying that can pay off is thinking through, all right, if something does break, or if something gets shipped that shouldn't, then what is our plan in how we handle that? How do we roll back? Or how do we get things back to a stable build? CHRIS: It's funny. I was actually visiting with a friend this past weekend, and we were chatting more generally about life things but the idea of worrying and anticipation and trying to prepare for every bad outcome. And there's the adage of an ounce of prevention is worth a pound of cure. But increasingly, both in life, depending on the context, and in code, I've found that I've shifted to the opposite of it's impossible to stop everything. There are going to be bugs that are going to get out there. There are going to be places where we code things incorrectly. And I would rather...I still want to try as hard as I can to get things right, to be clear. I'm not giving up on trying. But I'm all the more focused on how do we know and how do we recover when those things happen? So it's interesting that you just described exactly that, which, again, is a very human life conversation, and yet it applies to the code. STEPH: I love that rephrasing of it. Instead of the mistakes are going to happen, it's, like, how do we know, and how do we recover? I think that's perfect. I've also found that by answering the how do we know and how do we recover, that really helps you build trust with clients as well. Because again, things are going to happen, things are going to break. And the more prepared you are for that and then the better plan that you have, and then they can watch how you execute that plan, and it's going to establish a lot of deep trust with other engineers and also the team that you're working with, that you have been thoughtful and that you have ideas on how are we going to address this? Instead of waiting for that moment to happen. That's going to happen too. You're going to make decisions in the heat of the moment. But I have found that to be a really useful way to establish yourself with a team in terms of I care about this team and these processes and this application. So how do we handle the bad times, not just the good times? I do want to circle back because you alluded to the fact that you and I, we've tried to find things that we disagree on. And so far, Pop-Tarts and beer have been the two things that we disagree on. But I do have a question for you that maybe I will disagree with you on. But I need to know some more about it first. You have alluded to there's the Brussels snack, (Oh, I'm going to get this wrong.) Brussels sprout snack hour or working lunch, something combination of those words. [laughs] And it's the working lunch that has stuck out to me, and I've wanted to ask you about it. So here I am. I'm asking you about it. What's a working lunch? What's the Brussels snack happy hour, snackariffic working lunch look like? CHRIS: This is fantastic. I love that you waited until the last episode that this was rolling around in the back of your head. And you're like, are you making the team work through lunch? And now, on this final episode, we get to address the controversy that has been brewing in the back of your head. Spoiler alert, no, this is just ridiculous nomenclature. These are two meetings that we have that are more like, let's get the dev team together and talk about stuff that's in our platform sort of developer experience. Or stuff in observability often is talked about in this context because it doesn't quite impact users, but it's how we think about the work. And so there are two different meetings that alternate every other week. So every Friday afternoon, we do this, but it's one of two meetings depending on the day. So there's a crispy Brussels snack hour that was the first one that was named, which was named purely for nonsense reasons because we don't have anything else that's named nonsensically in our organization. And so I was like, oh when we name this meeting, we should make it nonsense because we don't have any other...We don't have, you know, an SOA microservices fleet with Barbie doll and Galactus and all of the other wonderful names. Those are references to the greatest video ever about microservices; if you've not seen it, that will be in the show notes. It's required reading. But anyway, we don't have that. And so we thought, let's be funny with the name of this. So the crispy Brussels snack hour is one, and the crispy Brussels we wanted something that was...the first one is a planning meeting. The second is like, let's actually sort of ensemble program. Let's get the four of us together, and we'll work on some of the stuff that we're talking about here but as a group. And so I wanted the idea of we're working, and so I was like, oh, this will be the crispy Brussels work lunch. But it's purely a name. It's the same time slot. It's 3:00 o'clock on a Friday afternoon. [laughs] So it is not at all us working through lunch. I don't think we should work through lunch. I'm concerned that you thought that for a while, and you were just like, I'm a little worried, but I'm not going to bring it up. But I'm glad we got to cover this before we wrapped up this whole Bike Shed co-hosting adventure together. STEPH: I feel relieved and also a little robbed of an opportunity for us to have something that we disagree on because I thought this might be a thing. [laughs] CHRIS: We can continue searching for that thing. But maybe it's okay that we agreed on most stuff for the run [laughs] of this fun, little show that we did together. STEPH: Yeah, that's gone on quite a time. We've got like three years together that we have managed to really only find two, I mean, very important of course, two things. But yeah, it's been pretty limited to those two areas. And each time that you'd mentioned the work lunch, I was like, huh, I need to ask about that because I have feelings about it. But then, you always would dive into very interesting stories of things that came out of it, and I quickly forgot about it. So this feels good. This feels like very good important closure. I'm glad that this finally surfaced. But circling back, since I took us on a detour for a little bit, what are some other things that you still hold deeply about building great software? CHRIS: I've really got one last thing on the list. It's interesting, there's not a ton technically in this list, which I think represents broadly how I feel about software, and I think how you feel about software. It's like, it's actually mostly about how the people interact at the end of the day. And you can program in any language or framework, and you can get the job done. We certainly have our preferences and things that we enjoy. But the last one really rounds us out, which is think about the users. I always want to be anchoring the conversations that we're having, the approach that we're taking to building the software in what do the users think? Who are our users? What do we know about them? What do they care about? How are they using this technology? How is it impacting their lives? We've talked a number of times about potentially actually watching the sales demo as an engineering team, trying to understand what's the messaging that we're putting out into the world for this piece of software that we're building? Or write along with customer support and understand what are the pain points that people are hitting? And really, like, real humans, what are they experiencing? Potentially with a name attached. And that just changes the way that you think about the software. There's also even the lower-level version of it. As we're building classes or modules, what are the public facets of that, and what are the private API? What's the stuff that we're hiding away? And what's the shape that we are exposing to the outside world for varying definitions of outside? And how can we just bring in a little bit of empathy to try and think about, again, in the case of like the API for a class, it's probably you on the other side of it, but it's future you in a slightly different mindset with a little bit less information and context on the current problem that you're working on. And so, how can we make things easier for ourselves in the code, for our users at the end of the day? How can we deliver real value that is not mired in the minutiae of technical complexity and whatnot but really is trying to help people live better lives? That's a little too fancy as I say it out loud. But it is kind of the core of what I believe, so I'm not going to take it back. STEPH: I love how you've expanded users where more traditionally, it's people that are then using the software. But then you've expanded it to include developers because that is something that is often on my mind and something that I just agree with wholeheartedly in terms of when you're writing software; as you mentioned before, software is for people. And so we want to include others. And it does improve people's lives. People show up to work every day, and if you've been thoughtful if your past you has been thoughtful, it's either going to give you your future self a better day, or it's going to give other people a better day. So I think that's a very fair statement, improving lives by being thoughtful in regards to focusing on the users, people consuming software, and working in the codebase. CHRIS: I know we've talked about this before, but I was having a conversation with one of the developers on the team at Sagewell just last week, and they were mentioning how they really loved working on admin features. And I was like, oh, that's interesting. Let's talk more about that. And it was really it's that same thing that I think you and I have discussed of like there's that immediacy. There's that connection. These are actually colleagues, but you can build software to make their day better. You can understand in detail what the pain points are. What's the workflow that as you watch it, you're like, oh, I could put a button up in the corner of the screen that would automate almost all of this and your day would be that much faster? Oh, let me do that. That's exciting. And so I love that as another variation of it, like, yeah, there's for other developers. There's also for the admin team or other users in the organization of the software. There are so many different versions of users, but I think I think we build a better thing if we think about them more. STEPH: I have definitely worked with teams where I can tell that certain people are demoralized, and it comes down to they feel frustrated and often disconnected from the people that they are building for. And so then you really feel isolated. I'm pushing code around, but I don't really see the benefit or the purpose of it. And I think that's very hard for developers who typically want to build something that's going to be useful and not feel like it's just going to be thrown away. So connecting your team to those users, I certainly understand. Getting to build something for your colleagues and then they get to say how much they like it is an incredible, rewarding experience. You also touched on something that I really appreciate, where you highlighted that a lot of the technical decisions that we make are important, but they're not at the center of the things that we believe when it comes to building great software. And that's something that I will often reflect on. Like, as we were thinking through these particular ideas that we still hold true today, how mine are more people and process-focused and rarely deep in the technical weeds. And there are times that I think, well, shouldn't there be something that's more technical, something that's very concrete? Yes, you should build your code this way or build your application or use a specific technology. But after all the projects and teams that I've been a part of, that's just usually not the most important part. And so I appreciate that you highlighted that because sometimes I have to remind myself that, yes, those things can be challenging, but it's often with people and process. That's where the heart of great software lies. CHRIS: That's a fantastic phrase, I think, that really encapsulates all of the conversations that we're having here. MID-ROLL 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: Actually shifting gears a little bit, so we've just talked about what we still believe about building great software. I'm intrigued. We've been chatting for a number of years here on this microphone, these microphones. We have separate ones because we're in different states. But I'm interested; what have we changed our minds about? What have you changed your mind about, Steph? I got a couple of ideas, but I'm intrigued to hear yours. STEPH: Nothing. I've never been wrong. I've stuck to everything that I've ever thought. CHRIS: That must be boring. STEPH: [laughs] Yeah, that's totally not true there. There are definitely things that I've changed my mind about. One of the things that I've changed my mind about is that people who know the most will ask the fewest questions. That's something that I used to consider the trademark of someone who is a more experienced senior developer in terms of you really know what you're doing. And so you typically don't ask for help or need help very often. And so, I'm going way back in terms of things that I have changed my mind about. But I have definitely changed my mind where people who know the most are actually the ones that do a really great job of constantly asking questions and asking for feedback. And I think that is still a misconception that people still carry forward. The idea that if you're asking a lot of questions or asking for help that you are not as skilled in your work, and I view it as quite the opposite, that you are very good at what you do and that you know precisely the value of your time. And then also reaching out to others for help, and then also just getting validation on things that you may have concerns around. So that's one I've changed my mind on is that I think the more experienced you are, the more questions you tend to ask. CHRIS: Oh, I love that one. It's a behavior that I know...I think we've talked about this before. But as consultants, we try and model it just the like; it's totally fine to ask questions. And because we often come in with less context, it makes sense for us to be asking questions, but I will definitely intentionally lean into it in those contexts to be like, everybody keeps throwing around this acronym. I don't actually know what that is. Let me raise my hand. And my favorite moment is when people disagree on what the acronym or what the particular word or what the particular project is. Like, I ask the question, and people are like, "Oh, it's this," and someone across the room is like, "Wait, that's what it means? I thought it was this totally other thing." I'm like, cool, glad that we sorted that out. Glad that we got that one up in the air. But I actually remember many, many, many years ago, at this point, there was a video series of...PeepCode was the company, and there was the Play by Play series. And so there were particular prominent developers, particularly in the Ruby community. And they would come and sort of be interviewed and pair program. And it was amazing getting to watch these big names that you had heard of, like Yehuda Katz is the one that stands out in my mind. He was one of the authors of merb, which was a framework that was merged with Rails, I want to say around the 3.0 time. And just an absolute, very big name in this world and someone that I looked up to and respected. And watching this video, they had to Google for particular API signatures and Rails methods. They were like, "Oh, how does that work? Is it link to and then you pass the name?" I forget what it was specifically. But it was just this very human normalizing moment of this person who has demonstrably done incredible work in our community and produced very complex software still needs to Google for the order of arguments to a particular method within Rails. I was like, oh, okay, that's good to know. And with complete humility in the moment, I was just like, yeah, this is normal. Like, it's impossible to hold all of that in your head. And seeing that early on shook me off the idea that that's the thing to do is just memorize everything. It's like no, no, get good at asking the questions. Get good at debugging. Get good, yeah, asking questions. It's a core skill rather than a thing that you grow out of. But I definitely shared early on I was like, not allowed to ask questions, that'll be scary. STEPH: I love that example. Because counterintuitively, to me, it demonstrates confidence when someone can say, "Oh, I don't remember how this works," or "Let me go look it up." And so I just very much appreciate when I see someone demonstrating that level of confidence of let's keep going. Let's keep making progress. I'm going to ask for help because that is totally fine, and we are in a safe space. Or I'm going to create a safe space for us to do that. One of my favorite versions of this where you shared like if you ask about an acronym and then people disagree, one of my favorite versions is to ask about a particular area of the codebase and be like, what would you say this code is doing here? What do you think users do here? Like, what is the purpose? What's the point of this? [chuckles] And then having people be able to say, "Oh, yeah, this definitively does this thing." Or people are like, "You know, I'm not sure. I don't even know if that code is getting run." That's one of my favorite outcomes of asking questions. How about you? What's something you've changed your mind about? CHRIS: I made a list of a couple of things like remote is on there. I didn't know if I'd like remote. I wanted to try it for a while. Tried it, turns out I like it a lot. It's complex. You got to manage it, whatever. But that I think everybody's talked about that a bunch. I think probably the most interesting one is deadlines. Initially, in my career, I didn't really feel anything about them. And then I experienced the badness of deadlines. Deadlines are bad. Deadlines are things that come down from on high and then you fail to hit them, and then you're sad. And maybe along the way, you're very stressed and work long hours to try and get there. But they're perhaps arbitrary. And what do they even mean? And also, we have this fixed scope, and they're just bad. And then there was a period of my time where, like, deadlines are bad. The only thing that we do is we show up, and we make the software as quickly as we can. But in reality, there are times that we need that constraint. And in fact, I have found a ton of value in deadlines when used intentionally. So we can draw a line in the sand, and we can say, at this point in time, we will have a version of the software. We have a marketing campaign that we need to align with this. So we got to have something at that point. And critically, if you're going to have a deadline, you've now fixed a point in time. You need to flex other things. And critically, I think the thing to flex is the scope. So we need to have team management. We have user accounts right now, but now we need to organize them into teams. That is like a category of functionality. It's not a singular feature. And so yeah, we can ship teams in the next quarter. What exactly that means is up in the air. And as long as we're able to have conversations essentially on a day-to-day at least weekly cadence as to what will make it in by that deadline and what won't, and we're able to have sometimes the hardest conversations but the very necessary conversations of the trade-offs that we have to make as we're building that software, then I find deadlines are absolutely fantastic tools for focusing and for actually reducing scope but in a really useful way. And getting something out there in the hands of users so that you start to get real feedback so that you start to learn, is this useful? What are the ways that people are using this? What should we lean into and do more of? What maybe should we roll back, actually? So yeah, deadlines. First, I didn't know them, then I feared them. Now I love them but only under the right circumstances. It's a double-edged sword, definitely. STEPH: I, too, have felt the terribleness of deadlines and railed against them pretty hard because I had gone through a negative experience with them but have also shifted my feelings about them where they can be incredibly useful. So I really liked that's one of the things that you've changed your mind about. It also reminds me of one of the other things...I'm going to circle back for a moment to one of the things that I believe about creating great software is to not wait for perfection, and deadlines are a really good tool that helps you not wait for perfection. Because I have also seen teams really struggle or sometimes fail because they waited until there was something perfect to present, and then you realize that you've built the wrong thing. So I do want to transition and talk a bit about the show because it's our last episode, and we should talk about it, and the fun adventures that we've had and some of the things that we've learned or things that we're feeling in the moment. So given that it's been a wonderful three years for me, it's been four years for you since you've been a host on the show. How are you feeling? CHRIS: I'm feeling a bunch of different things sort of all at once. I am definitely going to miss this immensely. Particularly, I loved when I started, and I got to interview a bunch of thoughtboters and other people from the community. But frankly, three-plus years of getting to chat with you has been just such a delight. There's been an ease to it. We kind of just show up and talk about what we're doing. And yet there are these themes that have run through it. And it has definitely helped me hone and shape my thinking and my ability to communicate about what I'm thinking. I've learned that you have a literal superpower to remember the last thing that you were talking about. Listeners, you may not know this, but we are not quite the put-together folks that we may sound like in these recordings. We have a wonderful editor, Mandy Moore, who makes us sound so much better than we are. But we'll often pause and stop and then discuss what we want to talk about next. And Steph always knows the exact phrase that she or I left off on. And it has been so valuable to the team. But really, it's been just such a pleasure getting to have these conversations. It's also been something that has just gently been in the back of my mind at all times. And so, I'm observing the work in any given week as I'm doing it. It's almost like meditation in a certain way, whereas I'm working on something, like, oh, this is actually really cool. I want to take a note about this and talk about it on The Bike Shed with Steph. And having this outlet, having this platform to be able to have those conversations and knowing that there are people out there is fantastic, although it's very weird because really, every one of these recordings is just you and I on a video call. And so there is an audience, I'm pretty sure. I think people listen to the show; I don't know, occasionally they write in, so it seems like they do. But at the end of the day, this really just feels like a conversation with a friend, and that has been so valuable to have. And yeah, I'm definitely going to miss that. It's been a wonderful run, you know, four years is a long time. It's about as long as I've done most things in my career. And so I'm very happy with what we have done here. And there's a trite saying that isn't...yeah, whatever; I'll just say it, which is, "Don't be sad that it's over. Be glad that it happened." And I guess I'm still going to be sad that it's over. But I am so glad that I got the opportunity to do this, that you joined in this adventure and that we got to chat each week. It's been really delightful. STEPH: I really liked how you refer to this as being a meditative state. And that is something that I have certainly picked up from you and thoroughly enjoyed that I have this space that I get to show up and bring these ideas and topics and then get to talk them out with you. And that has been such a nice way to either end the week or start a week. I mean, it doesn't matter. Anytime that we record, it's this very nice moment of the week where we get to come together and talk through some of the difficulties and share our stories. And that's been one of my favorite moments is because you and I get to show up and share everything that's going on. But then when someone writes into the show or if they send a tweet or something and they share their story or their version of something that happened, or if they said that we made them laugh, that was one of my favorite accomplishments is the idea that something that we have done was silly enough or fun enough that it has brought them joy and made them laugh. So I, too, I'm very, very much going to miss this. It has been a wonderful adventure. And I thank you for encouraging me to come on this adventure because I was quite nervous in the beginning. And this has definitely been an aspect of my life that started out as something that was very challenging and stretching my limits, and now it has become this very fun aspect and something that I get to show up and do and then get to share with everyone. And I do feel very proud of it, very much in part to Thom Obarski, who was our initial producer and helped us have that safe space to chat about things. And now Mandy, who keeps the show running smoothly and helps us sound our best week to week. So it's been a wonderful adventure. This is going to be hard to let go. And I think it's going to hit me most. Like, this was one of those things as we're talking about it, it's, like, I'll see you next week. This will be fine. But I think it's going to hit me when there's something that I want to talk about where I'm like, oh, this would be great to talk about, and I'll add it to The Bike Shed Trello board. And I'll be like, oh yeah, that's not a thing anymore, at least not quite in the same way that it was. CHRIS: So what I'm taking away from this is that you're immediately going to delete my phone number the minute we hang up this call and stop recording. [laughs] STEPH: Oh yeah. I preemptively deleted. So that's already done. Friendship is over at this point. CHRIS: That's smart. Yeah, because you might forget otherwise in the heat of the moment as we're wrapping this whole thing up. STEPH: [laughs] CHRIS: But actually, on that note, in a slightly more serious vein, again, there's this weird aspect where the audience is out there. But we're very sort of disconnected, particularly at the moment in time where we're recording. But it has been so wonderful getting various notes from listeners, listener questions, but also just commentary and the occasional thanks and focusing; oh, you pointed me in the direction, or you helped me think through a complicated piece of work or process a problem that we were having. And so that has been just so, so rewarding. And one of the facets of this that has been so interesting to me is being able to connect to people and basically put out there what we believe about software, and for the folks that resonate with it and be able to have that connection instantly. And meeting people, and they're like, "Oh, I've listened to The Bike Shed. I like all these things." I'm like, oh, cool, we get to skip way further into the conversation because I've already said a bunch, and you say you like that thing. So, cool, we're halfway through our introductory chat. And I know that we agree about a bunch of things, and that's really wonderful. And frankly, I'm going to miss that immensely. So for anyone out there who's found something valuable in this, who's enjoyed listening week to week, or perhaps even back to Upcase for things, I would love to hear from you. I'd love to connect to folks. Send me an email, Twitter. I'm on all the places. I'm Chris Toomey in various spots or ctoomey.com on the internet. Chris Toomey on GitHub. I'm findable, I think. Chris Toomey developer will probably get you there. But I would really love to hear from folks, to connect to folks, you know, someday down the road; I think I'll be hiring again. And that'll be fun. I would love to work with some of the folks that have listened to this show or meet you at a conference, or if I happen to be traveling to a city or you're traveling to Boston. Really for me, so much of what this show is about is connecting with people around how we think about building great software. And so, I would love to continue that forward into the future. So yeah, say hi, if you're interested. STEPH: I agree. That's been one of the most fun aspects of being co-host of the show. And I'll be honest, you are welcome to contact me, but I am going to be off-grid for probably six months. [laughs] So just know that there will be a bit of a delay before you hear back from me. But I would definitely love to hear from you. I also want to say a very heartfelt thanks to a couple of people, just folks that have made this journey incredible and have made it so much fun. One, in particular, is everyone at thoughtbot for their continuous stream of knowledge. I mean, frankly, my software opinions wouldn't be half as interesting if it wasn't for everyone at thoughtbot constantly sharing their knowledge and being a source of inspiration. So I deeply appreciate everyone that has contributed to topics and ideas and just constantly churning out blog posts because those are phenomenal. And I also want to give a shout-out to my husband, Tim, because he has listened to The Bike Shed for many years and even helped out with a number of show notes when that was something that you and I used to do before Mandy made our life so much easier and took that over for us. And has intervened a number of times when Utah mid-recording would decide it's time to play. So I want to give a very special thank you to him because he has been a very big supporter of the show and frankly helped me manage through a lot of the recordings for when I had an 80-pound dog that was demanding my attention. CHRIS: I think continuing on the note of thanks; similarly, I'm so grateful to thoughtbot as an organization for everything that is represented in my career. It's a decade-plus that I have been following and then listening to the podcasts and then joining the organization, and then getting so many wonderful opportunities to learn about this thing called web development. And then, even after I left the organization, I was able to stay on here on The Bike Shed and hang out and still chat with you, Steph, which has been really wonderful. So thank you, thoughtbot, so much. Thank you to Joël Quenneville, who will be the continuing host of the show. This show is not going anywhere. And, Steph, you and I aren't really going anywhere, but we won't be around anymore. But we are leaving it in the very, very capable hands of Joël, and I'm super excited to hear the direction that he takes it and Joel's incredibly thoughtful and nuanced approach to thinking about programming and communicating. So I think that will be really wonderful. And lastly, I definitely want to thank Derek Prior and Sage Griffin, the two original hosts of this show, who really produced something wonderful, and for many years, I think it was about four years that they hosted together. I was an avid listener despite actually working at the company the whole time and really loved the thing that they produced and was so grateful that they entrusted me with continuing it forward. And hopefully myself and then with the help of you along the way, we've...I think we've done an okay job, but now it is time to pass the torch or the green lantern. That's the adage I've been going with. Gotta pass the lantern, pass the mantle on to the next one. So, Joël, it's going to be in your hands now. STEPH: Yeah, I'm so looking forward to future episodes with Joël Quenneville. They are going to be fabulous. So I've been thinking in terms of this being our finale episode and then a fun ending for it, so there's a thing called the 21-gun salute, which is the military honor that's performed by firing cannons or artillery. Not to be confused with the three-volley salute, which I definitely confused earlier that is reserved and used at funerals, which this is not. So using the 21-gun salute, I was like, hmm, it is The Bike Shed, and we have this cute ring ring that goes. So I think for our finale, we should have a 21-bell salute as we exit the shed and right off into the sunset. CHRIS: I love it. I couldn't imagine a more perfect send-off. So with that, what do you think? Should we wrap up? STEPH: Yes, but I have one more silly thing to add. I've thought of a new software idiom that I'm excited about. And so, this may be my final send-off into glory that I'd like to share with you. And I think that we should make like a shard and split. CHRIS: [laughs] I so appreciate that in this moment, this final moment that we have together, you choose to go with a punny joke. It is so on brand for the show. It is absolutely perfect. And I think with that note, 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: 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 announce Joël Quenneville as the new host of the show!

Steph and Chris prepare to say goodbye (for now) to The Bike Shed.

Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough? They answer a listener's question about where to get started testing a legacy app. 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. jnicklas/capybara_table: (https://github.com/jnicklas/capybara_table) Capybara selectors and matchers for working with HTML tables Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Just gotta hold on. Fly this thing straight to the crash site. 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 Chris Toomey. CHRIS: And I'm Steph Viccari. STEPH: And together, we're here to share a bit of what we've learned along the way. I love that you rolled with that. [laughs] CHRIS: No, actually, it was the only thing I could do. I [laughs] was frozen into action is a weird way to describe it, but there we are. STEPH: I mentioned to you a while back that I've always wanted to do that. Today was the day. It happened. CHRIS: Today was the day. It wasn't even that long ago that you told me. I feel like you could have waited another week or two. I feel like maybe I was too prepared. But yeah, for anyone listening, you may be surprised to find out that I am not, in fact, Steph Viccari. STEPH: And they'll be surprised to find out that I actually am Chris Toomey. This is just a solo monologue. And you've done a great job of two voices [laughs] this whole time and been tricking everybody. CHRIS: It has been a struggle. But I'm glad to now get the proper recognition for the fact that I have actually [laughs] been both sides of this thing the whole time. STEPH: It's been a very impressive talent in how you've run both sides of the conversation. Well, on that note, [laughs] switching gears just a bit, what's new in your world? CHRIS: What's new in my world? Answering now as Chris Toomey. Let's see; I got two small updates, one a very positive update, one a less positive update. As is the correct order, I'm going to lead with the less positive thing. So I have a small toy app that I maintain on the side. I used to have a bunch of these little purpose-built singular apps, typically Rails app sort of things where I would play with a new technology, but it was some sort of like, oh, it's a tracker. It's a counter. We talked about breakable toys in the past. These were those, for me, serve different purposes, productivity things, or whatever. But at some point, I was like, this is too much work, so I consolidated them all. And I kept like, there was a handful of features that I liked, smashed them all together into one Rails app that I maintain. And that's just like my Rails app. It turns out it's useful to be able to program the internet. So I was like, cool, I'll do that for myself. I have this little app that I maintain. It's got like a journal in it and other things. I think I've talked about the journal in the past. But I don't actually take that good care of it. I haven't added any features in a while. It mostly just does what it's supposed to, but it had...entropy had gotten the better of it. And so, I had a very small feature that I wanted to add. It was actually just a Rake task that should run in the background on a schedule. And if something is out of order, then it should send me an email. Basically, just an update of like, you need to do something. It seemed like such a simple task. And then, oh goodness, the failure modes that I fell into. First, I was on Heroku-18. Heroku is currently on their Heroku-22 stack. 18 being the year, so it was like 2018, and then there's a 2020 stack, and then the 2022. That's the current one. So I was two stacks behind, and they were yelling at me about that. So I was like, okay, but whatever. Can I ignore that for a little while? Turns out no, because I couldn't even get the app to boot locally, something about some gems or some I think Webpacker was broken locally. So I was trying to fix things, finally got that to work. But then I couldn't get it to build on CircleCI because Node needed Python, Python 2 specifically, not Python 3, in order to build Node dependencies, particularly LibSass, I want to say, or node-sass. So node-sass needed Python 2, which I believe is end of life-d, to build a CSS authoring tool. And I kind of took a step back at that moment, and I was like, what did we do, everybody? What is going on here? And thankfully, I feel like there was more sort of unification of tools and simplification of the build tool space and whatnot. But I patched it, and I fixed some things, then finally I got it working. But then Memcache wasn't working, and I had to de-provision that and reprovision something. The amount of little...like, each thing that I fixed broke something else. I was like, the only thing I can do at this point is just burn the entire app down and rebuild it. Thankfully, I found a working version of things. But I think at some point, I've got to roll up my sleeves some weekend and do the full Rails, Ruby, everything upgrade, just get back to fresh. But my goodness, it was rough. STEPH: I feel like this is one of those reasons where we've talked in the past about you want to do something, and you keep putting it off. And it's like, if I had just sat down and done it, I could have knocked it out. Like, oh, it only took me like 5-10 minutes. But then there's this where you get excited, and then you want to dive in. And then suddenly, you do spend an hour or however long, and you're just focused on trying to get to the point where you can break ground and start building. I think that's the resistance that we're often fighting when we think about, oh, I'm going to keep delaying this because I don't know how long it's going to take. CHRIS: There's something that I see in certain programming communities, which is sort of a beginner-friendliness or a beginner's mindset or a welcomingness to beginners. I see it, particularly in the Svelte world, where they have a strong focus on being able to pick something up and run with it immediately. The entire tutorial is built as there's the tutorial on the one side, like the text, and then on the right side is an interactive REPL. And you're just playing with the Svelte REPL and poking around. And it's so tangible and immediate. And they're working on a similar thing now for SvelteKit, which is the meta-framework that does server-side rendering and all the fancy stuff. But I love the idea that that is so core to how the Svelte community works. And I'll be honest that other times, I've looked at it, and I've been like, I don't care as much about the first run experience; I care much more about the long-term maintainability of something. But it turns out that I think those two are more coupled than I had initially...like, how easy is it for a beginner to get started is closely related to or is, you know, the flip side of how easy is it for me to maintain that over time, to find the documentation, to not have a weird builder that no one else has ever seen. There's that wonderful XKCD where it's like, what's the saddest thing on the internet? Seeing the question that you have asked by one other person on Stack Overflow and no answers four years ago. It's like, yeah, that's painful. You actually want to be part of the boring, mundane, everybody's getting the same errors, and we have solutions to them. So I really appreciate when frameworks and communities care a lot about both that first run experience but also the maintainability, the error messages, the how okay is it for this system to segfault? Because it turns out segfaults prints some funny characters to your terminal. And so, like the range from human-friendly error message all the way through to binary character dump, I'm interested in folks that care about that space. But yeah, so that's just a bit of griping. I got through it. I made things work. I appreciate, again, the efforts that people are putting in to make that sad situation that I experienced not as common. But to highlight something that's really great and wonderful that I've been working with, there is a project called capybaratable. capybaratable is the gem name. And it is just this delightful little set of matchers that you can use within a Capybara, particularly within feature spec. So if you have a table, you can now make an assertion that's like, expect the table to have table row. And then you can basically pass it a hash of the column name and the value, but you can pass it any of the columns that you want. And you can pass it...basically, it reads exactly like the user would read it. And then, if there's an error, if it actually doesn't find it, if it misses the assertion, it will actually print out a little ASCII table for you, which is so nice. It's like, here's the table row that I saw. It didn't have what you were looking for, friend, sorry about that. And it's just so expressive. It forces accessibility because it basically looks at the semantic structure of a table. And if your table is not properly semantically structured, if you're not using TDs and TRs, and all that kind of stuff, then it will not find it. And so it's another one of those cases where testing can be a really useful constraint from the usability and accessibility of your application. And so, just in every way, I found this project works so well. Error messages are great. It forces you into a better way of building applications. It is just a wonderful little tool that I found. STEPH: That's awesome. I've definitely seen other thoughtboters when working in codebases that then they'll add really nice helper methods around that for like checking does this data exist in the table? And so I'm used to seeing that type of approach or taking that type of approach myself. But the ASCII table printout is lovely. That's so...yeah, that's just a nice cherry on top. I will have to lock that one away and use that in the future. CHRIS: Yeah, really, just such a delightful thing. And again, in contrast to the troubles of my weekend, it was very nice to have this one tool that was just like, oh, here's an error, and it's so easy to follow, and yeah. So it's good that there are good things in the world. But speaking of good things, what's new in your world? I hope good things. And I hope you're not about to be like, everything's terrible. But what's up with you? [laughter] STEPH: Everything's on fire. No, I do have some good things. So the good thing is that I'm preparing for...I have maternity leave that's coming up. So I am going to take maternity leave in about four-ish weeks. I know the date, but I'm saying the ish because I don't know when people are listening. [laughs] So I'm taking maternity leave coming up soon. I'm very excited, a little panicked mostly about baby preparedness, because, oh my goodness, it is such an overwhelming world, and what everyone thinks you should or shouldn't have and things that you need to do. So I've been ramping up heavily in that area. And then also planning for when I'm gone and then what that's going to look like for the team, and for clients, and for making sure I've got work wrapped up nicely. So that's a big project. It's just something that's on my mind, something that I am working through and making plans for. On the weird side, I ran into something because I'm still in test migration world. That is one of like, this is my mountain. This is my Everest. I am determined to get all of these tests. Thank you to everyone who has listened to me, especially you, listen to me talk about this test migration path I've been on and the journey that it's been. This is the goal that I have in mind that I really want to get done. CHRIS: I know that when you said, "Especially you," you were talking to me, Chris Toomey. But I want to imagine that every listener out there is just like, aww, you're welcome, Steph. So I'm going to pretend for my own sake that that's what you meant by, especially you. It's especially every one of you out there in the audience. STEPH: Yes, I love either version. And good point, because you're right, I'm looking at you. So I can say especially you since you've been on this journey with me, but everybody listening has been on this journey with me. So I've got a number of files left that I'm working through. And one of the funky things that I ran into, well, it's really not funky; it was a little bit more of an educational rabbit hole for me because it's something that I hadn't considered. So migrating over a controller test over from Test::Unit to then RSpec, there are a number of controller tests that issue requests or they call the same controller method multiple times. And at first, I didn't think too much about it. I was like, okay, well, I'm just going to move this over to RSpec, and everything is going to be fine. But based on the way a lot of the information is getting set around logging in a user and then performing an action, and then trying to log in a different user, and then perform another action that was causing mayhem. Because then the second user was never getting logged in because the first user wasn't getting logged out. And it was causing enough problems that Joël and I both sat back, and we're like, this should really be a request back because that way, we're going through the full Rails routing. We're going through more of the sessions that get set, and then we can emulate that full request and response cycle. And that was something that I just hadn't, I guess, I hadn't done before. I've never written a controller spec where then I was making multiple calls. And so it took a little while for me to realize, like, oh, yeah, controller specs are really just unit test. And they're not going to emulate, give us the full lifecycle that a request spec does. And it's something that I've always known, but I've never actually felt that pain point to then push me over to like, hey, move this to a request spec. So that was kind of a nice reminder to go through to be like, this is why we have controller specs. You can unit test a specific action; it is just hitting that controller method. And then, if you want to do something that simulates more of a user flow, then go ahead and move over to the request spec land. CHRIS: I don't know what the current status is, but am I remembering correctly that the controller specs aren't really a thing anymore and that you're supposed to just use request specs? And then there's features specs. I feel like I'm conflating...there's like controller requests and feature, but feature maybe doesn't...no, system, that's what I'm thinking of. So request specs, I think, are supposed to be the way that you do controller-like things anymore. And the true controller spec unit level thing doesn't exist anymore. It can still be done but isn't recommended or common. Does that sound true to you, or am I making stuff up? STEPH: No, that sounds true to me. So I think controller specs are something that you can still do and still access. But they are very much at that unit layer focus of a test versus request specs are now more encouraged. Request specs have also been around for a while, but they used to be incredibly slow. I think it was more around Rails 5 that then they received a big increase in performance. And so that's when RSpec and Rails were like, hey, we've improved request specs. They test more of the framework. So if you're going to test these actions, we recommend going for request specs, but controller specs are still there. I think for smaller things that you may want to test, like perhaps you want to test that an endpoint returns a particular status that shows that you're not authorized or forbidden, something that's very specific, I think I would still reach for a controller spec in that case. CHRIS: I feel like I have that slight inclination to the unit spec level thing. But I've been caught enough by different things. Like, there was a case where CSRF wasn't working. Like, we made some switch in the application, and suddenly CSRF was broken, and I was like, well, that's bad. And the request spec would have caught it, but the controller spec wouldn't. And there's lots of the middleware stack and all of the before actions. There is so much hidden complexity in there that I think I'm increasingly of the opinion, although I was definitely resistant to it at first, but like, yeah, maybe just go the request spec route and just like, sure. And they'll be a little more costly, but I think it's worth that trade-off because it's the stuff that you're not thinking about that is probably the stuff that you're going to break. It's not the stuff that you're like, definitely, if true, then do that. Like, that's the easier stuff to get right. But it's the sneaky stuff that you want your tests to tell you when you did something wrong. And that's where they're going to sneak in. STEPH: I agree. And yeah, by going with the request specs, then you're really leaning into more of an integration test since you are testing more of that request/response lifecycle, and you're not as likely to get caught up on the sneaky stuff that you mentioned. So yeah, overall, it was just one of those nice reminders of I know I use request specs. I know there's a reason that I favor them. But it was one of those like; this is why we lean into request specs. And here's a really good use case of where something had been finagled to work as a controller test but really rightfully lived in more of an integration request spec. 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! STEPH: Changing gears just a bit, I have something that I'd love to chat with you about. It came up while I was having a conversation with another thoughtboter as we were discussing how do you track velocity and know if you're working quickly enough? So since we often change projects about every six months, there's the question of how do I adapt to this team? Or maybe I'm still newish to thoughtbot or to a team; how do I know that I am producing the amount of work that the client or the team expects of me and then also still balancing that and making sure that I'm working at a sustainable pace? And I think that's such a wonderful, thoughtful question. And I have some initial thoughts around it as to how someone could track velocity. I also think there are two layers to this; there could be are we looking to track an individual's velocity, or are we looking to track team velocity? I think there are a couple of different ways to look at this question. But I'm curious, what are your thoughts around tracking velocity? CHRIS: Ooh, interesting. I have never found a formal method that worked in this space, no metric, no analysis, no tool, no technique that really could boil this down and tell a truth, a useful truth about, quote, unquote, "Velocity." I think the question of individual velocity is really interesting. There's the case of an individual who joins a team who's mostly working to try and support others on the team, so doing a lot of pairing, doing a lot of other things. And their individual velocity, the actual output of lines of code, let's say, is very low, but they are helping the overall team move faster. And so I think you'll see some of that. There was an episode a while back where we talked about heuristics of a team that's moving reasonably well. And I threw out the like; I don't know, like a pull request a day sort of thing feels like the only arbitrary number that I feel comfortable throwing out there in the world. And ideally, these pull requests are relatively small, individual deployable things. But any other version of it, like, are we thinking lines of code? That doesn't make sense. Is it tickets? Well, it depends on how you size your tickets. And I think it's really hard. And I think it does boil down to it's sort of a feeling. Do we feel like we're moving at a comfortable clip? Do I feel like I'm roughly keeping pace with the rest of the team, especially given seniority and who's been on the team longer? And all of those sorts of things. So I think it's incredibly difficult to ask about an individual. I have, I think, some more pointed thoughts around as a team how we would think about it and communicate about velocity. But I'm interested what came to mind for you when you thought about it, particularly for the individual side or for the team if you want to go in that direction. STEPH: Yeah, most of my initial thoughts were more around the individual because I think that's where this person was coming from because they were more interested in, like, how do I know that I'm producing as much as the team would expect of me? But I think there's also the really interesting element of tracking a team's velocity as well. For the individual, I think it depends a lot on that particular team and their goals and what pace they're moving at. So when I do join a new team, I will look around to see, okay, well, what's the cadence? What's the standard bar for when someone picks up a ticket and then is able to push it through? How much cruft are we working with in the codebase? Because then that will change the team's expectations of yes, we know that we have a lot of legacy code that we're working with, and so it does take us longer to get through things. And that is totally fine because we are looking more to optimize our sustainability and improving the code as we go versus just trying to get new features in. I think there's also an important cultural aspect. So some teams may, unfortunately, work a lot of extra hours. And that's something that I won't bend for. I'm still going to stick to my sustainable hours. But that's something that I keep in mind that just if some other people are working a lot of evenings or just working extra hours to keep that in mind that if they do have a higher velocity to not include that in my calculation as heavily. I also really liked how you highlighted that certain individuals often their velocity is unblocking others. So it's less about the specific code or features or tickets that they're producing, but it's how many people can they help? And then they're increasing the velocity of those individuals. And then the other metrics that unfortunately can be gamified, but it's still something to look at is like, how many hours are you spending on a particular feature, the tickets? But I like that phrasing that you used earlier of what's your progress? So if someone comes to daily sync and they mention that they're working on the same thing and we're on like day three, or four, but they haven't given an update around, like, oh, I have this new thing that I'm focused on, or this new area that I'm exploring, that's when I'll start to have alarm bells go off. And I'm like, okay, you've been working on the same thing. I can't quite tell if you've made progress. It sounds like you're still in the depths of the original thing that you were on a couple of days ago. So at that point, I'm going to want to check in to see how you're doing. But yeah, I think that's why this question fascinates me so much is because I don't think there's one answer that fits for everybody. There's not a way to tell one person to say, "Hey, this is your output that you should be producing, and this applies to all teams." It's really going to vary from team to team as to what that looks like. I remember there was one team that I joined that initially; I panicked because I noticed that their team was moving at a slower rate in terms of the number of tickets and PRs and stuff that were getting pushed up, reviewed, and then merged. That was moving at a slower pace than I was used to with previous clients. And I just thought, oh, what's going on? What's slowing us down? Like, why aren't we moving faster? And I actually realized it's just because they were working at a really sustainable pace. They showed up to the office. This was back in the day when I used to go to an office, and people showed up at like 9:00 a.m. and then 5:00 o'clock; it was a ghost town, and people were gone. So they were doing really solid, great work, but they were sticking to very sustainable hours. Versus, a previous team that I had been on had more of like a rushed feeling, and so there was more output for it. And that was a really nice reset for me to watch this team and see them do such great work in a sustainable fashion and be like, oh, yeah, not everything has to be a fire, not everything has to be rushed. I think the biggest thing that I'd look at is if velocity is being called into question, so if someone is concerned that someone's not producing enough or if the team is not producing enough, the first place I'm going to look is what's our priorities and see are we prioritizing correctly? Or are people getting pulled into a lot of work that's not supporting the priorities, and then that's why suddenly it feels like we're not producing at the level that we need to? I feel like that's the common disconnect between how much work we're getting done versus then what's actually causing people or product managers, or management stress. And so reevaluating to make sure that they're on the same page is where I would look first before then thinking, oh, someone's not working hard enough. CHRIS: Yeah, I definitely resonate with all of that. That was a mini masterclass that you just gave right there in all of those different facets. The one other thing that comes to mind for me is the question is often about velocity or speed or how fast can we go. But I increasingly am of the opinion that it's less about the actual speed. So it's less about like, if you think about it in terms of the average pace, the average number of features that we're going through, I'm more interested in the standard deviation. So some days you pick up a ticket, and it takes you a day; some days you pick up a ticket, and suddenly, seven days later, you're still working on it. And both at the individual level and at the team level, I'm really interested in decreasing that standard deviation and making it so that we are more consistently delivering whatever amount of output it is but very consistently doing that. And that really helps with our ability to estimate overall bodies of work with our ability for others to know and for us to be able to sort of uphold expectations. Versus if randomly someone might pick up a piece of code or might pick up a ticket that happens to hit a landmine in the code, it's like, yeah, we've been meaning to refactor that for a while. And it turns out that thing that you thought would be super easy is really hard because we've been kicking the can on this refactoring of the fundamental data model. Sorry about that. But today's your day; you lose. Those are the sort of things that I see can be really problematic. And then similarly, on an individual side, maybe there's some stuff that you can work on that is super easy for you. But then there's other stuff that you kind of hit a wall. And I think the dangerous mode to get into is just going internal and not really communicating about that, and struggling and trying to get there on your own rather than asking for help. And it can be very difficult to ask for help in those sorts of situations. But ideally, if you're focusing on I want to be delivering in that same pace, you probably might need some help in that situation. And I think having a team that really...what you're talking about of like, if I notice someone saying the same thing at daily sync for a couple of days in a row, I will typically reach out in a very friendly, collegial way, hey, do you want someone else to take a look at that with you? Because ideally, we want to unblock those situations. And then if we do have a team that is pretty consistently delivering whatever overall velocity but it's very consistent at that velocity, it's not like 3 one day and then 0, and then 12, and then 2; it's more of like, 6,5,6,5 sort of thing, to pick random numbers out of the air, then I feel so much more able to grow that, to increase that. If the question comes to me of like, hey, we're looking at the budget for the next quarter; do we think we want to hire another developer? I think I can answer that much more accurately at that point and say what do I think that additional individual would be able to do on the team. Versus if development is kind of this sporadic thing all over the place, then it's so much harder to understand what someone new joining that team would be able to do. So it's really the slow is smooth, smooth is fast adage that I've talked about in the past that really captured my mind a while back that just continues to feel true to me. And then yeah, I can work with that so much better than occasional days of wild productivity and then weeks of sadness in the swamp of refactoring. So it's a different way to think about the question, but it is where my mind initially went when I read this question. STEPH: I'm going to start using that description for when I'm refactoring. I'm in the refactoring swamp. That's where I'm spending my time. [laughs] Talking about this particular question is helping me realize that I do think less in terms of like what is my output in the strict terms of tickets, and PRs, and things like that. But I do think more about my progress and how can I constantly show progress, not just to the world but show it to myself. So if there are tickets that then maybe the ticket was scoped too big at first and I've definitely made some really solid progress, maybe I'm able to ship something or at least identified some other work that could be broken out, then I'm going to do that. Because then I want everybody to know, like, hey, this is the progress that was made here. And I may even be able to make myself feel good and move something over to the done column. So there's that aspect of the work that I focus on more heavily. And I feel like that also gives us more opportunities to then iterate on what's the goal? Like, we're not looking to just churn out work. That's not the point. But we really want to focus on meaningful work to get done. So if we're constantly giving an update on this as the progress that I've made in this direction, that gives people more opportunities to then respond to that progress and say, "Oh, actually, I think the work was supposed to do this," or "I have questions about some of the things that you've uncovered." So it's less about just getting something done. But it's still about making sure that we're working on the right thing. CHRIS: Yeah, it doesn't matter how fast we're going if we're going in the wrong direction, so another critical aspect. You can be that person on the team who actually doesn't ship much code at all. Just make sure that we don't ship the wrong code, and you will be a critical member of that team. But shifting gears just a little bit, we have another listener question here that I'd love to get into. This one is about testing a legacy app. So reading this question, it starts off with a very nice note to us, Steph. "I want to start by saying thanks for putting out great content week after week." We are very happy to do so." So a question for you two. I just took over a legacy Rails app. It's about 12 years old, and it's a bit of a mess. There was some testing in place, but it was completely broken and hadn't been touched in over seven years. So I decided to just delete it all. My question is, where do I even start with testing? There are so many callbacks on the models and so many controller hooks that I feel like I somehow need to have a factory for every model in our repo. I need to get testing in place ASAP because that is how I develop. But we are also still on Ruby 2 and Rails 4.0. So we desperately have to upgrade. Thanks in advance for any advice." So Steph, I actually replied in an email to this kind listener who sent this. And so, I definitely have some thoughts, but I'm interested in where would you start with this. STEPH: Legacy code, I wouldn't know anything about working in legacy code. [laughs] This is a fabulous question. And yeah, the response that you provided is incredible. So I'm very excited for you to share the message that you replied with. So I'm going to try not to steal any of those because they're wonderful. But to add to that list that is soon to come, often where I start with applications like these where I need some testing in place because, as this person mentioned, that's how they work. And then also, at that point, you're just scared to ship anything because you just don't know what's going to break. So one area that you could start with is what's your rollback strategy? So if you don't have any tests in place and you send something out into the world, then what's your plan to then be able to either roll back to a safe point or perhaps it's using feature flags for anything new that you're adding so that way you can quickly turn something on and off. But having a strategy there, I think, will help alleviate some of that stress of I need to immediately add tests. It's like, yes, that's wonderful, but that's going to take time. So until you can actually write those tests, then let's figure out a plan to mitigate some of that pain. So that's where I would initially start. And then, as for adding the test, typically, you start with testing as you go. So I would add tests for the code that I'm adding that I'm working on because that's where I'm going to have the most context. And I'm going to start very high. So I might have really slow tests that test everything that is going to be feature level, integration level specs because I'm at the point that I'm just trying to document the most crucial user flows. And then once I have some of those in place, then even if they are slow, at least I'm like, okay, I know that the most crucial user flows are protected and are still working with this change that I'm making. And in a recent episode, we were talking about how to get to know a Rails app. You highlighted a really good way to get to know those crucial user flows or the most common user flows by using something like New Relic and then seeing what are the paths that people are using. Maybe there's a product manager or just someone that you're taking the app over that could also give you some help in letting you know what's the most crucial features that users are relying on day to day and then prioritizing writing tests for those particular flows. So then, at this point, you've got a rollback strategy. And then you've also highlighted what are your most crucial user flows, and then you've added some really high level probably slow tests. Something that I've also done in the past and seen others do at thoughtbot when working on a legacy project or just working on a project, it wasn't even legacy, but it just didn't have any test coverage because the team that had built it before hadn't added test coverage. We would often duplicate a lot of the tests as well. So you would have some integration tests that, yes, frankly, were very similar to others, which felt like a bad choice. But there was just some slight variation where a user-provided some different input or clicked on some small different field or something else happened. But we found that it was better to have that duplication in the test coverage with those small variations versus spending too much time in finessing those tests. Because then we could always go back and start to improve those tests as we went. So it really depends. Are you in fire mode, and maybe you need to duplicate some stuff? Or are you in a state where you can be more considerate with your tests, and you don't need to just get something in place right away? Those are some of the initial thoughts I have. I'm very excited for the thoughts that you're about to share. So I'm going to turn it over to you. CHRIS: It's sneaky in this case. You have advanced notice of what I'm about to say. But yeah, this is a super interesting topic and one of those scary places to find yourself in. Very similar to you, the first thing that I recommended was feature specs, starting at that very high level, particularly as the listener wrote in and saying there are a lot of model callbacks and controller callbacks. And before filters and all of this, it's very indirect how this application works. And so, really, it's only when the whole thing is integrated together that you're going to have a reasonable sense of what's going on. And so trying to write those high-level feature specs, having a handful of them that give you some confidence when you're deploying that those core workflows are still working as expected. Beyond that, the other things that I talked about one was observability. As an aside, I didn't mention feature flags or anything like that. And I really loved that that was something you highlighted as a different way to get to confidence, so both feature flags and rollbacks. Testing at the end of the day, the goal is to have confidence that we're deploying software that works, and a different way to get that is feature flags and rollbacks. So I really love that you highlighted that. Something that goes really well hand in hand with those is observability. This has been a thing that I've been exploring more and more and just having some tooling that at runtime will tell you if your application is behaving as expected or is not. So these can be APM-type tools, but it can also be things like Sentry or Honeybadger error monitoring, those sorts of things. And in a system like this, I wouldn't be surprised if maybe there was an existing error monitoring tool, but it had just kind of decayed over time and now just has perhaps thousands of different entries in it that have been ignored and whatnot. On more than one occasion, I've declared Sentry bankruptcy working with clients and just saying like, listen; this thing can't tell us any truths anymore. So let's burn it down and restart it. So I would recommend that and having that as a tool such that much as tests are really wonderful before the code gets out there into the wild; it turns out it's only when users start using it that the real stuff happens. And so, having observability, having tooling in place that will tell you when something breaks is equally critical in my mind. One of the other things I said, and this is probably the spiciest take on my list, is questioning the trade-off space that you're in. Is this an application that actually has a relatively low defect rate that users use and are quite happy with, and expect that level of performance and correctness, and all of those sorts of things, and so you, frankly, need to be careful with it? Or, is it potentially something that has a handful of bugs and that users are used to a certain lower fidelity experience, let's call it? And can you take advantage of that if that happens to be true? Like, I would be very careful to break something that has never been broken before that there's no expectation of that. But if we can get away with moving fast and breaking things for a little while just to try and get ourselves out of the spot that we're in, I would at least want to consider that trade-off space. Because caution slows you down, it means that your progress is going to be limited. And so, if we're able to reduce the caution filter just a little bit and move a little bit more rapidly, then ideally, we can get out of this place that we're in a little more quickly. Again, I think that's a really subtle one and one that you'd have to get buy-in from product managers and probably be very explicit in the conversations and sort of that trade-off space. But it is something that I would want to explore if I found myself in this sort of situation. The last thing that I highlighted was the fact that the versions of Ruby and Rails that were listed in the question are, I think, both end of life at this point. And so from a security perspective, that is just a giant glaring warning sign in the corner because the day that your app gets hacked, well, that's a bad day. So testing, unfortunately, I think that's the main way that you're going to get by on that as you're going through upgrades. You can deploy a new version of the application and see what happens and see if your observability can get you there. But really, testing is what you want to do. So that's where building out that testing is all the more critical so that you can perform those security upgrades because they are now truly critical to get done. And so it gives sort of more than a nice to have, more than this makes me feel comfortable. It is pretty much a necessity if you want to go through that, and you absolutely need to go through the security upgrades because otherwise, you're going to get hacked. There are just automated scanners out there. They're going to find you. You don't need to be a high vulnerability target to get taken down on the internet these days. So if it hasn't happened yet, it's going to. And I think that's an easy business case to sell is, I guess, the way that I would frame it. So those were some of my thoughts. STEPH: You bring up a really good point about needing to focus on the security upgrades. And I'm thinking that through a little bit further in regards to what trade-offs would I make? Would I wait till I have tests in place to then start the upgrades, or would I start the upgrades now but just know I'm going to spend more time manual testing on staging? Or maybe I'm solo on the project. If I have a product manager or someone else that can also help the testing with me, I think I would go for that latter approach where I would start the upgrades today and then just do more manual testing of those crucial flows and then have that rollback strategy. And as you mentioned, it's a trade-off in terms of, like, how important is it that we don't break anything? CHRIS: I think similar to the thing that both of us hit on early on is like, have some feature specs that just kick the whole application as one connected piece of code. Have that in place for the security upgrade, testing. But I agree, I wouldn't want to hold off on that because I think that's probably the scariest part of all of this. But yeah, it is, again, trade-offs. As always, it depends. But I think those are my thoughts. Anything else you want to add, Steph? STEPH: I think those are fabulous thoughts. I think you covered it all. CHRIS: Sounds good. Well, in that case, 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: 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.

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.

About ChrisChris is the Co-founder and Chief Product Officer at incident.io, where they're building incident management products that people actually want to use. A software engineer by trade, Chris is no stranger to gnarly incidents, having participated (and caused!) them at everything from early stage startups through to enormous IT organizations.Links Referenced: incident.io: https://incident.io Practical Guide to Incident Management: https://incident.io/guide/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted guest is Chris Evans, who's the CPO and co-founder of incident.io. Chris, first, thank you very much for joining me. And I'm going to start with an easy question—well, easy question, hard answer, I think—what is an incident.io exactly?Chris: Incident.io is a software platform that helps entire organizations to respond to recover from and learn from incidents.Corey: When you say incident, that means an awful lot of things. And depending on where you are in the ecosystem in the world, that means different things to different people. For example, oh, incident. Like, “Are you talking about the noodle incident because we had an agreement that we would never speak about that thing again,” style, versus folks who are steeped in DevOps or SRE culture, which is, of course, a fancy way to say those who are sad all the time, usually about computers. What is an incident in the context of what you folks do?Chris: That, I think, is the killer question. I think if you look at organizations in the past, I think incidents were those things that happened once a quarter, maybe once a year, and they were the thing that brought the entirety of your site down because your big central database that was in a data center sort of disappeared. The way that modern companies run means that the definition has to be very, very different. So, most places now rely on distributed systems and there is no, sort of, binary sense of up or down these days. And essentially, in the general case, like, most companies are continually in a sort of state of things being broken all of the time.And so, for us, when we look at what an incident is, it is essentially anything that takes you away from your planned work with a sense of urgency. And that's the sort of the pithy definition that we use there. Generally, that can mean anything—it means different things to different folks, and, like, when we talk to folks, we encourage them to think carefully about what that threshold is, but generally, for us at incident.io, that means basically a single error that is worthwhile investigating that you would stop doing your backlog work for is an incident. And also an entire app being down, that is an incident.So, there's quite a wide range there. But essentially, by sort of having more incidents and lowering that threshold, you suddenly have a heap of benefits, which I can go very deep into and talk for hours about.Corey: It's a deceptively complex question. When I talk to folks about backups, one of the biggest problems in the world of backup and building a DR plan, it's not building the DR plan—though that's no picnic either—it's okay. In the time of cloud, all your planning figures out, okay. Suddenly the site is down, how do we fix it? There are different levels of down and that means different things to different people where, especially the way we build apps today, it's not is the service or site up or down, but with distributed systems, it's how down is it?And oh, we're seeing elevated error rates in us-tire-fire-1 region of AWS. At what point do we begin executing on our disaster plan? Because the worst answer, in some respects is, every time you think you see a problem, you start failing over to other regions and other providers and the rest, and three minutes in, you've irrevocably made the cutover and it's going to take 15 minutes to come back up. And oh, yeah, then your primary site comes back up because whoever unplugged something, plugged it back in and now you've made the wrong choice. Figuring out all the things around the incident, it's not what it once was.When you were running your own blog on a single web server and it's broken, it's pretty easy to say, “Is it up or is it down?” As you scale out, it seems like that gets more and more diffuse. But it feels to me that it's also less of a question of how the technology has scaled, but also how the culture and the people have scaled. When you're the only engineer somewhere, you pretty much have no choice but to have the entire state of your stack shoved into your head. When that becomes 15 or 20 different teams of people, in some cases, it feels like it's almost less than a technology problem than it is a problem of how you communicate and how you get people involved. And the issues in front of the people who are empowered and insightful in a certain area that needs fixing.Chris: A hundred percent. This is, like, a really, really key point, which is that organizations themselves are very complex. And so, you've got this combination of systems getting more and more complicated, more and more sort of things going wrong and perpetually breaking but you've got very, very complicated information structures and communication throughout the whole organization to keep things up and running. The very best orgs are the ones where they can engage the entire, sort of, every corner of the organization when things do go wrong. And lived and breathed this firsthand when various different previous companies, but most recently at Monzo—which is a bank here in the UK—when an incident happened there, like, one of our two physical data center locations went down, the bank wasn't offline. Everything was resilient to that, but that required an immediate response.And that meant that engineers were deployed to go and fix things. But it also meant the customer support folks might be required to get involved because we might be slightly slower processing payments. And it means that risk and compliance folks might need to get involved because they need to be reporting things to regulators. And the list goes on. There's, like, this need for a bunch of different people who almost certainly have never worked together or rarely worked together to come together, land in this sort of like empty space of this incident room or virtual incident room, and figure out how they're going to coordinate their response and get things back on track in the sort of most streamlined way and as quick as possible.Corey: Yeah, when your bank is suddenly offline, that seems like a really inopportune time to be introduced to the database team. It's, “Oh, we have one of those. Wonderful. I feel like you folks are going to come in handy later today.” You want to have those pathways of communication open well in advance of these issues.Chris: A hundred percent. And I think the thing that makes incidents unique is that fact. And I think the solution to that is this sort of consistent, level playing field that you can put everybody on. So, if everybody understands that the way that incidents are dealt with is consistent, we declare it like this, and under these conditions, these things happen. And, you know, if I flag this kind of level of impact, we have to pull in someone else to come and help make a decision.At the core of it, there's this weird kind of duality to incidents where they are both kind of semi-formulaic and that you can basically encode a lot of the processes that happen, but equally, they are incredibly chaotic and require a lot of human impact to be resilient and figure these things out because stuff that you have never seen happen before is happening and failing in ways that you never predicted. And so, this is where incident.io plays into this is that we try to take the first half of that off of your hands, which is, we will help you run your process so that all of the brain capacity you have, it goes on to the bit that humans are uniquely placed to be able to do, which is responding to these very, very chaotic, sort of, surprise events that have happened.Corey: I feel as well—because I played around in this space a bit before I used to run ops teams—and, more or less I really should have had a t-shirt then that said, “I am the root cause,” because yeah, I basically did a lot of self-inflicted outages in various environments because it turns out, I'm not always the best with computers. Imagine that. There are a number of different companies that play in the space that look at some part of the incident lifecycle. And from the outside, first, they all look alike because it's, “Oh, so you're incident.io. I assume you're PagerDuty. You're the thing that calls me at two in the morning to make sure I wake up.”Conversely, for folks who haven't worked deeply in that space, as well, of setting things on fire, what you do sounds like it's highly susceptible to the Hacker News problem. Where, “Wait, so what you do is effectively just getting people to coordinate and talk during an incident? Well, that doesn't sound hard. I could do that in a weekend.” And no, no, you can't.If this were easy, you would not have been in business as long as you have, have the team the size that you do, the customers that you do. But it's one of those things that until you've been in a very specific set of a problem, it doesn't sound like it's a real problem that needs solving.Chris: Yeah, I think that's true. And I think that the Hacker News point is a particularly pertinent one and that someone else, sort of, in an adjacent area launched on Hacker News recently, and the amount of feedback they got around, you know, “You're a Slack bot. How is this a company?” Was kind of staggering. And I think generally where that comes from is—well, first of all that bias that engineers have, which is just everything you look at as an engineer is like, “Yeah, I can build that in a weekend.” I think there's often infinite complexity under the hood that just gets kind of brushed over. But yeah, I think at the core of it, you probably could build a Slack bot in a weekend that creates a channel for you in Slack and allows you to post somewhere that some—Corey: Oh, good. More channels in Slack. Just when everyone wants.Chris: Well, there you go. I mean, that's a particular pertinent one because, like, our tool does do that. And one of the things—so I built at Monzo, a version of incident.io that we used at the company there, and that was something that I built evenings and weekends. And among the many, many things I never got around to building, archiving and cleaning up channels was one of the ones that was always on that list.And so, Monzo did have this problem of littered channels everywhere, I think that sort of like, part of the problem here is, like, it is easy to look at a product like ours and sort of assume it is this sort of friendly Slack bot that helps you orchestrate some very basic commands. And I think when you actually dig into the problems that organizations above a certain size have, they're not solved by Slack bots. They're solved by platforms that help you to encode your processes that otherwise have to live on a Google Doc somewhere which is five pages long and when it's 2 a.m. and everything's on fire, I guarantee you not a single person reads that Google Doc, so your process is as good as not in place at all. That's the beauty of a tool like ours. We have a powerful engine that helps you basically to encode that and take some load off of you.Corey: To be clear, I'm also not coming at this from a position of judging other people. I just look right now at the Slack workspace that we have The Duckbill Group, and we have something like a ten-to-one channel-to-human ratio. And the proliferation of channels is a very real thing. And the problem that I've seen across the board with other things that try to address incident management has always been fanciful at best about what really happens when something breaks. Like, you talk about, oh, here's what happens. Step one: you will pull up the Google Doc, or you will pull up the wiki or the rest, or in some aspirational places, ah, something seems weird, I will go open a ticket in Jira.Meanwhile, here in reality, anyone who's ever worked in these environments knows that step one, “Oh shit, oh shit, oh shit, oh shit, oh shit. What are we going to do?” And all the practices and procedures that often exist, especially in orgs that aren't very practiced at these sorts of things, tend to fly out the window and people are going to do what they're going to do. So, any tool or any platform that winds up addressing that has to accept the reality of meeting people where they are not trying to educate people into different patterns of behavior as such. One of the things I like about your approach is, yeah, it's going to be a lot of conversation in Slack that is a given we can pretend otherwise, but here in reality, that is how work gets communicated, particularly in extremis. And I really appreciate the fact that you are not trying to, like, fight what feels almost like a law of nature at this point.Chris: Yeah, I think there's a few things in that. The first point around the document approach or the clearly defined steps of how an incident works. In my experience, those things have always gone wrong because—Corey: The data center is down, so we're going to the wiki to follow our incident management procedure, which is in the data center just lost power.Chris: Yeah.Corey: There's a dependency problem there, too. [laugh].Chris: Yeah, a hundred percent. [laugh]. A hundred percent. And I think part of the problem that I see there is that very, very often, you've got this situation where the people designing the process are not the people following the process. And so, there's this classic, I've heard it through John Allspaw, but it's a bunch of other folks who talk about the difference between people, you know, at the sharp end or the blunt end of the work.And I think the problem that people are facing the past is you have these people who sit in the, sort of, metaphorical upstairs of the office and think that they make a company safe by defining a process on paper. And they ship the piece of paper and go, “That is a good job for me done. I'm going to leave and know that I've made the bank—the other whatever your organization does—much, much safer.” And I think this is where things fall down because—Corey: I want to ambush some of those people in their performance reviews with, “Cool. Just for fun, all the documentation here, we're going to pull up the analytics to see how often that stuff gets viewed. Oh, nobody ever sees it. Hmm.”Chris: It's frustrating. It's frustrating because that never ever happens, clearly. But the point you made around, like, meeting people where you are, I think that is a huge one, which is incidents are founded on great communication. Like, as I said earlier, this is, like, a form of team with someone you've never ever worked with before and the last thing you want to do is be, like, “Hey, Corey, I've never met you before, but let's jump out onto this other platform somewhere that I've never been or haven't been for weeks and we'll try and figure stuff out over there.” It's like, no, you're going to be communicating—Corey: We use Slack internally, but we have a WhatsApp chat that we wind up using for incident stuff, so go ahead and log into WhatsApp, which you haven't done in 18 months, and join the chat. Yeah, in the dawn of time, in the mists of antiquity, you vaguely remember hearing something about that your first week and then never again. This stuff has to be practiced and it's important to get it right. How do you approach the inherent and often unfortunate reality that incident response and management inherently becomes very different depending upon the specifics of your company or your culture or something like that? In other words, how cookie-cutter is what you have built versus adaptable to different environments it finds itself operating in?Chris: Man, the amount of time we spent as a founding team in the early days deliberating over how opinionated we should be versus how flexible we should be was staggering. The way we like to describe it as we are quite opinionated about how we think incidents should be run, however we let you imprint your own process into that, so putting some color onto that. We expect incidents to have a lead. That is something you cannot get away from. However, you can call the lead whatever makes sense for you at your organization. So, some folks call them an incident commander or a manager or whatever else.Corey: There's overwhelming militarization of these things. Like, oh, yes, we're going to wind up taking a bunch of terms from the military here. It's like, you realize that your entire giant screaming fire is that the lights on the screen are in the wrong pattern. You're trying to make them in the right pattern. No one dies here in most cases, so it feels a little grandiose for some of those terms being tossed around in some cases, but I get it. You've got to make something that is unpleasant and tedious in many respects, a little bit more gripping. I don't envy people. Messaging is hard.Chris: Yeah, it is. And I think if you're overly virtuoustic and inflexible, you're sort of fighting an uphill battle here, right? So, folks are going to want to call things what they want to call things. And you've got people who want to import [ITIL 00:15:04] definitions for severity ease into the platform because that's what they're familiar with. That's fine.What we are opinionated about is that you have some severity levels because absent academic criticism of severity levels, they are a useful mechanism to very coarsely and very quickly assess how bad something is and to take some actions off of it. So yeah, we basically have various points in the product where you can customize and put your own sort of flavor on it, but generally, we have a relatively opinionated end-to-end expectation of how you will run that process.Corey: The thing that I find that annoys me—in some cases—the most is how heavyweight the process is, and it's clearly built by people in an ivory tower somewhere where there's effectively a two-day long postmortem analysis of the incident, and so on and so forth. And okay, great. Your entire site has been blown off the internet, yeah, that probably makes sense. But as soon as you start broadening that to things like okay, an increase in 500 errors on this service for 30 minutes, “Great. Well, we're going to have a two-day postmortem on that.” It's, “Yeah, sure would be nice if we could go two full days without having another incident of that caliber.” So, in other words, whose foot—are we going to hire a new team whose full-time job it is, is to just go ahead and triage and learn from all these incidents? Seems to me like that's sort of throwing wood behind the wrong arrows.Chris: Yeah, I think it's very reductive to suggest that learning only happens in a postmortem process. So, I wrote a blog, actually, not so long ago that is about running postmortems and when it makes sense to do it. And as part of that, I had a sort of a statement that was [laugh] that we haven't run a single postmortem when I wrote this blog at incident.io. Which is probably shocking to many people because we're an incident company, and we talk about this stuff, but we were also a company of five people and when something went wrong, the learning was happening and these things were sort of—we were carving out the time, whether it was called a postmortem, or not to learn and figure out these things. Extrapolating that to bigger companies, there is little value in following processes for the sake of following processes. And so, you could have—Corey: Someone in compliance just wound up spitting their coffee over their desktop as soon as you said that. But I hear you.Chris: Yeah. And it's those same folks who are the ones who care about the document being written, not the process and the learning happening. And I think that's deeply frustrating to me as—Corey: All the plans, of course, assume that people will prioritize the company over their own family for certain kinds of disasters. I love that, too. It's divorced from reality; that's ridiculous, on some level. Speaking of ridiculous things, as you continue to grow and scale, I imagine you integrate with things beyond just Slack. You grab other data sources and over in the fullness of time.For example, I imagine one of your most popular requests from some of your larger customers is to integrate with their HR system in order to figure out who's the last engineer who left, therefore everything immediately their fault because lord knows the best practice is to pillory whoever was the last left because then they're not there to defend themselves anymore and no one's going to get dinged for that irresponsible jackass's decisions, even if they never touched the system at all. I'm being slightly hyperbolic, but only slightly.Chris: Yeah. I think [laugh] that's an interesting point. I am definitely going to raise that feature request for a prefilled root cause category, which is, you know, the value is just that last person who left the organization. That it's a wonderful scapegoat situation there. I like it.To the point around what we do integrate with, I think the thing is actually with incidents that's quite interesting is there is a lot of tooling that exists in this space that does little pockets of useful, valuable things in the shape of incidents. So, you have PagerDuty is this system that does a great job of making people's phone making noise, but that happens, and then you're dropped into this sort of empty void of nothingness and you've got to go and figure out what to do. And then you've got things like Jira where clearly you want to be able to track actions that are coming out of things going wrong in some cases, and that's a great tool for that. And various other things in the middle there. And yeah, our value proposition, if you want to call it that, is to bring those things together in a way that is massively ergonomic during an incident.So, when you're in the middle of an incident, it is really handy to be able to go, “Oh, I have shipped this horrible fix to this thing. It works, but I must remember to undo that.” And we put that at your fingertips in an incident channel from Slack, that you can just log that action, lose that cognitive load that would otherwise be there, move on with fixing the thing. And you have this sort of—I think it's, like, that multiplied by 1000 in incidents that is just what makes it feel delightful. And I cringe a little bit saying that because it's an incident at the end of the day, but genuinely, it feels magical when some things happen that are just like, “Oh, my gosh, you've automatically hooked into my GitHub thing and someone else merged that PR and you've posted that back into the channel for me so I know that that happens. That would otherwise have been a thing where I jump out of the incident to go and figure out what was happening.”Corey: This episode is sponsored in part by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: The problem with the cloud, too, is the first thing that, when there starts to be an incident happening is the number one decision—almost the number one decision point is this my shitty code, something we have just pushed in our stuff, or is it the underlying provider itself? Which is why the AWS status page being slow to update is so maddening. Because those are two completely different paths to go down and you are having to pursue both of them equally at the same time until one can be ruled out. And that is why time to identify at least what side of the universe it's on is so important. That has always been a bit of a tricky challenge.I want to talk a bit about circular dependencies. You target a certain persona of customer, but I'm going to go out on a limb and assume that one explicit company that you are not going to want to do business with in your current iteration is Slack itself because a tool to manage—okay, so our service is down, so we're going to go to Slack to fix it doesn't work when the service is Slack itself. So, that becomes a significant challenge. As you look at this across the board, are you seeing customers having problems where you have circular dependency issues with this? Easy example: Slack is built on top of AWS.When there's an underlying degradation of, huh, suddenly us-east-1 is not doing what it's supposed to be doing, now, Slack is degraded as well, as well as the customer site, it seems like at that point, you're sort of in a bit of tricky positioning as a customer. Counterpoint, when neither Slack nor your site are working, figuring out what caused that issue doesn't seem like it's the biggest stretch of the imagination at that point.Chris: I've spent a lot of my career working in infrastructure, platform-type teams, and I think you can end up tying yourself in knots if you try and over-optimize for, like, avoiding these dependencies. I think it's one of those, sort of, turtles all the way down situations. So yes, Slack are unlikely to become a customer because they are clearly going to want to use our product when they are down.Corey: They reach out, “We'd like to be your customer.” Your response is, “Please don't be.” None of us are going to be happy with this outcome.Chris: Yeah, I mean, the interesting thing that is that we're friends with some folks at Slack, and they believe it or not, they do use Slack to navigate their incidents. They have an internal tool that they have written. And I think this sort of speaks to the point we made earlier, which is that incidents and things failing or not these sort of big binary events. And so—Corey: All of Slack is down is not the only kind of incident that a company like Slack can experience.Chris: I'd go as far as that it's most commonly not that. It's most commonly that you're navigating incidents where it is a degradation, or some edge case, or something else that's happened. And so, like, the pragmatic solution here is not to avoid the circular dependencies, in my view; it's to accept that they exist and make sure you have sensible escape hatches so that when something does go wrong—so a good example, we use incident.io at incident.io to manage incidents that we're having with incident.io. And 99% of the time, that is absolutely fine because we are having some error in some corner of the product or a particular customer is doing something that is a bit curious.And I could count literally on one hand the number of times that we have not been able to use our products to fix our product. And in those cases, we have a fallback which is jump into—Corey: I assume you put a little thought into what happened. “Well, what if our product is down?” “Oh well, I guess we'll never be able to fix it or communicate about it.” It seems like that's the sort of thing that, given what you do, you might have put more than ten seconds of thought into.Chris: We've put a fair amount of thought into it. But at the end of the day, [laugh] it's like if stuff is down, like, what do you need to do? You need to communicate with people. So, jump on a Google Chat, jump on a Slack huddle, whatever else it is we have various different, like, fallbacks in different order. And at the core of it, I think this is the thing is, like, you cannot be prepared for every single thing going wrong, and so what you can be prepared for is to be unprepared and just accept that humans are incredibly good at being resilient, and therefore, all manner of things are going to happen that you've never seen before and I guarantee you will figure them out and fix them, basically.But yeah, I say this; if my SOC 2 auditor is listening, we also do have a very well-defined, like, backup plan in our SOC 2 [laugh] in our policies and processes that is the thing that we will follow that. But yeah.Corey: The fact that you're saying the magic words of SOC 2, yes, exactly. Being in a responsible adult and living up to some baseline compliance obligations is really the sign of a company that's put a little thought into these things. So, as I pull up incident.io—the website, not the company to be clear—and look through what you've written and how you talk about what you're doing, you've avoided what I would almost certainly have not because your tagline front and center on your landing page is, “Manage incidents at scale without leaving Slack.” If someone were to reach out and say, well, we're down all the time, but we're using Microsoft Teams, so I don't know that we can use you, like, the immediate instinctive response that I would have for that to the point where I would put it in the copy is, “Okay, this piece of advice is free. I would posit that you're down all the time because you're the kind of company to use Microsoft Teams.” But that doesn't tend to win a whole lot of friends in various places. In a slightly less sarcastic bent, do you see people reaching out with, “Well, we want to use you because we love what you're doing, but we don't use Slack.”Chris: Yeah. We do. A lot of folks actually. And we will support Teams one day, I think. There is nothing especially unique about the product that means that we are tied to Slack.It is a great way to distribute our product and it sort of aligns with the companies that think in the way that we do in the general case but, like, at the core of what we're building, it's a platform that augments a communication platform to make it much easier to deal with a high-stress, high-pressure situation. And so, in the future, we will support ways for you to connect Microsoft Teams or if Zoom sought out getting rich app experiences, talk on a Zoom and be able to do various things like logging actions and communicating with other systems and things like that. But yeah, for the time being very, very deliberate focus mechanism for us. We're a small company with, like, 30 people now, and so yeah, focusing on that sort of very slim vertical is working well for us.Corey: And it certainly seems to be working to your benefit. Every person I've talked to who is encountered you folks has nothing but good things to say. We have a bunch of folks in common listed on the wall of logos, the social proof eye chart thing of here's people who are using us. And these are serious companies. I mean, your last job before starting incident.io was at Monzo, as you mentioned.You know what you're doing in a regulated, serious sense. I would be, quite honestly, extraordinarily skeptical if your background were significantly different from this because, “Well, yeah, we worked at Twitter for Pets in our three-person SRE team, we can tell you exactly how to go ahead and handle your incidents.” Yeah, there's a certain level of operational maturity that I kind of just based upon the name of the company there; don't think that Twitter for Pets is going to nail. Monzo is a bank. Guess you know what you're talking about, given that you have not, basically, been shut down by an army of regulators. It really does breed an awful lot of confidence.But what's interesting to me is the number of people that we talk to in common are not themselves banks. Some are and they do very serious things, but others are not these highly regulated, command-and-control, top-down companies. You are nimble enough that you can get embedded at those startup-y of startup companies once they hit a certain point of scale and wind up helping them arrive at a better outcome. It's interesting in that you don't normally see a whole lot of tools that wind up being able to speak to both sides of that very broad spectrum—and most things in between—very effectively. But you've somehow managed to thread that needle. Good work.Chris: Thank you. Yeah. What else can I say other than thank you? I think, like, it's a deliberate product positioning that we've gone down to try and be able to support those different use cases. So, I think, at the core of it, we have always tried to maintain the incident.io should be installable and usable in your very first incident without you having to have a very steep learning curve, but there is depth behind it that allows you to support a much more sophisticated incident setup.So, like, I mean, you mentioned Monzo. Like, I just feel incredibly fortunate to have worked at that company. I joined back in 2017 when they were, I don't know, like, 150,000 customers and it was just getting its banking license. And I was there for four years and was able to then see it scale up to 6 million customers and all of the challenges and pain that goes along with that both from building infrastructure on the technical side of things, but from an organizational side of things. And was, like, front-row seat to being able to work with some incredibly smart people and sort of see all these various different pain points.And honestly, it feels a little bit like being in sort of a cheat mode where we get to this import a lot of that knowledge and pain that we felt at Monzo into the product. And that happens to resonate with a bunch of folks. So yeah, I feel like things are sort of coming out quite well at the moment for folks.Corey: The one thing I will say before we wind up calling this an episode is just how grateful I am that I don't have to think about things like this anymore. There's a reason that the problem that I chose to work on of expensive AWS bills being very much a business-hours only style of problem. We're a services company. We don't have production infrastructure that is externally facing. “Oh, no, one of our data analysis tools isn't working internally.”That's an interesting curiosity, but it's not an emergency in the same way that, “Oh, we're an ad network and people are looking at ads right now because we're broken,” is. So, I am grateful that I don't have to think about these things anymore. And also a little wistful because there's so much that you do it would have made dealing with expensive and dangerous outages back in my production years a lot nicer.Chris: Yep. I think that's what a lot of folks are telling us essentially. There's this curious thing with, like, this product didn't exist however many years ago and I think it's sort of been quite emergent in a lot of companies that, you know, as sort of things have moved on, that something needs to exist in this little pocket of space, dealing with incidents in modern companies. So, I'm very pleased that what we're able to build here is sort of working and filling that for folks.Corey: Yeah. I really want to thank you for taking so much time to go through the ethos of what you do, why you do it, and how you do it. If people want to learn more, where's the best place for them to go? Ideally, not during an incident.Chris: Not during an incident, obviously. Handily, the website is the company name. So, incident.io is a great place to go and find out more. We've literally—literally just today, actually—launched our Practical Guide to Incident Management, which is, like, a really full piece of content which, hopefully, will be useful to a bunch of different folks.Corey: Excellent. We will, of course, put a link to that in the [show notes 00:29:52]. I really want to thank you for being so generous with your time. Really appreciate it.Chris: Thanks so much. It's been an absolute pleasure.Corey: Chris Evans, Chief Product Officer and co-founder of incident.io. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice along with an angry comment telling me why your latest incident is all the intern's fault.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

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.

Chris is weathering through a slight lull, a holding period, where his team waits for new features to become available with some of the platforms they integrate with, and as they think out new facets of the platform they're building. Steph has been thinking recently about working in isolation. It's a topic that Joël Quenneville pointed out to her and mentioned. Can engineers work in isolation and be successful? Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Always be singing. STEPH: I can't remember if I've shared the story with you. But I had a beautiful little human moment with someone at airport security. Because when I travel with my mic, I always get stopped because there's the middle long, thin piece that looks like what you would screw on to a gun like for a silencer. And so [laughs] as he was going through, the person was looking at it, and then he called over a buddy. And then they called over another buddy, and there's like three TSA agents all looking at the X-ray screen. And finally, they're like, "Yeah, we need to flag it." So they moved it over. And then he was digging through, and he pulled out the big metal piece. And I said, "It's for a microphone." And he's like, "Okay," and he kept looking, and then he finally found the microphone. And he lit up because I guess he wasn't really sure to believe me at first when I said it. But he lit up, and he was like, "Karaoke?" [laughs] I was like, "No, it's for podcasting." CHRIS: But not 100% no because we do sing plenty on this show, so... STEPH: I think that's what made me think of it. It was your singing. [laughs] CHRIS: Yep. My wonderful, wonderful singing. 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's new in my world? We are in sort of a...what's the word? There's a bit of a lull right now, not like a big lull, but we had a bunch of clear work that came into the team, did a bunch of iterations, some testing, built some new features, et cetera. And now there's a small holding period basically where we wait for some new features to become available with some of the platforms that we integrate with and also as we think out some new facets of the platform that we're building. So we've got this little bit of time here where we're not necessarily building out as many new novel features. But instead, as a dev team, we're taking this moment to be like, oh, cool, let's tie down. I want to make a sailing analogy here, but I don't know sailing. It's like tie down the somethings and batten the hatches, maybe. That sounds like a thing. [chuckles] But so we have a couple of projects going right now. We want to really accept the truth and lean into Sidekiq. So right now, we have a mix of ActiveJob and Sidekiq jobs. And they're confusing, and et cetera, et cetera. So we want to kind of lean into that, upgrade dependencies, that sort of thing. We are, again, doing a little bit of work on the observability foundation of our system. so how do we know what's going on at runtime? Also, working on just some core features and functionality. We have done a little bit of an exploration into the event processing stuff, some of that that I've been talking about. It's actually been very interesting. So we're working with Customer.io as a platform, which is omnichannel communication behavior-based messaging sort of thing. So when a user does X, send them an email and then wait three days. And if they haven't responded, then do this other thing. And I think I've said this in previous episodes; I'm so wildly impressed with that platform. They have done such a good job. And I know that good software doesn't happen in a vacuum. In fact, if we're being honest, a lot of the software out there is not very good. And not only do they do a good job, but it's across...there's a ton of functionality in Customer.io. And it's interesting because we're finding ourselves leaning into it even more because it is such a solid platform and because it connects into our event system. Like, it's a segment destination, so all of our analytics events get piped into Customer.io, and then we can action on any of them. And the actions can be quite complicated. And this is where we're getting into good idea, terrible idea space. And to be clear, this is still just an exploration. But we basically wanted a way to do more. There are a bunch of different actions that you can take so, like send an email, send an SMS, or there are a couple of other slightly fancier ones. You can trigger an event within the Customer.io system. You can actually do an arbitrary HTTP POST, PUT, PATCH, whatever, any web requests you want to make. So if you want to integrate with essentially anything else out there, you can do that. You can send some structured data over the wire. And so we've now been like, okay, what if, and stay with me here, what if we use our analytic system and we send events whenever a user does something, and then that event eventually trickles down to Customer.io? Within that, we allow ourselves to respond to that event by emitting a different event within the system, within Customer.io. And then, via the webhook functionality, we fire that back to the Rails application. And then there we can do whatever we want. And in a way, that sounds absurd because we're starting from our app, and then we're sending some events down, processing them in certain ways, sending it back to the app, and then maybe doing something. In particular, one of the things we want to do is richly formatted Slack alerts. And Customer.io has a Slack alert functionality, but they can't have any of the fancy stuff. They can't link to our customer in the admin dashboard. So we found that that functionality is particularly useful for our admin team. And so we're like, ah, this feels weird. But if we were to do this loop out and back, then ideally, we get the power of Customer.io for non-technical users or non-engineering team users to configure workflows and to say, "When a user does this, I actually want to alert the admin team via Slack." And we want it to be rich and have buttons that you can click and all that kind of stuff. And although the thing that I just described seems complicated, is a word that I'll use for it, confusing at times, it isn't...like, I don't want to do all of that in the app. I don't want the app to have to think about how do I wait three days? We technically can do that with Sidekiq, but it gets us in trouble and whatnot, whereas Customer.io that's a core concept for them. And so, again, very much exploration. This will probably be a future good idea, terrible idea segment. But that's been an interesting one to explore. STEPH: You have quite a talent for you preface something as a bad idea, and you do a very good job of making it sound reasonable and good. [laughs] So it's interesting to be on that side of like, good idea, bad idea. It's like, I'm looking for the bad. And I have questions, but overall, [chuckles] you do a very good job of being very thoughtful and walking through why it makes sense or what are the benefits of it. So you answered some of my questions around why still send it to Customer.io versus just having it all in-house. So the fact that the admin team has access to it makes a lot of sense. I want to clarify one point. So when you send it to Customer.io, Customer.io then needs to send a message back to your application. And then that's when you customize the Slack message. Do you need Customer.io to send that message, or could you just fire off an event to Customer.io to say, "Hey, capture this, but don't do anything with this. And then we're going to send the Slack message because we want to customize it."? CHRIS: I think the key is that we want to leverage the fact that Customer.io is the platform that our operations team really is now becoming comfortable with and using for this behavioral automation workflow type logic. So that idea of when this event, you know, when this triggering event happens, if this condition is true, then respond in this way. And so because Customer.io is the platform that A, is quite good at that and B, is where our admin team is now thinking about doing that, one thing that we might do let's say a user completes some action within the application. So they fill out a form to submit their interest in some new platform feature. Initially, what we might want to do there is alert ourselves to say, "Hey, this happened. Take some action." And then eventually, we may want to instead switch that over and send an email to the customer with the next steps that they need to do. And the ability to gradually transition across that spectrum is really interesting to me, and again, Customer.io being the platform, sort of the hub for how we respond to these events. At the same time, I know that this feels like a generic message processing system that might be a Kafka queue somewhere else. And so I've got that in the back of my head of like, is this weird? I think it's a little weird. But it also, thus far as we're exploring it, is very approachable for the admin team, very familiar for them, and reasonably powerful. And also, there's a drag and drop editor for the events and the payloads. And it knows for this event, here's the stuff that's available to you. And so the ability for our admin team to interact with that interface is really great. And we don't have to build it. We don't have to think about it. But I will say I've worked at so many different companies that have their ad hoc system that makes it easy to do generic X, Y, and Z. And it's bad, and it falls down. And it's impossible to know when anything happens. And so, I've got a lot of concerns in the back of my head, which I will want to at least think through and understand the trade-offs that we're making if we pursue this path, but it is very interesting to me. So right now, a lot of this logic does live in the app. But it means that it requires a code change for anything that we want to do like this. We want to have a Slack alert whenever X happens. Now, the developers are in the loop for all of that. And really, it's the operations team that owns the decisioning on that. And so if they can also self-serve and instrument the action, the alert, the follow-up, the whatever it is, if we can give them those primitives in a platform that they already understand, that sounds nice. I'm intrigued, is what I'll say. So anyway, while we're in this lull period, we are trying out some fun stuff like that and exploring those sorts of things. STEPH: I like that perspective that you're putting on it, or at least the one that's standing out to me is the concept of ownership is like who gets to own these actions. But then beyond that, that's the part where I feel a little squirmy is, so we are using this third-party tool because it makes life easier. But then, at what point when we start building software around this third-party tool to then customize it back on our own side. Then if someone is in Customer.io, so if an admin user is in there and then they trigger an event, is there going to be confusion as to what's going to happen? And can they retry an event? Because I'm realizing my initial suggestion where it was like, hey, notify Customer.io that this is there but then also manage sending the Slack message that would prevent them from being able to have that retry capability. And that may be very much worth preserving. So then it's understood that hey, if you want to manage this, we are giving you full access to manage this work. We may customize it, but this is still the interface in which you go through to have three tries or to manage that workflow or these actions that get sent to users. CHRIS: Yeah. I think you've perfectly highlighted the why this might not be a great idea or at least the concerns to explore before adopting this more thoroughly. And even just the idea of adopting it more thoroughly, like, how tied into the system are we? How business-critical does this new external piece of software become? Because I've seen that to be really problematic where there are organizations that I've worked with that are like, "Oh God, we would love to move off of system X. But unfortunately, it's basically the one thing holding this business up." And I'm like, yeah, I get that. And that happens. So yeah, being really intentional with that. And that's why we're very much in an exploration place. But we have a bunch of stuff that we've done that required engineering work. And we're now seeing like, actually, could we map this into this other tool? And can we build the set of primitives in that space that now this team can own that whole experience? And then critically, can they debug it? Will we know when something goes wrong, et cetera? Those are always parts. At this point, I don't think I can just imagine a happy path. And I hope this isn't true for the rest of my life. But the work as a software developer, especially after having done a couple of rounds of it and as a consultant, I just imagine failure modes. It's all I do. I'll be like, okay, we just need to wire X up to Z, and then we need to fire off a request. And then, once we get the message back, then we can process them. I'm like, right. You just described 13 things that can go wrong. Now let's imagine each of the different failure states because that's all I'm going to do. Who cares about the happy path? Those are easy. Those write themselves. It's all of the failure modes that I need to think about. And someday, when I retire, and I go to a log cabin in the woods, and I don't talk to people for a while, maybe I'll go back to a place of only happy paths. But that is not my truth right now. STEPH: I can't tell you how many people in my personal life I have annoyed so much [laughs] because all I see are failure modes. And one, that's a delightful t-shirt. [laughs] I'd love to have that. And then yeah, I feel you because there are so many times where someone is...like, I'm with someone who's like a big idea person. And so they're just launching into what-ifs, and we did this. And I can't help it, and I have learned to help it. But it has been a struggle with some strong feedback from family and friends to reel it in. Because then I will start to think through okay, well, what's the details? And I have some questions. What happens when this happens? And yeah, all I see are failure modes. [laughs] It is very true for me too, and not always...not so great. So I, too, shall get a log cabin one day and try to forget all of that. CHRIS: I will say I painted that as a particularly glib version of myself. But some of what I'm doing right now, particularly joining an early-stage startup and taking the role of CTO, was very much to try and intentionally resist that. Because right now, I have to be really careful with how much of the potential edge cases and whatnot. I'm considering exactly how robust of a platform are we building? Very is the answer. But what about extremely? Because extremely is an option but extremely costs four times as much. Mostly in time being the critical element there. And so part of the work that I'm doing now is just trying to push on those edges, push on those boundaries, find the places where we can move quickly, and still build a robust platform because frankly, we're building...Sagewell is a financial platform under the hood, and I can't be flippant with that. We as a team have to be really careful with the thing that we're building. But we also have to move quickly. We have to be able to iterate. We have to be able to build something and try it out and see if it works. And then, if it doesn't, maybe shelve it and pull it out of the codebase. And it has been a real challenge, but it was the challenge that I wanted here. And so I've been enjoying that work, but it has been a stretch, a growth moment, let's call it. STEPH: I don't know if you've shared that particular goal with me in transitioning to a CTO role, but I really, really like it. One, it's very aligned with who you are. You're very thoughtful, and you look for areas to push and ways to do that. And then I also struggle in those areas, and thoughtbot specifically and consulting has helped push me in directions, push me out of my comfort zones but still in a safe space where I have other people to talk to as I'm making those decisions and pushing past the comfort areas that I have. But one of them is that I will initially think things have to be perfect or really planned. And I had a really nice conversation with Chad Pytel, who is one of the Founders of thoughtbot and also COO and host of the Giant Robots Smashing Into Other Giant Robots Podcast. And we were chatting about a new offering that thoughtbot is bringing to the market. And it's one that I've been involved with. And I started getting really in the weeds of like, but we really have to plan out how this is going to look and all the actions that need to take place before then we can really sell this type of engagement to a new client. And as I was going through this list of worries, when I was done, he mentioned he's like, "All of those are valid and something to consider." He's like, "But we don't have any customers yet." So the first part is we feel that we are in a space that we have enough of information to get started. And it's something that we've done before. And then, we'd like to see where customers align with us on this need because we're going to end up shaping this work in response to what their needs are. And so, we can't really begin that shaping until we understand more of what people are looking for. I was like, oh yeah, that's such a nice point. It just reminded me in regard to pushing those boundaries of yes, we need planning upfront, and we look for failure modes. But then there's also an important aspect of then finding ways to keep moving forward and getting more feedback and then balancing those two. CHRIS: Yeah, I think that's definitely right the as always, anchoring it to the customer. What is it that they need? How do we connect with them and hear from them? And ideally, keep those feedback loops as short as possible. That's the game, and everything else fits around that. But yeah, so we're trying some stuff. We'll see how it goes. I will certainly report back, depending on how it plays out. But that's a little bit of what's up in my world. What's up in your world? STEPH: I have been thinking recently about working in isolation. It's a topic that Joël Quenneville, who's another thoughtboter and has been on the show a number of times, it was a topic that he'd actually pointed out to me and mentioned. And so, I wanted to bring that here and share it with you because I'd love to get some of your thoughts on this as well. But I've typically had the viewpoint that when developers are sent off to work on a large, nebulous task, that it's a recipe for disaster, and almost everyone's going to lose in that scenario. And it tends to be a combination of isolation, very distant due dates, and loosely defined scope that leads to those really poor results. However, as developers, it's not inconceivable for us to land in that position. And it's very similar to my current project, who I'm working with Joël on, where we were given a very fuzzy project with some really aggressive goals, and the engagement is going really well. So that led Joël and I to wonder why is this working? This is the thing that we said that people should never do, but it's actually going quite well for us. So reflecting upon some of the things that are working well for us, even though we are in more of an isolated state than we would typically work, some of the things that I've been reflecting on or some of the strategies I should say that we've applied to this situation is number one, we did work hard to plug into an existing team. So when we joined, we joined more of an ad hoc volunteer team. And in everybody's spare time, those individuals were then contributing to the CI process in terms of trying to speed things up and improve things for the rest of the team. But otherwise, there wasn't really a team. There wasn't much structure to it. So it felt like everybody was very much off in their own world doing their own thing, occasionally putting up some code changes for review. And then you had to gain a lot of context to understand what it was that they were doing. So one of the things that I advocated for early on that I thought was more of just my personal preference but I think has actually worked well in regards to the success of the project as well is to plug into an existing team. So even if you are not working with that team on their day-to-day tasks, but you want to have more people to interact with and more people to share your context with. So you are essentially reducing the isolation of you're no longer these two people who are off in a corner working on something, and nobody has any idea what you're doing, and only one person is getting a status update. There is now a whole channel or team of people that have some insight as to what's going on. And they can also really unblock you for when you get stuck because then if you do have a question, but there's that one person who has been like your go-to person for this whole project, if they're out on vacation, or if they leave, or just something happens, you're suddenly blocked. And you don't know who to go to because you've been part of this larger company, but you haven't interacted with anybody outside of that one person. So at least if you're plugged into another team, you've immediately got some friends or some other people to go to and say, "Hey, I'm not sure who can help me with this, but I have this problem." And then, from there, you can get more help. CHRIS: This is super interesting. To start, I really like that you're framing this in terms of this is a thing that we often recommend against or see as an anti-pattern, and yet in this particular case, it's working. Let's look at that. Because I think the things that you're like, huh, that's interesting. That phrase "Huh, that's interesting" is very interesting. It often highlights like oh, something is behaving counter to how we would expect it to, so let's dig in and explore that. And so I love that that was the reaction and then sort of the conversation that spilled out of that. I'm also not super surprised that the combination of you and Joël were able to find a way to make this successful because you are two of the most capable developers that I've worked with but also particularly excellent communicators and advocates for the work that you're doing and the way that one should do the work. So the idea that there's a situation that may not be the ideal mode of working and that you're able to take that and say, "What if we shift it just a little bit and make it a little bit more manageable and whatnot?" So unsurprised, frankly, that you found a way collectively to make this a little bit better. And then I think yeah, it sounds like you're doing the things...so just like, we're in isolation, hmm, that doesn't seem great. Let's unisolate and connect to some people, and that just feels so true. I'm very interested to hear, though. I'm guessing there's more to this story or other things that you've done. Are there other tactics or ways that you've shifted this around? STEPH: Yeah, there's a couple more. So this is one that (And thank you for the kind words.) this was one that I think Joël is really exceptional at. So Joël is really good at building diagrams and graphs and then sharing that with the team as sort of like we've spent a couple of days understanding this big, messy concept. Here's a nice condensed graph that shows how we went about understanding this. And then here's the big overall picture of what we've learned from this, which has been wonderful for so many reasons. And every time that we share something with the team, one, it just helps build camaraderie, especially in remote days, it just builds camaraderie on hey, we're all online. And we're working. And here's the thing that I'm working through or struggling with or something that I learned. I often do that, especially when I get frustrated and something goes wrong. I love to share the I did this today. It went terribly. [laughs] Let me tell you about it, so you're aware of it in case it helps you. And specifically, the diagrams are really nice because then other people can just see and appreciate it, or they can point something out that we didn't know. Or they'll see a different angle because they're more familiar with the system. So they can say, "Oh yeah, that totally makes sense," or "I had no idea that was happening." So that's been a really nice way to engage with the team. And so, essentially, the little title for that strategy is just overshare. Just share all the things that you're doing and find ways to make it digestible for the team so then they can go along on this big, nebulous journey with you. And you can also put it in threads so that way, you're not flooding a channel, but then people can opt-in to that oversharing if they would like more insight into the work that you're doing. CHRIS: Opt-in to that oversharing. [laughs] STEPH: Exactly. I mean, it's not forced oversharing; it's just it's here if people would like it. That was a really nice compliment that some other thoughtboters received from their client team is someone had mentioned that there's so much information that's getting shared from the thoughtboters that they had trouble keeping up. And they really liked that. They really appreciated that they could then go check out this channel or these threads and see exactly the type of work that was happening and the outcomes of it. And then they could just check it maybe beginning of the day, end of the day and get that knowledge dump. Some of the other strategies that we've used are giving ourselves mini-goals to accomplish as part of the larger, more nebulous task. So as we have this very large goal in mind, it's like, where's the small piece? Where's an entry point? What's a task or a goal that we can define? And then we want to break that down into what questions do we need to ask? How can we start moving in this direction? And we want to find something that has an answer. So each time that we start researching once we've gotten to that point...and this is hard. I feel like people may know that, but I should just say that this is hard to take something nebulous and then find the entry point and break down some goals. And that has been one of the wonderful parts of then having a buddy for this type of project because then we can bounce ideas off of each other. And we can also help the other person not go too deep into an area. Because I have definitely had moments where I've been very passionate about like, "We need to do this," and Joël is just like, do we? And I'm like, "Yeah." And he's like, "Do we though?" And I'm like, "I guess not. I just really, really want to." [laughs] It's been very helpful to have a partner balance some of those feelings. And once you can break down some of that amorphous problem into those smaller goals, then you can also create tickets, which is also a really nice way to then surface the work that you're doing. You can document how you're researching, document the question. And then once you have that question of what you're in search of, it's so nice because then once you find the answer, that's immediately a good moment to pause and reflect. So I think in a recent episode, we were chatting about this where Joël and I were trying to understand why the tests weren't being balanced properly across each process that was available. And we found the answer, and we started immediately digging into fixing it or solutions. And then it took us a moment to go back and say, "Actually, this ticket is really just about understanding the problem, not fixing the problem." And so that was a nice; now that we understand the problem, let's go back high-level to define our next goal from this big, nebulous task because maybe fixing that balancing is the right thing to do, but maybe not, and we just need to reconsider. So for that portion of breaking down a big, nebulous task and then identifying smaller tasks that you can achieve, time-boxing has been huge for us in regards of what's something that we can accomplish this week, or what's something we can accomplish today that will then move us forward? And then making sure that we are setting deadlines for ourselves. So normally, this is another area where it's like, huh, that's interesting. I'm a big believer in deadlines. But I do think self-imposed deadlines are really helpful. CHRIS: I'm intrigued to hear you say that you're not a big fan of deadlines because I assume we're actually more aligned on this. But deadlines that are arbitrary and also come with fixed scope and other immovable things, yes, those are the worst in the world. But deadlines that we set for ourselves, and then we use that as a mechanism to hone and refine the scope that we're going to get out the door by that deadline, I find those incredibly useful. And that sounds like that's the same sort of thing you have going on here is like by saying we're willing to expend this much to get a result, that defines the work going into it. STEPH: Yeah, that's fair. Everything that you said is true, too; in regards to, I'm realizing I default that when I hear the word deadline, I'm so used to teams having deadlines that are defined by other individuals that are not part of the work. And as you said, the scope has already been defined, and it can't be changed. And it's all of the bad things that then go with it. So when I think of deadlines, I immediately think of that type of deadline versus the more self-imposed, yes, we can revisit, yes, the team has bought in and understands why this is important. Those types of deadlines are very helpful. It's that first part that I default to that I think of immediately, and I need some reassurance that that is not the type of deadline that I'm looking at or being forced to meet. I have a very similar feeling for estimates. Like, those both fall in the same category for me is; as soon as I hear estimation and deadline, I get nervous. And then I just need to understand the purpose of both and who is setting both of those and the communication around them. And then what does that failure mode look like, the one that we're always looking for? So yeah, deadlines and estimations fit into that. Initially, I'm very hesitant and cautious, but I think they're both very good tools. CHRIS: Yeah, I feel like those are very closely related. And they're definitely tools that can be used for great good or for great evil. And so, ideally, we advocate for the great good usage. But more generally, I love, again, the sharing around the process and what's worked for you in this less typical or often somewhat problematic workflow. I will say, again, so I gave you the series of compliments earlier, and I stand by those compliments for you and Joël. But I think also the sort of related aspect is that you two are both quite senior, very capable, very comfortable suggesting changes, suggesting workflows. So I think the potential dangers of isolation are still very much there. And the fact that the two of you have been able to find a way to work more effectively and perhaps change the terms of things just a little bit to make this effective is A, unsurprising but B, not something that I would expect of every team. I think you've described a wonderful list of the specifics as to how you did that. And ideally, if folks that are perhaps a little earlier on in their career are sent out for a month with a wild project, and they're sent to do it in isolation, hopefully, they can borrow from that list. But again, I do think this is a thing that, from an organizational perspective, we should be very careful with when we're imposing this isolation on it because it takes two fantastic folks like you and Joël to break out of the shackles of it. STEPH: The more we're talking about this, the more apparent it's also becoming that I started with this; how do you manage isolation? And my answer is you get out of it. [laughs] Get out of isolation as quickly as possible. Someone thought it was a good idea to put you there or a good idea to structure it that way. Or maybe they didn't mean it intentionally, but that's how things then shook out. So that's really what a lot of those strategies are about is, then how do I get myself out of this corner that you put me in? Because nobody put Stephanie in a corner. So it's essentially that's all the strategies are looking for ways to say, hey, I'm isolated, but I really don't want to be, and it's dangerous for me to be isolated in this way. Even as a more senior capable developer, it's more likely that things could go wrong, and miscommunications, misaligned expectations. So I need to find ways to then bring the work that I'm doing to make it more relevant to other people on the team. So then we can have more overlap, or at least I can share a lot of the work that's being done. CHRIS: Yeah, absolutely. I think with that wonderful summary and, frankly, utterly fantastic movie reference, what do you think? Should we wrap up? STEPH: Let's do it. 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: 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.

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 is joined by a very special guest and fellow thoughtboter, Rob Whittaker. ngrok (https://ngrok.com/) Time Off Book (https://www.timeoffbook.com/) Rob's Codespace Setup (https://github.com/purinkle/codespace) Rob Whittaker on Twitter (https://twitter.com/purinkle) 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. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker. Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today. ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is. STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs] ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is. STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team. ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II. I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap. So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up. And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director. The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot. And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby. I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize. STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question. So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director? ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out. So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point. And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed. And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction. STEPH: I think the fancy term for that is just delegating. [laughs] ROB: Yes, thank you. [laughs] STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship. And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career. ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations. Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary. STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life. So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in. ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people. STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that? ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars. And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates. And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right. But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying. STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on. But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process? ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different. The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for. We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency. STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings. And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do. ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess. STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways. ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days. Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment. STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities? Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work. ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that. It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones. And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine. So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly. So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment. It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view. STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally? ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun. And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup? STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out. Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too. ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers. And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something. There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started? I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago. STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out. And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not. But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit. GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work. And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it? And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it. ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place. So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service. So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction. Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with. STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that. ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting. STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well. ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than... Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know. STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week? ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible. As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water. I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head. And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done. And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose. The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available? We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies. But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room. And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people. STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier. I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me. And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit. And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime. I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone. So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful. ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else? STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone. ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification. STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs] Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers? ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot. But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down. And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair." One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people. There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems. STEPH: Have you found any helpful strategies to normalize that take a break culture? ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from. And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well. A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together. STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea. On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk." And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example. ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards. STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose? ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer. STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up. Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that? ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily. And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you. STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up? ROB: Yeah, 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: 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.

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.

Chris switched from Trello over to Linear for product management and talks about prioritizing backlogs. Steph shares and discusses a tweet from Curtis Einsmann that super resonated with the work she's doing right now: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one." This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. Linear (https://linear.app/) Curtis Einsmann Tweet (https://twitter.com/curtiseinsmann/status/1521451508943843329) Louie Bacaj Tweet (https://twitter.com/LBacaj/status/1478241322637033474?s=20) 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 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. CHRIS: Good morning, and welcome to Tech Talk with Steph and Chris. Today at the top of the hour, it's tech traffic hits. STEPH: Ooh, tech traffic. [laughs] I like that statement. CHRIS: Yeah. The Git lanes are clogged up with...I don't know. I got nothing. STEPH: [laughs] 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? Actually, I have a specific new thing that I can share, which is, as of the past week, I would say, switched from Trello over to Linear for product management. It's been great. It was a super straightforward transfer. They actually had an importer. We lost some of the comment threads on the Trello cards. But that was easy enough to like each Linear ticket has a link back to Trello. So it's easy enough to keep the continuity. But yeah, we're in a whole new world, a system actually built for maintaining a product backlog, and, man, it shows. Trello was a bunch of lists and cards and stuff that you could link between, which was cool. But Linear is just much more purpose-built and already very, very nice. And we're very happy with the switch. STEPH: I feel like you came in real casual with that news, but that is big news, that you did a switch. [laughter] CHRIS: How are you going to bury the lead like that? You switched project management...[laughter] I actually didn't think it was...I'm excited about it but low-key excited, which is weird because I do like productivity and task management software. So you would think I would be really excited about this. But I've also tried enough of them historically to know that that's never going to be the thing that actually makes or breaks your team's productivity. It can make things worse, but it can't make you great. That's the thing that I believe. And so it's a wonderful piece of software. I'm very excited about it but -- STEPH: Ooh, I like that. It can make you worse, but it doesn't make you great. That's so true, yeah, where it causes pain. Well, and it does make sense. You've been complaining a bit about the whole login with Trello and how that's been frustrating. But I haven't even heard of Linear. That's just...that's, I mean, you're just doing what you do where you bring that new-new. I haven't heard of Linear before. CHRIS: I try to live on the cutting edge. Actually, I deeply try to not live on the cutting edge at this point in my life. That early adopter wave, no, no, no, that's not for me anymore. But I've known a few folks who've moved to Linear. And everyone that I've spoken to who has moved to it has been like, "Yeah, it's been great." I've not heard anything negative. And I've heard or experienced negative things about every other product management tool out there. And so, it seemed like an easy thing. And it was a low-cost enough switch in terms of opportunity costs or the like, it took the effort of someone on our team moving those cards over and setting up the new system and training, but it was relatively straightforward. And yeah, we're super happy with it. And it feels different now. I feel like I can see the work in a different way which is interesting. I think we had brought in a Chrome extension for Trello. I think it's like Hello Epics or something like that that allows...it abuses the card linking functionality in Trello and repurchases that feature as an epic management thing. But it's quarter-baked is how I would describe it, or it's clearly built on top of existing things that were not intended to be used exactly in that way. So it does a great job. Hello Epics does a great job of trying to make something like parent-child list management stuff happen in Trello. But it's always going feel like an afterthought, a secondary feature, something that's bolted on. Whereas in Linear, it's like, no, no, we absolutely have the idea of projects, of course, and you can see burndown charts and things. And the thing that I do want to be careful about is not leaning too much into management. Linear has the idea of cycles or sprints, as many other folks think of them, or iterations or whatever you want to call them. But we've largely not been working in that mode. We've just continued to work through the next up list; that's it. The next up list should be prioritized and well defined at the top and roughly in priority order. So just pick up the next card and work on it. And we just do that every single day. And now we're in a piece of software that has the idea of cycles, and I'm like, oh, this is vaguely interesting. Do we want to do that? Oh, but if you're going to do that, you probably do some estimation, right? And I was like, oh no, now we're into a place that's...okay, I have feelings. I got to decide how to approach that. And so, I am intrigued. And I wonder if we could just say like ten carts that's how many come into a cycle, and that's it. And we use the loosest heuristics possible to define how we structure a cycle so that we don't fall into the trap of, oh, what's our roadmap going to look like six months from now? JK, what's anything going to look like six months from now? That's not a knowable fact. STEPH: I was just thinking where you said that you're moving into sprints or cycles, and then there's that push, well, now you got to estimate. And I just thought, do you? Do you have to estimate? [laughs] CHRIS: We need a burndown chart through 2024, and it must be meticulously accurate down to the hour. STEPH: I think meticulously wrong is how that goes. [laughs] CHRIS: Which is the best kind of wrong. If you're going to be wrong, be meticulous about it. STEPH: Be thorough about it. [laughs] Yeah, the team that I'm on right now, we have our bi-weekly planning, and we go through the board, and we pull stuff in. But there's never a discussion about estimation. And I hadn't really appreciated that until just now. How we don't think about how long is this going to take? We just talked about, well, what's in-flight? And how much work do people still have going on? And then here's the list of things we can pull in. But there's always a list that you can go back to. Like, it's very...we pull in the minimum and knowing that if we run out of work, there's another place to go where there's stuff that's organized. And I just love that cadence, that idea of like, let's not try to make guesses about the future; let's just have it lined up and ready for us to go when we're ready to pull it in. Although I know, that's also coming from a very developer's perspective, and there are product managers who are trying to communicate as to when features are going to get out into the world. So I get that there's a balance, but I still have strong feelings and hesitations around estimating work. CHRIS: Well, I feel like there is a balance there. And so many things in history are like, well, this is an overcorrection against that, and that's an overcorrection against this. And the idea that we can estimate our work that far out into the future that's just obviously false to me based on every project I've ever worked on that has tried to do it. And it has always failed without question. But critically, there is the necessity to sync up work and like, oh, marketing needs to plan the launch of this feature, and it's a critical one. What's it going to look like? When's it going to be ready? You know, we're trying to go for an event, it's not just know...we developers never estimate anything past the immediate moment where like, that's not acceptable. We got to find a middle ground here. But where that middle ground is, is interesting. And so, just operating in the sort of we do work as it comes up is the easiest thing because no one's lying about anything at that point. But sometimes you got to make some guesses and make some estimations. And then it gets into the murky area of I believe with 75% confidence that in three weeks, we will have this feature ready. But to be clear, I said with 75% confidence that means one-quarter of the time; we will not be there at that date. What does that mean? What does that failure mode look like? Let's talk about that. And can you have honest, open, transparent, useful conversations there? That's the space that it becomes more subtle if you need to do that. STEPH: You're reminding me of a conversation that I had with someone where they shared with me some very aggressive team goals. And it was a very friendly conversation. And they're like, "How do you feel about aggressive goals?" And I was like, "Well, it depends. How do you feel about aggressive failure?" Because then once I know where you stand there, then we can talk about aggressive goals. Now, if we're being aggressive, but then we fail to achieve that, and it's one of those, okay, we didn't meet the goal that we'd expected, but everything is fine, and it's not a big deal, then I am okay. Sure, let's shoot for the stars. But if it's one of those, we are communicating these goals to the outside world, and it's going to become incredibly important that we meet these goals, and if we don't, then things are going to go on fire, people are going to be in trouble, and it's just going to be awful, then let's not set aggressive goals. Let's not box ourselves into a space where we are setting ourselves up to fail or feel pain in a meaningful way. I agree that estimations are important, especially in terms of you need to collaborate with other departments, and then also just to provide some sense of where the product is headed and when things may be released. I think estimations then just become problematic when they do become definite, and they're based on so many unknowns, and then when I don't know is not an answer. So if someone asked, "What's your estimate for this?" And the very honest real answer is I don't know, like, we haven't done this type of work before, or these are all the unknowns, and then someone's like, "Well, let's just put an estimation of like two weeks on it," and they just sort of try to force-fit it into being what they want, then that's where it starts to just feel incredibly problematic. CHRIS: Yeah, estimation is a very murky area that we could spend entire episodes talking about, and in fact, I think we have a handful of times. So with that, Linear has been great. We're going to see just how much or how little estimation we actually want to do. But it's been a very nice addition to the toolset. And I'll let you know as we deepen our usage of it what the experience is like, but that's the main thing that's new in my world. What's new in your world? STEPH: Well, before we bounce over to my world, you said something that has intrigued me that has also made me start reflecting on some of the ways that I like to work. And you'd mentioned that you have this prioritized backlog that people are pulling tickets from. And I don't know exactly if there's a planning session or how that looks, but I have recognized that when I am working with a team, and we don't have any planning session, if everybody is just pulling from this backlog, that's being prioritized by someone on the team, that I find that a bit overwhelming. Because the types of work being done can vary so drastically that I find I'm less able to help my colleagues or my teammates because I don't have the context for what they're working on. It surprises me. I'm like, oh, I didn't even know we're working on that feature, or I don't have the context for what's the problem that we're trying to solve here. And it makes it just a lot harder to review and then have conversations with them. And I get overwhelmed in that environment. And I've recognized that about myself based on previous projects that were more similar to that versus if I'm on a project where the team does get together every so often, even if it's high level to be like, hey, here's the theme of the tickets that we're working on, or here's just some of the stuff, then I feel much more prepared for the work that is coming in and to be able to context switch and review. And yeah, so I've kind of learned that about myself. I'm curious, are you similar, or how does that work for you? CHRIS: I'm definitely similar. And I think probably the team is closer to what you're describing. So we do have a planning session every week, just a quick 30-minute scan through the backlog, look at the things that are coming up and also the larger themes. Previously, Epics and Trello now projects and Linear. But talking about what are the bigger pieces of work that we're moving on, and then what are the individual tickets associated with that that we'll be expecting to work on in the next week? And just making sure that everyone has broad clarity around what that feature set is. Also, we're a very small team at this point. Still, we're four people total, but one of the developers is on a break for a couple of weeks this summer. And so there are really only three of us that are driving on the code. And so, with three of us working on the projects, we try very intentionally to have significant overlap between the various...like, we don't want any one person to own any portion of things at this point. And so we're doing a good amount of pairing to cross-pollinate and make sure everyone's...not everyone's aware of everything, but at least one other person is sufficiently aware of everything between the three of us. And I think that's been working well. I don't think we have any major gaps, save for the way that we're doing our mobile architecture that's largely managed by one of the developers on the team and a contractor that we're working with to help do a lot of the implementation. That's a known we chose to silo that thing. We've accepted the cost of that for now. And architecturally, the rest of us are aware of it, but we're not like in the Swift code writing anything because I don't know how to write Swift at this point. I'd love to learn it. I hear good things about the language. [12:26] So yeah, I think conceptually very similar to what you're describing of still want to have people be able to review. Like, I don't want to put up a PR and people be like, I don't know, that looks like code, I guess. I'm not sure what it does. Like, I want it to be very...I want us all to be roughly on the same page, and thus far, we are. As the team grows, that will become trickier to maintain because there are just inherently probably more things that are moving, more different feature areas and surface area that we're tackling in any given week, or there are different ways to approach that. I know you've talked about having a limited number of themes for a given cycle, so that's an idea that can pop up. But that's something that we'll figure out as we get further. I think I'm happy with where we're at right now, so yeah, that's the story there. STEPH: Okay, cool. Yeah, all of that resonates with me, and thinking about it a little more deeply in this moment, I'm realizing I think something you said helped me put this together where when I'm reviewing someone's change, I'm not necessarily just looking to see does your code work? I'm going to trust you that your code works. I may have thoughts about design and other things, but I really want to understand more what's the change to the product that we're making? What's the goal that we're looking to achieve? How are we measuring this? And so if I don't have that context, that's what contributes to that feeling of like, hard context switching of not just context switching, but now I have to level myself up to then understand the problem that's being solved by this. Versus had I known some of the themes going into that particular cycle or sprint, I would have felt far more prepared for that review session versus having to then dig through all the data and/or tickets or talk to someone. Well, switching back to what's going on in my world, I have a particular tweet that I want to share, and it's one that Joël Quenneville brought to my attention. And it just resonates so much with all the type of work that I'm doing right now. So I'm going to read the tweet, and then we'll link to it in the show notes as well. But it's from Curtis Einsmann, and Curtis wrote: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one." And that describes all the work that I'm doing right now. It's a lot of exploratory, a lot of data-driven work, and finding ways that we can reduce the time that it takes to run RSpec on CI. And it also ties in nicely to one of the things that I think we talked about last week, where we discovered that a number of files have a high runtime variance. And I've really dug into the data there to understand, okay, is it always specific files that have these high runtime variants? Are there any obvious contributions to what's causing this? Are we making real network calls that then could sometimes take a long time to return? And the result is there's nothing obvious. They're giant files. The number of SQL commands that are being run for each file varies drastically. They're all high, but it's still very different. There's no single fact about these files that has really been like, yes, this is what's causing these files to have such a runtime variance. And so while I've been in the data, I'm documenting it, and I'm making a list and putting it all together in a ticket so at least it's there to look at later. But I'm going to move on. It's one of those I would love to know what's causing this. I would love to address it because it would put us in an ideal state for how we're distributing tests, which would have a significant impact on our runtime. But it also feels a little bit like chasing my tail because I'm worried, like with some of the other experiments that we've done in the past where we've addressed tentpoles, that as soon as you address the issue for one or two files, then other files start having the same problem. And you're just going to continue to chase and chase, and I don't want to be in that. So upfront, this was one of those; hey, let's look at the data. If there's something obvious, let's address it; if not, move on. So I'm at that point today where I'm wrapping up all of that data, and then I'm going to move on, move on to the next thing. CHRIS: There's deep truth in that tweet that you shared at the start of this segment. The idea like if we knew the work that we had to do at the front, yeah, we would just do that, but often, we don't. And so, being able to not treat it as a failure when something doesn't work out is, I think, so critical. I think to expand on the idea just a tiny bit, the idea of the scientific method, failure is totally an option and is part of science. I remember watching MythBusters, and Adam Savage is just kind of like, "Failure is always an option," and highlighting that as part of it. Like, it's an outcome. You've learned something. You have a new data point. You can take that and then carry it forward with you. But it's rough in the moment. And so, I do think that this is a worthwhile thing to meditate on. And it's something that I've had to revisit a handful of times in my career of just like, man, I feel like I've just been spinning my tires all week. I'm like, we know what we want to get done, but just each approach I take isn't working for one reason or another. And then, finally, you get to the end. And then you've got this paragraph-long summary of all the things that didn't work in your PR and one-line change sort of thing. And those are painful, but they're part of the game. Like, that is unavoidable. I have not found a way to just know how to do the work upfront always. I would love that. I would sign up for whatever seminar was selling that. I wouldn't. I would know that that seminar is a lie, actually. But broadly, I'm intrigued by the idea if someone were selling that, I'd be like, well, I mean, pitch me on it. Tell me why I should believe you; I don't, just to be clear. But yeah. STEPH: This project has really helped me embrace always setting a goal or a question upfront about what I'm wanting to achieve or what I'm looking to answer because a number of times while Joël and I have been spelunking through data...And then so originally, with the saga, we started out with why doesn't our math match reality? We understand that if these tests are distributed perfectly across the CPUs, then that should cut the runtime in half. But yet, we weren't seeing that even though we had addressed the tentpoles. So we dug into understanding why. And the answer is because they're not perfectly distributed, and it's because of the runtime variance. And that was a critical moment to look back and say, "Did we achieve the goal?" Yes, we identified the problem. But once you see a problem, it's just so easy to dig in and keep going. It's like, well, now I want to know what's causing these files to have a runtime variance. But it's one of those we achieved our goal. We acknowledged upfront that we wanted to at least understand why. Let's make a second decision, do we keep going? And I'm at that point where, frankly, I probably dug in a little more than I should because I'm stubborn. But I'm recognizing that now's the time to back away and then go back and move on to the next high-priority item, which is converting for funsies; I'll share. The next thing is converting Test::Unit test over to RSpec because we have, I think, around 25 tests that are written in Test::Unit. And we want to move them over to RSpec because that particular just step in the build process takes a good three to four minutes. And part of that is just booting up Rails and then running the tests very fast. And we're underutilizing the machine that's running them because it's only 25 tests, but there are 86 CPUs to run it. So we'd really like to combine those 25 tests with the rest of the RSpec suite and drop that step. So then that should add minimal time to the overall build but then should take us down at least a couple of minutes. And then also makes it easier to manage and help folks so that way, there's one consistent testing framework that's in use versus having to manage some of these older tests. CHRIS: It's funny; I think it was just two episodes back where we talked about why RSpec, and I think both of us were just like, well yeah. But I mean, if there are tests and another, like, it's fine, you just leave them with the exception that if there's like 2% of our tests are in Test::Unit, and everything else is in RSpec, yeah, maybe that that conversion efforts seem totally worth it. But again, I think as you're describing that, what I'm hearing is just like the scientific method, just being somewhat structured in the approach to what's the hypothesis? And what's the procedure we're going to use to determine if that hypothesis is true or false? And then what do we do? And then what are the results? And then you just do that on loop. But being not just sort of exploring. Sometimes you have to be on exploratory mode. But I definitely find that that tiny bit of rigor of just like, wait, okay, before I actually do anything, what do I think is going on here? What's my guess? And then, okay, if that guess were true, what would I be able to observe in the world? Okay, here we go. And just that tiny bit of structure is so...it sometimes feels highly formal to go into that mode and be like, no, no, no, let me take a step back. Let me write down my thoughts. I'm going to have a little checklist and do the thing. But I've never regretted doing it. I will say that. I have deeply regretted not doing it. I feel like I should make a list of things that fit that structure. I've never regretted committing in Git ever. That's been great. I've always been able to unwind it, but I've never been able to not unwind it or the opposite. I've regretted not committing. I have not regretted committing. I have regretted not writing out my hypothesis or approach. I have not regretted doing it. And so, yeah, this feels like it falls firmly in that category of like, it's worth just a tiny bit of structure. There's a reason it is the scientific method. STEPH: Yeah, I agree. I've not regretted documenting upfront what it is I look to achieve and how I think I'm going to answer the question. That has been immensely helpful. Because then I also forget, like, two weeks ago, I'll be like, wasn't there a question around why this was happening, and I need to understand? And all of that was so context-heavy that as soon as I'm out of the thick of it, I completely forget it. So if I care about it deeply or if I want to be able to revisit it, then I need to document it for myself. It's given me a lot of empathy for people who do more scientific research around, oh my gosh, like, you have to document everything you do and then still be able to prove it five years from now or however long. I'm just throwing out numbers. And it needs to be organized enough that someone, if they do question your research that, then you have it there. My research documents would not withstand scrutiny at this point because they are still just more personal notes. But yes, it's given me a lot of empathy and respect for people who do run very serious research, experiments, and trials, and then have to be able to prove it to the world. Pivoting just a bit, there's a particular topic that resonated with both you and I; in fact, it's a particular tweet. And, Louie, I do apologize if I mispronounce your last name, but Louie Bacaj. And we'll include a link in the show notes to the tweet, but Louis shared, "I managed multiple engineering teams before quitting tech. Now that I quit, I can speak freely. Here are 12 things your manager may not be telling you, but I know for a fact will help you." So there are a number of interesting discussions and comments that are in this thread. The one thing in particular that really caught my attention is number 10, and it's "Advocate for junior developers." So they said that their friend reminded them that just because you don't have 10-plus years of experience does not mean that they won't be good. Without junior engineers on the team, no one will grow. Help others grow; you'll grow too. And that's the part that I love so much is that without junior engineers on the team, no one will grow because that was very thought-provoking for me. It's something that I find that I agree with deeply, but I hadn't really considered why I agree with that so much. So I'm excited to dive into that topic with you. And then, as a second topic to go along with that is, can juniors start with a remote team? I think that's one of the other questions when you and I were chatting about this. And I'm intrigued to hear your thoughts. CHRIS: A bunch of stuff there. Starting with the tweet, I love elements of this. Some of it feels like it's intentionally somewhat provocative. So like, without junior engineers on the team, no one will grow. That feels maybe a little bit past the bar because I think we can technically grow, and we can build things and whatnot. But I think what feels deeply true to me is truly help others grow; you'll grow too. The act of mentoring, of guiding, of training, of helping someone on their journey will inherently help you grow and, I think, change the way that you think about the work. I think the beginner mind, the earlier in the career folks coming into a codebase, they will see things fundamentally differently in a really useful way. It's possible that along your career, you've just internalized things. You've been like, yeah, no, that was weird. But then I smashed my head against it for a while, and now I understand this thing. And it just makes sense to me. But it's like, that thing actually doesn't make sense. You have warped your mind to match the thing, not, quote, unquote, "come to understand it." This is sounding too judgmental to people who've been in the industry for a while, but I found this of myself. Or I can just take for granted things that took a long time to adapt my head to, and if anything, maybe I should have pushed back a little more. And so, I find that junior engineers can be a really fantastic lens for the complexity of a project. Like, the world is truly a complex place, and that's just true. But our job as software engineers is to tame that complexity and manage it. And so, I love the mindset that can come or the conversations that can come out of that. And it's much like test-driven development is a pressure on the complexity of your code, having junior engineers join the team and needing to explain how all of the different features work, and what the overall architecture is, and the message passing under this and that, it's a really useful conversation to have. And so that "Help others grow; you'll grow too" feels deeply, deeply true to me. STEPH: Yeah, I couldn't agree more in regards to how juniors really help our team and especially, as you mentioned, with complexity and ¬having those conversations. Some of the other things that have come to mind for me as well around the importance of having junior developers on your team...and maybe it's not specifically they're junior developers but that you just have a variety of experience on your team. It's going to help you lean into a culture of learning because you have people that are at different stages of their career. And so you want an environment where people can learn together, that they can fail together, and they can be public about it. And having people that are at different stages of their career will lead, well, at least ideally, it'll lead to more pair programming. It's going to lead to more productive code reviews because then people can ask more questions around why did you choose this, or why are you doing that? Versus if everybody is at the same level, then they may just intuitively have reasons that they think someone did something. But it takes someone that's a bit new to say, "Hey, why did you choose this?" or to bring up some other ideas or ways that they could pursue it. They may bring in new ideas for, like, why has the team always done something this way? Let's think about new ways that we could do this. Or maybe this is really unfriendly, the way that we're doing this, not just for junior people but for people that are new to the team. And then there's typically less knowledge siloing because then you're going to want to pair the newer folks with the more experienced folks. So that way, you don't have this more senior developer who's then off in a corner working by themselves. And it's going to improve your communication skills. There's just...I realized I'm just rambling because I feel like there are so many benefits that go along with having a variety of people on your team, especially in terms of experience. And that just leads to such a better learning environment and, ultimately, better software and better products. And yet, I find that so many companies won't embrace people that are newer to software. They always want the senior developers. They want the 10x-er or whatever those are. They want the people that have many, many years of experience. And there's so much value that comes from mentoring the next group of developers. And it's incredibly frustrating to me that one, companies often aren't open to it. But honestly, more than that, as long as you're upfront and honest about like, hey, this is the team that we need right now to build what we're looking to build, I can get past that; I can understand that. But please don't then mislead people and say that you're a junior-friendly team, and then not be prepared. I feel like some teams will go so far as to say, "Yes, we are junior-friendly," and they may even tweak their interview process to where it is a bit more junior-friendly. But then, by the time that person joins the team, they're really not prepared. They don't have an onboarding plan. They don't have a mentorship plan. And then they fail that person because that person has worked hard to get there. And they've worked hard to bring that person onto the team, but then they don't have a plan from there. And I've seen it too many times. And it just frustrates me so much because it puts that junior person in such a vulnerable state where they really have to be an incredible self-advocate to then overcome those hurdles from a lack of preparation on that company's part. Okay, I think that's my event. I'm sure I could vent about this a lot more, but I will cut it off there. That's the heart of it. CHRIS: I do think, like, with anything else, it's something that we have to be intentional about. And so what you're saying of like, yeah, we're a junior-friendly company, but then you're just hiring folks, trying to find folks that may work at a slightly lower pay grade, and that's what that means to you. So like, no, no, that's not what this is. This needs to be something different. We need to have a structure and an organization that can support folks at different points in their career. But it's interesting to me to think about the sort of why of it. And the earlier part of this conversation, we talked about some of the benefits that can come organizationally from it, and I do sincerely believe in that. But I also believe that it is fundamentally one of the best ways to find really talented people early on in their career and be in a position to hire them where maybe later on in their career, that just wouldn't happen naturally. And I've seen this play out in a number of organizations. I went to Northeastern University for my college, and Northeastern is famous for the co-op program. Northeastern sounds really fancy. Now I learned that they have like a 7% acceptance rate for college applications right now, which is wildly low. When I went to Northeastern, it was not so fancy. So just in case anyone's hearing that and they're like, "Oh, Northeastern, wow." I'm not that fancy. [laughs] But they did have the co-op then, and they still have it now. And the co-op really is a differentiating thing. You do three six-month rotations. And it is this fundamental differentiator in terms of when you're graduating. Particularly, I was in mechanical engineering. I came out, and I actually knew what that meant in the world. And I'd used Outlook, and I knew what a water cooler was and how to talk near one because that's a critical thing to learn in the world. And really transformative experience for me. But also, a thing that I observed was many of my friends ended up working at companies that they had co-opted for. I'm one of those people. I would say more than 50% of my friends ended up with a position at a company that they had done a co-op rotation with. And it really worked out fantastically. That organization and the individual got to try things out, experience. And then, I ended up staying at that company for a number of years, and it was a wonderful experience. But I don't know that I would have ended up there otherwise. That's not necessarily the way that would have played out. And similarly like, thoughtbot has the apprenticeship. And I have seen so many wonderful developers start at that very early point in their career. And there was this wonderful structure around them joining the thoughtbot team, intentional, structured, supported. And then those folks went on to be some of the most talented developers that I've ever worked with at a wonderfully talented organization. And so the story of like, you should do this, organizations. This is a thing that you should invest in for yourself, not just for the individual, like, for both. Everybody wins in this case, in my mind. I will say, though, in terms of transparency, I currently manage a team of three developers. And we hired very intentionally for senior folks this early on in where we're at. And that was an intentional choice because I do believe that if you're going to be hiring more junior developers, that needs to be something that you do very intentionally, that you have a support structure in place, that you're able to invest the time in where they're at and make sure we have sort of... I think a larger team makes more sense to bring juniors into broadly. That's the thing that I'm saying out loud that I'm like, I should push on that a little bit. Is that true? Do I really believe that? But I think so, my actions obviously point to it. But it is an interesting trade-off space of how do you think about that? My hope is that as we grow as an organization, that we would then very intentionally start hiring folks in a more junior, mid-level to junior and be very intentional about how we support them, bring them into the organization, et cetera. I do believe it is a win-win situation for everyone when done with intention and with focus. STEPH: That's such an interesting bit that you just said because I very much appreciate when companies recognize do we have the bandwidth to support someone that's more junior? Because at thoughtbot, we go through periods where we don't have our apprenticeship that's open because we recognize we're not in a place that we can support someone. And we don't want to bring someone in unless we can help them be successful. I very much admire that and appreciate that about companies when they can perform that self-assessment. I am so intrigued. You'd mentioned being a smaller team. So you more intentionally hire senior developers. And I think that also makes sense because then you need to build up who's going to be in that mentorship pool? Because then people could leave, people could take vacations, and so then you need to have that support system in place. But yeah, I don't know what that then perfect balance is. It's like, okay, so then as soon as you have like five people available to mentor or interested in mentorship, it's like, then do you start bringing in the conversation of like, let's bring in someone that we can help build up and help them be successful and join our team? And I don't know what that magical number is. I do think it's important for teams to reflect to say, "Can we take on someone that's junior?" All the benefits of having someone that's junior. And then just being very honest and then having a plan for once that junior person does arrive. What does their career path look like while they've joined that team, and who's going to be that person that's going to help them level up? So not only make that choice upfront of yes, we are bringing someone on but let's also think about like the first six months of their work here at the company and what that's going to look like. It feels like an important step that a lot of companies fail to do. And I think that's why there are so many articles that then are like, hey, if you're a junior dev, here's all the things that you should do to be the best junior dev. That's fabulous. And we're constantly shoring up junior devs to be like, hey, here's all the things that you need to be great at. But we don't have as many conversations around; hey, here's all the things that your manager or the rest of your team should be great at to then support you equally as you are also doing your best to meet them. Like, they need to meet you halfway. And I'm not completely unsympathetic to the plight; I understand. It's often where I've seen with teams the more senior developers that have very strong mentorship communication skills are then also the teammates that get pulled into all the meetings and all the different projects, so then they are less available to be that mentor. And then that's how this often fails. So I don't think anybody is going into this intentionally, but yet, it's what happens for when someone is new and joining a team, and it hasn't been determined the next six months what that person's onboarding and career path looks like. Circling back just a bit, there's the question around, can juniors start with a remote team? I can go first. And I'm going to say unequivocally yes. There's no reason a junior can't start with a remote team. Because all the things that I feel strongly about come down to how is your team going to plan for this person? And how are they going to support this person? And all the benefits that you get from being in an office with a team, I think those do exist. And frankly, for someone like myself, it can be easier to establish a bond with someone that you get to see each day, get to see in person. You can walk up to their desk and can say, "Hey, I've got a question for you." But I think all those benefits just need to be transferred into a remote-friendly way. So I think it does ratchet up how intentional you have to be with your team and then onboarding a junior developer. But I absolutely think it's doable, and we should do it. CHRIS: You went with unequivocally yes as your answer. I'm going to go with a qualified maybe as my answer. I want this to be true, and I think it can be true. But I think it takes all the more intentionality than even what we've been describing. To shift the question around a little bit, what does remote work mean? It doesn't just mean we're doing the work, but we're separate. I think remote work inherently is at its best when we also are largely async first. And so that means more structured writing. The nature of the conversation tends to be more well-formed in each interaction. So it's like I read a big document, and then I pass it over to you. And at your leisure, you respond to it with a bunch of notes, and then it comes back to me. And I think that mode of interaction, while absolutely wonderful and something that I love, I think it fits really well when you're a little bit further on in your career when you understand things a little bit better. And I think the dance of conversation is more useful earlier on and so forth. And so, for someone who's newer to a team, I think having the ability to ask a quick question over and over is really useful to someone who's early on in their career. And remote, again, I think it's at its best when it's async. And those two are sort of at odds. And so it's that mild tension that gives me pause of like, something that I think that makes remote work great I do think is at least a hurdle that you would have to get over in supporting someone who's a little bit newer. Because I want to be deeply present for someone who's newer to their journey so that they can ask a lot of questions so that I am available to be interrupted regularly. I loved at thoughtbot sitting next to someone and being their mentor and being like, yeah, anytime you want, just tap on my desk. If I got my headphones on, that doesn't mean I'm ignoring you; it means I just need to make the sounds go away for a minute because that's the only way my brain will work. But feel free to just tap on my desk or whatever and grab my attention for a moment. And I'm available for that. That's an intentional choice. That's breaking up my continuity of the day, but we're choosing that for a reason. I think that's just a little harder to do in a remote context and all the more so if we're saying, hey, we're going to try this async thing where we write structured documents, and we communicate in these larger, more well-formed, communicates back and forth. But I do believe it can be done. I think it should be done. I just think it's all the harder for all of those reasons. STEPH: I agree that definitely makes it harder. But I'm going to push a little bit and say that when you mentioned being deeply present, I think we can be deeply present with someone and be remote. We can reduce the async requirements. So if you are someone that is more senior or more accustomed to the team, you can fall back to more of those async ways to communicate. But if someone is new, and needs more mentorship, then let's just set up time where we're going to literally hang out for a couple of hours each day or whatever pairing environment works best for them because pairing can also be exhausting. But hey, we're going to have a check-in each day; maybe we close out each day and touchpoint. And feel free to still message me and interrupt me. Like, you're going to just heighten your availability, even though it is remote. And be aware, like, hey, this person could message me at more times, and I'm okay with that. I have opted into this form of communication. So I think we just take that mindset of, hey, there's this person next to me, and I'm their mentor to like, hey, they're not next to me, but I'm still their mentor, and I'm still here for them. So I agree that it's harder. I think it falls on us and the team and the mentors to change ourselves versus saying to juniors, "Hey, sorry, it's remote. That's not going to work for you." It totally works for them. It's us, the mentors, that need to figure out how to make it work. I will say being on that mentor side that then not being able to see someone so if they are next to me, I can pick up on body language and facial expressions, and I can tell when somebody's stuck. And I can see that they're frustrated, or I can see that now's a good time for me to just be like, "Hey, how's it going? What are you working on? Or do you need help with something?" And I don't have that insight when I'm away. So there are real challenges like that that I don't know how to address. I have gone the obnoxious route [laughs] where I just message people, and I'm like, "Hey, how's it going? How's it going? How's it going?" And I try not to do that too much. But I haven't found a better way to manage that other than to constantly check in because I do have less feedback from that person that I'm working with unless they are just incredibly open about sharing when they're stuck. But typically, when you're newer to a team or newer to a career, you're going to be less willing to share when you're stuck. But yeah, there are some real challenges, but I still think it's something for us to figure out. Because otherwise, if we cut off access for remote teams to junior folks, I mean, that's where we're headed. There are so many companies and jobs that are headed remote that not being junior friendly and being remote in my mind is just not an option. It's something that we need to figure out. And it's hard, but we need to figure it out. CHRIS: Yeah, 100% on we need to figure that out and that that's on us as the people managing and structuring and bringing folks into teams. I think my stance would be like, let's just be clear that this is hard. It takes effort to make sure that we've provided a structure in which someone newer to a team can be successful. It takes all the more effort to do so in a remote context, I think. And it's that recognition that I think is critical. Because if we go into this with the wrong mindset, it's like, oh yeah, it's great. We got this new person on the team. And yeah, they should be ready to go in like two weeks, right? It's like, no, no, this is a different thing. We need to be very clear about it. This is going to require that we have someone who is able to work with them and support them in this. And that means that that person's output will likely be a little bit reduced for the period of time that we're talking about. But we're playing a long game here. Let's make sure we're clear on that. This is intentional. And let's be clear, the world of hiring and software right now it's not like super easy. There aren't way more software developers than there are jobs; at least, that's been my experience. So this is something absolutely worth investing in for just core business reasons and also good for people. So hey, it's a win-win. Let's do it. Let's figure it out. But also, let's be clear that it's going to be a little tricky along the way. So, you know, let's be intentional about that. But yeah, obviously do it, got to do it. STEPH: Wait, so I feel like we might have circled back to unequivocally yes. [laughs] Have we gotten there, or are you still on the fence? CHRIS: I was unequivocally yes from the beginning, but I couched it in, but...yeah, I said other things. You're right. I have now come around; let's say to unequivocally yes. STEPH: [laughs] Cool. I don't want to feel like I'm forcing you to agree with me. [laughs] But I mean, we just so rarely disagree. So we've either got to identify this as something that we disagree on, which would be one of those rare occasions like beer and Pop-Tarts. CHRIS: A watershed moment. Beer and Pop-Tarts. STEPH: Yeah, those are the only two so far. [laughter] CHRIS: Not together also. I just want to go on record beer and Pop-Tarts; I don't think would be...anyway. STEPH: Ooh, I don't know. It could work. It could work. CHRIS: Well, there's another thing we disagree on. STEPH: I would not turn it down. If I was eating a Pop-Tart, and you're like, "Hey, you want a beer?" I'd be like, "Sure," vice versa. I'm drinking a beer. "Hey, you want a Pop-Tart?" "Totally." CHRIS: Okay. Well yeah, if I'm making bad decisions, I'm obviously going to chain them together, but that doesn't mean that they're a good decision. It's just a chain of bad decisions. STEPH: I feel like one true thing I know about you is that when you make a decision, you're going to lean into it. So like, this is why you are all about if you're going to have a Pop-Tart, you're going to have the highest sugary junk content Pop-Tart possible. So it makes sense to me. CHRIS: It's the Mountain Dew theorem, yeah. STEPH: I didn't know this had a theorem. The Mountain Dew theorem? CHRIS: No, that's just my name. Well, yeah, if I'm going to drink soda, I'm going to drink Mountain Dew, the nonsense nuclear option of soda. So yeah, I guess you're describing me, although as you say it back to me, I suddenly feel very, like, oh God, is this who I am as a person? [laughs] And I'm not going to say you're wrong. I'm just going to spend a little while thinking about some stuff. STEPH: I mean, you embrace it. I think that's lovely. You know what you want. It's like, all right, let's do this. Let's go all in. CHRIS: Thank you for finding a wonderfully positive way to frame it here at the end. But I think on that note, 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.

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.

Steph has a question for Chris: When you have no idea how you're going to implement a feature, how do you write your first test? Chris has thoughts about hybrid teams (remote/in-person) and masked inputs. 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. Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) iMask (https://imask.js.org/) Mitch Hedberg - Escalator Joke (https://www.youtube.com/watch?v=yHopAo_Ohy0) 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: I am recording in a new room because we're in Pennsylvania, and so I'm recording at this little vanity desk which is something. [laughs] But there's a mirror right in front of me, so I feel very vain because it's just like, [laughs] I'm just looking at myself while I'm recording with you. It's something. CHRIS: [laughs] That is something. STEPH: [laughs] So, you know. CHRIS: Fun times. STEPH: Pro podcast tip, you know, just stare at yourself while you chat, while you record. CHRIS: I mean, if that works for you, you know, plenty of people in the gym have the mirrors up, so podcasting is like exercising in a way, and I think it makes sense. STEPH: I appreciate the generosity. [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've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. So I have a funny/emotional story that [laughs] I'm going to share with you first because I feel like it kind of encapsulates how life is going at the moment. So we've officially moved from South Carolina to North Carolina. I feel like I've been talking about that for several episodes now. But this is it: we have finally vacated all of our stuff out of South Carolina house and relocated to North Carolina. And once we got to North Carolina, we immediately had to then leave town for a couple of days. And normally, Utah, our dog, stays with an individual in South Carolina, someone that we found, trust, and love. And he has a great time, and I just know he's happy. But we didn't have that this time. So I had to find just a boarding facility that had really high reviews that I felt like I could trust him with. I didn't even have time to take him for a day to test it out. It was one of those like, I got to show up and just drop him off and hope this goes well, so I did. And everything looks wonderful. Like, the facility is very clean. I had a list of things to look for to make sure it was a good place. But it's the first time leaving him somewhere where he's going to spend significant time in a kennel that has indoor-outdoor access. And as I walked away from him, I started to cry. And I just thought, oh no, this is embarrassing. I'm that dog mom who's going to start crying in this boarding facility as she's leaving her dog for the first time. So I put on my shades, and I managed to make it through the checkout process. But then I went to my truck and just sat there and cried for 15 minutes and called my husband and was like, "I'm doing the right thing, right? Like, tell me this is okay because I'm having a moment." And I finally got through that moment. But then I even called you because you and I were scheduled to chat. And I was like, I am not in a place that I can chat right now. I think I told you when you answered the phone. I was like, "Everything is fine, but I sound like the world's ending, or I sound like a mess." [laughs] And yeah, so I had like two hours of where I just couldn't stop crying. I partially blame pregnancy hormones. I'm going to go with that as my escape rope for now. So I feel like that's been life lately. Life's been a little overwhelming, and that felt like the cherry on top. And that was the moment that I broke. Update: he's doing great. I've gotten pictures of Utah. He's having a wonderful time at camp, it seems. [laughs] It was just me, his mom, who is having trouble. CHRIS: Well, you know, reasonable to worry, and life's dialed up to 11 and all of that. But yeah, I will say even though you lead the conversation with everything's fine, your tone of voice did not imply that everything was fine. So when I eventually came to understand what we were talking about, I hope I was kind in the moment. But I was like, oh, okay, this is fine. We're fine. I'm so sorry you're feeling terrible right now. STEPH: [laughs] CHRIS: But okay, we're fine. For me, there was a palpable moment of like, okay, my stress is now back down a little bit. But I'm glad that things are going well and that Utah is having a fun vacation. STEPH: Yep, he seems to be doing fine. I've calmed down. You know, as you said, life's been dialed up lately. On a less emotional note and something that's a little bit more technical, I had a really great conversation with another thoughtboter where we were talking about testing. And the idea of when you learn testing, it's often very focused on like, you have this object, and it has a method. And so, you're going to write a unit test for this particular method. And it's very isolated, very specific as to the thing that you're looking to test. Versus in reality, when you pick up tickets, you don't have that scope, and like, it is so broad. You have to figure out what feature you're implementing, figure out how to test it. And it feels like this mismatch between how a lot of people learn to test and learn TDD versus then how we actually practice it in the wild. And so we had a phone conversation around when you are presented with a ticket like that, and you have no idea how you're going to implement a feature, how do you get started with testing, and when do you write your first test? Do you TDD? Do you BDD? Or do you PDD? That last one I made up, it stands for Panic-driven development. But it's what's your approach to how do you actually then get to the point where you can write a test? And I have a couple of thoughts. But I'm really curious, how does that flow work for you? What have you learned throughout the years to then help yourself write that first test? Or where do you start? CHRIS: Well, this is an interesting question. I like this one. I think it varies. And I think there's a lot of dogma around TDD as a practice. And I think it is super useful to break that apart and hear different individual stories of it. I know there are plenty of folks who are like, TDD is just not a thing and whatnot, and I'm certainly not in that camp. But I also don't TDD 100% of the time because sometimes I'm not super clear on what I'm doing, or I'm in more of an exploratory phase. That said, I think there's a...I want to answer the question somewhat indirectly, which is I know how to test most of the code that I work on now as a web developer in a Rails application because I've done most of the things a bunch of times. And the specifics may be different, but the like, to integrate with this external system, and I have to build an API client or whatever, I know how to do that. And there is a public API of some class that I will be exercising against and so I can write tests against that. Or I know that the user is going to click a button, and then something needs to happen. And so I can write that test, and it fails, and then it starts to push me towards the implementation. There are also times where it's actually quite hard to get the test to lead you in the right direction, and you have to know what hop to make, and so sometimes I just do that. But yeah, rolling back a little bit, I think there is a certain amount of experience that is necessary. And I think one of the critical things that I want to share with folks that are potentially newer to testing overall is that it is actually quite hard. You have to understand your system and how you're going to approach it, you know, one step removed, or it's like a game of chess where you're thinking a couple of moves ahead. You have to understand it in a deeper way. And so, if testing is difficult, that might just be totally reasonable at this point. And as you come to see the patterns within a Rails application or whatever type of application you're working on over and over, it becomes easier to test. But if testing is hard, that may not mean...like, how do I phrase this? There's like an impostor syndrome story in here of like, if you're struggling with testing, it may not be that something is fundamentally broken. You just may need a couple more chances to see that sort of thing play out. And so, for me, in most cases, I tend to know where to start or when not to. Like, I feel fine not testing when I don't test most of the time. I will eventually get things under test coverage such that I feel confident in that. And whenever I have one of those moments, I will stop and look at it and say, "Why didn't I know how to test this from the front, like, from the start?" But it's rare at this point for things to be truly exploratory. There's always some outer layer that I can wrap around. But like, I know X needs to happen when Y occurs. So how do I instrument the system in that way? But yeah, those are some thoughts. What are your thoughts? Does what I said sound reasonable here? STEPH: Yeah, I really like how you highlighted that pausing for reflection. That was something that I didn't initially think of, but I really liked that, to then go back to be like, okay, revisiting myself a couple of days or however earlier when I first started this. Now I can see where I've ended up. How could I have made that connection sooner as to where I was versus the tests I ended up with? Or perhaps recognizing that I couldn't have gotten there sooner, that I needed that journey to help me get there. So I really like the idea of pausing for reflection because then it helps cement any of those learnings that you have made during that time. Also, the other part where you mentioned the user clicks a button, and something happens, that's where I immediately went with this. I also liked that you highlighted that TDD has that bit of dogma, and I don't always TDD. I do what I can, and it helps me. But it has to be a tool versus something that I just do 100% of the time. But with more of that BDD approach or that very high-level user-level integration test of where if I need to pull data from an API and then show it to the user, okay, I know I can at least start with a high-level test of I want the user to then see some data on a page. And that will lead me down some path of errors. It might help me implement a route and a controller and then a show action, so it will at least help me get started. Or even if it doesn't give me helpful enough errors, it at least serves as my guideline of like, this is my North Star. This is where I'm headed. So then, if I need to revisit, okay, what's the thing that I'm focused on at the moment? I can go back and be like, okay, I'm focused on achieving this. What's the next smallest step I can take to get there? The other thing that I've learned over time is I've given myself the chance to be messy because I got so excited about the idea of unit testing and writing small, fast test that I would often try to start with small objects and then work my way backwards into like, okay, I have this one object that does this thing and one object that like...let's use a concrete example. So one object that knows how to communicate with API and one object that knows how to then parse and format the data I want and then something else that's then going to present that data to the user. But I found when I started with small objects, I would get a little lost, and I wasn't always great at bringing them together. So I've taken the opposite approach of where if I'm really not sure where I'm headed and I'm in that more exploratory phase or even just that first initial parse of a feature, I will just start messy. So if I am pulling data from an API and need to show it to a user on a screen, I'll just dump it in the controller if I need to. I'll put it all there together. And then once I actually have something that is parsing, or I have something appearing on the page, then I will start to say, "Okay, now that I can see what I need and I can see the pieces that I've written, how can I then start to extract this into smaller objects?” And now, I can start writing unit tests for that data. So that is something that has helped me is just start high, keep it high, be messy, and until you start to see some of the smaller objects that you can pull out. CHRIS: Yeah, I think there's something that you were just saying there that clicked for me of we didn't start with the why of TDD. And I don't think we've talked about why we believe in TDD in a while. So this feels like a thing we're saying. It's not good just because it's good, or we don't believe it's good just because that's what we say. For me, it is because it anchors us outside of the code sort of it starts to think of it from the user perspective or some outer layer. So even if you're unit testing some deeply nested class within your application, there's still an outer layer. There's still a user of that class. And so, thinking about the public API, I think is really useful. And then the further out you get, the better that is, and I believe strongly in thinking from the outside in on these sort of things. And then the other thing you said of allowing for refactoring. And if we have tests, then it's so much easier to sort of...I totally 100% agree with like; I start messy. I start very messy. I wanted to pretend that I was going to be like, oh, I'm so...Steph, I can't believe this. But no, of course, I start messy. Why would you start trying to do the hard thing first? No, get something that works. But then having the test coverage around that makes it so much easier to go through those sequential refactoring steps. Versus if you have to write the code correctly upfront and then add test coverage around that, it sort of inverts that whole thing. And so, although it may take a little bit longer to write the tests upfront, I do exactly what you're describing of like, I write the tests that tell some truth about the system and constrain the system to do that thing. And then I can have a messy implementation that I can iteratively refactor over and over, and I can extract things from. And then, I can tell a more concise testing story about those. And so it really is both the higher-level perspective I think is super useful and then the ability to refactor under that test coverage is also very useful. And it makes my job easier because I can start messy. I love starting messy. It's so much better. STEPH: Yeah, and I think former me had the idea that for me to do TDD properly meant that I had these small, encapsulated objects that I wrote unit tests for. And yes, that is the goal. I do want that, but that doesn't mean I have to start there. That is something that then I can work my way towards. That also falls in line with the adage from Sandi Metz that the wrong abstraction is more costly than no abstraction. And so I'd rather start with no abstractions and then start to consider, okay, how can I actually move this out into smaller objects and then test it from there? There's also something that I heard that I haven't done as often, but I really liked the idea; it feels very freeing, is that when you do get started and if you write your first test, if you write a test and it helps you make some progress but then you come back to it later and you're like, you know, the test doesn't really add value, or it's not helping me anymore, just thank it and delete it and move on. Just because you wrote it doesn't mean it needs to stay. So if it provided some benefit to you and helped you through that journey of adding the feature, then that's wonderful. But don't be timid about deleting it or changing it so that it does serve you because otherwise, it's just going to be this toxic test that gets merged into the main branch, and it's going to be untrustworthy. Or maybe it's fussy and hard to please, or it's just really not the supportive test that you're looking for. And so then you can turn it into more of a supportive test and make it fit your goals instead of just clinging to every test that we've written. CHRIS: I like the framing of tests as scaffolding to help you build up the structure. But then, at the end, some of the scaffolding gets ripped away and thrown out. And I do think, again, testing ends up in this weird place. The dogmatic thing that we were talking about earlier feels very true. And I've noticed, particularly on larger teams, folks being very hesitant to delete tests like, that feels like sacrilege. Of course, you can't delete tests; the tests are how we know it's true, which is true, but you can interrogate that. You can see like, how true is it? And every test has a cost and maintenance burden, runtime, et cetera. You probably know well, Steph, about having test suites that take a bunch of time to run and then maybe wanting to spend a little bit of time trying to reduce that overall time. And so there's always going to be a trade-off there. Actually, someone reminded me of an anecdote recently. I joined a project, and most of the test suite or all of the test suite was commented out because it was flaky or intermittent. And I was like, "Oh, I'm going to delete that." And people were like, "You're what?" I'm like; it's commented out. We're not using it. Let's tell the truth. Git will have it. We can go back and get it. But let's tell the truth with what we're like...this commented-out test suite is almost worse in my mind than having nothing there. The nothing feels painful, right? Let's experience that. Whereas the commented out stuff is like, well, we have a test suite; it's just commented out. It's like, no, you don't have a test suite at all. That's not what's going on here. But there were other thoughtboters on the project that poked a good amount of fun at me when they were like, "The first thing you did on this project was delete the test suite?" As I was like, "Yeah, I don't know, I was feeling spicy that day or something." But I think the test suite needs to serve the work that we're doing in the same way that everything else does. And so occasionally, yeah, deleting tests is absolutely the right thing and then probably add back some more. STEPH: It's funny how that reaction exists. And I've done it before myself where like, if you see commented out code and you put up a PR to remove it, I feel like most people are going to be like, yeah, yeah, that's great. Let's get rid of this. It's clearly not news. It's commented out. But then removing a skipped test then has people like, "Well, but that test looks like it could be valuable, and we're going to fix it." And it's like...all I can go back to is that silly example of like, you've got your skinny jeans, one day I'm going to fit into those skinny jeans. And so one day, I'm going to fix this test, and it's going to serve the purpose. And it's going to be the me I want to be. [laughs] And it is funny how we do that. With code, we're like, sure, we can get rid of it. But with tests, we feel this clinginess to them where we want to hold on to it and make it pass. And I think that sometimes has to do with the descriptions. There are test descriptions commented out that I've seen are like, user can log in, or if given a user without permission, they can't access. And it's like, oh, that sounds important. I'm now nervous to delete you versus fix you, but you're still not actually running and providing value. And so then I have to negotiate with myself as to where do we actually go from here? But I do love the idea of deleting tests that are skipped because we should just let them go. We either have to dedicate time to fix them or let them go and make that hard decision. CHRIS: The critical idea of future me will have more time, future me will be calm and will work through all the other bugs and future discounting; as far as I understand it as a formalization of the term, yeah, it's never true. I've only gotten busier over time, just broadly speaking. And that seems to be a truism in software projects as well. It's like, oh, we just have to write a bunch of features, and then it'll be calm. I don't even think I'd want that. But future me will not have more time. And so choosing the things that we do invest in versus not is tricky, but the idea of that future me will have a lot of time or future us probably not true. STEPH: Well, I think the story that I just shared at the beginning of our chat highlights that future me won't always be calm. [laughs] So let's work with what I've got. Let's not bank on that. Future Stephanie might be very emotional about dropping her dog off at boarding for a couple of days. [laughs] Future me might be very emotional about fixing this test. All right, well, thanks for going on that journey with me. That's really helpful. I knew you'd have some great insights there. 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: What's going on in my world? Last week we had our first ever Sagewell all-hands get-together in person. Many of us have met in person before, but not everyone. And so this was a combination celebration for our seed fundraising round, which had happened actually sometime right at the end of last year. But due to COVID in the world and complexity, it was difficult to get everybody together. So that finally happened. And then we sort of grafted on to that celebration, that party that we were having. Like, let's just extend a day in either direction and do some in-person working and all of that. And that was really great. I'm trying to find that ideal middle ground between we are a remote team, but there is definitely value in occasionally being in person, particularly getting to know people but also just having some higher bandwidth conversations, planning, things like that. They just feel different in person. And so, how do we balance that? And how do we be most productive and all that? But it was really great to meet the team more so than I had on the internet and get to spend some time in person and do some whiteboarding. I drew on a whiteboard with a team. We were all looking at the same whiteboard. We're in the same room. And I drew on a whiteboard some entity relationship diagrams. It was awesome. [laughs] It was super fun. It was one of those cases where we had built an assumption deeply into our codebase, and suddenly instead of having one of a thing, we may now have multiple of a thing. There's a wonderful blog post by Shawn Wang called Preemptive Pluralization which I think is based on an episode of Ben Orenstein's podcast, The Art of Product, where Ben basically framed the idea of like, I've never regretted pluralizing something earlier. A user has one account; they have multiple accounts. They just happen to have one at this time, et cetera. So we're in one of those. And it was a great thing to be able to be in a room and whiteboard. I knew at the time when I did it way back when that I was making the wrong decision. But I didn't know exactly how and the shape. And so now we have to do that fun refactoring so glad that we have a giant test suite that will help us with said refactoring. But yeah, so that was really great to be able to do in person. STEPH: I think there can be so much value in getting together and getting to see your team and, like you said, have those high-level conversations and then just also getting to hang out. So it's really nice to hear that reinforced since you experienced that same positivity from that experience. Do you think that's something that y'all will have going forward? Do you think you're going to try to get together like once a year, once a quarter? Maybe it hasn't even been talked about. But I'm hearing that it was great and that maybe there will be some repeats. CHRIS: Yes, yeah. I think I'm inclined to quarterly at a minimum and maybe even slightly more than that. Some of us are centered around Boston, and so it's a little bit easier for us to pop in and work at a WeWork, that sort of thing. But I think broadly, getting the team together and having that be intentional. And personally, I'm inclined to that being more social time than productive time because I think that's the thing that is most useful in person is building relationship and rapport and understanding folks better. I remember so pointedly when thoughtbot would have the annual Summer Summit, and leading up to that; there was a certain amount of conversation. But there were also location-specific rooms, and a lot of the conversation happened like in the Boston channel or whatnot. And then, without fail, every year after the Summer Summit, suddenly, there was a spike in cross-team chatter. Like, the Ruby room now had a bunch of people from San Francisco talking to Boston, talking to New York, et cetera. And it was just this incredibly clear...I think we could actually, like, I think at one point someone plotted the data, and there's just this stepwise jump that would happen every time. And so that sort of connecting folks is really what I believe in there. And the more we're leaning into the remote thing, then the more I think this is important. So I think quarterly is probably the lowest end that I would think of, but it might be more. And it's also a question of like, what shape does this take? Is it just us going and hanging out somewhere? Or are we productively trying to get together with a whiteboard? I think we'll figure that out as we go on. But it's definitely something that I'm glad we've done now, set the precedent for, and we'll hopefully do more of moving on. STEPH: Yeah, I always really love the thoughtbot Summits. In fact, we have one coming up. It's coming up in May, and this one's taking place in UK. But there have been some interesting conversations around Summit because before, it was the idea that everybody traveled. But typically, they were in Boston, so for me, it was particularly easy because it was already where I lived. So then showing up for Summit was no biggie. But with this one happening in UK and COVID and travel still being a concern, there's been more conversations around; okay, this is awesome. People who want to get together can. There are these events going on. But there are people who don't want to travel, don't feel up to travel. They have family obligations that then make it very difficult for them to leave one partner at home with the kids. And I myself I'm in that space where I thought really hard about whether I was going to travel or not. And I've decided not to just for personal reasons. But then it brings up the question of okay, well, if we have a number of people that are going to be in person together, then what about the people who are remote? And the idea of running something that's hybrid is not something that we've really figured out. But those that are remote, we're going to get together and figure out what we want to do and maybe what's our version of our remote summit since we're not going to be traveling. But I feel like that's definitely a direction that needs to be considered as teams are getting in person because if you do have people that can't make it, how can you still bring them in so it's an inclusive event but respect to the fact that they can't necessarily travel? I don't know if that's a concern that every team needs to have, but it's one that I've been thinking about with our team. And then I know others at thoughtbot we've been considering just because we do have such a disparate team. And we want to make everybody comfortable and feel included. CHRIS: Yeah, as with everything in this world, there's always complexities and subtlety. Thankfully, for our first get-together, we were able to get everyone into the same space. But I do wonder, especially as the team grows, even just scheduling, the logistics of it become really complicated. So then does the engineering team have get-togethers that are slightly different, and then there's like once yearly a big get-together of the whole team? Or how do you manage that and dealing with family situations and all that? It is very much a complicated thing that thankfully was very straightforward for us this first time, but I fully expect that we'll have to be all the more intentional with it moving forward. And, you know, that's just the game. But switching gears ever so slightly, we did have a fun thing that we've worked on a little bit over the past few weeks. We've finally landed it in the app. But we were swapping out our masked input library that we were using, so this is for someone entering their birthday, or a phone number, or social security number, or dates. I guess I already said dates. Passwords I think we also use here. But we have a bunch of different inputs in the app that behave specially. And my goodness, is this one of those things that falls into the category of, oh yeah, I assume this is a solved problem, right? We just have a library out there that does it. And each library is like, oh no, all of the other libraries are bad. I will come along, and I will write the one library to solve all of the problems, and then we'll be good. And it is just such a surprisingly complicated space. It feels like it should be more straightforward. And as I think about it, it's not; it's dealing with imperative interactions between a user and this input. And you need to transform it from what happens when you hit the delete key? What do you want to happen? What's the most discoverable for every user? How do we make sure they're accessible? But my goodness, was it complicated. I think we're happy with where we landed, but it was an adventure. STEPH: I'll be honest, that's something that I haven't given as much thought to. But I guess that's also I just haven't worked with that lately in terms of a particular library that then masks those inputs. So I'm curious, which library were using before, and then which one did you switch to? CHRIS: That's a critical piece of information that I have left off here. So for the previous one, we were using one called svelte-input-mask, which, again, part of the fun here is you want to have bindings into whatever framework that you're using. So svelte-input-mask is what we were using before. We have now moved on to using iMask, which is not like the thing you wear on your face, but it is the letter I so like igloo, Mike, et cetera, I-M-A-S-K, iMask. And so that is a lower-level library. There are bindings to other things. But for TypeScript and other reasons, we ended up implementing our own bindings in Svelte, which was actually relatively straightforward. Again, big fan of Svelte; it's a wonderful little framework. But that is what we're using now, and it is excellent. It's got a lot of features. We ended up using it in a slightly more simple version or implementation. It's got a lot of bells and whistles and configurations. We went up the middle with it. But yeah, we're on iMask, which also led to a very entertaining moment where it was interacting with our test suite in an interesting way. And so, one of the developers on the team searched for Capybara iMask. [laughs] And I forget exactly how it happened, but if you Google search that, for some reason, the internet thinks an iMask is a thing that goes over your mouth. And so it's a Capybara, like the animal, facemask. It's very confusing, but this got dropped into our Slack at one point, someone being like, "I searched for Capybara iMask, and it got weird, everybody." So yeah, that was a fun, little side quest that we got to go on. STEPH: [laughs] I just Googled it as you told me to, and it's adorable. Yeah, it's a face mask, and it has a little capybara cartoon on the front of it. Yeah, there are many of these. [laughs] CHRIS: When I think of an iMask, though, it's the thing that you put over your eyes to block the light if you want to sleep. But they're like, an iMask like, a mask that still keeps her eyes outside of it. I don't understand the internet. It's a weird place. STEPH: I think that was just Google saying Capybara iMask. Nope, don't know I, so let's put together Capybara mask, and that's what you got back. [laughs] CHRIS: I guess, yeah. It's just a Capybara mask. And I'm projecting the ‘I' because I phonetically heard that for a while. Anyway, yes. But yeah, masked inputs so complicated. STEPH: This is adorable. I feel like there should be swag for when people move. Like when people find things like this, this is the type of thing that then I stash and then wait for their anniversary at the company, and then I send it to them to remind them of this time that we had together. [laughs] There was also a moment where you said, ‘I.' You were explaining I as in in the letter I, not E-Y-E for eyemask. And you said igloo, and my brain definitely short-circuited for a minute to be like, did he just say igloo? Why did he say igloo? And it took me a minute to, oh, he's helping phonetically say that this is for the letter I. CHRIS: Yep. The NATO phonetic alphabet that if you don't explain that that's what you're doing, now I'm just naming random other objects in the world. Sorry. STEPH: [laughs] CHRIS: And that's why I cut myself off halfway through. I'm like, now you're just naming stuff. This isn't helping. STEPH: [laughs] CHRIS: Yes, the letter I, the letter M. [laughs] STEPH: All of that was a delightful journey for me, and I was curious. I'm glad you brought the test because I was curious if y'all are testing if things are getting obscured, but it sounds like y'all are, which is what helped give you confidence as you were switching over to the new library. CHRIS: Yeah, although to name it, we're not testing at a terribly low level. This is a great example of where I believe in feature specs. Like, within our Capybara feature spec, we are saying, and then as a user, I type in this value into the input. And critically, although this input needs to have special formatting and presentational behavior, it should functionally be identical. And so it was a very good litmus test of does this just work? And then, actually, our feature specs ended up in a race condition, which is just an annoying situation where Capybara moves so quickly that it represented a user. But as we were having that conversation, I was like, wait a minute; I know that users are slower than a computer. But is this actually an edge case that's real that we need to think about? And I think we did end up slightly changing our implementation. So our feature specs did, in a way, highlight that. But mostly, our feature specs did not need to change to adapt to and then fill in the formatted input. It was just fill in the input with the value. And that did not change at all, but it did put a tiny bit of pressure on our implementation to say, oh, there is a weird, tiny, little race condition here. Let's fix that. And so we did race conditions, no fun at all. STEPH: Interesting. Okay, so y'all aren't actually testing. Like, there's no test that says, "Hey, that when someone types into this field, that then there should be this different UI that's present because then we are obscuring the text that they're putting into this field." It was, as you mentioned, we're just testing that we changed over libraries, and everything still works. So then do you just go through that manual test of, then you go to staging, and then you test it that way? CHRIS: Yeah, that's a great question, yes, although as you say it, it's interesting. I guess there's a failure mode here or that our test suite does not enforce that the formatting masking behavior is happening. But it does test that the value goes through this input, gets submitted to the server, turns into the right type of value in the back end, all of that. And so I guess this is an example of how I think about testing, like, that's the critical bit, and then it's a nicety. It's an enhancement that we have this masking behavior. But if that broke, as long as the actual flow of data is still working, that can't break in a way that a user can't use. It sort of reminds me of the Mitch Hedberg joke, an escalator can never break, and it can only become stairs. And so I'm in that mindset here where a masked input that you have proper feature spec coverage around can never quote, unquote, "break." It can just become a plain text input. STEPH: I love how much that resonates with me. And I now know that when I'm writing tests, I'm going to think back to Mitch Hedberg and be like, oh, but is it broken-broken, or is it just now stairs? Because that's often how I will think of feature specs and how low level I will get with them. And this is on that boundary of like, yes, it's important that we want to obscure that data that someone's typing in, but it's not broken if it's not obscured. So there's that balance of I don't really want to test it. Someone will alert us. Like if that breaks, someone will alert us, and it's not the end of the world. It's just unfortunate. But if they can't sign in or they can't actually submit the form, that's a big problem. So yes, I love this comparison now of is it actually broken, or is it just stairs? [laughs] As a guideline for, how much should we test at this feature level or test in general? What should we care about? CHRIS: I feel like this is a deep truth that I believed for a long time. And I think I probably, somewhere in the back of my head, connected it to this joke. But I feel really good that I formally made that connection now because I feel like it helps me categorize this whole thing. Sorry for the convenience as a joke. And so yeah, that's where we're at. STEPH: For anyone that's not familiar with the comedian Mitch Hedberg, we'll be sure to include a link to that particular joke because it's delightful. And now it's connected to tech, which makes it just even more delightful. CHRIS: I only understand anything by analogy, especially humorous analogy. So this is just critical to my progression as a developer and technologist. STEPH: Yeah, I've learned over the years that there are two ways that I retain knowledge: it either caused me pain, or it made me laugh. Otherwise, it's mundane, and it gets filtered out. Laughter is, of course, my favorite. I mean, pain sticks with me as well. But if it's something that made me laugh, I just know I'm far more likely to retain it, and it's going to stick with me. 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. CHRIS: On that wonderful framing there, I think we should wrap up. What do you think? 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: 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 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.