The Bike Shed

This week Chris talks about Bifunctor optics and introduces an app he's been liking recently called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX. Steph talks about her experience using New Relic Browser Stats to troubleshoot a slow page and burnout. Who's feeling it? (Raise your hand.) How do we identify it? What do we do about it? Svelte Is Beloved! - Stack Overflow Survey Bifunctors CleanShot X Next.js Image Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. And we're off the rails already, everybody. It's going to be a good one. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going? STEPH: Hey, Chris, it's going really well. We talked recently that I have a new laptop. So I have been migrating the things that I'm accustomed to over to my new laptop, but I also love that clean, fresh start. So as part of that fresh start, I was like, what if I use Safari? What if I just switch? I'm a Chrome user, for the record. I'm pretty sure you know that, but just to share that. I was like, well, what if I just switched and I try out Safari for a while? So that was the thing. CHRIS: So I heard the words try and the phrase that was the thing, but I'm going to probe a little deeper. How'd that go? Was it good, great, not so great? STEPH: Honestly, it was fine. I did enjoy being in a new environment to see how Safari handles bookmarks and then also the inspector. So it was novel to be in a different browser where I really don't spend much time in a different browser other than when I need to test this specific UI bug or things like that. But the reason that I ended up migrating back to Chrome was frankly for Chrome profiles because I really like that I can have this clear separation now between my work life and my personal life, and then it also keeps me signed in. So my personal email versus my thoughtbot one versus before the Chrome profiles, which I'm not sure how recent of an addition that is where Chrome introduced that feature. But before, I just always had to be signed into both, and it was just all together in one spot. But now I really like that I can separate. And it's more intentional where I'm like, oh, I'm going into work mode, so I just want that profile versus I do need to hop over to my personal side for a while. So that was the thing that brought me back. CHRIS: Interesting. I don't take advantage of that at all. I know of the feature, but it's never really called to me. And if anything, I do the opposite. So specifically, this doesn't work in the browser, but on my phone, I use the iOS Gmail client, and I use the unified inbox. So I just have everything come together. And I subscribe to the idea of, I don't know, it's all work and stuff. And hopefully, people aren't sending me a lot on the weekends, and I will defer and snooze and all of that. But that holistic view pulls me in. And so it's interesting that you're just on the other side of that. It totally makes sense. I actually think I'm wrong here. I think I'm doing the wrong, bad thing. But it's interesting just the way we're on the two sides of that. STEPH: I can see the merits for your approach where it all goes to one place. So you have one place to go and triage, and I think that makes total sense. I haven't triaged my personal life well enough that I want it to come into my work life. And that's the one that needs the more immediate response typically. So I want to prioritize all of my work emails and focus on that and then have my personal ones more like, okay, I've got some time, and I want to check on this. But I don't want to blend those together. Because frankly, I need to do some more triage on the personal side if I'm just going to bring it all into one space. CHRIS: Interesting. Yeah, I would almost view it from the other point of view of I want to protect my personal space, and this is obviously not what I do based on what I just said but protect my personal time so that when it's evenings or weekends or whatever, that I'm not seeing work emails in there. I do my best to snooze them and get them out of the way. But if they are coming in, maybe there's something I need to respond to or, I don't know, maybe it's FOMO in a certain way, FOMO but professional FOMO. I don't really know. It's interesting that that's the feature that brought you back. But overall, how was your experience using Safari? I have heard loosely that now most of the browsers are evergreen; even Edge has really caught up and is now implementing features in a similar way. And so Chrome, Firefox, and Edge are very similar. And my understanding is Safari is the one that actually lags behind or even holds back web standards and implementations and things like that. So, did you find any rough edges of that sort, or was it otherwise just fine, and it was mostly the profile stuff that made you switch? STEPH: It was honestly just fine. I also may have not used it long enough to run into any of those rough edges. But overall, it was just fine. It worked. I just got to that point where I've run into this situation before where I'm signed into my personal email, and then I'm signed into my work email. And then I'm going to Google Hangouts, and Google Hangouts gets confused, and it's like, which person are you? And then I have that moment of where I have to sign out of one, or sometimes it just gets complicated. And what I found with profiles is that that's just never an issue. I don't have to worry about it anymore. So yeah, overall, Safari was fine. I wouldn't mind going back to using it. I just really like the profile feature. This was one of those moments where it helped me notice how much I really liked that feature because I had just opted into it a while back. But this was that moment where I was like, oh yeah, I really miss that. So I'm going to go back to it. CHRIS: The thing you said a minute ago about which person am I? [chuckles] There's a deep philosophical underpinning there, but I've definitely struggled with that and trying to trick the browser into it. So Trello is the one that I'm struggling with that right now. I am one human in the world, I assure you. But GitHub gets this; GitHub plays the game correctly where I'm one human, but I have multiple internet identities. I am the work person. I am the open-source person. And I'm able to route notifications and things to the different inboxes based on the organization that they're part of, et cetera. And I really liked that, that GitHub seems to understand that I am a human that is multifaceted, whereas Trello does not. And so I use Trello in a professional context a lot, but it's my personal...like, I would have to create a distinct account on Trello. And I'm like, Trello, that's not true; I'm still one person. Just understand this Trello organization is a separate facet of my existence. Got on my soapbox on that part. The other thing I want to say is I do feel bad about the fact that I'm just on Chrome. Because increasingly, Chrome has got so much of the market share, and it's becoming the new deeply dominant thing. And so I want to be the agent of change or like, no, we should use different browsers, and we should support them and make sure that we're testing against them and all of that. And then I'm just on Chrome all the time, and I feel bad about it. But it's one of those like; I have so much muscle memory and built-up knowledge around how to use Chrome. And I've just used it for so long now that the switching cost would be pretty high, I assume. I actually haven't even really tried, but I feel bad about it. I'm now saying two things which are I feel bad about it, and I've never even really tried. So I don't feel great in this moment, but these are my truths. STEPH: [laughs] Well, I can plus-one your truths. Those resonate with me. Well, there's always stuff that I am trying that's new all the time. So I feel like I need some constant in my life until I'm ready for other things to be the constant in my life. And then I can muck around with which browser I'm using and change other things. And you have to be in that moment. You have to be ready for it. So going back to a thing that you said a minute ago about separating your work life and your personal life, I very much like that framing, and that's a nice segue, frankly. And it's something that I've been thinking about where you and I often start with technical topics. But I have a very people-centric topic that I'd love to chat with you about today, and it is emphasis on burnout. And who's feeling it? How do we identify it? What do we do about it? And that's been very much on my mind because I have noticed a lot of people around me, including myself; I just feel like we are more inclined to experience burnout right now or are going through it actively. And it feels even more important to have those conversations with each other and with ourselves to talk about what does it look like when we're burned out? How do we recognize when we're there? Because often, when we are burned out, it's not something that happens gradually, or at least it's not something that we notice happening gradually. It's like, okay, I'm fine. And then suddenly, okay, I'm burned out. And I'm at a place where then I can't really focus. I feel overwhelmed. I'm drained. For anyone that is less familiar with burnout, one, hooray, and then two, burnout is a state of emotional, physical, and mental exhaustion that can be caused by excessive and prolonged stress. So then that's what leads to us feeling very overwhelmed, emotionally drained, unable to meet constant demands, or those are the things that are causing our burnout. So I have been doing what I typically do when I'm thinking about a particular topic, and then I'm looking to gather knowledge and information is I try to go pretty wide where I start looking for podcasts, books, just people that are having similar conversations and trying to synthesize a lot of the information that they're sharing. And I have found some really good stuff. The question is now, what does one do once one has that content, and then how do you bring it back and help apply that content to yourself and then people that are around you? So I have some thoughts there, but before I go further, I'm curious, what's your experience with burnout? CHRIS: I think for me, I've been somewhat lucky in that I don't think I've ever really got into an acute period of burnout, but I've definitely had periods where I just felt weighed down. And there are ebbs and flows of life, and of work, all of those things. There is something that I've been thinking about recently, which is the inherent nature of the work that we do where consistently we're working on something where we don't quite know how to do it, and we're struggling, and we're struggling. And finally, we figure out how to do the thing, how to trick the computer into doing what we want. And then the minute we do that, in trying to encode, ideally, we're automating that away. And we take that solved problem, and we just ship it off. And then, we pick up the next unsolved problem from the list. This isn't entirely true, but it feels like sometimes unspecificity in sort of I'm just working on things that are underdefined, underspecified, and I'm trying to solve little puzzles constantly. And, I don't know, I was feeling that recently of the nature of the work was burning me out. And I think earlier on in my career; I definitely experienced this in a certain way. And then, in the middle of my career, there was this perfect inflection point of my skills and the level of tasks that I was going for. But then, the further I got into my career, the more I tend to take the weird underspecified stuff and anything that's relatively clear I'm giving to other folks on the team. I'm like, "Oh, here's this well-defined piece of work here. Can you go implement this admin page?" Whereas I am doing the investigate integrating with third-party platform XYZ that uses a SOAP API that isn't documented. I'm like, okay, cool. Let me roll up my sleeves and figure out what that means. And I noticed in my work that that was starting to weigh on me, and I was able to shake that off and shift around some of the tasks that I was doing. But that was a particular form where the work itself was weighing on me. And I took a step back, and I was like, why do we do the things that we do as developers? Because there's something just fundamental like, you have to enjoy that nature of challenge and constantly escalating challenge to a certain degree, I think, to really like this work, but it can be a lot sometimes. So I feel like maybe that's a slight digression from the topic, but it was a thing that I was feeling in this space. And that's a little bit of my story. STEPH: Well, the beautiful thing about that is it highlights everybody experiences burnout differently. So that could really be how someone is experiencing burnout where they're taking on all these very complicated, different tasks, and they're feeling just worn down by that and that they're not able to meet demand. And they get to that point where maybe they lose their interest in tech and coding because they have pressed too hard in one direction. And so then they need to take a step back. As for me, I've been thinking back over the last couple of months because there was once or twice where you and I had, I think a conversation here on The Bike Shed where I shared that things were okay, but I didn't feel like my normal self. I was losing some of my interest and energy for technology and coding. And I'm very fortunate; I love what I do. So the fact that I wasn't feeling that interest was a really big sign to me that something's different; something feels off. And it does vary depending on the client that I'm working with. And I think feeling that burnout then was a mix of some of those client pressures that I was feeling and that I was working perhaps too many hours as I was very interested in that client's success. And then the other stuff was more personal because we only have, to borrow from the spoon theory, we only have so many spoons to give. And so if you have a lot going on in your personal life as well, that's going to detract from the energy that you also have to give to work. Are you familiar with the spoon theory? CHRIS: I am not. STEPH: I recently heard about it, and I can't stop using it now because I really like it. But it essentially...and there's a really great article that we can link to so others can read about it because I'm not going to remember exactly who came up with this theory. But the idea is that each spoon represents a unit of energy. And let's say if you start each day with only ten units of energy and you use spoons to represent that, as someone needs energy from you, maybe it's work, maybe it's a personal commitment, maybe you're dealing with a chronic illness, then you are giving a spoon away to each of those. So at some point, you're going to run out of spoons. And you want to also be mindful of who you're giving these spoons to because you are giving that energy away. CHRIS: I definitely liked the idea of we start each day with a certain amount of energy, and different things can pull from that pool and whatnot. I'm intrigued by spoons as the unit. It just feels like a weird...I got this little bag of spoons that I walk around with, [chuckles], and I give them out throughout the day. I guess it could be anything in there, you know, objects. But, I don't know, spoons are interesting to me. STEPH: I think it's because this person who came up with the idea was literally having a conversation with their friend in a cafe. And so that was just something that was in front of them. And they're like, oh, I can use spoons to represent. Well, we'll have to double-check the article to make sure, but I think that's why spoons became the representation. So circling back to once you're in burnout, what do you do with it? And that is one of my questions right now. And that's what I'm trying to synthesize a lot of information around. Because once you're in that state, I don't know of a lot of great ways to help other than take time off because, at that point, you're in a crisis state. And you need to step away, and you need to find out how you can recover from having entered this state of crisis. So that feels really important to identify ways that once someone is in that state, that then we can help them. And that feels good. We can advise someone to take PTO. I still don't feel great about it in terms that then, as a manager myself, I don't really know of other helpful ways to then help someone through that period. So then I really started thinking about the fact that once someone is in that burnout stage, frankly, it's too late. We have let someone get to that point that now they are in that crisis instead of addressing it early on. So that is the other thing that's on my mind is one, how do we help people that are already in that crisis state? But then two, how do we start identifying that someone is starting to go in that direction? And then how do we help them tell us? How do we then triage those situations? How do we prevent them from getting to that burnout state? And that's where I've also found some really good content. And specifically, there is a podcast that I've started listening to called The Burnout Show. They essentially share their experience with burnout, and what they did about it, how they recovered from it, and then how they continue to fight it because a lot of people then still go back to the workforce. So then, once you do find a way to recover, then how do you go back to work? And there have been some really great episodes. And I'll be sure to include a link for it in the show notes. There's one particular episode with Grant Gurewitz, who is a guest on the show. And he speaks specifically to the strategy of Three Good Pockets. And this speaks to the idea that there are many things that we can't control in our day. It could be work, family, other commitments, but we can strive for Three Good Pockets of time where we focus on something that's just for us. This is time that's reserved for you and any activity that you find restorative or joyful. And each pocket can vary in size. So perhaps that first pocket is spent just reading a few pages from a book that you're enjoying, and then the next pocket of time is spent outside or calling a friend. And Grant also has a great suggestion around if you're worried that you'll get sidetracked and not actually step away, which I felt called out for that one because that one's definitely me. I will have good intentions, but then I won't actually take the break that I set for myself. So Grant recommends creating a list of restorative activities so that way when it is time for that break when your calendar is reminding you, then you have a list of these activities to choose from. So it makes it easier to say, okay, then I can do this for a couple of minutes, and I can truly step away from work and step away from my screen. But especially now, when so many of us when we're sharing our workspace with our restorative space, for everybody who is still working from home or working remotely, then creating those daily breaks are incredibly important to our wellbeing. And so, it has me thinking about what restorative activities can I add to my day? How can I encourage other people to add more restorative activities to their day? So I really appreciated that advice. And I have noticed that the idea of burnout, but not so much burnout specifically, I've been thinking of it as recovery and balance is a theme for me. And it is something that I am purposely choosing as a theme right now where I want to research and understand more of how we handle these situations and continue to make progress not just for myself but also for my team. CHRIS: I think finding that right cadence and structure and way to reinvest in yourself and ideally gain more spoons if that is at all possible or at least defend the spoons that you have, those all feel very meaningful. I do have a question. I'm interested in your thoughts on this. I feel like we hear about burnout a lot in our industry. I get the sense maybe that it is a more common thing. Like, I hear so many developers talking about how their dream is just to give up tech and go get a cabin and just farm in the woods or something like that. And I wonder, is it a more pervasive thing in our industry? So that's one question. Another is just an observation that we actually do work in a wonderfully...it's an amazing industry where being a developer, there are so many jobs out there. And I don't want to discredit anyone's efforts if they're earlier on and struggling with that. But broadly speaking, it is a developer's market trying to go out there and get jobs and extremely well-compensated, as a general rule. But does that come with this inherent burnout? And if so, which I'm not sure is true, I wonder if maybe we're just more vocal and maybe we actually share more in public. We have more blogs and podcasts and things like that. And that's just a common thing for developers, and so we hear the stories more often, whereas maybe in other industries, it is actually very common, but people are suffering in silence. But also I do wonder, our industry is still so young. The work that we're doing is changing constantly, and that churn and that working in the unknown maybe there is an inherent nature. So that's a bunch of pontifications off the top of my head. And I have no idea what the answer to any of them is. But I am intrigued because it does feel like the shape of burnout as a concept in the developer world is perhaps a little overrepresented, or maybe it shows up more than I would expect. And, I don't know, is the work that hard? I don't know. But then I hear these stories constantly, and I definitely have felt it myself, so maybe. STEPH: Yeah, maybe. Yes, I do think the work is that hard for the record. It's challenging work. I enjoy it, but it is challenging work between figuring out the tech but then also everything else that comes with that. I don't have anything to back this up, but I suspect that a lot of other industries are also experiencing burnout. And I just happen to be more aware of it right now because I'm hearing it more from my friends and the people that I work with. And I suspect that's more directly related to we all just went through 2020, and probably a number of us were trying to forge ahead and get through that time. And so there may be a lot of us that are just now dealing with those consequences of where we just pushed ourselves through a very hard time. And now a lot of that is manifesting and surfacing around really identifying the damage that we may have done to ourselves by just prioritizing work and trying to put our head down and get the work done even though there was so much happening around us. And I suspect that may be a contributing factor is that now people are really starting to recognize, like, oh, I feel this way. And maybe there's time for me to address it. Or frankly, it may not even be that there's time, but your body is just like, okay, I'm done. I made it through the past year or however many months, and I'm going to start shutting down on you. I've given you all the warning signs, but now we're here. We're at a breaking point. So I don't know about the other industries, but I do know the reason that it's more on my mind is because I'm just hearing it more from people, and they're just expressing it. And so, it has become more of a focal point for me, and I've experienced it myself more recently. I'm sure I experienced this back early on in my career, but I took a strategy of well, I'm just a junior, and I just have to get through this. And I have to build experience. For the record, that is not a healthy mentality. I'm just being honest about where I was in my life. And so, I didn't really stop to think about it, but perhaps it is becoming more normalized where people are having more open, honest discussions about where they're at. And if other industries aren't talking about this, I would love for them to. So to round that out a bit, this is something that is just very interesting to me. It's very top of mind. So I suspect I will be sharing a lot more content in future episodes that are just around this. How do we recover? And then how do we balance? How do we work hard without burning out? CHRIS: Work hard, play hard; those are the two placards that you have. Well, I look forward to continued conversations on all of those topics because they are sort of that's the story that underpins all of the work that we do. So I'm very interested to chat more about that. STEPH: Thanks. So what's going on in your world? How's your week been? CHRIS: Oh, my week has been fine. My topics are going to be way more mundane and tech-focused. But let's see, a couple of things, so one is that Stack Overflow has their I think it's Annual Developer Survey. And this year, the results came out, and there was an interesting standout, which was that Svelte was the most beloved framework, which was very exciting to see. Granted, you always have to take these sorts of stats with a grain of salt. But Svelte was 71% loved and 23% dreaded, which they give it as a ratio of how many people really love this thing versus how many people really hate this thing. And so Svelte, 23% of people who have used it are like, I hate that, but 71% loved, so that's a 48% net approval rating. Versus React which was 69% loved, 31% hated or dreaded as the word would be, so that's a 38% net approval. And then Vue, interestingly, was 64% loved, 36% dreaded for a 28% net approval rating. So, yeah, Svelte was decidedly winning in that. But again, the big grain of salt there is looking at the usage stats. React has 40% usage. So of all the respondents, 40% of the people responding to the survey were like, yeah, I've done React professionally, which is a wildly high number for a JavaScript framework. Vue was at 19%, so roughly half of React's usage, which I'm actually impressed that Vue is that high. And Svelte came in at 3%, so it's definitely still in the early adopter strong fan phase. So it makes sense that they would have this outsized high rating. I'm actually surprised that Vue wasn't higher than React, given that. Because I feel like more people are cajoled into React versus Vue can be more of a choice. And I would have expected this to shape out a little bit differently, but yeah, that's the story. STEPH: That's really cool. I liked how you described that as in the very early adopters’ strong fan base stage. CHRIS: But nonetheless, the people that are using Svelte do seem to really like it; that’s coming through in these numbers. And that definitely is my experience. I love Svelte and would love to continue using it for as long as possible. But really, I want a lot of other people to start using it. I want to really grow the usage base so that there are more libraries, and frameworks, and blog posts, and just mindshare in that space because I really do believe there are some wonderful ideas in Svelte. And it's just so straightforward to implement things that I just want more people hanging out. So that's one quick thing. Another quick thing is, I've been using a utility lately or a program called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX, and it is just fantastic. So I can capture a screenshot. I can capture a window. You can capture a GIF or a video. And then you can do little trims and annotations. And then it has this really nice feature where after you take a screenshot, it just hovers in the bottom corner of your screen and is easily accessible. So if you take a video, and then you want to upload it to a Trello card, it's just floating there waiting for you. You can actually dismiss it and push it down, but it's still peeking up from the bottom of your screen, and you can pull it back up, and you can have a couple of them. But it just really makes the whole workflow of grabbing screenshots or videos so easy. And I cared deeply about that because now that I have this tool, I'm all the more inclined to grab a screenshot or a video with just about every piece of work that I do. So it's going into pull requests; it's going into Trello cards. And it's so nice to have a utility that just really makes that as easy as possible. STEPH: I really liked how you mentioned that you can annotate because I often...I'm laughing as I'm thinking about this. When I am taking a video of something that I'm going to share with someone, I will use my mouse to indicate, oh, this is important. And so I circle around it and do silly things with my mouse to try to indicate but being able to annotate would be so much nicer. I know there is another tool that you're really excited about that I can't remember off the top of my head right now. Do you know the name of the tool I'm thinking of? CHRIS: Was it Loom? STEPH: Yes, Loom, because I also used that for a little while, and I've really enjoyed it. So I'm curious, how does Loom and CleanShot X stack up? Is one replacing the other, or are they complementary tools? CHRIS: Mostly complimentary. Loom is great because it hosts the videos, and you can also do audio capture, although I wonder if CleanShot has that as well. CleanShot also, I think, has a hosting thing. So I think there's a strong overlap in their functionality, but right now, I'm using both. And definitely for screenshots and things, CleanShot owns that end of it. And I think it's more likely that I could have CleanShot as the entire tool that I'm using. But I'm still using Loom for this is a walkthrough where I'm going to talk to you about a thing. I want to make it available at a URL that everyone can see rather than actually getting a GIF or MOV artifact file on my computer. So ever so slightly different, but I think of them, CleanShot X is probably the ideal one. But yeah, I'm still reaching for both. So the one other thing I did want to talk about is I have been expanding our use of the dry-monads within the project that I'm working on. And I've done some things. I did some stuff, Steph, and I think it's good. STEPH: Shtuff with Shteph. [chuckles] CHRIS: Shtuff with Shteph, yeah. I'm definitely pushing the envelope of how much we're leaning on these concepts within the app, and I continue to question it. I'm really intrigued to see what happens when other folks come into the project, and they're like, "Why can't I just get the value? It should be a string. Why isn't it a string? Why is it a string that I have to do a ceremony and a dance to get at?" And I'm like, "Well, because everything can fail, you know, like life." But what I have done here so dry-monads is the project that we're using, particularly their result type. So the result represents something that can either succeed or fail. And so we either have a success, which is this wrapper around the value that's successfully executed. So say we make an API call, we get back a response. If we get a 200 or maybe even a 300, then we get the data, and that's a success, or we get a failure and the error message. But fundamentally, we're modeling that in our system in a way that downstream from that, we have to basically determine if it was success or failure. So we're really encoding into the system; listen, pretty much everything can fail, so let's be careful with that. Let's be intentional and purposeful with it. But there is an interesting thing where these objects have fmap as a method on them. So fmap is a way to transform that wrapped value, but fmap works specifically on the success case. So if you make an API request, you get back the data. Everything's great. You can call fmap, and it will yield into a block that data. You can transform that data in some way, and then it will rewrap it up as a success object. So you can operate on this thing as if it has been successful. But in the case that it's a failure, it will just ignore that transformation because you don't want to transform the failure. It's going to be a totally different shape of data. So you want to separate those. We're getting into functors and monads here. So I'm going to handwave a bunch. But fundamentally, that's the thing that we're going for here. But we found ourselves really wanting to work with both sides. So we make this API request, and in the case that it succeeds, we actually want to transform and actually slice out a piece of data from the nested object that we get back. So that's one transformation that we want to apply on the success portion of the aisle. But then, we also want to transform the failure message. It turns out this backend is giving us very unfriendly error messages. So we want to take those and transform them into friendlier user-facing error messages. So it turns out we want to map both sides. And so I went to dry-monads, and I was like, what do you got? I want to know about this in the world. And it turns out they did not have anything. So I started looking into it, and it turns out this is a concept in the world of functors, specifically. Or, more specifically, I reached out to a former colleague, Sid Raval, a former thoughtboter as well. And he likes the functional programming stuff, so I knew he was the right person to ask about this. And he pointed me at bifunctors. So I found myself in a new space and category theory which I never thought I would explore a category theory in this way, but here we were. So a bifunctor basically is exactly what I was talking about where there are these two branches. In our case, it's either success or failure, but it allows you to operate on both sides, both branches. So the method or the function that gets applied there is bimap. So it's fmap which I don't know why it's f why that's typically what it's called. Success map would be a really great word in this context in my mind. So success map only deals with the success side, but bimap takes two different transformations, one for the successful outcome and one for the failure outcome. And it allows you to very directly talk about what you want to do with that. To be clear, dry-monads has a function called Either or Either, depending on how you want to pronounce it. And that takes two Lambda proc-type things because it's Ruby, and functions are kind of weird in Ruby. But it yields you either the successful value or the failure value, but then it doesn't rewrap them. So it's meant to be the terminal. You use that in a controller when you're either redirect or render or whatever it is you want to do. What I wanted was something for mapping, so staying in the success object or the failure object but yeah, bimaps. So I introduced my own extra wrapping layer. This is where things go off the rails, I think. We now have our own internal result objects. I thought about monkey patching for a while. I convinced myself monkey patching was a bad idea. Now that I've implemented as an extra layer of wrapping and I got the wrapping wrong like four times, or I kept recursively wrapping and re-wrapping, and there's a reason people aren't supposed to write these things themselves. But I think monkey patching may have been a better idea here, or maybe I should have never done any of this. We ended up with a stable working implementation and a nice test suite that covers it. But I introduced bimap and failmap as two different methods on our success object. And I did it by doubly wrapping the result objects. So we have our internal result, which wraps the dry-monad result. And I'm worried about that future situation where a junior developer comes on the team and is like, "I don't know what any of this is." STEPH: I love the weekly progression of I've done some things, and let's talk about it. And then seeing this glimpse into your argument with yourself as to yes, but we need it, and we want it, and it's not something that's defined. So let's go ahead and implement it. You ended on a high there where you talked about the fact that it is nice to work with. It does the thing that you'd like it to do, and it's well tested; I love that part. I'm deciding which thread to go with because there were a lot of interesting bits in everything that you shared. And I'm intrigued about the monkey patching as to why you think that could have been a better approach. Could you talk more about that one? CHRIS: Sure. So I ended up having to introduce the secondary object that then wraps the result. And so if you poke at that even a tiny bit, you start to see this like Russian doll nesting of it's our result wrapping a result, wrapping a value. And it's a burrito with three different tortillas wrapped around it. And if you want to add guacamole, you got to unwrap all three burritos. I'm sorry, this is a terrible monad joke here. [laughs] STEPH: For the record, if Taco Bell is not offering that, they should now, now that you've created that. [laughter] CHRIS: There is one, but there's usually cheese in between the layers. They're not just extra layers of tortillas, so that's what I've got here. It's way too much tortilla, and that's sad. You don't want that. And it's confusing. You're like, wait, does this one have two or three layers of tortilla? So when I was working on it and when I was implementing our additional wrapping layer, I tricked myself multiple times. And my test suite was telling me that things were working, but I was testing incorrectly. And I was like, oh man; this is very subtle. And even though I'm deeply immersed in the context here, I'm still struggling with this. So the question is, did I successfully encapsulate all of this? And now anyone downstream just gets to use it,, and everything will be fine. Am I the heroic programmer that made the perfect abstraction that no one's ever going to struggle against, or was that pain that I was feeling representative of the complexity of what I'm trying to do here, and maybe I got it wrong? And so then the monkey patching side is we've got this one layer of wrapping. What if we just monkey patch the result such that it's got these new methods? I'm not adding an additional layer. I don't need to deal with double mapping through multiple layers, and I just get to deal with the context that I have. So I did an initial spike of an implementation that way, but I talked myself out of it because #monkeypatchingisbad, but I don't know. I don't know where I'm ending here. I am happy with where we're at, but I am aware that I may be sad down the road. STEPH: I'm just dying over here [laughs] from everything you're saying. I have this image of you staring out the window thinking, am I the hero, or am I the villain? And figuring out who you are in this scenario with this abstraction that you've created. CHRIS: To be clear, it's raining, and I have a nice rocks glass of scotch in my hand. And I'm just wistfully looking out the window trying to determine what's true. That's pretty accurate, actually. That's pretty much what's going on here. STEPH: I think we're just going to need updates as it progresses along. CHRIS: I will say overall this paradigm...so failures can happen at all levels. These command objects, which are the core of where this is coming in in the application, really represent the workflows of the app in a wonderful, testable, straightforward way. So I love that part. And if I have that, it implies that I have to have this other stuff. I don't think I can get away from that. The other thing is I've always loved Gary Bernhardt's Functional Core, Imperative Shell, which is a conference talk that he gave a while back. I talked to Gary about it actually when he was on the show, and we can link to both that and the conference talk because they are fantastic. And I just love the way he thinks about software. But that was always a little bit abstract for me. Like, what does that actually look like, though, in say, a Rails architecture? And I didn't have a great answer. And now this thing that I'm doing is the closest I think to that where the innards of the system are almost functional even though it's Ruby. We're leaning into that. And so we have these command objects that take in some data, and then they operate on it, and they yield out these results. Did it go well, or did it not? We've got the railway-oriented stuff, which again I'll link to. I link to now every third episode, apparently, but here we are. And that just models the reality of these programs in a really great way. And then we've been trying to introduce some, not rules per se, but guidelines as to how we interact with these things. So inside of the core of the application, we're trying to be as functional as possible. We do transformations on these result objects, but that's it. And then it's only really in the controllers or the mailers that we are doing unwrap or deal with the actual nested value, but everything else is working on conceptual values or whatever it is…these result objects. And that's actually been really nice, and it's allowed us to have really nice error handling within the app. The logging is very straightforward. A lot of apps that I've worked on in the past, I've just silently thrown away many error cases or edge cases. And this is a really great way to sequence the work that needs to be done but never throw away data that you would want. And so far, I'm finding it to be really great. And I'm seeing very obvious ways to hook into it like, oh, this is where we need to find the user-facing error message versus this is where we figure out what we want to log. And so, in some ways, it's great, but I am still open to the idea that this was a terrible idea. I always remain open to that idea to be clear. [chuckles] STEPH: I love how that's the feedback that you're always open to it. You're always trying something new, and then you're constantly going back to revisit; was this a good idea or a bad idea? To go back just a little bit, I do absolutely love the priority and focus that you're giving to the failure state because I feel like that is an area that we, as developers we're very skittish of that failure state. And I realize I'm projecting here. So if you're listening, feel free to take that however you like; maybe it doesn't apply to you, maybe it does. But the failure state is like you said, it's life, it's important, and it's something that is going to happen. And it is something that we should make accommodations for. And I find that we're often very hand-wavy with a failure state. So I love, love how much you always prioritize the failure state and make that something that people can work with and understand. Versus then when something goes wrong, then that's when we have to start to understand the failure state. I recognize there's a balance there because you're not going to know the failure state until you encounter it, but there are ways that we can still optimize to have observability into that failure state for when we do encounter that failure. CHRIS: I've definitely seen that as an evolution in my own thinking, how much am I focused on how easily can I do the core thing, the happy path versus how robustly can I do all of the variations of what this app needs to do? What if the network's down? What do we do there? I do occasionally worry that I've overcorrected on that. And it's like, you know what? This thing that I'm worried about that I'm protecting against in the application is a 0.01% edge case. It's going to affect almost no users, and we're both putting time into trying to avoid it. But also, there's code complexity that comes from trying to handle all the different variants. And so there's definitely an optimization, and I feel like, at different points in my life, I've been undercorrected or overcorrected on that. But I think if I were to describe the arc of my career, it is desperately searching for that optimal path and trying to find exactly the right amount of error handling to apply, and then yeah, then I'll be happy, then it'll be great. But it is like when I look at DHH's classic 15-minute I'm making a blog, look how much I'm not doing, I'm like, sure, sure, sure. Show me that in three years, though. What does the blog look like? How easily can I add a new feature? What happens when there's a bug in production, and a user reports it? Can I chase it down? Can I figure it? Can I fix it? These are the questions that I care about now, almost to the exclusion of what's the first run experience like? I almost don't care about that at this point. Because I spend my time…six months and on that's where the hard work is. And so the first couple of months where you're figuring things out, that's not the hard work of this thing. And so, I'm very strongly focused on those later periods of time. But again, I'm open to the idea that maybe I am overcorrected there. STEPH: I think it does highlight more of a shift in our career. We're still building, but we have experienced the maintenance side as well, and we felt that pain. And so that has led to perhaps overcorrecting, or maybe it's the correct amount of correction. But I do like how you highlighted there is always a cost to each side and those are usually the questions that I'm asking myself when I'm thinking about the failure mode and how much I want to optimize for the failure mode is how much does it cost when this fails? Who's it going to impact? And how much does it cost for me to make this more observable or to address this failure state? And then I try to find the balance between those two. Because you're right, it's not free to address that failure state. And so I may not want to fully optimize to handle that if it's going to be a very small percentage of users that actually are impacted by this failure state, or it seems very rare this is going to happen. But then still finding ways to know that if it does fail, then I can say, "Okay, I'll come back, and now it's worth the investment to improve this." CHRIS: When you said earlier that this is really hard work that we do, I don't know that I believed you. What you just described sounds super easy. You just handle all the stuff, and you dynamically optimize for the needs at the point in time. And that seems easy. [laughs] STEPH: Super easy, yeah. [laughs] Way to bring it back. Well, speaking about observability and failure states, that does lead nicely into a bug that I was working on this past week where there was a particular page that was loading very slowly. And it was something that we'd heard from users that then they let us know that this page was either taking a very long time to load or, frankly, it was just crashing. And then they were never getting to that page. So I happened to be the one that then picked up that ticket. And I went to reproduce the issue, and sure enough, when I clicked on this particular link and then started counting, it took about 14 seconds for that page to load, which is a very long time. And then also sometimes it was just crashing. So the first place that I went was to our error tracking. So I went to New Relic to then look to see okay; maybe there's a slow query. There's something here that's creating this performance issue, but I couldn't find anything. And New Relic does a great job of breaking down all the different response times so I can see how long Postgres is taking, Redis, and Ruby. All of those looked very normal. I couldn't find anything that seemed alarming that was indicating that the page was struggling to load even though I could reproduce the problem. Because I was clicking on it several times thinking, okay, well, if I just do this a couple of times, New Relic's going to notice, and then I'll get to see something, a little breadcrumb that's going to lead me in the right direction. And while I was waiting for New Relic to surface something helpful to me, I mentioned to another developer the issue that I was triaging. And they said, "Yeah, that page has been getting progressively slower, and we don't know why." And I thought, ooh, okay, I'm intrigued even more now as this is something that has been escalating over time, and now we've hit this threshold that we're working on it. And I discovered that in New Relic, I can look specifically at Postgres, Redis, Ruby, all those different response times. But there's a browser monitoring tool that I had not used before. And it showed a lot of helpful information around first paint, First Contentful Paint, window load, all of those areas. So I started diving in and found session tracing, and it was there that then I saw New Relic was telling me, "Hey, you have a page that's taking about 14 to 15 seconds to load." And I thought, okay, I feel validated now that at least New Relic is recognizing this issue. I have seen this issue, but I still didn't know why it's occurring. So the next tool that I used that I don't know if I've used before or it's just been a very long time; it felt fresh in the moment, but it's the Chrome DevTools, the performance tool. And so you can open that up in your inspector, and then you can go to the page that you want to track the performance. And then you can essentially say, "Hey, go ahead and start profiling and reload this page." And it has so many stats when it finally does load. It has CPU flames charts, which essentially it visualizes a collection of all the stack traces. It has a film strip, so you can actually see the rendering progress of your website along different time points. So if you wanted to go back to a specific time, you can see what did the webpage look like at this point? And then if you go a little further, okay, how much was loaded at this point? So there's a lot of interesting and a little overwhelming information that's there. But the thing that did catch my attention is there's a chart. I don't actually know what this chart is called. It's not a pie chart because there's no center to it. So it looks like a donut chart, and it's broken down. And it shows you the loading times, scripting, rendering, painting, all of those different values. And the rendering time was taking 35 seconds. And I was like, ooh, okay, that is meaningful right there. So then further investigation, now that I knew what I was looking for, I wasn't looking for something more on the back end. I was looking for something more on the front end. And I didn't think it was necessarily JavaScript because we also have JavaScript on this page. So at least this was helping me get a little bit closer before then I went into the codebase to start seeing what's happening. So once I knew it was a rendering issue, I went to look specifically at that view, and we have a form on that page that was generating an empty HTML select option for every record that's in the system. So let's say that you're ordering from a restaurant. On this page, there was a form where it had a list of all the restaurants, and, in our particular case, we had about 17,000 restaurants. So there were 17,000 empty HTML selection options, which could have some significant impact on the DOM and page load time. And that was the piece that was really leading to the performance, is the fact that we were rendering that empty select option. So from there, it was then just triaging okay; we don't really need to render all of these restaurants. There are ways we can scope this down. And that way, we're only showing a little bit at a time versus creating all of these empty options. I should clarify they're empty because part of this form is you select from the first dropdown, and then it populates the other one, and it gives you more information. But the way that this form was implemented, it was actually trying to show all of them at once. But it didn't actually have the data yet, but it was doing like a restaurant.all type of count. And so then that's how we were getting that many empty options. So it was a very interesting journey. It was very helpful to learn that New Relic has this browser monitoring tool. And I really appreciated their performance tool. And circling back to Chrome, Safari may have something similar. But I found Chrome's performance tool very helpful because then it helped me realize that it was the rendering. And so then I could really focus on the markup and the view versus knowing it wasn't more in the database layer. CHRIS: I really love the description, almost like a mystery novel of these bugs when we encounter them. Because if you just get to the end and you're like, oh, I was rendering a select, and it had all of this, that loses so much of this story because again, the coding is not the hard part of the work that we do; it's the figuring out what needs to be done. And in this case, that journey that you went on to find the bug. I really like the point where you said, "And someone mentioned this page has just been getting progressively slower over time." I was like, ooh, that's interesting. Now we got a clue. Now we've got a lead, and we'll chase it down, and then finding the browser tools and all of that. And also, as an aside, browsers are just such an immensely impressive piece of technology, everything that they do. And then you add the DevTools on top of them and magical stuff going on there. But yeah, also probably don't render 17,000 empty selects. [laughs] That seems like it will get you in trouble pretty quickly. But also very easy to get to and especially if there is this incremental, slow creep over time where it's like, oh, that page seems like it's a little slower. It's a little slower still, and it just keeps creeping up over time. But yes, I appreciate you taking us on that journey with you. STEPH: Yeah, it was a fun discovery. And it made me realize that while we have alerting set up for some of our other queries, we don't have anything set up for the browser time. So that would be a good optimization on our side is to start alerting us before a page gets to the point that it's taking that long to load to notify us sooner. So we don't have to wait for a user to reach out to us, but we can triage sooner. CHRIS: I also do love the idea of extending the metrics that we hold ourselves accountable to all the way through to the user, and so the First Contentful Paint and all of that. The one that I really love recently that has captured an idea that I struggled to put words to is the Cumulative Layout Shift. Are you familiar with this piece? STEPH: Uh-uh. CHRIS: So there's like, how quickly does the page render? That's the thing that we want to know. But a lot of applications these days, particularly single-page apps, render pretty quickly, but they render what ends up being a skeleton or a shell of the page. And then behind the scenes, there are like ten different AJAX requests happening. And as the data comes in, suddenly, a part of the screen will render. And they'll render a list of items that they just got back from the back end, but they're still waiting for the information to populate the header. And so if you look at that page, it's constantly shifting as it's loading and just feels, I don't know, flimsy in my mind. But I didn't have a good word, or I didn't have a metric or a number to attach to that. And then I learned about Cumulative Layout Shift, and I was like, oh, that's the one. Now you've mapped the thing that I was feeling. And I like when that happens. STEPH: Is that the difference between the first paint and First Contentful paint? Is that similar? CHRIS: I think it's more than that because there are not just two discrete events in this. It can be multiple. And so it's like, how many different times did the thing that's rendered on the screen move around? And so if images are loading, but you didn't have a proper image height and width set, that's another way that this can happen. Then initially, the browser is not going to reserve any space for that because it's like, I don't know how big this is. And then, when the image shows up, it now knows the intrinsic height and width of the image. So suddenly, your page is going to jump from that. You can get ahead of that by putting the height and width on your image, and that's great to do. And frameworks like Next.js have done some really amazing work of making that a build time step as opposed to something you have to do manually. But then also, more generally, how do we handle this? React is doing some interesting work with Suspense, where you can aggregate together multiple different loading states into one collective thing. It's almost like promise.all, but for your page. I haven't followed that too closely, but I know that that's framework-level work that's happening over there. GraphQL does a really great job of allowing you to group queries together. So there's a solution on that side. But broadly, if you just render some HTML on the server and you send it to the front end, then you don't have this problem because you just have one ball of HTML. The browser is pretty good at rendering that in one pass versus if you have single-page applications that are making a handful of AJAX requests that will resolve in their own timelines and eventually paint to the screen. You get this different shape. And then the worst case of it in my mind is you render half the page. And then suddenly, one of the requests realizes the JWT has expired, and suddenly, you get thrashed over to the login page. Please don't give me that experience, developers, please. Please do something else that isn't that. That makes me sad in my heart. STEPH: Prioritize the failure state. That's what I'm hearing. CHRIS: Callbacks. STEPH: Well, on that wonderful circular reference, shall we wrap up? CHRIS: Wait, I thought circular references were bad...Never mind. Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed, or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: 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.Support The Bike Shed

This is the sweeps week episode, the epic crossover episode, the mega episode! We have a very special episode as Chris, and Steph teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. They cover the origins of their shows, their experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Remote Ruby Rails with Jason Ruby on Rails podcast *Transcript: * STEPH: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. This week we have a very special episode as Chris, and I teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. This episode was so much fun to record, and we have Brittany Martin to thank as she organized and moderated this special event. So without further ado, here is the mega Ruby episode. BRITTANY: Welcome, everyone. We have a whopping seven podcast hosts recording today. So, listeners, you are in for a treat. This is the sweeps week episode, the epic crossover episode, the mega episode. We're going to need our editor to insert some epic sound effects right here. Announcer: The mega episode. BRITTANY: So let's go ahead and introduce the crew today. I am Brittany Martin from the Ruby on Rails Podcast. CHRIS OLIVER: I'm Chris Oliver from Remote Ruby. JASON CHARNES: I am Jason Charnes, also from Remote Ruby. ANDREW: I am Andrew Mason, also from Remote Ruby. STEPH: And I'm Stephanie Viccari from The Bike Shed. CHRIS TOOMEY: I'm Chris Toomey from The Bike Shed. JASON SWETT: And I'm Jason Swett from Rails with Jason BRITTANY: Today, we're going to cover the origins of our shows, our experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Now I know personally, I really enjoy the origin story behind Remote Ruby. So, Chris Oliver, could you kick us off with that? CHRIS OLIVER: Yeah, we can go back maybe to the first time that Jason and I met, which was Jason emailed me out of the blue and was like, "Hey, are you going to be at RailsConf?" And I wasn't planning on it, but it was over in Kansas City, like four hours away from me. I was like, "No, I'm not going, but I'll meet you." So we went and drove over there and met and have been friends ever since. And Jason had the idea of doing an online meetup. And I'll let him explain where that started and turned into the Remote Ruby Podcast. JASON CHARNES: I thought it would be a good idea. There weren't any online meetups. This was pre even the idea of shutting down the world for a pandemic. And maybe I was just too soon because I got Chris to speak at the first one, and we had 40, 50 people. I spoke at the next one, and there were 20. And by the third one, there were five of us. So it wasn't really a super sustainable thing for me to do. So Chris and I got together and said, "What if we tried podcasting?" Chris, you hadn't really done your own podcast at that point, had you? CHRIS OLIVER: No, I don't think so. And you and I were just having calls every week or whatever just to hang out and chat. And we were like, why don't we just record that and publish that as a podcast? And here we are. JASON CHARNES: Yeah. So we've been doing that. I think we started in 2018, so yeah, three years in June, and somehow people still keep listening to us talk but probably because we brought along our friend, Andrew. ANDREW: Wow. Okay. No, that's not true. But yes, I was a guest on Remote Ruby before I joined as a host. And not to get into the details, but I was on another podcast, and something went down, and I no longer was on that podcast anymore. And Chris and Jason were like, "Do you want to come hang out with us?" And I was like, [chuckles] "Absolutely." So I started doing that, and at the same time, I also started The Ruby Blend with Nate Hopkins and Ron Cooke. And so we were doing that for a while until that had to tragically shut down. But I'm still here with Jason and Chris. I guess I should also mention that Jason Swett gave me my start in podcasting a month or two after I started full-time as a Rails developer on a now archived show called The Ruby Testing Podcast. BRITTANY: Which is the perfect segue because Jason Swett was also my first opportunity to guest on a podcast. So I was already hosting, but I hadn't guested, which is kind of the opposite order. So, Jason, do you want to tell the origin of where Rails with Jason came from? JASON SWETT: Sure. I'd been involved with podcasting since around 2016. I somehow ended up on the Ruby Rogues Podcast and was on there for maybe a year or so. And then, somehow, I got the idea that I could start my own podcast. And as an experiment, I started a podcast that I called The Ruby Testing Podcast, which I figured was sufficiently narrow that I could get some traction. And to my surprise, guests actually said yes to coming on the show. And also, to my surprise, people actually listened to the podcast. That gave me some confidence. So maybe a year later, I broadened, and I changed from The Ruby Testing Podcast to just Rails with Jason. And I have been doing that for something like two years. BRITTANY: That's fantastic. I want to move to probably our most experienced podcast veteran, and that would be Chris Toomey. When I was learning how to code, I was listening to Giant Robots and then was excited for the transition that The Bike Shed took. Chris, I would love to hear the story of what it was like taking over a really popular podcast and really maintaining the drive behind it. CHRIS TOOMEY: So, as you mentioned, I had done a little bit of podcasting. It was about a six-month run where I was a co-host on Giant Robots, which was the original podcast of thoughtbot. And that was more in the business and sort of how do we build a software company? So at that point, I was running Upcase, which was the subscription learning platform that thoughtbot had. So I was talking about the inner details of the business, and the marketing tests, and A/B tests and things like that that I was doing. And every week, I was sharing my MRR rather transparently in that thoughtbot way that we do. I did that for, like I said, about six months and then took a while off. And in the background, thoughtbot had started up a new podcast called The Bike Shed, and that started October 31st of 2014. So The Bike Shed has been going for a long time now, and that was hosted by Derek Pryor and Sage Griffin. And they ran that for a number of years. I think it was about four years that the two of them worked collectively on that. But at some point, they both moved on from thoughtbot, and there was an opportunity for new hosts to step in. So I took over in August of 2018. So I've been doing this now for about three years. And so, for that first year, I took the opportunity to do a tour around thoughtbot and talk with many different individuals from the company and a handful of people external to thoughtbot. But I knew that there were so many great voices and ideas and points of view within thoughtbot that I really wanted to spend some time getting to know more of them personally and then sharing that as much as I could with the existing audience that The Bike Shed had. But secretly, all along, I was looking for a person to hang out with all the more so, and Steph was the person that was a perfect choice for that. And so, for the past two years, Steph and I have been chatting. And I will send it over to Steph to share a little bit of her point of view on that transition. But from my point of view, it's been fantastic. STEPH: I still remember exactly when we had the conversation. You were running The Bike Shed and doing an incredible job of just having weekly guests. And then you'd reached out to me and said, "Hey, would you be interested in doing an episode?" And I thought, "No, absolutely not. I can't podcast. I can't begin to do this." So you continued to convince me. And finally, you said something that resonated where you were like, "Well, we can just show up and record, and we don't have to publish. We can just see how it goes." I was like, that's a perfect safety net. I'm into that. So I showed up, and I think the first episode that you and I recorded ended up being titled What I Believe About Software. And it was a lot of fun. I realized I have a lot of things to say. And after that, I think it was another month or so. You continued interviewing more guests, but then you reached out to me and asked me if I wanted to be a co-host. And at that point, I was super jazzed about it, and it's been wonderful. It's been a roller coaster. I have learned a ton. BRITTANY: I'm kind of seeing a pattern here where over the last three years, it seems like Remote Ruby came into place, Bike Shed transitioned. That's when I took over as host of the 5by5 Ruby on Rails Podcast. We're going to call it the golden era of the Ruby Podcasts. But for me, I probably have the longest-running podcast. It was started back in 2009 on the 5by5 Network, but it's gone through many different hosts. And so, I took over roughly about three and a half years ago as the main host from Kyle Daigle. And then, just a couple of weeks ago, as I announced on my podcast, we took the podcast independent. We are now just The Ruby on Rails Podcast. And I'm starting to change the model where I'm bringing in more co-hosts. So that way, I can get those regular updates that I really appreciate on all these podcasts we have featured on the show today. I am curious. I want to talk about how we put together the episodes and plan out how everything's going to go down. I know for me, I'm currently a mix of interviews and co-host episodes. So I'd love to hear from Andrew. How do you plan out what Remote Ruby is going to be week to week? ANDREW: This is an easy question because we don't at all. We don't plan. We do have some guests that come on, and sometimes, they may get their Zoom link the day of; who’s to say? But we really don't have a plan. We don't talk about what we're going to talk about beforehand. We all just kind of show up, and I think we have that kind of relationship and flow where it always just works. JASON CHARNES: And I think part of that came from actually how Chris and I started the show because we were trying to make it as low stress as possible because we knew if we put a lot of pressure on it, we would stop doing it. Our first episodes were YouTube live links that we just shared out. And then in our next episodes, we were like, oh, we should start using some software to do this. And then eventually, we got an editor, but that same core of let's just keep it fun for better or for worse, I think, also affects our planning. BRITTANY: I've been lucky in the sense that I have guests sit on all three of the episodes. And I do want to give a compliment to The Bike Shed because it is very well run and very well planned. So I want to kick it over to Steph as to how putting together a Bike Shed episode looks. STEPH: Oh, thank you. That's wonderful to hear, by the way. That's wonderful feedback. So we predominantly use Trello to organize our thoughts. So we will have...and as we're capturing community questions that are coming in, so we will capture those on the board. And then, we will have a ticket that represents a particular episode. Usually, on the day of, we'll share some thoughts about, hey, these are the broad topics I'm interested in. And there's usually some hot takes in there, which is fun because the other person doesn't know exactly what's coming, and we can have real honest conversations on the mic. And then, every so often, we'll grab a beer, and we'll go through that list. And we'll chat through what sparks joy. What do we want to talk about? What would we like to respond to? And that's pretty much how we organize everything that we discuss. Chris, is there anything I've left out that you want to add? CHRIS TOOMEY: I think that mostly covers it. We do occasionally have interviews just as a way to keep some variety and different things going on, but primarily it's the sort of what's new in your world? And I find that those episodes are the ones that I think are the most fun to record for Steph and I when it really feels like a sincere conversation. I've recently taken to a segment I call good idea, terrible idea where I'm like, "I'm actually considering this, Steph. What do you think?" And live on-air, I'm getting Steph's feedback, and generally, we're very aligned. But every once in a while, she's like, "That's a terrible idea. Don't do that." And I love those, and I love being able to share that because I think it's really easy to talk about, you know, here's a list of things that are true about software, but really, everything depends. And it's all the nuance. And so, being able to share some of our more pointed experiences and then share the conversation that we have over those is hopefully very valuable to the audience but definitely the thing that I enjoy the most. BRITTANY: So kicking it over to Jason Swett, I really enjoy the interviews that you do. I'm curious, how do you select guests? JASON SWETT: Well, thanks. Selecting guests is tough. I had Peter Cooper on the other day, and I was telling him that I feel like every guest that I get on the show is the last guest I'm ever going to be able to get on the show. But somehow, I keep finding more and more guests. Early on, it was relatively easy because I would just find book authors, or if somebody else does podcasting, then it's fairly obvious okay, you're the kind of person who does podcasts, so I'll invite you. But it's a little bit tough because I don't want to invite people who aren't into podcasting and would be really thrown, although sometimes that happens. But let's see, sometimes I send an email out to my email list, and I'm like, "Hey, I'm looking for guests for my show." Sometimes I just tweet that I'm looking for guests. And sometimes I get some really interesting guests from surprising places. But at least in the start, it was looking for those authors and podcasters and the people who are known in the Ruby community. BRITTANY: I know for me, I strive to have at least 50% of my interviews be with people who've never been on a podcast before. And so that usually involves the top of the episode they're dry heaving into a paper bag. And I'm explaining to them, don't worry, about halfway through the episode, you're not going to remember that you're recording anymore. It'll be fine. And you know what? It's always fine. And so, I do love hearing from a wide variety from the Ruby community just because it really proves just how big it is. So I'm curious, could you host the podcast that you are currently hosting now if you weren't actively working in Ruby? ANDREW: I could because Chris is the one that has all the clout. I could sit back and make dumb jokes and memes during it. And as long as Chris is there, I think we'll be good. JASON SWETT: Yeah, I think I could because a good majority of what we talk about on Rails with Jason actually has nothing to do with Rails, so that would probably actually work out. STEPH: I think yes is the answer. While a lot of our conversations do focus around Ruby and Rails, we often use a lot of other languages and tools, and those are a lot of fun to talk about. So I think I would just talk about whatever new tool or language that I'm using. So I think yes, it would just take a slightly different form but would still be at its core the same where we're still talking about our daily experiments and adventures in web development. BRITTANY: I agree with you, Steph. I will say that it seems like Chris Oliver and Chris Toomey have an endless well of things to talk about just based on what they do day-to-day. CHRIS TOOMEY: I try and go on adventures and then share as much as I can. But to resonate with what Steph was saying there, we try to make the show more generally about software, and it happens to be that it's grounded in Ruby on Rails because the vast majority of the work that we do is in that. And I just recently started a new project. I was given the choice of I could pick any technology I want, and it remains the technology that makes sense to me to be the foundation of an application that I want to maintain for years and years and years. So, on the one hand, I think I could definitely talk about software more generally. I think I'm doing that most of the time. But at the other end of the spectrum, but it's always going to be based on Ruby because I haven't found a thing elsewhere in the world that is better than that. CHRIS OLIVER: I completely agree with that. I probably have a little bit of a unique thing doing a screencast every week. A lot of those are based on I'm building some project, and I need to build some random feature like Stripe Checkout. And that's a good one to do a screencast on and implement in the project. And then, we can also talk about the decisions along the way on the podcast, which is kind of nice. BRITTANY: Yeah, it feels like every week, Chris Oliver is like, yeah, I've created a new open-source library, and I'm fabulous. [laughs] Let me listen to this. CHRIS OLIVER: Too many of them. I'm currently rewriting a lot of the Pay gem. And it's just one of those things where you make a bunch of decisions. And then, if you make an open-source project, people use it in all these different ways that you didn't intend yourself, and so you want to support that. But then you need to rearchitect things in it. It is a lot of learning as you go, which is always a lot of fun. So those I think are really good topics to talk about when you're building something like that. I'm always amazed by how does the Rails core team make these decisions on what should be in the framework and what shouldn't? And what do they want to maintain, and how do they keep it flexible but yet have some sort of rule with how they allow things to be implemented and whatever? It is a very hard job to have. So I get my little taste of that with some open source but not on their level. BRITTANY: I always thought that you had a good contrast to Jason Charnes because Jason works at Podia. And while you do get to work on a lot of really cool technologies, I feel like the stakes are much higher. So you can't just rip out StimulusReflex and put in something else just because it sounds cool that week. And I love how you talk through the pluses and minuses to making a big change within the Podia codebase. JASON CHARNES: Yeah. I haven't really thought about that contrast before, but it's helpful for me even just to talk it out with two other people once a week, and luckily, pretty cool about me just coming on and talking about hey, these are the steps we took to get here. Yeah, it's a cool dynamic. BRITTANY: Steph, have you ever had a client from thoughtbot say, "Hey, were you talking about me?" whenever you're talking about your current client? STEPH: That is one of my fears at times that it will happen [chuckles] although we stay very positive on the show. That's something that's very important to us. There's enough negativity in the world. So we really want to focus on our positive experiences through the week. But there have been times where I'm speaking about some of the challenges or things that we are running into that yes, the engineering team is listening to the podcast, and they're like, "Oh, I heard you talk about this feature that we're working on or this particular challenge." And that's really cool because they get that behind-the-scenes peek to see how Chris and I are chatting about that. But yet they know enough, and they know which project that I'm on that they recognize exactly the technology and the feature that I'm trying to describe. So that has certainly happened, and it can be a lot of fun when it does. BRITTANY: Andrew, how have things changed for you now that you're not working at CodeFund, which was very much like an open-source thing? People could see what you were actively working on. And now you're working for a company where it's closed source. And so, you might not be able to reveal as much as what you're working on at any given point. ANDREW: It's different, but I don't think it's been an issue per se. I'm not like, oh crap, I let that slip, and I didn't mean to. That's not really an issue. I really cherish the time I had at CodeFund. When I think back on my experiences, that was my favorite time just because I was able to do that thing that a lot of people really want to do. I was working as an open-source developer. We were spiking StimulusReflex; that’s when we were building up StimulusReflex and trying to build up the community. I joined Ruby. We started the Ruby Blend, and things were going good before a dramatic turn. But in terms of the closed and open source, it hasn't been that big of a shift just because instead of talking about what I'm doing at work, like, I still talk about it, but I speak about it in more general terms. But I also then kind of freed up to talk a lot more about the dumb crap I do on the nights and weekends. BRITTANY: So the majority of our podcasts either have the word Ruby or Rails in it, but I think we've all agreed that a lot of the topics that we're talking about are not specific to that community. But in a lot of ways, I feel that having podcasts in our community is how we're going to keep our community thriving. So I'm curious if anyone has any thoughts around...is there a way to market our podcasts so that other developers will listen to it? I get really excited when I get listener feedback saying, "Hey, I used to do Rails maybe ten years ago, but I've been listening to your podcast, and I really enjoy such and such episode." How can we make our podcasts accessible to the general software community as opposed to just Ruby? CHRIS TOOMEY: One thing that stands out to me about Ruby and Rails is because it's full-stack, because of its foundations, it tends to be holistically about web development. And so, whereas I look at React projects or other JavaScript or different things that are going on, I see a more narrow focus in those frameworks. And with Ruby and Rails, what I love about it is that it's really about building software. It's about building products that are valuable, that deliver value to end-users. And so that being the core of it, that's the story that constantly brings me back to Ruby and Rails. And it's the story that I want to keep telling as much as possible. And it's the thing that keeps me engaged with this community. And so, I think podcasts are a great way to continue to literally tell those sorts of stories and really celebrate that aspect of Ruby and Rails and why it remains such a productive way to build software. CHRIS OLIVER: I think related to that, one of the things that we should talk about more is the draw of Rails was look at what you can do with one person or two people. And I feel like we went down the JavaScript route, and now you need two teams of people, and you end up building bigger stuff. And Hotwire has kind of been like, hey, here's a reminder of what you can do with a very small team. And I think that resonates a lot with a lot of people building startups and trying to build side projects and everything. And that's one that is Rails-related. But there's a ton of people building Hotwire stuff in Laravel too. And they're all very similar. So I think at a certain point, yeah, we're talking about maybe Rails specifically, but you can apply all those things to different frameworks and just different tools. STEPH: I'd like to add on and extend that because I wholeheartedly agree with what both Chris Toomey and Chris Oliver just said. And in addition, a lot of the conversations that we have on The Bike Shed are focused on Ruby and Rails, but then we will extract that particular concept to the point that it really doesn't matter which language that you're using or which framework that you're using. We're talking more about the high level. What's your process? What are you thinking as you're going through and implementing this? And based on more of our recent conversations, you'd think we're more of a Postgres podcast, how much we hype up Postgres, and the things that we can do at the database layer. So I think there are a lot of ways that we can start with a foundation of this is how we're doing it with Ruby and Rails, but then talk about it at a higher level where then it's really applicable for everybody. JASON CHARNES: If talking about one technology defined your podcast, we might as well be a Laravel podcast because we talk about that framework more than we do Rails sometimes. [chuckles] BRITTANY: So that begs the question: is there room for more Ruby and Rails podcasts outside of who's currently on this call? JASON SWETT: I think so. And I mentioned that Peter Cooper was on our podcast a little bit ago. That's something he and I actually talked about in that episode. And I shared the anecdote about how in the new America's founding, Ben Franklin's brother or something like that wanted to start a newspaper. And somebody told him what a dumb idea that was because America already had a newspaper. And people might say, oh, there are already however many Rails podcasts. There are a small handful. But I think there could be ten more Rails podcasts or even more than that potentially because I think people have an appetite for help, and camaraderie, and stuff like that. And I don't think we've nearly bottomed out in terms of satisfying people's appetite for that stuff. JASON CHARNES: Yeah, I agree with that because a lot of times, when I listen to podcasts, the more you get to know someone, that connection becomes what it's about for me. So, yeah, there's plenty of room. I mean, brand it as Ruby and tell me about your life as a developer I'll listen. CHRIS TOOMEY: I'll also throw it out there that the way you framed the question is like, is there room for it? But one of the wonderful things about podcasting as a medium is it is distributed. It's not centralized. You can start up a podcast any day. And I will say, as someone who inherited a popular podcast or a sufficiently popular podcast and just got to run with that, it has been such a wonderful way to get my voice out there and provide opportunities that I want that for everyone. I want everyone to have this ability to speak about the way they think about software and then find like-minded people and be able to build even many communities within the larger community of Ruby on Rails. So beyond the question of, Is there room?” which I definitely think there is, I so wholeheartedly support anyone pursuing this for their own reason. ANDREW: Yeah, I think to bring it all the way back, one thing that Chris, Jason, and I care a lot about is Ruby as a community. The community aspects of Ruby are very important to us. And we're actively trying to build that up and bring in new people and bringing people onto their first podcast. We say it all the time, like, hey, if you want to come on the show, let us know. We've had a few people even, you know, recognition in jobs from that. So to us, that is the payoff of doing the show. Maybe our show is the first time someone learns about Rails. And that to me is the possibility in the future. It's like, how can we market our shows that markets Ruby as well so that this meme of Ruby being dead finally goes away because it's not. I think it's growing. And I think the more and more we push as people who are public figures in this space that we want to bring more people on, that this is a space for everyone, I think that's just kind of the ethos that all of us have, and I think that's great. BRITTANY: So I'm curious, on a lighter note, has anyone had the funny experience of realizing that you're not just podcasting into the ether and that what you're saying and what you're doing matters? For me, I have definitely been at conferences where people will run up and hug me just because they heard my voice, and they are like, "I didn't know what you looked like, but I have your voice memorized," and it just blew my mind. And I was like, "Thank you so much for being such a loyal listener." And it just proves that people are out there listening. ANDREW: I tend to talk very openly about mental health. And I very often fail in public and talk about it. And I've had a lot of people message me and email me over the past three or four years and be like, "Hey, thank you for talking about this thing that's not actually about Ruby. It's not actually about coding, but it's just about being a developer." And those are the emails that make me feel the best. Like, someone who's out there like, "Yeah, I also feel like this. Thank you for speaking about it." JASON SWETT: I had a surreal experience. I went to India in 2019 through RubyConf India. And this guy wanted to take a selfie with me because apparently, he considered me famous. So that was cool and pretty surprising because I definitely didn't consider myself famous. STEPH: My favorite has been when we receive listener questions because it lets us know that people are listening and engaged in the conversation, and I essentially feel like they're part of the conversation. They will write in to us and share anecdotes, or they'll share answers to some of the questions that Chris and I will pose on the show. But every now and then, we will also get an email from someone that says, "Hey, just thanks for doing the show. I listen, and it's great," and that's all they share. And that, to me, is just the most wonderful thing that I could receive. BRITTANY: Some of my favorite episodes from all of your shows is when we get an inside peek into what people are doing, like Andrew moving. Jason Charnes, you putting together a conference was actually some of my favorite episodes of yours, which was really early on, which proves that I'm a Remote Ruby OG. But I loved hearing the inside track as to what organizing a conference is because I think we need to get more content out there about how difficult but how rewarding it is. JASON CHARNES: Yeah, I hadn't really thought about...that was around those times we hadn't done... It feels like it's been ages since we did Southeast Ruby, but Chris and I actually podcasted from the last Southeast Ruby we did. We just met in a room and recorded. But when I started that conference, I didn't have a lot to go on. So I'm more than glad to share because the reason I started is there were no Ruby conferences around me, plus I'm an open book. So for better or for worse, maybe that's good podcast material. JASON SWETT: Side note, it's one of the most enjoyable conferences I've ever been to. JASON CHARNES: Thank you. BRITTANY: I completely agree. I miss the regional conferences. JASON CHARNES: We lucked out because we were already planning on skipping 2020 because we were tired, and then COVID hit. I just sat on the couch one night and looked at Shannon (she helps me put on the conference), and I was like, "Wow, that would have been terrible. That would have come out of our own bank account, all that loss if we would have already booked somewhere." So phew, when it chills out, we'll try it again. BRITTANY: So let's talk about legacies. I know that some of us have taken over from popular podcasts. Some of us have grown podcasts from the very beginning. So I'm curious, do you ever put any thought into the legacy of your podcast, whether or not you're going to stay with it to the end? Would you eventually pass it off? Do you think about whether or not it's your responsibility to the community to make sure that it keeps going? JASON SWETT: I, for one, plan to have my consciousness uploaded to a supercomputer upon my death so that the Rails with Jason Podcast can continue on indefinitely. JASON CHARNES: Did you recently watch Upload the TV show? JASON SWETT: No, I've never heard of it. JASON CHARNES: Oh, man. That's a whole nother conversation. BRITTANY: Consider that homework, Jason. JASON CHARNES: It's an interesting question because we started ours out of nothing. I wonder, is one of us going to get tired and just quit? I'd like to think that if one of us did, it would keep going because there are plenty of cool people who could hang out and talk Ruby on it. But it's interesting, something that's casually crossed my mind, but I think we're good. I think we're still doing it unless Chris and Andrew have a surprise for me today. ANDREW: Surprise! [chuckles] I've thought about it a few times, specifically because I'm the youngest member of Remote Ruby. What if Jason and Chris just left, and they were like, "Oh, it's all yours now." Could I keep running it by myself? I think honestly, the answer is I would probably still do it just to have an excuse to talk to someone. I enjoy it. It's almost like a hobby at this point. I don't feel any obligation to create it. To me, it's really like an excuse to hang out with two friends, and other good stuff comes from that. But at the end of the day, I cherish that time just us hanging out a lot. CHRIS OLIVER: Yeah. I think that's why we sometimes joke about it being a weekly therapy session where we are just hanging out and chatting about stuff. It's nice to be able to talk about programming things at a high level with people you don't work with that have totally different perspectives and stuff. So yeah, if Jason and Andrew dropped off, I would still try to have conversations with random people I know and keep it going just because it's enjoyable. I would hope that we would be able to keep it going and have other people on there. BRITTANY: I'd love to hear from someone from The Bike Shed. STEPH: I have thought about it. I've thought about it partially from the perspective that Chris Toomey brought up earlier in regards to being on a podcast is an incredible platform. You get to share your opinions, and people listen to you. And they know you, and it's really wonderful marketing. So I have thought about it from the perspective of I want other people to have access to this really wonderful podcast that we put on each week. So part of me is very aware of that and thinking about how more people can have similar exposures. So a sort of a similar event occurred when Chris was moving on from thoughtbot and pursuing other interests. And at that moment, I just thought, oh my goodness, Chris brought me on as co-host, and now I'm here alone, and I don't know what I'm going to do. And I just panicked. I truly don't think I even considered other options. I was like, well, okay, it's over now. This was fun. And then it turned out where Chris was going to stay with the show. So things have just gone on swimmingly, and it's been wonderful. But similar to what someone was saying earlier around when you start listening to a podcast, and you really develop that relationship and you go back to that podcast because you really enjoy hearing from those people and their adventures, it's very similar for me where The Bike Shed is very much the conversations and chats with Chris. So I think if we were to move on, it would be whenever Chris and I decided to move on and give the reins over to somebody else. I don't know if Chris fully agrees, so this will be interesting to find out. [chuckles] CHRIS TOOMEY: I agree with that. Honestly, I'm honored to have continued on in the podcast after having moved on from thoughtbot because, in a very real way, the show is thoughtbot's channel to talk about things. I was at thoughtbot for seven years. I think I live and breathe that truth. And to me, that's what maybe has made sense for me to continue on. But I really do feel a responsibility to keep the show in good shape so that someday someone else gets to inherit this thing because I was so happy to get handed it. It was such a wonderful thing. And it has been such a joy to do for these past three years. But at some point, I do presume that we will move on. And at that point, I do hope that other people pick up the mantle. And thankfully, thoughtbot as an organization, there is a group of individuals that I'm sure there will be someone wonderful that gets to step in, but I'm in no hurry to do that. And, Steph, I hope you're not either. So we'll continue the conversations for now, but I definitely do want to keep this thing alive if for no other reason than I got handed it. I don't feel like I could let it drop on the floor. That doesn't feel right. BRITTANY: Well, I think on that warm, fuzzy feeling, we should wrap up. So let's go through everybody and just tell the listeners where they can listen to your podcasts and follow you. I am Brittany Martin, @BrittJMartin on Twitter. And you can listen to the Ruby on Rails Podcast at therubyonrailspodcast.com. JASON CHARNES: So I'm Jason. We are Remote Ruby. I am @jmcharnes on Twitter. And I'll let the others tell you where you can find them. ANDREW: You can find me everywhere @andrewmcodes. And if you email me, there's a really good chance you're never going to see a response because my email is a disaster. Please don't email me, but you can contact me anywhere else. CHRIS OLIVER: I'm Chris Oliver, and you can find me on Twitter @excid3 or at Go Rails, and of course, gorails.com. And you can find the Remote Ruby podcast at remoteruby.com. CHRIS TOOMEY: I am @christoomey on Twitter. The Bike Shed is @bikeshed on Twitter. We are at bikeshed.fm for a URL. I'm pretty sure www works, but I'm going to go check that real quick after because I want to make sure that's true. And yeah, that's me. And I'll send it over to Steph for her part. STEPH: I am on Twitter @SViccari, and I post programming stuff, usually pictures of cute goats, cute dogs, that kind of content if you're into that. JASON SWETT: For me, if you want to find my podcast, it's Rails with Jason. And if you search for Rails with Jason anywhere, you should be able to find it. And then my website, if you're interested in my blog and all that stuff, is codewithjason.com. BRITTANY: Fantastic. Thank you, everyone, for being on this mega episode today. It was a lot of fun. We are going to be having a podcast panel at RubyConf; we’re excited to announce and some of us will be present. So stay tuned for details around that. And if you enjoyed this mega episode and want to see more mega episodes, please let us know on Twitter. All: Bye. 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 @bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Support The Bike Shed

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

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

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

The big "Three Oh Oh!" What a milestone for this podcast! Aside from celebrating that the show has made it this far, Chris gives some followup on some Inertia.js issues he had been having, and talks about open source licenses and legality and testing against external APIs. Steph has thoughts on mozzarella sticks and what makes good ones; particularly the cheese to bread ratio... They then, together, answer a listener question re: knowledge silos: Jan asked, "Our team (3 pairs) is currently working on two different projects due to that fact we are creating information silos. Now we are looking into ways how we can minimize those information silos. Do you have any ideas how we could achieve this?" With switching pairs they are unsure about it as it can be difficult for new pairs to get up to speed. inertia-rails thread safety Rails Cache-Control no-store fix Transcript: STEPH: I have no shame. CHRIS: That's important in this industry. 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 learned along the way. Hey, Chris. So today's an exciting day. It's a rather momentous day, at least in my world, because today is our 300th episode. CHRIS: 300? That is incredible. STEPH: That's an incredible amount of episodes. And it made me pause and reflect on how many episodes I have been a part of. And I've realized it's over 100. I think it's around 104 or something like that, and I can't believe it. Time flies when you're behind the mic. CHRIS: Time does fly, yeah. So yeah, fully a third of these you've been involved in. I don't know what the number is. And I'm just so grateful to Derek Prior and Sage Griffin, who started this whole process. And then to Thom Obarski, who was the producer for so long, and Mandy Moore, who recently joined us and has been doing a wonderful job of carrying that forward and to you, Steph, because this has just been such a joy to work on. Yeah, it's just a joy to be on the show and to get to chat with you each week and share some things. And frankly, learn from folks writing in questions and sharing pointers with us, and it really is such a delight. And yeah, 300 is pretty momentous. STEPH: The listener questions and feedback have undoubtedly been a highlight for me. That is one of the areas that I love the most. I love the questions. I also love when people provide helpful answers to us, and then they help us out in return and also, all the incredible guests that we've had on the show. It has been phenomenal. I'm also very thankful to have been part of this journey and appreciate everyone that has got us here today. I wonder what the fourth iteration of The Bike Shed looks like. I consider this the third iteration because the first iteration was Sage Griffin and Derek Prior. The second iteration was where you took over The Bike Shed, and then you were hosting a number of incredible guests on the show. And then the third iteration is the iteration that we're living, so I wonder what the fourth will look like. CHRIS: Oh, that is an interesting question. Hopefully, you and I get to hang out for a good bit longer. But at some point, much like the Green Lantern, this will get passed on, and someone else will take up the mantle and tell some stories. But, yeah, hopefully, that's not too soon because I certainly enjoy hanging out with you. STEPH: Oh, I agree. I certainly enjoy this, and I'm in no rush to leave The Bike Shed. But I think it's just fun thinking about the next people that will carry this journey forward. CHRIS: And determine the color of The Shed. STEPH: And determine. I mean, that is their right. As host and co-host, they get to determine the color of The Shed. CHRIS: 300 episodes in, and we still haven't figured it out. So I guess we got to keep trying. STEPH: Oh, I have. I already know what color it is. CHRIS: Is it yellow? STEPH: It's yellow. CHRIS: Yeah. Okay. [laughs] STEPH: I like how we said yellow at the same time, you know. [laughs] CHRIS: I do, although I feel like it's wrong to have a color in mind, or at least I want to dig in and talk about it for a while just to be in keeping with the show, but... STEPH: One must first argue before deciding and then argue again. But to not continue bikeshedding on The Bike Shed, what's new in your world? CHRIS: My week has been good. Actually, I have two quick updates on various Inertia things that I've shared in previous weeks. So we can include a show notes link for the two different episodes where I talked about these respective things. But there was one weird issue that I ran into with Inertia where it could start clicking a button that would delete, was behaving weirdly and occasionally, intermittently; some of the responses would end up as a full HTML page response as opposed to the expected Inertia response. And there's a bunch of subtlety around this. I actually reported it as an issue to the Inertia team. And they very kindly pointed me to the HTTP semantics at place. So it's the difference between a 302 redirect and a 303 redirect. And so, in their code, they were correctly doing a 303. They were standards-compliant; everything was great. But for some reason, it was still misbehaving sort of randomly, and I could never pin it down. I ended up working around it and opting out of Inertia behavior for those endpoints. But my assumption was that something in my Rails Middleware Stack was behaving weirdly and occasionally overriding Inertia Rails' setting of the status. So Inertia Rails was saying, "303," which is a special version of redirect, and something else in the Rails Middleware Stack, was saying, "302, it will be fine." Turns out, in retrospect, the Inertia Rails team has discovered that this was, in fact, a threading bug on their side. So it's not Inertia's fault. Inertia as a core concept and as a protocol was definitely doing the right thing. And the Inertia-Rails Middleware was attempting to do the right thing. But threads and concurrency got in the way, which I'll be honest, I don't deeply understand those concepts. So I was just like, oh okay, that sounds like a thing that could go wrong occasionally, which is exactly how I experienced it. But now they've made an update to the project, so that should be resolved in a deep way. But goes to show you threading and concurrency are really tricky to chase down. STEPH: I appreciate that you're coming back to give us the conclusion to that issue because I remember talking about it, and you were still going off on a journey and finding out what's wrong, so that's super interesting. And yeah, threads and concurrency those are super easy, like cache invalidation and naming, that's right up there. CHRIS: It's actually kind of funny. One of the issue threads where I wrote about it, someone followed up and asked if I'd come to any solution. And I said, "Oh, I've gone kind of this weird way, and I'm doing these things." But I shared a code sample, and I said, "Just to be clear, this is 100% about something Rails is doing and not Inertia, which remains a stellar project." And then, very shortly after that, someone from the Inertia-Rails team was like, "Ah, actually, I think it was us. Sorry about that, but we fixed it now." And I was like, "I still love you guys. This is great. You're doing a great job. [chuckles] You continue to push the envelope in a wonderful way." But it was a funny interaction where I was like, never shall I let the name be dragged through the mud. Whoops. Okay. Never mind. STEPH: You're an excellent hype man for Inertia. CHRIS: I try, I really try. I believe in it to my core. And actually, there's another one that this one's not really related to Inertia at all, although I've seen it discussed within the context of Inertia. And again, I think the Inertia team has done a really great job of responding and pointing to here are the HTTP semantics, and adhering to the standards, and the way that things should work. But this one has to do with the back button. When you're doing sequential forms or really any sort of form type thing, the browser will just pull from its back/forward cache, which is a local cache of the HTML of the page as it just had it. And I had come to the understanding that this was not something that I could workaround. This was not something that I could control. I had tried every combination of headers, at least I thought I had, in Rails to try and control this from the server-side because ideally, the server is the one who knows about when data is changing and things of that nature. The server should be able to inform the browser, "Hey, don't cache or store this page in any way, always revalidate it." It turns out there was a bug in Rails that was improperly normalizing the Cache-Control header and always removing the no-store Cache-Control value. So there are like five different or a handful of possible values that can be set for that header for the Cache-Control header. And Rails has a bunch of internal logic that says, "Okay, if you've set this, then I'll put these two, but not that one." And they're just trying to manage it and do nice things on our behalf. But unfortunately, they were being a little overzealous in that normalization effort. And so they were dropping an important value, which is no-store. So now there's a PR opened in Rails, or I think it's actually been merged in at this point that will fix that and allow you to set that particular header value, which then should get the behavior of "Hey, browser, if I hit the back button, please go ask the server. Don't trust your local cache, “which is exactly what I want. STEPH: Interesting. Wow. So that's two very helpful resolutions to some of those strange issues you were running into before. CHRIS: Yeah, definitely. And actually, for that issue, in particular, it was a very kind Bike Shed listener; Alexei Vasiliev wrote in and shared some initial thoughts, pointed me in the direction of some things. In that case, I actually was like, "I don't think that's the case. I tried it." And he was like, "No, no, no, pretty sure." And he was definitely correct in this case and was very kind and gave me an example of code reproduction and all of those nice things. So I was able to chase this down and then eventually find the issue in Rails, which had been opened like eight days before. So I think for me, I just happened to run into a weird period of time where Rails was subtly broken around this behavior. And therefore, I determined that the world was broken when, in fact, it was just a tiny slice of Rails' history. But yes, thank you so much, Alexei, for writing in and pointing me in the right direction on that. STEPH: The dream came true. We talk about some of our troubles and our strifes, and people respond and help us out. CHRIS: That is the dream. But yeah, so those are some quick updates, not really about me, although tangentially, I got to go along for these rides, and it was fun. But what else is up in your world? STEPH: Let's see. Well, I also have a small update that I can share. It's circling back to the conversation that we had talking about extracting an untrustworthy service to a new location. And at that time, I don't remember exactly the process I laid out. But at that time, it’s the idea that it is a bit untrustworthy, but we have some security in how this process works, and it is ideal that we move it to this other location. So let's just go ahead and move it wholesale, bugs and all to the new location. And then there, we will start to refine, and we'll start to improve the service. Well, the update is that we have realized that the untrustworthy service is untrustworthy enough that I'm actually working on improving it in its current place just to a certain extent that then it feels like we can move it to another location. There have been enough issues with it that it has taken my focus to continue patching those bugs and making sure everything is working appropriately. But now I'm in the space of where I'm like, goodness, I thought I knew this thing and now I'm realizing I don't. And so, I'm looking for ways to inform myself and the team when something isn't working when we think it is. So to provide a bit of context, this service is sending a bunch of messages to other systems, and most of the time, that is working, but there are times that it's not. And when it's not working, it's silent about the fact that those messages aren't being sent, and it's very important that we send those messages. So what's been on my mind is looking for a way to then elevate myself and the team to say, "Hey, these are the number of messages that are being sent on average." And then suddenly, let's say it dropped by 50%, or maybe we typically send 98% successful messages, and we have a 2% failure rate, but suddenly we have a 50% failure rate, but looking for those metrics that I can capture and then alert the team if something is going wrong. And one of the suggestions that was bubbled up by Chad Pytel, who's a developer, he's also founder and COO of thoughtbot, and we're working on the same project together. And he had highlighted that a previous project that he worked on used AWS specifically to leverage the idea of tracking how many successful messages are being sent, or perhaps in their particular project, it was focused on how many orders were being processed. That was important to know. And in our case, we could do a similar metric where we look to see are we still sending messages? Has the number dropped significantly lately so then we can be notified, and then we can escalate that to PagerDuty? So then we notify the team that something's going on. I don't know the specific mechanics of how I'm going to implement that yet. So I will report back, but I'm excited to have something that's going to alert me for when things aren't working the way I expect versus waiting for then someone that's a customer to notice it and then get back to us. It's very in line with a number of the topics that you've brought to the show recently, talking about how we can measure more of the user's experience and be notified sooner versus waiting for a user to bump into an error and then they reach out and notify us. CHRIS: I'm super interested to hear where you get with that because that's definitely an area that I've poked at but not dug into particularly deeply. I know there are a number of projects like StatsD is one of them. I think there are others in that space, but that's where you're sending metrics just out to some service, and then you can aggregate and graph. I've also done similar things with Papertrail; I want to say, where you can do a very specific search in the logs, and then within that, you can aggregate and graph and show things over time. So you can do a very simplified version of what you're describing to sort of visualize a rate of something over time. And then I think they might have some thresholding alerts. But also, that's one of those super hard things to do because it turns out like Monday morning, a lot of emails get sent and then Friday afternoon, fewer, and then on the weekend, none. And so, there's going to be an inherent sort of fluctuation to the data. And so then what is normal? What does the baseline look like? And then how do you do anomalies around that? Because inherently, there's going to be noise in the data. And so is it a 10% band around the normal? And I'm just saying a lot of words now that I barely know the meaning of. But it's one of those things where it's like, oh yeah, just let me know if it's behaving abnormally. There's so much in that one little sentence. And it's one of the like; I love the fractal complexity of this space where every part of that sentence that I just said is like, oh, that's way more complicated than it sounds when you just say that word. So very interested to hear where you get with this. And this is also something that I'll probably be pushing on in my work in the near term. So maybe we can even compare notes, but as of now, I just have, I think, buzzword-level knowledge of it. STEPH: Well, I love that phrasing fractal complexity because yes, that was also where my brain got hung up in starting to think about this process and like, well, what's normal? I don't actually know what normal looks like because I haven't been tracking this until now. So do I go back a week and say, "Okay, let's compare our average sent rate to in the past week and try to define normal in that timeframe?" And I think the answer, for now, is to do the smallest thing but also has the biggest impact, and that's to notify the team if messages just stop. That feels like the first, small step to take, and then we can fine-tune. Do we want to know if suddenly successful messages are being marked as a failure? We have an increase in failed messages versus successful messages. But I think the first iteration is just to know or to confirm that we are sending messages and send us an alert if suddenly we're not sending messages for...ooh, I just realized there's a complexity in that statement too. It's like, how long are we not sending messages for? Is it for an hour? Is it for a day? CHRIS: I was going to ask. [laughter] STEPH: I just caught myself there. Yeah. I don't have an answer to that right now. I have to think about it, but there's an answer there. I will have to choose an answer. CHRIS: You sure will. And then you'll probably have to tweak it over time. It's also one of those topics where false negatives and false positives are really easy to fall into where the system's alerting too often. And so people then start to ignore the alerts versus it's too cautious before it will send out an alert and, therefore, you're missing things and so finding that optimum level. It also might be different days of the week. Aah. [chuckles] STEPH: Yeah, I think that's very true. It will be different for different days of the week. So I have a lot more to think about in regards to how we're going to report on this. But that still feels very much like something I want in the world because right now, it's a lot of spelunking and production consoles to find out what's going on with the data and making sure that it's going through. And that feels like the least favorable option as to the world that I want to live in. Oh, on a completely unrelated topic, I saw an article that I'm very excited to read. And it's not related to technology at all, but it looks like a very delightful article that someone wrote and titled My 14-Hour Search for the End of TGI Friday's Endless Appetizers. And I haven't read it in-depth yet, but I just read the first bit, and it seems like it's going to be delightful. But I thought of you because we've had previous outtakes around mozzarella sticks. And you were very excited when you thought thoughtbot had mozzarella sticks, the actual fried kind versus just the healthier cheese stick kind. So this seems like a thing that you'd enjoy. CHRIS: I feel like it may have even ended up in an episode, and we talked about mozzarella wedges and the ratio of surface area to volume. STEPH: Yes. CHRIS: I don't know if that made it into an episode or not, but we have definitely you and I discussed mozzarella sticks before. And I'm definitely intrigued by this article. I will add it to Instapaper immediately and then probably never read it again because Instapaper is where I put things to forget them. But maybe someday I'll sit down with a coffee and read things. STEPH: I've heard you mention Instapaper before, and I've looked into it. And I don't know why, but it just hasn't stuck for me. So I always throw anything that I want to explore or something that is also critical for me to do. I use Todoist. I don't know if you're familiar with that app, but that's my go-to. CHRIS: Well, I'm familiar with Todoist. I take a slight line between my to-do list, which I want to be as, I don't know, clean and tidy and only the things that I have to do versus for me, Instapaper is a list of when I get around to it when I've got those ten free minutes, which apparently don't exist in the world. But when I have them, this is the list of things that I can read. But I think I've heard this from a number of people of having a more integrated system that all the stuff's in the same place. I keep my to-dos in Trello, also as an aside, and I'm not super happy with that. How do you like Todoist? Is it bringing you joy? STEPH: I really like Todoist. I find it is simple enough an interface that I'm not spending a lot of time customizing it or messing around with it. I can just go there and log the things that I want. I can create individual projects and spaces as well. So if I want to separate my personal to-do list from my work to-do list or if I have a project, that's a really nice feature as well. I think my only small complaint is if I'm writing a date or if I'm writing tomorrow, Todoist will try to do the smart thing and say, "Oh, I'm going to add a due date for you since you mentioned a date." And I'm like, no, no, no, I don't want a due date. I just want to mention the specific date because somehow it's relevant. And undoing that is sometimes a little tricky. But otherwise, I have found Todoist very helpful. I'm a big fan. Also, you and I are slightly different creatures in terms of how neat and tidy we keep our spaces. I think how we both manage our email inbox is a really good indicator of this where you are more organized than I am when it comes to emails. And so, our to-do list might be similar. I'd be interested to see if Todoist fits your needs or if it doesn't offer enough structure. CHRIS: I almost certainly could make it work. And it's one of those things where I've actually settled on Trello, which is a very loose tool. And so I've been able to shape it sort of to what I want, but it doesn't really have that many true productivity-type features. It's just a loose board where I can drag around cards and move them through. And that's worked fine, or I've been able to talk myself into not trying to be as neat and tidy and intentional with my to-do list, which I think has been good overall. I've looked at Todoist in the past. And the thing that gives me pause sort of related to what you were talking about with the date things, but I get the idea, or I get the sense that Todoist really, from a fundamental philosophical approach, really wants things to have dates and to have priorities, and my thinking is not quite that. Like, there is a priority, but it's relative. So it's the order of things in a list, but it's not this is a one, and this is a two, and that's another two. I find that logic of like there are different tiers of importance doesn't really map to my world, nor do dates. Almost everything I do has no date, has no context. It's just like when I'm at the computer because that's the only place I ever am. So it's when I'm at the computer, it's all kind of important-ish. Nothing really has a date, but it should probably be done pretty soon. That sort of stuff doesn't quite map to what I see in Todoist. So I've always found a little bit of a mismatch between what I think I want and what Todoist, as far as I understand, provides. I know they added Kanban-type boards recently. So I think that might help with just visualizing workflow and being a little closer to Trello, which I'm familiar with. But I'm sort of on the search right now for another to-do list. I like what you said about being able to separate the work and personal because that's definitely a thing that I would want, although there's always the added complexity of whatever tracking tool that we're using as a team at work and which things go into my list versus that list. And do I try and synchronize them in any way? And then I do what I do, which is I start to imagine this ridiculously complex, fully integrated, bi-directional sinking nonsense system where like, never mind. Stop it. Pen and paper, Trello. I don't know; you’ve lost your privileges, though. This is me talking to myself. I lose my privileges much like I'm not allowed to ever try Emacs. I have had a multi-year moratorium on exploring new productivity tools, but I think maybe, just maybe, now is the time to revisit that. STEPH: If you ever disappear for a week or two, I'll know that you tried Emacs or something like that happened CHRIS: [chuckles] My beard is three times longer when I come back, and I'm like, "All right. I figured some stuff out, though." STEPH: I'm with you in regards to trying to bucket all of your to-do items as if it's a priority one, two, three. I am not good at that, and I'm always wrong. So I've also given up on that system. I would describe myself as a minimalist user. I'm using all the basic functionality. I'm not leveraging what a lot of stuff that Todoist probably can do for me. And so I have a very just flat list of things that I'd like to do. I do have a couple of projects because I do try to have that personal versus work, and maybe I have some other project that's on there as well. And then, in my mind, I try to avoid due dates unless it's really important. Although I say that if it's really important, it's going on my calendar too because I'm going to budget time for it or make sure that I don't forget it. But then each day then I go through that full list, and then I pick the things that need to be done that day or it's reasonable to get done that day, and then I kick everything to the next day. So that way, I'm always reevaluating a fresh list of what do I need to tackle? What's reasonable for today, and what can I punt on? And Josh Clayton said this to me before, and I really liked it in terms of punting on work because typically, when you're really busy, something's always going to drop. You're always going to push something to the next day. So then it's just figuring out what's going to bounce and what's going to break? So I'm always looking for what's going to break? And let's prioritize that for today to make sure it gets done. If it will bounce, then I'm going to kick it to the next day, and I can't see it until I'm going back through that full list again. CHRIS: I really like that framing around you're going to have to drop things. That's just the nature of life. There's always more to do than there is time. So will it bounce, or will it break in that? And that framing around how to decide which things get moved out. Interestingly, I just looked up because I wanted to know does Todoist support snoozing things? Which is something that I use constantly in Trello and Gmail and basically everywhere else. I'm just like, nope, future me problem, future me problem, and I just keep pushing things into the future. But critically, I want them to be hidden until that time. And it sounds like Todoist; you can set a future due date, and then it'll show up in today. But again, that's sort of conflating how I think about productivity and whatnot. Also, I found…this is a Reddit post that I'm looking at where I'm determining this. And there is the question, and then there's someone answered, but the answer is deleted. And then there's someone replying to that saying, "Wow, what a thoughtful response. Have you written this up anywhere else, like a blog post? You sound like an absolute pro." But the parent comment, which apparently was beautiful, and articulate, and well-written, has been deleted. And this is the sadness of the internet. So a really beautiful xkcd about the saddest thing you can see is you search for a question, and you find Stack Overflow from 10 years ago one person asking the question and no answers. And you've got one other person out there in the world who cares the same way you do, but you have no answers, and it's sad. But I'm just sad about the loss of information. STEPH: That's so tragic, or that's a really pro troll move. And you leave a comment, and then below, you're like, “Wow, that was amazing. That was beautiful.” And then you delete your own previous comment. So then you're just tricking people into thinking there was an answer. CHRIS: It does sound almost performative, especially the last line, "You sound like an absolute pro." So I could see that being the case. And you know what? I'm going to choose to believe that that's what it is because then I can sleep better at night. So thank you, Steph. STEPH: Happy to help. CHRIS: But I think we should probably move on to perhaps a listener question or something. But before we do that, I do want to ask if anyone out there has a to-do list that they're using and they love; I would love to hear about it. I think I'm familiar with most of them, but votes of confidence from the listeners of this show will certainly go a long way with me. Because I think you folks are all very smart people. I mean, you're listening here, so, obviously. STEPH: Yes, obviously. This very deeply intellectual show about mozzarella sticks and the ratio of cheese to fried and what's the best. CHRIS: It's an important question. STEPH: It is an important question. I have strong feelings about it. That's why we've talked about it. [chuckles] CHRIS: On this very serious show that we host. STEPH: [chuckles] Yes, we have an awesome listener question that I'm really excited to dive into. But before we do, I have a quick git thing that I'd love to share. It's a tip that Dimitry, another thoughtboter, shared with me today that I think is just really nice and something that I have not used before. And it's specific to a workflow where if you need to grab a file from another branch or from another commit, and then if you want to bring it into your current branch. And there are a couple of ways to go about it. One of them is you can do git checkout main and then pass the file presuming the file that you want is in main and then you want to bring it to your current branch. And that will copy over the file to that exact location. But if you wanted to grab a file that's on the main branch but then you want to port that file to a new location, then you can use git-show and do git show branch. So let's say you're bringing a file from main over to your current branch, so it would be git show main: and then pass to the file that you wish to copy, and then the greater than sign and the path to where you want that file to live. So you can grab that file and then stash it in a new location, and you can also do it for commits too. So if someone has pushed up a commit and you want to copy a particular file, say if you need to bring in some of their work into your branch, then you could also do git show commit, and then that colon, and then the path to the file. And then, if you wanted to move it to a new location, you can use that greater than sign and then the path to where you would like that file to live. So it's a nice combination of the git command of git show and then also shell redirection. So then, you can pipe that content from the file that you wish to copy over to the new location that you would like. And it's not something that I've reached for very often, but I find lately I've been in a mode where I'm trying harder and harder to stay within my terminal and not have to jump over to GitHub or to external UIs if I can. And so this just feels like a nice additional tool where then I can use this one more thing where I don't have to either...I guess it's small. I could check out main locally. But even with this way, I don't have to switch branches, grab something, and bring it over, or I don't have to go to GitHub and then look for something. It feels like a nice way that then I could grab that file locally and bring it over to my branch. CHRIS: That's a nice combination of tips there. Like you said, a bunch of different pieces at play, but that is definitely a super useful thing. It's one of those that I've not gotten that into muscle memory yet or even close to muscle memory. Git is complicated in terms of the interface that it provides, at least at the command line. I've been trying to make sense of it all and then trying to find what are the useful workflows that I want to build? Because you can do anything, and you can do most things in five different ways. And so finding that set that you do want to know deeply but then also getting that committed into your hands, not even into your head, is the thing that I strive for. But that particular one is one that I struggle with every single time. So especially, I think you broke that down really nicely, so it makes sense. There's a corollary in Fugitive for any Vim users out there. There's a Gread command, so it's capital G-re-a-d. And then after that, it takes some identifier, and I've never gotten the identifier right. But as you just described it, it's the same as the git show sequence. So it's a commit or a branch name, colon, and then the file path that you want. And then, in Vim, you can use % to reference the current file. So I've tried really hard to teach my brain Gread main :%, and somehow, my brain doesn't want to remember that ridiculous sequence of characters. So, only in this moment am I like, oh, it all kind of fits together. STEPH: Oh, that's nice. I am a Vim Fugitive user, but I didn't know that one. And I'm with you; I rarely remember all these off the top of my head unless I've done them like a hundred times, and it finally starts to sink in. So I always have a cheat sheet, or since we were talking about tooling earlier, I use Notion to capture tidbits for myself. So this is a place where I would probably stash in a web development folder that I have. And it's just a tip to my future self as to like, hey, remember when you were trying to do that thing, and then you had to look it up and figure it out? Well, here's how you did it, so then I can revisit it in the future. CHRIS: I thought a number of times about introducing a flashcard system to revisit these sorts of things. Gary Bernhardt, who I had on a while back now, is building a platform that does this essentially for TypeScript and regular expressions in JavaScript arrays and a bunch of different topics. But it's got built into it the idea of spaced repetition, so you review a thing and then three days later, you review it again and then seven days later, and then ten. And there's a particular sequence to it, but it helps you to really internalize that knowledge. I've never gotten to the level of going to that, but I like that idea of being purposeful and trying to commit some things to memory because having them at your hands and being able to stay, like you said, in the terminal and closer to the work and not having to break out of the context, I do find a lot of value in that. But it does take some effort to build that up. So I've never quite gotten to that flashcard system myself. STEPH: Yeah, that's interesting. I think I have mixed feelings about it because, on one hand, it is nice to commit some things to memory. And on the other hand, I'm totally cool with having a way to organize stuff so I can easily search it and find it later and not use up memory space for something that I don't use that often that then I just can't commit it. So I could definitely see it being useful. But I'm also okay with just having a nice way to search for it. But pivoting a bit and circling back to the listener question that you alluded to earlier, we have a listener question from Jen and Jen wrote in about knowledge silos across different projects. Specifically, Jen wrote in "Hello, Steph and Chris, first of all, I want to say that I love to listen to your podcast for multiple years now." That's awesome. Thank you, Jen. "I like how you both share things along your week and fill the discussion with so many useful things and findings. Our team, which consists of three pairs, is currently working on two different projects. And due to that fact, we are creating information silos. Now we are looking into ways into how we can minimize those information silos. And do you have any ideas for how we can achieve this? Some additional context, switching pairs we're unsure about as this will be difficult for the new person to get up to speed. And currently, we are thinking about having a mob review session. But of course, with those, you only get a limited overview." All right. Well, thank you, Jen, for the question. I'm excited for knowledge silos because, I'll be honest, I am guilty of this one right now. I am a bit of a knowledge silo on my current project if we're telling our truths here on the show today. CHRIS: Steph, I thought I knew you. STEPH: You know, I'm full of surprises. CHRIS: Aren't we all at various times? This really does feel like one of those core things that I associate with you, though. So it is interesting. But it's so easy to fall into this space. I think without purposeful, intentional effort, this is the natural way things will trend. It's so much easier for the person who understands a portion of a system or an entire system to take on the next piece of work for that system. And I think we can probably offer some specific advice. But to talk about it more generally, Jen, I think you've found yourself in the pretty common position of there isn't a great answer here. There's going to have to be an investment of some amount of effort; some potentially decreased productivity for a period of time in order to get out of the situation that you're in. But that's just the name of the game. So if we name it as that, and we say that, then the question becomes how much effort do we need to put towards that, and what are the different ways that we can do it? So to go through the two that you listed, mob review sessions, I think can be a great way to give an introduction to a project, but I think they'll very quickly taper off in my experience. So I think it's a great way, especially if you're going to do any more formal things after that; a mob review or even a mob overview of the system is a great way to introduce new folks into it. But then from there, I personally would think that if you are feeling pain around the knowledge silos or even if you're not, because frankly, knowledge silos can very quickly become a major problem, say if someone needs to...if someone happens to leave the company or if someone needs to take some time off, anything of that nature, this is one of those things that can be fine until it's not, and then it's not in a very serious way, and that's the wrong time to try and resolve it. So I would very much be in favor of more purposeful things. As you described, switching pairs is an interesting one. I think that's a cost you're probably going to have to pay. I am interested; the way you're talking about it, it sounds like your teams are paired up consistently, so you're working exclusively in those pairs, which frankly is a really interesting thing. I think it was the previous episode where Steph and I talked about agile and particularly 100% pairing, and that's a pretty intense idea. It also does potentially lean towards this. Now, each of those groups of people, each of those pairs is collectively aware of the same subset of the application. But now, if you were to split that up and you have six individuals that pair in varying sets across the different projects, you have this sort of Venn diagram tapestry of knowledge of the different systems and the subsets and the features. And for that reason, I actually would probably question, at least if I'm correctly interpreting it, that you have three consistent pairs; maybe you shuffle that up. Maybe that's a practice that should be unwound. And now the pair should rotate on a daily basis or something to that effect. But overall, I think this is a cost you're going to have to pay but will pay off longer term. And it's definitely worth doing in my mind. But yeah, that's some high-level thoughts. What do you think, Steph? STEPH: I agree with all of those sentiments very much. And as you're talking about the cost and investing in the team, I think that's very true and something that needs to be done. The fact that they're working in pairs is already reducing knowledge silos because you at least have another person. Because I have been part of teams where there's one person that is that knowledge silo. So at least here, we already have two people that are aware of how code works and then why code was implemented in a certain way. So then, to categorize how painful that knowledge silo is or how risky that knowledge silo is, I think there are really two ends of the spectrum. And on one side, there's that example that you alluded to a little bit ago about isolating one developer on a project for six months, and they have minimal code reviews. And then suddenly that person leaves, and that's the hardest silo to then rectify. And it will probably be a lesson that stings enough that hopefully it won't be repeated where someone gets that isolated and then others have to figure out what was going on while that person was working on something independently. And then on the other side of that spectrum is you need to take some time to explore and understand a portion of the application that you haven't worked on before, or perhaps it's you need to understand how to work with an internal API. And stuff on that side of the spectrum feels more addressable with documentation and also mob reviews. And maybe there are also demos as well because a lot of the knowledge that goes into building a product may not be specific to the code, but it's more why was this done, and why was it built, and why did we go this way? And that feels more addressable with documentation, with commit messages, with those mob review sessions, and also with demos where then you can show the high-level functionality of a feature that's being implemented. So then, even if everyone else on the team doesn't have the technical knowledge as to how it was built, they'll have more of the user context, and the product context as this is a feature that we built, and this is why it's useful to the world. I find a lot of that knowledge is what's harder to capture because then you'll find a feature and wonder who uses this and how is it in use? And that stuff is harder to backtrack. Circling back to something that Jen caught out in their question, highlighting that it takes time for someone to get up to speed. That's a really interesting one for me because it goes back to the idea of wanting to know well; what’s difficult? Not specifically what is difficult, but let's define difficult and what's a reasonable level of difficultness because onboarding to any applications or onto a new section of code is always going to take some time to process and understand. But what's an acceptable timeline in which someone can onboard and be productive? There's something that I've heard from someone at thoughtbot. I don't have the exact context to quote them directly. If I find it, then I'll be sure to add it to the show notes. And they shared that another company is measuring this difficulty of onboarding by they take the person's first starting date, and then they track to see when that person has merged in 10 PRs because they are looking to see how long it took for that person to get up and running to then feel comfortable, to then make some contributions. Often, your first couple of PRs might be something that's less challenging. It might be something that's updating the README because you are going through that onboarding process. And that's a great time to then reevaluate how clear the instructions are. But by the time you get to the 10th PR, you've probably addressed something that's a bit meatier and impactful to the product. And then they use that as a metric to then calculate okay; how well are we doing? Is it a month? Is it six months until someone gets there? How complicated is the application is another way that you could look at that metric to say, "Well, if it takes people a very long time to get there, maybe it's because of the codebase versus processes." And I really like that thinking of we have knowledge silos; let’s think about where it's actually hurting us. And then, if we think it's specific to the onboarding process where that part is painful, then let's break down how we can measure how difficult it is, and then look for ways to improve it but then also track that improvement. CHRIS: Well, I like that idea of trying to quantify and measure onboarding. I've heard a lot of organizations having like, "We want you to ship a PR on your first day," that's a meaningful thing. But obviously, that first one will probably be pretty small, and it's sort of getting that first one out of the way, if anything. But it's not truly representative of someone being able to comfortably work within the repo, but ten, that starts to feel like a real number. And I do like quantifying it. More generally, I'm intrigued. Metrics around developer productivity is such a difficult thing to pin down. And it can, I think, become really complicated, especially if you're looking at individuals and trying to say, "Well, you had four PRs, but you had two PRs," and comparing individuals. But I do really like the idea of more aggregate stats of on average; right now last month, we were doing 1.2 PRs per week per developer, and now we're down 2.7 PRs per week per developer, something like that, and seeing that looks like something that we might want to address. Are there fundamental things that are happening that are causing development to slow down? Are we doing bigger PRs, et cetera? And starting to look at that, but try and have a metric to keep an eye on that. So I'm super intrigued by that and then again, more specifically to the onboarding one that you were talking about there. Actually, popping up a slightly higher level, though, I think both you and I sort of jumped into this conversation as, like, yes, knowledge silos got to fix those, that's a problem. And I do feel that way. This is a topic that I feel pretty strongly about and pretty clearly about that knowledge silos are the natural state that things fall to, and it's not a good thing, and we want to avoid it. But it is important to ask the question of who is deeming this to be a problem and for what reasons? And we had a good conversation two episodes back in response to a different listener question about consulting versus building product. And I feel like, with this, we can almost go up to the consulting level of this can be a problem, but it also maybe isn't. Or, who believes it's a problem? Is it management thinking, "Oh no, when that person went on vacation, suddenly everything ground to a halt? This is a problem, and we need to resolve that." Or is it the development team themselves saying, "Hey, we feel like we're a bit siloed here, and that's a problem we're recognizing," but they don't have buy-in from management. Or worst case management saying, "This is a problem, but you get no time to resolve it." As long as everyone's in agreement of the potential benefits and aligned to this is a thing that we would want to improve, and then also aligned to there will be a cost to resolving it, that it's not free to try and unwind this siloing of knowledge, then I think everything can be great. But any mismatch at sort of any level of that either on the cost or the benefit side can be problematic. And so getting to the point where you've had a clear conversation that defines this and gets everyone to come to an idea of yes, we think it's a problem, and yes, we want to put in the effort to resolve it, then I think you can move forward and tackle any number of different approaches. But I think you have to start from that conversation. STEPH: I love asking that question of how has this manifested into a problem or a concern? Because you just highlighted a really great example where if it's only a concern because someone was on vacation and the team couldn't respond to a customer request or couldn't respond to an outage, then there are different ways to address that. So documentation may not be the best way to help out with that. That's probably a pairing session. So then someone can respond quickly to an outage versus you don't want to say, "Okay, here's a couple of pages of documentation," and then have that developer go on vacation again, and then there's an outage, and you're trying to read through those pages to figure out what's wrong. So figuring out the right approach based on the pain that's being felt feels like a really great way to go about this. Because frankly, breaking down a knowledge silo is always going to have a cost. So you want to make sure that you're being as cost-efficient as possible with your approach and then addressing the root concerns and making everybody's lives better. Because I do think there's some knowledge silo that's appropriate. And I think silo may be the wrong word, but someone who is more skilled or an expert in the area or has more context for a particular area of the application. Because applications can get so large that not everyone's going to know everything and context switching between all of those can be really challenging. So I think it's very natural that you're going to have different people that you go to around a certain feature. If there is some lofty feature around search and you know a particular person that has worked on it for a while, then you go to them, and that feels like an appropriate level of knowledge that someone has obtained. And I wouldn't classify that as a silo at that point. But then if you do get to the point where that person went on vacation and then search broke, then you can start to revisit okay, maybe this person does have too much context, and then we can offload some of that context to someone else. CHRIS: There was a phrase I used earlier of like a patchwork quilt, but I think that's not quite the right image. There's an image in my mind of little islands of color that are fully separated; that’s bad. And then there's a version of more like a Venn diagram overlap where each of the colors sort of bleeds into the other ones, and I think that's good. But then the perfect overlap where it's just one big blob of brown because all the colors are the same, that's bad. And I think that's what you're highlighting is like, you don't want to go to that. You don't need the perfect overlap of everyone having a complete shared knowledge set. I'm trying to make word pictures over internet radio. So it's probably not going great, but it's something to that. Like, there is an optimization here, and I think the way to find that is by starting from what are the pain points? What are we feeling that is less than optimal? And then coming up with solutions that directly address those pain points, not generically try and target like knowledge silos bad. And retros are a perfect way to do that. So if you listen to our previous episode where we talk about the virtues of retros and other agile philosophies...This is great. I feel really good about being able to reference previous episodes. I think we've talked about good stuff in the previous episodes. STEPH: You've been on fire with this episode. I think you've referenced at least two, three episodes at this point. [chuckles] CHRIS: Yeah. Wow. Well, I mean, we're at 300 now, so we've got plenty to go back to. [laughter] STEPH: We've got plenty of content to reference. I think you and I do have an advantage here based on our experience where we have had to join a number of projects. And then we know our time with that project is very determined, and we want to make sure that we don't take any knowledge with us. So something that you and I have acquired as a skill is seeking knowledge when we first join a project and asking a lot of questions around how the application works and then understanding more about the intent of different features, and then knowing where to dive into a codebase to then make fruitful contributions. And I think there's a similar approach that can be taken when trying to break down a knowledge silo is a person who is that silo may be in a spot where they're having trouble communicating all that information and then dispersing it to others. So then us, as their teammates, can go to them and try to ask those types of questions to then help ourselves level up and then recognize areas that don't feel documented. And maybe it's adding documentation, maybe it's adding tests, or maybe it's doing a demo, maybe it's recording something about the feature and then sharing that with the team. But then you can be an advocate for that person who is in a silo position to then help them share that knowledge because they may be too far down that path where they don't recognize what they know, and other people don't. I don't know if that's directly related to being a knowledge silo but just an additional way to approach helping breaking down when you recognize that a silo does exist and looking for ways to then help that person communicate and distribute their knowledge. CHRIS: Yeah, I think you're describing a distinction between a push versus a pull. It could be incumbent upon the person who has the knowledge to try and push it out to the team. But often, they're going to be perhaps a more senior person. They've got code review to do. They've got other meetings, and planning, and things, and they just may not have the time. But is there a way that other team members can proactively pull that information from them and help them find the moments that will clarify that? So, yeah, broadly, as a team, let's rally around the desilofication of the whole adventure. STEPH: That's exactly what I was going for is that push versus pull mentality and how we can break down the silo from both sides. So thank you, Jen, for that wonderful question. I hope we gave you some helpful ideas and suggestions around addressing a silo and then also identifying the pains that you're feeling so that way you can find the most cost-effective approach. But on that note, shall we wrap up? CHRIS: Let's wrap up. STEPH: The show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey. STEPH: And I’m @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: 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._Support The Bike Shed

Let's talk about Agile! What is it, what do we like, we do we not like? In this episode, Steph and Chris discuss: Broadly, are they fans? What makes this practice work well? What makes this practice work poorly? And also, hit specific topics and practices like Scrum, Kanban, and Extreme Programming. Twitter Poll re: Gotime Podcast - Is Agile's Time Over? The Mortifying Ordeal of Pairing All Day The Real Story Behind Story Points Agile Manifesto & Agile Manifesto -- Principles Extreme Programming Introduction Extreme Programming Explained Ron Jeffries - What is Extreme Programming Transcript: CHRIS: I feel like we should try a couple of different byes just so we have sort of a smorgasbord of options, and then we can pick the best one. STEPH: With countdowns, [laughter] because I do so well with countdowns. 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, I thought we would try maybe something a little bit different this week, a little bit more of a structured topic. In particular, I've been gathering little tidbits of information. I've been seeing conversations happen all around the topic of Agile, things that people like about Agile, things that people hate, mostly it's things that people hate about Agile. Lots of ire on the internet about Agile, but I think also some disagreement about what it actually means. And I think; generally, you and I are probably fans, so I want to talk about that. What parts do we like? What parts do we not like? What do we think Agile actually means or, at its best, maybe what it means? But yeah, let's start at the very top stuff. Steph, what do you think about Agile? STEPH: I am generally a fan. I'm with you. And yeah, the internet being full of more negative remarks and ire, that sounds very true. But generally, I am very much a fan of Agile, and the very broad scope of this is how we work, and this is how we plan our work, and this is how we collaborate as a team, and then how we reflect on the work that we have completed. I can also pick apart some of the things I don't like about Agile, but in the broad umbrella definition, I'm a big fan. I've enjoyed that approach. Granted, I've also only ever used Agile. I haven't written software using a Waterfall style, at least not purposefully. And then if I have encountered a team that was using more of a Waterfall style, then we changed it quickly. I really only have known the more Agile approach to writing software. CHRIS: I think that's largely true of me as well, where most of my work would fit somewhere under the umbrella of lowercase "a" agile, although I've tried variants of Scrum and Kanban and a bunch of other things that we'll probably chat about today. But I think in general, I find that things are most effective; things seem to move the most smoothly. And I think the software that we come out with is the best one. It's closest to those very simple ideals of Agile. And every layer of process that gets added on even though, like you, I've not done true Waterfall where it's like six months requirements gathering and then it gets handed off, and no one talks for a while. I've never done that. STEPH: I have to interject because I actually think you have in a previous life when you were an engineer. You have done the more Waterfall. Like, you have to plan very far in advance. CHRIS: I think this is one of those cases where people think "engineering" quote, unquote like mechanical engineering is one thing and it's actually...there is a little more structure, and there's a little more necessity of sequencing where you've got to figure out what you need to buy first because sometimes it takes a while to find the particular piece of metal that you need in the world. But it also has a lot of figuring out as you go and being like, well, we've got a bunch of stuff, and we're just going to figure it out. And also, this is something that as I was studying software while working as a mechanical engineer, I started to hear about this whole Agile thing, and I was like, huh, I wonder how I can bring more of that? Because I definitely saw cases where a more Waterfall-centric approach to engineering projects was leading to bad outcomes. It's like we decided upfront what we're going to do, and then we went away for six months, and we did it. And then we came back, and it turned out it was wrong. So that was solvable along the way. There were ways to build prototypes and things like that. So that is definitely a part of the mechanical engineering world. Although I think there are some true constraints, but I think there are also some occasionally self-imposed constraints, but again, I see sort of the same thing in software. Anytime that we can shorten feedback loops, that's what I like. And I think that for me, that's the core of Agile. Specifically, to come to the Agile Manifesto, to start at the very top, the thing that kicked it all off is a very simple document that the first line of it is "We prioritize individuals and interactions over processes and tools." It's like, yeah, that seems like a great thing, having more regular conversations about the things that we're building rather than having those initial conversations. And everybody goes away for a while and tries to build that thing, and then they come back, and hopefully, the thing that they've produced actually solves the problem. But I think almost always there are some deviations like, oh, actually, it would have been better if it was like this or now that we're actually trying it in the field, it's fundamentally different. So in that way, I think there's actually a lot of commonality between mechanical engineering and software development. STEPH: Okay, that makes sense. Yeah, I was thinking around the process of where you'd have to order stuff in advance versus for us; we can describe everything that we need as we need it unless we're having to procure some specific software or licensing. But otherwise, we don't have to wait on that shipment flow to then have our goods. And then, if we also mess something up, then we don't have to reorder more pieces. But I like how you started talking about that agile with lowercase "a" and then talking about the manifesto because I suspect most people are familiar with Agile, but it wouldn't hurt just to read off some of those top things about what Agile is so that way we're all on the same page together for this conversation. So you already covered the first one that talks about individuals and interactions over processes and tools, and then the others are working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. And that's it; those are the aspects of Agile. And so then, circling back to what you were saying earlier where people are having more criticisms around Agile, it sounds that it's less about Agile, and it's often more about the implementation of these ideas and then how you're approaching them. Because, boy, do we have several ways to implement Agile. We have Scrum; we have Kanban; there’s Extreme Programming. Does that fall within the Agile umbrella? I think it does. CHRIS: I believe so. And I think a lot of the things that people take issue with particularly come from Scrum and Extreme Programming. We're taken to their extremes. Yeah, it's right there in the name, so you should probably know that it's going to be a little out there. But taken to the extreme and especially where it becomes rigid and dogmatic, then it becomes a problem. But again, so we listed out now the four items that are the core of the manifesto. There is a separate part of the manifesto, which is the principles, which digs in a little bit deeper, but it's still very much in that same ethos. But I do want to highlight because there's a subtext to the Agile Manifesto that I really love, which is given there are things on the left and then things on the right when the Agile Manifesto was presented. And so it's like we like individuals and interactions, that's the thing on the left, over processes and tools. And so the subtext below it is that is while there is value in the items on the right, we value the items on the left more. And that's one of the things that I love about the Agile Manifesto is it's not this very rigid thing that says, "This is good, and that is bad," it is a statement of a preference of well, yeah, it's definitely good to have comprehensive documentation. That's a really nice thing to have, but it's incredibly difficult. And if we have to choose, we're going to choose working software. We're going to prioritize that well before we have comprehensive documentation. So I really love the juxtaposition, and the emphasis on it's not that one is good and one is bad of these two things that we're comparing but that we have a preference, and that we want to orient our work around the items on the left rather than the items on the right, which I think the items on the right are more traditional or were more traditional to the Waterfall approach. STEPH: I like how you highlighted how those statements are presented to the reader. So then that way, as you mentioned, we still value what's on the right, but we favor more what's on the left. So one of the things that I saw recently was something that you shared with me in regards to where you're bringing up the idea of, like, hey, let's talk about Agile. And you shared with me a clip or a specific tweet that linked to a clip from the Go Time Podcast, which is a podcast that I hadn't listened to before. But I listened to that episode or at least part of it, and it's really delightful. I enjoyed listening to them very much. And they had Kris Brandow on the episode. And at the end of the episode...and they do something really fun where they ask the guests, "Do you have an unpopular opinion that you'd like to share?" And one thing that I like about their unpopular opinions is they often have polls afterwards, and they want to see was this truly an unpopular opinion? And if most people agree with you, then they actually consider it nope, he didn't win. I don't know if they use the word win if you didn't achieve the unpopular opinion. And in this instance, Kris shared the opinion that Agile is done and over with and that we should move on, which is a big thing to say. Everyone on the podcast reacted in a similar way that I would where it's like, well, how do we track things? And there are still things that we need to care about. But then also, there's a part of me that's just like, yes. I am not sure where Kris has heard it just yet when I heard that, but I'm already tuned in and very interested. And one of the things that Kris said that also really resonated with me is he mentioned that "I've never worked on a team where Scrum specifically like sprint and story points functions well," and I absolutely agree. There are parts of Scrum, we can get to the specifics that I think are fine that I've certainly used in the past and that have worked. Story points resonate deeply. I very much agree that story points are something that I do not enjoy using, and I do not find that they really lead to building software. There's even a blog post that I published along with Matt Sumner, a former thoughtboter and guest on this show, where we talk specifically about story points and some of the concerns and issues that we have with using story points. CHRIS: It was actually also the first episode where you came on as a guest to Bike Shed; that that was the topic that we dove into because it was so near and dear to our respective hearts. STEPH: That's right. I forgot about that. So yeah, story points are certainly up there on my don't list. I feel like we're doing a fashion do and don't, but we're doing the Agile do and don't list. [laughs] CHRIS: I kind of like that. Yeah, we should lean into that vibe. But yeah, continuing on with the poll there, it was interesting to see also, like you said, they tweeted out, and then there's the poll that comes after. And it was 64-ish percent of folks agreed that Agile's time is over and done with, and we need to move. Granted, it wasn't a huge sample size. It was like 85 people that took the poll but still, seeing both the statement and then also the general support from folks on the Twitter, it was interesting to see. So I do have the question of like, well, okay, if not, what else? And I share your sentiment of we should be able to ask questions and iterate. And nothing is so precious that it can't be replaced by something else that's better. So we always need to be trying to find the best ways to work. But again, I think there are still kernels of good stuff in the Agile. So I found this and I was like, oh, this is interesting. What's going on here? STEPH: So I'd love to dive into some of the specifics around Agile to understand what are the bits and pieces that work for you and the bits and pieces that don't. So if we are taking our Agile approach and reviewing the things that do and don't work and changing that process, what are the things that you would keep, and what are the things that you would throw out? CHRIS: Yeah, well, we can dig in, and we can bounce back and forth, I think, on this. But again, there are sort of a few different camps. So I collected together some of the lists of practices associated with some of the different approaches to Agile. So starting with Scrum, which I think perhaps is one of the most rigid, most structured, and perhaps most ire-deserving of the approaches to Agile, one of the first things is sprints or iterations, so the idea of starting...before you begin the work, you sit down, you define how much work you think you're going to take on. There's often an estimation process. Actually, we'll say that because that's maybe a separate idea, but even just broadly the idea of sprints and iterations, which often involve the idea of committing to a certain body of work. And that commitment is always handwavy and loose. No, no, no, we won't hold you to it, but then it's a constraint that's placed on the team. It's an expectation that's set, but it's wildly difficult to estimate software, as we all know. So sprints and iterations, personally, I am not a fan of. I really like a more continuous flow where we're constantly reprioritizing the work to be done. We're constantly measuring against what we built, what we think we need to get out there. How can we get something out in front of users as quickly as possible? But I've not found a ton of utility in the sprint or iteration workflow. But what do you think of that one? STEPH: Yeah, I'm generally not a fan of sprints, and it has taken me a while to get there. And I feel like I can admit that openly because it is something that I feel like when I first started doing software development, sprints were life. It was how you planned everything. It was how you committed to work. It's how you measured your work. It's how you then looked back to see what you could and couldn't accomplish in two weeks’ time or maybe a week's time, depending on how long your sprint is. But over time, I have realized that I don't like the mentality of sprinting, and that may just be a nitpick on my part, but that is something that I don't enjoy because we write better software when we have breaks. And with the sprint methodology, there's really never that break unless you're going to plan that into your sprint. And then there's the idea of the upfront commitment, as you'd mentioned, it's one of those, don't worry, we're not going to hold you to this, but can we all commit to this work? And it's one of those you just feel compelled to say, "Yes," to the person who's asking because then you feel like a jerk if you push back and you say, "Well, actually, I don't know if I can, so I'm going to commit to way less." And then that's the approach that I started taking of, well, I don't know. So I'm going to always commit to a little bit because I'd rather overachieve and then deliver more than come in under because I could work really hard, but I've over-committed and then still feel like I didn't reach my goals, and that's a rough feeling. So I found that I was already lowering my commitment there. So then, it felt more appropriate to be in line with that sort of continuous workflow instead of trying to commit to all these features or all these tickets that needed to get done. I think those are the two areas for sprint where it doesn't align with me and where it can work for teams. But I feel like there's always that underlining unhappiness that a lot of us just don't want to talk about because we don't know what else to do other than to keep sprinting. CHRIS: Yeah, I think you said something about the specific, like nitpicking the word sprint, but I do think that's actually meaningful. It's The Bike Shed, after all; if we're not going to Bike Shed about some words, what are we doing here? But I do think that we're using that word...it's obviously the wrong word; this thing's a marathon. You can't have 26 2-week sprints back to back throughout a year. That's not going to work. That's not how humans work. But any amount that we let that thinking into our head, I think, is problematic. If I'm understanding correctly, it sounds like you've come to a place of comfort around committing to a smaller body of work and then ideally overdelivering. But in my experience, many developers, perhaps even most developers, don't feel comfortable. It's so difficult to say, "Yeah, I know that the login form should take a day. That's what I feel in my heart. But let's be honest, every other time we've done a form, it's taken a week. So I'm going to say a week." It's so hard to do that. And so I think continuously, we end up in a mode where we are failing to meet the collective commitment that we made, and that's demoralizing. That's going to constantly just be a drag on the team, even if they're fake, made-up deadlines that we're constantly setting, that we're constantly not hitting. Just doing that over and over, I think, is really detrimental to the morale of the team, to the cohesions, and the feelings of are we actually doing this work? So perhaps pedantic, but I definitely share all of that. STEPH: I do want to highlight, as I mentioned earlier, I'm feeling more comfortable that I can under commit and then I can overdeliver, and that is hard. That is something that still in the moment, even today, is very hard for me to do. And it's like how you said, in my heart, I feel like this should take a day, and the heart lies. But on top of that, it's often it's also my ego that's driving me all the time. And with that, it feels like a competitive environment to me where someone's saying, "Hey, can you get this done?" And in the moment, that brings out my more competitive side where I want to say, "Yes, I can get all this done, and I can deliver all the things." When, in truth, that's often not how it's going to work out. There is one thing I do like about sprints that I want to reflect on, or perhaps it's actually two. And one of them is that we are getting together every so often, and we're agreeing on the important work to be done. And I really like that planning process that is typically coupled with a sprint. So you get together, you review the work, you address any concerns or raise any concerns. And then you could say, "Yes, we all agree this feels like important work." And essentially, we're buying into the work that's getting done, and I really like that process. And then, as an extension of that, I really like how we often then pick themes. So as we are agreeing to the work, we're often grouping together work that makes sense where it's either the most cross-functional or collaborative. We're already going to be in that space together. We're aware of what everybody is working on. And those are the aspects that I really do like about sprint and some of the other styles, that more continuous workflow of where we're always pulling from a backlog. It feels more of a grab bag in terms of I don't really know what I'm going to get next. I don't know how this work has been reviewed or vetted. I haven't really gotten to talk to anybody, perhaps. I'm making some broad statements here. But I haven't really gotten to talk to anybody from the product side to understand this change. And I also don't really know what the rest of the team is working on, so I feel more disconnected from them. CHRIS: Yeah, I definitely share that, the planning or the meeting where we discuss the work that's coming up and shape it a little bit; I love that. Although it's interesting within the context of Scrum, I think like truly to the letter Scrum; my understanding is there are very discrete meetings, and they each have a distinct purpose. And so there's the sprint planning meeting, there's a backlog grooming, there's a sprint review and the sprint retrospective. And each of those are these four distinct meetings that are happening once every two weeks or so or whatever your sprint cadence happens to be. And the splitting of those becomes interesting. And some of the practices in there, I think, are...I think you and I share not being interested in doing them or not finding them to be super valuable. But I think broadly having some version of hey, let's sit down and talk about the work before we have to do the work, definitely a fan of that. For me, it often can be let's collapse four of those meetings into one sort of thing and maybe have it more regularly or something to that effect. But actually, we'll touch on the rest of those. But if you're good with bouncing from sprint/iteration, I think we've covered that topic well. Let's move on to one that I think we can do pretty quickly because I'm pretty sure I know how we feel, but sprint planning/planning poker/estimation. How do you feel about this one, Steph? STEPH: We grouped a couple of things in there. There's sprint planning, and then there's sprint poker, and those are different to me. CHRIS: Yeah. So let's go specific to the planning poker as the most pointed version of it but also generally estimation and sizing of stories. STEPH: Nope. Throw it out. I don't know how to play poker. Let's just get rid of it. [laughs] I was never a good poker player. CHRIS: Playing poker can be fun, but planning poker...Well, so actually, to ask a slightly different question, I think in the past we've talked about keeping aspects of it, definitely not keeping the let's figure it out, let's hash it out. Let's get down to an exact point value, and then we know we can have 34 story points a week, and that's what we're going to do. But the version of using planning poker, using this numerical communication tool to see if we're aligned, that one I think we've talked about liking that. I have enjoyed that, but under the strict guidelines that we throw the numbers out. The numbers are only a communication tool. They get thrown out after the fact. We do not commit to a set amount of work or anything like that. We just use it to say, "I think it's an eight. I think it's a one. Oh, we should talk," just for that. That's when it's useful. STEPH: I agree. Yeah, in my previous answer I was being flippant about it, but I do agree very much where I don't like the specificity of where you're trying to plan exactly what numbers are these. But I do find it very helpful for the reasons that you just said where the team agrees with the estimation around how long they expect something to take. Because then that is really great where you have someone who's never touched the codebase, and they're like, "I think it's a five or whatever system we're using here." It's an elephant...whatever scale you're using. And then someone else is like, "Well, I think it's a doughnut size." I'm making up silly stuff because it's more fun for me. And then those two people can talk and reconcile. So I do like discussing the estimation of work for that purpose but then not actually writing it down or maybe going with t-shirt sizes, something that's more simple, and then doesn't have anything with points, really. Anything with points can then be gamified and also brings out people's more competitive side. So, if you can make it something that's more fun, maybe around t-shirt sizes or a bunch of cute animals, various sizes, whatever works for your team. I'm trying to think of other fun measurements now [laughs] that we could use instead of t-shirt sizes. CHRIS: There are the sizes of bottles of wine as you go past. So there's a regular bottle of wine, and then there's a magnum. And then it gets to weird names like a Nebuchadnezzar and other things. These are big performative champagne bottles. So I think we should use that kind of sizing because I think they also have a geometric progression type thing, not quite Fibonacci but something like that. So I'm going to make that push for Nebuchadnezzar as being my go-to [chuckles] sizing in story points. STEPH: I have never heard of that, and I love it. That's great. CHRIS: Okay. We'll find a relevant link to the wine bottle sizing, and we'll put that into the show notes. We will also, of course, include a link to your wonderful blog post. What's the story with story points that you wrote with Matt Sumner? Because I think that really does dial into this topic really well. And again, coming back to that core idea around Agile, while we see value in the item on the...which side is it? While we see potential value in story points, I have worked with countless teams who desperately wanted to make this thing work. So it would be great if we could quantify the work and then numerically understand the work that we had ahead of us and sequence things and talk about deadlines and whatnot. Man, that would be amazing. I would really love to do that. So with every other developer and every manager of a team of developers in the world, I have not seen it done. I am still looking for that day. When that day shows up, then I think this will be a wonderful practice. But unfortunately, my experience has been that this doesn't work, and trying to do it causes more harm than good. STEPH: I agree that I certainly understand the reason that people want story points to work because it's very nice to then say, "We can calculate, and we can measure, and then we can have delivery dates." And that's really nice from a management perspective. But that does blend in nicely to the next topic, which I think fits nicely underneath the Agile umbrella, our daily syncs. Because that does bring us closer to that goal of where we can't give real valid updates on how something is going and provide a more real estimate as to when we think something is going to get delivered. That doesn't have the same effect of where we think we're able to plan and then promise delivery dates a week in advance because we're getting those updates in real-time, but they're going to be more reliable. And that is, we're so much more than where we try to over commit to work or if we try to say how much time something is going to take. And that is so much more valuable to have that reliable update and estimate versus trying to trick ourselves into thinking that we know when something is going to get delivered. CHRIS: Yeah, I think the daily sync or sometimes called the daily Scrum, or standup, or otherwise morning meeting often in the morning, this is one that I see lots of folks really hate, and I'm personally a big fan of. This is one that I would definitely hold onto. But I think you have to be very, very purposeful with how you structure it. It really should be as short as possible. And there's one particular thing that I see very regularly in teams, which is almost a performative version of what I did yesterday. It's trying to demonstrate to the team that yes, I, in fact, did work yesterday. I was a valuable team member. Please don't let me go from the team. And I think that's the sort of thing that we should try and just get rid of. There are definitely times where what you did yesterday is relevant to the team, or you worked on something, and now you have a bunch of questions, and bringing that to the team is useful. But that version of everyone needs to prove that they did work yesterday or...it's the sort of thing like if anyone says that sort of thing, then everyone else is like if you don't say what you did yesterday, then it sounds like you did nothing because everyone else is saying what they did. So you have to, I think, get a team buy-in to do this, say, "We're not going to talk about sort of bullet-list what we did yesterday. That's not going to get us anywhere as a team." But what's useful are those little magical moments of connection where I say, "Yep, I'm working on this. I'm going to implement it in this way." And someone's like, "Wait, wait, that way? Oh, we shouldn't implement it that way." And then ideally, what happens there is okay; let’s connect after this meeting. You've now made this connection, but you don't need to hold up the rest of the meeting for that. You can just say, "Cool, this connection has been made. That's an incredibly valuable little point in time, but now let's continue on with the flow of the meeting," so that it keeps that rapid pace. And so times where you're blocked, times where you have questions, times where you're just describing what you think you're going to be working on. So if anyone's like, "Oh wait, no, we needed to stop that work because we actually made a decision yesterday that impacts whether or not we actually wanted to build that feature at all." If you can head off incorrect work at the pass, there's so much potential value in that meeting that it is interruptive. And it does take up some time, but I find that it is so, so worth it if you're able to really keep it focused, keep it concise, and keep that end goal of those little connections. When those happen, they're so valuable. So I think it's really worth the input. STEPH: I'm still smiling from where you said performative of what I did yesterday because that is something that took me a while to understand, one of the things that I did not like about the daily sync or daily meeting whenever your team gets together to talk about the work that's being done. And it was finally when I realized we're just going through a list of who has the longest list of the things that they accomplished yesterday. And again, it felt like it was bringing out more of that competitive mode in folks to talk about what they did, and it didn't feel very useful. Every now and then, maybe there was one thing that was interesting that someone did. But most of the time, it was always more helpful to hear what the person was working on that day for all the reasons that you just highlighted. There is one practical concern that I have with these types of meetings or with these types of events. And it's where you'd mentioned where if we can keep it concise…and someone brings something up, and it starts to devolve into a conversation right there. So then whoever was up next is now waiting while that conversation is happening. And that part gets awkward because then there's usually one person who is then willing or no one frankly is willing to then say, "Hey, so sorry to interrupt, but let's actually table this discussion and let everybody else go, and then we'll come back to this." And if you have people on the team that have been there for a long time with that culture, then that will just work because everyone will keep each other in check. But otherwise, if you're starting that new process, or if you start to notice there's always that one person who's doing that awkward thing of trying to then set that culture of this is how we do our daily chat, and these are the things that then we wait for later, it's really hard. And I say that because I have often been that person that's in that space where then I encourage people to table a conversation. And it always just feels awkward to interrupt someone and ask them to please wait until everybody else has gone. CHRIS: I share your hesitations around that, but it is very important. And it's that sort of ideally someone in a more senior position will model that behavior and model it in a positive, friendly way. Where I have done that often it's in the form of a question, so it's, "Actually, do you think maybe we could take this offline?" or something like that. Not a command, not taking over or shutting people down because it is somewhat interjective, and you're sort of correcting course. And so, being as friendly and empathetic in that moment as possible, but that's a hard note to strike. And again, if it's something that only one person is like the taskmaster, the Hermione Granger of the team who's trying to keep everyone focused and doing their homework sort of thing, nobody wants to be that. Well, Hermione did, but otherwise, nobody wants to be. STEPH: I love all the Harry Potter-themed references that have been coming through in the last couple of episodes. And I agree it is something that's hard to help teams course-correct, but it's important, and it's very much something worth doing. I just recognized that I think that's why these roles get implemented, why there's this concept of a Scrum Master, and then why we designate these tasks to specific people because then you have someone who can do it. And then when they do interject, it feels more appropriate because that is their role, and that's one of the things that they're supposed to do versus putting it more on the social pressure of whoever is comfortable speaking up to then course-correct. So I do understand where that implementation of Agile has then tried to create those roles, which I've been on teams that have a Scrum Master. And my experience is it's often been a very positive experience because the person that is in that role is often very kind and caring about that team. And so they are a wonderful person to work with, but it's also one of those...I've also been on teams without them, and things have been fine. So I have mixed feelings about that one. It's one of those; it feels like an extra heavy process, but I've also been on teams, and it worked. CHRIS: It's interesting the way you frame it, of the utility of that role. Like, having a role where we've now all bought into the idea that this person may take these actions say, "Hey, can we take that conversation offline?" and rather than one individual choosing to do that. I like that framing. I share what you're saying about the rest of the baggage that comes along with having this formal position, and often, that person is otherwise removed from the work. That can often be an aspect of Scrum. I think that gets complicated. But now I'm wondering can we make a software solution to do this? Because, of course, that's where my head goes. Can we have a standup bot that is listening and is like, "Hmm, it seems like you two people have been talking for the past two minutes. I'm just going to interject like my little bot self that I am and ask maybe take this conversation offline," in the way that we've sort of automated a lot of code formatting things, and that's been really wonderful, so that's not a part of PR review. Can we do the same for standup? I don't know. STEPH: I think all the award ceremonies have these where they start to play the music, and that's your cue to move off stage. CHRIS: Oh, I like it. STEPH: I think that's it. [laughs] So you cue the music whenever someone has been going for quite some time. On a slightly separate note but still related to this, some conversations that have been bubbling up around me have been related specifically to this idea around stepping in to say, "Hey, I'll take on that thing that you need a volunteer for," or "Hey, I will help the team stay on track," will often fall on people with a specific personality and then they will often be the one that continues to do that. And so they will end up taking on additional work or taking on additional roles just because they may be in a more empathetic spot where they feel that's the kind, helpful thing to do. And so, we've been looking for more ways to make sure that those tasks are being distributed evenly across the team. So we're not just waiting on someone to say, "Who would volunteer for this?" And then typically being the same handful of people that are always speaking up and then volunteering for it. And then trying to shift to more of a purposeful approach of having a queue of people and then cycling through that queue, and then if someone can't do it at a certain time, then we move on and then we just put them back in the queue. But this way, we don't have people that are typically just always taking on these responsibilities. And that's something that is a new consideration for me but one that I have found really helpful to be aware of and notice on your team who's the one that's always volunteering for these roles and checking in with them to see if they're comfortable with this, or if they're feeling compelled to volunteer for stuff because they may feel more inclined to speak up versus others are okay with staying quiet. But circling back to some of the Agile discussions earlier, you'd mentioned a handful of meetings and that you have some feelings about those meetings. What are those meetings that you have feelings about? CHRIS: Yes, the meetings. So again, this is somewhat contextual to Scrum, but the structure of Scrum has a handful of meetings that sort of define the sprint. So you have some at the beginning, the middle, and the end. So there's sprint planning, there's backlog grooming, there's sprint review, which typically includes a demo for stakeholders, and then there's sprint retrospective. And these, as far as I understand it, are four distinct meetings and are intended to be kept distinct so that their purpose stays purified in each of those meetings. And I think my feelings would be that again; I don't really find a ton of value in the sprint structure or in the two-week cadence or things like that. And so I think it can make sense in those contexts to be like, we need to make sure we have space for these things. But in a more continuous context, I think the backlog grooming or, more generally, let's talk about the work that's coming up. Let's make sure that we're all unified in how we're thinking about that work, what we think matters, what's prioritized. I think that is an incredibly valuable meeting. I think sprint review and specifically demo for stakeholders I'm really intrigued by that one. I don't know that I feel like that needs to be a distinct meeting. And in fact, more and more these days, almost every feature I deliver has either screenshots or a screen recording of what that workflow looks like. So we're continuously demonstrating to the stakeholders what does this look like now that it's a real thing? What does an end-user see? What's that experience like? And in retrospect, I think we'll probably spend a minute on that one. I like retros; some people hate retros. Yeah, let's loop back to that. But of those, what are your thoughts? What do you like? What do you not like about those meetings? STEPH: I think grooming is a very helpful meeting that can help a product manager and a technical team have discussions about the upcoming work. I don't necessarily think it needs to be the whole team. I think it can be a couple of engineers from the team; maybe those people rotate, maybe it's the team lead. And they get together with the product manager, and they essentially answer any technical questions about upcoming work. So then it can be refined. So then, as we get closer to that planning session, whatever we want to call it, then it feels more in a ready state for folks to react to and then have opinions on. So I do like grooming, but I wouldn't necessarily advocate that the whole team needs to be present for those. For a demo, I'm with you; it really depends. I've worked on projects where the stakeholders are less close to GitHub and Slack and areas that we could demo some of the work that's being done, and maybe they weren't poking around on staging as much. So it was really helpful to then have a more formal demo to then show them the work that's being done. And then I've also worked on plenty of teams where a demo was something that we used as a fun internal event where we have all these different teams, and we get together. And then we get to show off all the great work that we have done across all the different products. So then us, as fellow teammates, can then celebrate what the other teams are working on. Retros, you know I love retros. I think retros are a microcosm of your team's culture and process. And if your team is struggling to have a productive retro, your team is struggling. Because I think that is representative of your team's ability to get together, and reflect, share concerns, celebrate wins, agree on what's important, and run measured experiments. And if you're not having a retro, then I think you're not going to know how your team's doing until it's too late, and it's going to be harder to course-correct. CHRIS: #HottakeswithSteph. I like it. I like the intensity that you came in with there, but I know retro is near and dear to your heart. So I'm unsurprised that that is the line that you've drawn. I definitely share all of those feelings, particularly around retro, because I think much like the daily sync, I've seen many people who are just like, "This is a bad meeting. It's useless. Nothing ever happens. I don't like it." And I'm often surprised by that because I've found so much value in it. Retro similarly is this magical meeting that can just regularly change the course of how we're working as a team. But I also have come into plenty of teams where it definitely did not have that shape, where it was basically a place that everyone sits down, and somewhat downtrodden restates their list of grievances, their airing of grievances, and then nothing changes. And much like the sprint iteration thing where you're constantly missing the commitments, and that's just going to wear a team down. I think if you constantly have retro and nothing changes and it's that same list of concerns, then that is going to be bad, but that, like you said, is not the reason not to do it. [chuckles] Oh, we just keep saying the same things in retro, so I don't think it's even that valuable. I would say that maybe we should change the things. But I've definitely been on plenty of teams where retro was just so valuable. And it's definitely one where I feel like having a facilitator, having someone who is in that particular seat trying to guide the conversation without necessarily being in the conversation, can be incredibly valuable. There are also structures that I've seen work particularly well. We have a video on Upcase that we can link to. That's a format that I've found; it’s a very lightweight format, but it basically involves getting everyone's input on a positive note, on a more critical note, and then revisiting and sort of sorting and waiting, and then digging into topics that need a little bit more focus. But I think a lot of different formats can work as long as retro is a way for people to sincerely meet up, safely talk about the things that they are feeling about the work, and then ideally, some change comes about as a result of that. You mentioned having measured experiments, and I love that as a framing or like something that retro can do for us. STEPH: I really do think that retros are so important because they're the health check of the team. As you'd mentioned, if people are having a very negative retro experience, which I understand, I've had very negative retro experiences as well, and I've walked away feeling like that was not a productive use of my time. But then that is our warning. That is our signal that's saying, "Something is not right, and something's not great, and we're not working together as we really want to be working together." And this retro is just that reminder that is right in our face, that is making this so uncomfortable and feel like a waste of our time because it is informing us that something needs to be improved upon. And we can feel like retros are not productive when we feel powerless to make that change. And that again is then another discussion to have with the team, to have with management, leadership, to talk about how do we get the power to then make the changes that we need to then have productive, happy retros? Because that's going to be a reflection that you have a happy, productive team. CHRIS: Love it, love the framing, love the symmetry there between team happiness and retro happiness. So to summarize, I think we've gone through most of Scrum now. So just to...correct me if I'm wrong on any of these, but I believe sprints and iterations, nah, we'll leave it. Planning poker, definitely not. That doesn't seem good, although maybe just to bring up conversations, but not as an artifact that we save in any way. And then otherwise, daily sync, we're fans. Retro, definitely fans. Sprint review, backlog grooming, some version of those, a lightweight version of a bunch of the meetings seems may be good, but a couple of things definitely are going to leave on the cutting-room floor. Does that sound about right to you for Scrum specifically? We've got other topics to cover. STEPH: Yep. All of that list sounds really good. CHRIS: All right. So we've now found our refined version of Scrum, re-Scrum as we'll call it. But now there's a couple of other pieces...So Scrum is very focused on the ceremonies and the team activities, but there's another facet of the Agile umbrella, which is Extreme Programming, which that's a book. I believe Extreme Programming Explained is the name of the book. And there are various different links that we'll include to point at those. But there are two particular practices that stand out that I have heard some people love, some people do not. So we'll go into both of them. The first is pair programming. What do you think, Steph? Do you like pair programming? STEPH: I do. I'm a huge fan. [laughs] Yes, I very much like pair programming, although it still has its limitations. I definitely want time on my own, and I can get exhausted from pair programming. It is a very vulnerable experience, too, where you have to share with someone: this is what I know, this is how I work, this is how I think. And I think that is incredibly challenging. I find that I am typically more productive when I'm pairing with someone or when I have the opportunity to pair with someone at least every couple of days. CHRIS: Yep. I'm definitely a huge fan of pairing. Although I think specifically to Extreme Programming, I think the idea is 100% pairing. I think you already spoke to this, but pairing is exhausting. And the idea of 100% pairing is I can't really even imagine that; even 50% pairing feels like an incredibly high bar to hold for any extended period of time. There's a recent article that was going around the mortifying ordeal of pairing all day, which spoke of one person's experiences getting deeply burnt out just going through that process. And so, as valuable as pairing is, it's definitely a tool to be used not all the time. That feels like a lot. STEPH: That's a lot of Stephanie singing because I tend to sing a lot whenever I'm stuck or thinking through things. So that's a lot of singing that I don't know if the world wants. CHRIS: I mean, based on all of the various Bike Shed intros that involve you singing, I think the world wants it. That's maybe one person's take. But definitely, something that you said of there's a vulnerability to it. And so many pairing sessions I've either been the one saying this or someone else that I was pairing with has said this to me, but they're like, "I swear I know how to type, just now that someone's looking, my hands don't work." It's like you're in a dream, and your legs don't work. You're like, I know how to run, I swear. But for some reason, my legs are made of jelly right now. Or you can't remember a particular method, or there's just something that happens, and so getting over that hump, getting comfortable with it, I think it is a skill and something to become accustomed to. And so, again, being conscious of that when you start doing it is super important. STEPH: I don't know if this is true because I only have access to people’s thoughts when I'm pairing with them, and then they're sharing their thoughts with me. But I do feel like people tend to beat themselves up more when they have someone watching because then you feel the need to say, "Oh, I normally can type, but because someone's watching..." which is so true; that definitely happens. But those moments are some of those really great moments to then reflect on the fact that just because someone's watching us doesn't mean that then we suddenly need to beat ourselves up. And I don't know how philosophical that I want to get with this, but I feel like there are so many opportunities while pair programming to then encourage other people around us to be kind to themselves. That is one of the things that I have really benefited from pair programming is learning to be more kind to myself. And even if I don't know exactly what's happening or what I'm doing and I may not be as confident with someone else, I can still be positive and kind. Just because you're in a vulnerable space doesn't mean that you then need to be unkind to yourself. CHRIS: Yeah. I definitely agree with the idea of being kind to yourself also, where you can, be kind to someone else who you're pairing with, especially if they're finding that they're like, "Ah, suddenly my hands don't quite work." But I have pretty uniformly seen that a pairing session may start out that way. And then as everybody kind of just relaxes into it, suddenly you'll see someone just kind of flying around their editor. And you're like, wait, what just happened there? That was so fast. I don't even know. And so there's just this comfort level that sometimes it takes a little bit of time to ease into. But yeah, so pair programming, broadly yes. 100%, oh, that's going to be a no, no, thank you, not that. All right, so one other practice that comes from Extreme Programming, which is Test-Driven Development AKA TDD. What do you think about that one, Steph? STEPH: I feel like you're giving me lay-up questions here. For anyone that's familiar with us, [laughs] I feel like this is an easy one. Test-Driven Development is a thing. It's a thing that I enjoy. I don't always write tests first, though, so I don't always follow TDD, but I am definitely a fan of tests. So, I guess in that light, it’s not so much that I adhere always to TDD. I don't feel the need that I have to write tests first, but I have found that with practice, that often helps me write code where I have tests then help me write out the logic for my code. So generally, yes, thumbs up on TDD, but I'm also not terribly strict about it where if you want to write some code first, write some code first. CHRIS: Yeah, I think I'm definitely in the mode where I like testing. I like Test-Driven Development. I can't always pull it off, frankly. It's hard. It is hard to know how to write a test in advance of the implementation that you're going to write such that the test will correctly constrain the system that you're about to write. That takes a couple of levels of knowledge that if I'm writing a Rail’s controller action form sequence, I can probably TDD that because I've done it so many times. But if I'm doing something that's a little bit more new, novel, less familiar to me, then likely I won't be able to pull it off. TDD is like a fancy move that I don't always have available to me. But I consider that whenever I'm in that mode like that's not oh, it's fine to just write the thing before the test. Like, I want to be able to do TDD 100% of the time. I'm just not a good enough developer, frankly. And I don't know that I ever will be because I always want to be working a little bit past the edge of my comfort. So it's a delicate line of when I will not use TDD, but wherever I can, wherever I do have that level of knowledge of the system and the frameworks and whatnot built up, I find it is a vastly more effective way to work. It's not that I feel cool when I do it. It's like I feel much more effective. It helps me stay focused and on task and get the thing done. So it's very utilitarian in that way but also not something I can always pull off. STEPH: So, circling back to when we first started chatting, you were asking about Agile and then my thoughts about it. And having this conversation with you, I'm realizing, or I think I was already aware, but it's helping me re-solidify I'm very much a fan of Agile. There are specific implementations of Agile that I don't find enjoyable, and I don't find helpful to writing software, and I don't find helpful from the project management side either. But broadly speaking, I'm still very much a fan of the approach that we use generally for Agile, where we want to work in small deliverable increments, and then we also want to have the ability to change any moment what is the most important thing to work on? To me, that is the heart of following the Agile process. And I don't think that's going anywhere. Like, I don't think Agile's going to disappear. But I wouldn't be surprised if we see another implementation of an Agile variety of the things that you and I just shared and the things that we like. And so, I feel like most teams that I work with follow Agile within their own unique bespoke version. And we don't have to give it names because everybody's going to have their own custom version where they decide which process works for them and which one doesn't work for them. And that's what retros are for so then you can figure out which process works for you. CHRIS: Once more, Steph on the record about her love of retro. I think the core of Agile, the Manifesto, those core ideas about small iterations, delivering value, staying close to stakeholders, all of that feels deeply true to me. And I would be really surprised if a year from now or two years from now I was doing something that was wildly different from that. But then each of the layers of practices on top of that to varying degrees I like or don't like. And I wouldn't be surprised if aspects of that were swapped out down the road. But that core, that idea of this is how we think about building software. I like that thing; that seems like a good thing. So I'm going to hold on to Agile for a little bit longer personally. STEPH: Same. I still see Agile in my future. On that note, shall we wrap up? CHRIS: Let's wrap up. STEPH: Show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I’m @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeee. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Support The Bike Shed

Chris gives some small updates on working with Svelte. He really likes Svelte so far. Svelte's great. Modals are complicated. He also talks about using a little JavaScript library, called Quicklink. Steph talks about sending data to a third-party system and using feature flags to help deprecate some code. Finally, they both riff on a listener question on consulting. Said listener asked, "Do you think about your work as 'consulting first' or as 'building great software first and then good experiences for your clients will follow naturally?'" Find out their take and give us your own, here on this episode of 'The Bike Shed!' Bike Shed "Nate Berkopec" Episode Svelte Quicklink Boring Rails: Skip the bullshit and ship fast mtime (File) - APIdock 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. How has your week been? CHRIS: Happy Friday. My week's been great, yeah. I've been writing a lot of code, moving things around, planning some features, and all that fun stuff that goes into building an app, so I'm enjoying that process. I'm also halfway through listening to your recent episode with Nate Berkopec, which was absolutely delightful, well, at least the first half that I've listened to so far. I assume the rest will continue to be absolutely delightful, but it does remain to be seen. So I'll report back next week when I've listened to the whole thing. But yeah, that's great. And I'm glad that Nate got to come on, and we got to share a little bit of his story as well. STEPH: I like how clear you are in terms of like, "The part that I've listened to so far is great, but I reserve judgment until I've heard the rest of it." [chuckles] But that's awesome. CHRIS: The thing about being a developer is it has broken my brain such that I am overly specific all the time because I just argue with a computer all day. It's what I do. So then I start talking to humans, and I'm like, wait, I should probably behave differently now. And I got to unwind some of those computer fights. But anyway, and let's see, small updates working with Svelte, really like Svelte. I'm leaning into it more and more and embracing...I think I'm starting to understand the aspects of it that I really like. And one of the things that I really like about it is that it is somewhat underpowered. And what I mean by that is working on React applications, I find that I can do some fancy stuff, and I can express it really well in TypeScript. And I can really go for it and create some components that are wildly variable and configurable and can take in any combination of props and do all sorts of things. And I can slice out tiny, little components and do all of this. When I'm doing that, I enjoy it. But in Svelte, I have a little bit less power in my control. Svelte is closer to HTML, CSS, and JavaScript fundamentally. So you can make components, and I really like that. You can bundle up the pieces of functionality and display and formatting, and all of that, but it's not quite as powerful. It's not quite as expressive. And I've actually found that to be a useful limitation, which is an interesting frame. It's not something that I thought I would say, but I'm finding that the code that I'm authoring in my editor is so much closer to the code that's actually going to be presented to the end-user. That is really useful in my mind. I find that to be really valuable. There are small things like in Svelte; you can actually say class equals when you're trying to define a class on an HTML element. It turns out I really like that one instead of having to say class name or similarly HTML for. There is a handful of them in React that you have to change the name of. So if you copy a snippet of HTML from the web, and then you dump it into your editor, if you're working in React, you have to change a bunch of stuff. It doesn't work right away. And it's a small thing, but I found that I really seem to care about it. But there's the “it's nice that it just works” version. But I feel like there's also an actually practical, meaningful edge of it is so much closer to the thing that's actually going to be in the browser, and I like that. STEPH: I liked the phrasing that you used just a moment ago where you said, "Useful limitation." Since I haven't used Svelte myself, one of my understandings is that you like the fact that it is that low JS in terms that we are introducing this framework, but it's not as heavy-handed as React or another framework that you could retour. But then you also said you're running up to areas where you feel like you're missing some stuff from React, is what I'm hearing. Is there a particular feature, or do you have a concrete example to help me understand some of the stuff that you are really missing? CHRIS: It's not so much that I feel like there are specific features missing, but as a pointed example, I am not able to pass in the DOM element that I would like the component to render as. That's a weird thing, but often, component libraries will do this. So you have a button component, but the button can render either as a literal HTML button element or an anchor element. And you can pass in as equals and then button as the string there. And in React, you can do that, and then you can actually do some type inference across it and say, "Okay, now the rest of the props that you can pass in are button props.” And if you pass in as equals a, so implying that you want it to be an anchor or a link, then it will constrain you to the link properties and say, "Oh, you must have a HREF now." That's really cool that you can do that. It's also super complicated, and the TypeScript representation of it, while it works, is very, very complicated and the types of errors that you get. The complexity of what you can build with React is really interesting. But I worry now that I've spent a good bit of time in Svelte, I worry if it's overpowered. I've worked on plenty of applications where the system as designed in React, all the set of different components is very, very complicated. And you sort of have to learn that system in order to be able to work in it, whereas in Svelte, you just start, and you're writing in HTML and CSS. And then, as you need more fancy stuff, you can slowly layer it in. And to be clear, Svelte definitely has plenty of power. This past week, actually, we were working on a modal component, but we were really focused on accessibility, which is probably a good thing that you should do, but it turns out modals are very hard to get right. The dialogue component that should exist in HTML is not complete, and it's not a thing that we can rely on. So we have to do certain things ourselves. So the idea of focus trapping when the model pops up, we need to say, oh, okay, the focus should be trapped inside of here, so you can tab forward and back, but it's going to stay within that modal component. There's actually a way that you're supposed to portal it. So you move it outside of the documents so that you can make the rest of the document...I want to say aria-hidden is the property, but you're basically saying the entire rest of the document that's behind this modal component should be inert to a screen reader essentially or invisible to a screen reader while the modal is up. And doing all of those sorts of things is super complicated. After you close the modal, you're supposed to refocus the button that opened it, the triggering element, and that's a tricky one where you have to pass down a reference to something. And that was all very expressive, actually, very straightforward in Svelte in a way that I was really impressed by. So it definitely has all the power that you need but not any more than what you need. Or there is a small line of it's just right. STEPH: So we should just scrap modals. That's one of the things that I'm hearing from you. So I just want to clarify because I do feel a little confused because in the beginning, it sounded like you were saying that Svelte is wonderful, but you do feel like you're missing a little bit of functionality there that you do receive with other frameworks like React. But then that last thing you said where “it's just right” sounds like it's the Goldilocks. So I'm a little confused as to exactly how you're feeling about Svelte in the moment. CHRIS: Yeah. I'm probably not being as clear as I should. I am a big fan of Svelte, so as the first answer, a big fan of Svelte. I'm recognizing that, strictly speaking, it is somewhat less powerful than React. But I'm also trying to say, perhaps failing at saying, but trying to say that I like that, that I'm finding its constraints are useful. React can do a ton of stuff. You can represent a real impressive array of component functionality and have components that take 17 different props that covary in different ways, and it's very complicated. And I've worked on plenty of React applications where I just have to stare very hard at the component library for a while. And I'm like, ugh, I still don't know how this works. And it's this custom bespoke language where Svelte feels like it is much closer to the thing that we're actually doing, which is rendering HTML and CSS and JavaScript and whatnot, and I like that. I'm finding that very useful. I'm finding that lack of power not to be a hindrance but, in fact, to be useful. STEPH: Hmm. Okay. I like that last part. Yeah, there are often times where I feel like the less powerful something is, even if it means a little extra work on my end but it's clear as to the work that's being done...I'm going to take it back a couple of years to when I was first learning Elixir because that's how I felt jumping from Ruby to Elixir and from Rails to Phoenix, where suddenly I felt like I had more clarity. There were some things that I had to do more on my own, but I felt more clarity as to what exactly was being done versus Ruby and Rails doing a lot on my behalf. So I can certainly relate to that. CHRIS: Yeah, I think that captures it well, that the expressive power of React can perhaps lead to somewhat more confusing code, and the small handful of cases where I need to be slightly more verbose in Svelte I actually find really useful. Like, Svelte is making sure that I'm writing components that are clear and easy to work with, but it still has all of the power that I need, and I can do everything I want in it. And yeah, overall, just yeah, Svelte's great. Modals are complicated. And that's my story. But yeah, that's a little bit of what's up with me. What's going on in your world? STEPH: Before we switch gears. I want to add on a little bit more to what you just said because something that I have noticed with me is that the longer that I've been a developer, the more I want that lower-level control and understanding as to what is happening. And it sounds like that is very much what you're saying that you're enjoying with Svelte is even if it does require a little more extra effort, that then at least I have that ability to exactly control what's happening versus if you're using higher-level obstructions, you're stuck with the API that's been designed for you. And that API works 98% of the time, that's wonderful but then that 2% of the time you're in trouble. So I've definitely noticed that trend, that over time, I want that lower-level control over everything that I'm working with and building, although not all the way to C, let's not go that far. CHRIS: I mean, there's Assembly underneath C. We can keep going, and we can just manually manipulate transistors as well if we really want to get after it. [laughs] STEPH: Next week on The Bike Shed. [laughs] CHRIS: Much, much higher level of abstractions are interesting to me, but yeah, there is a sweet spot. Svelte seems like it's the one for me. STEPH: Nice. So then switching back to what's new in my week, it's been a little bit of a weird week in terms of there's been a lot of focusing on sending data to a third-party system. So we had a lot of data that they needed in their system. So I have been focused on running a number of processes that are then sending that data over and then essentially babysitting processes, making sure everything is going smoothly. Also communicating with their team to understand okay, what's being received? Do we have any errors? Is there any sort of miscommunication between our systems, and that's why we're needing to resend this data to you? So it's been very different in terms that it wasn't a typical feature development week. It was more, hey, I sent you some data. What did you receive? And then let's fine-tune both of our systems on each end, which that part I always enjoy. As soon as I can get to that level of collaboration with someone, I very much enjoy that part because initially, it felt like a stressful task of like, hey, we've got this giant CSV. We need to process and send data. But then as soon as I have someone else to work with, then I'm like, yeah, okay, this is great. They can update their system. We can fine-tune ours as well in case there's something that's not communicating properly, and that part I really enjoy. I really enjoy collaborating with someone else so then we can both improve our systems together, so that part was a little different. But the actual weird thing that I did this week is we have feature flags, and we are using those feature flags to help us sunset and deprecate some code. So we have a controller path that is pretty gnarly. It is one of the more dense, difficult areas of our codebase to understand. And so we are refactoring it and creating a new green space for it so we can start to pull in some of that behavior and then also refactor as we go. So we essentially have class version one, and we now have class version two, which is always something. And we want to be able to feature flag this because, with our deployment workflow, we need the ability one; we want to be able to switch back quickly. So that way, if something goes awry, we can switch back to the original code if we've made some misassumption in our V2 version. And then we want to leave that on for a while to make sure things are running smoothly, and then we can go back and actually remove that class. But then the question came up is like, well, if we have these two files, how do we tell the team not to touch this particular file but only contribute or make a change to this other file? Because we have a sizeable team, and we work in different time zones. And there is a very reasonable answer that we communicate with the team that other folks are aware because they've seen the PR. There's a whole self-discipline of we review PRs and make sure stuff wasn't changed. All of that stuff is fine. It's reasonable. But I wanted to do something a little less reasonable [chuckles] that would still fail loudly in case someone changed a file. So the question was presented is there a way that we could fail loudly if someone changed this file? And there's a fun thing that we'll do at some of our daily syncs where someone will say, "That's a good idea. I have a bad idea." There's a fun thing that happens at our daily syncs where someone will often ask a question, and someone will provide an idea. And then someone else will say, "That's a good idea, but just to throw it out there, I have a bad idea. So let's just explore all of the ideas." And one of them was like, "Could we write a test around this? So if the file hash or something about that changed, then could we alert the team so then we know that this file changed and you're not supposed to change this file?" And essentially, having that discussion of like, well, then we're reimplementing Git because we're trying to track file changes. That seems like a bad idea but still a novel one to talk about for a few minutes. The implementation that I landed on and then shared with a person that's working on this is you do have the ability with Ruby, the file class itself; you can open a particular file. And for this one, select class one, and then you can use the function mtime, which returns the modification time for a file. So you can check the last time that a file was changed. So I wrote a test that says that "This file was last altered at…" and I grabbed that file's last altered at time with mtime. And then, I compared that to a particular DateTime. And then that DateTime could be any DateTime in the future once we deploy this class version two, so we don't expect that file to be altered. So this test will always pass until someone changes that file. And then Ruby is going to say, "Oh, your time is now greater than that other time you said." And so it's going to fail, which actually works pretty well. It's not as ugly as I thought it was going to be. [chuckles] As to whether it's a good thing to add to the codebase, I don't know, but it was a fun thing to write. CHRIS: I like it. I've definitely written things like that in the past, and I guess; therefore, I'm biased. [chuckles] I'm a fan of this sort of thing. But when you can take that group knowledge that is just shared in communication or via code review and you can capture it in the code, especially if you can do it in a stable, robust way…In particular, the first thing that comes to mind with that is like, well, are there going to be different representations of the timestamp on your system versus CI? Will that ever change over time? Like, Linux versus OS X or things like that. I actually have reached for Git in situations like this in the past. So, in particular, the one that I found myself doing a few times is trying to instrument code generation. So say we're working with Apollo, and we are generating the TypeScript types associated with a GraphQL request. I wanted to put something into CI to say, "If we haven't committed those changes," because we're supposed to be committing those files alongside, "then warn." And so the idea was take a snapshot of what things look like right now, run the command that does the code generation, and then check after that. I've done different versions where it's like, hey, Git, is the working directory dirty at this point? That's a version. I've also done one recently where I got the checksum of the file but again, asking Git. Because you're totally right that a lot of this...this is what Git does, and we don't want to rewrite Git. But I did feel okay reaching out and being like, "Hey, Git, can you help me understand the word?" But I like these sorts of things, particularly if you can do it in a way that won't ever require someone turning it off. I don't know if you've worked on projects where ESLint is enabled, but every third line has an eslint-disable-next-line. And it's just like, well, we have a bunch of rules, but we ignore them in a lot of cases. And those sort of...the like trust scenario with an automated tool I think is so important. If it's ever giving you false positives, false negatives, whichever it is, then it immediately, I think, loses so much of its utility. But if you can do it in a way that is stable and robust, then I am a huge fan. STEPH: Well, we'll see if the person decides to include it in their PR or not. But I do like that idea of where we can take away the idea that we're going to catch it if it changes in a PR because then we're just going to end up in a bad place that if we fix a bug in the class V1 but don't apply that to class V2, we're just going to be in a bad spot. And it's likely we'll forget about it when we go back to then delete class version one. There is something that you said that has reminded me of a very small change that I made to my process, but I feel like it had a big impact. And it's specific to working with feature flags, how often you'll have your tests where it's like if feature flag is on, this behavior should happen, if it's off, this behavior. And I often would wrap my test in the default path where the feature flag is off, and then I'd have my other if the feature flag is on; this is the behavior. But as we are migrating with the intent that this feature flag at some point in the near term future is going to always be on, so we know we're going to come back and remove all of the other code. I switched those two paths and treat the default happy path as the new if the feature flag is on; this is the new world. So then when folks are going back to say, "Okay, I just need to delete everything that represents when the feature flag is off," suddenly, it's just very easy to find that context to say, "Hey, feature flag is off and then boom, delete all of those tests." And that's been really nice. CHRIS: I really like that lens of designing or coding for deleteability. How easy is it to just rip this thing out? It's one of the things that I love about Tailwind, or one of the purported facets of Tailwind that makes it really nice is when you're looking at a given template, you can just rip it out. You don't have to worry about it because there's no associated CSS that you need to think about because the CSS is sort of generated available, whatever you want to call it with Tailwind. But I really like that idea of making it easy to delete stuff. Because it's so easy to just have your codebase slowly grow over time and look at files and be like, "I don't know if we're using that, but better to be safe." Cool. I'm excited to hear if that does land in the codebase and how folks respond to it. What did you phrase the message as? So if there's a test failure, did you give a particular like a special RSpec formatted message to be like, "Hey, friend, you're not supposed to touch this file. I know you're well-intentioned, but…" or is it just like, "Failure, bad. Mtime is different." Which end of the spectrum are we on there? STEPH: I love that you asked that question because I almost went down that path, and I was like, well, this should really have its own custom failure message because it's odd enough that I want to tell someone a little bit of a story when it fails. But I didn't because this was something that one; I just want to see if I could do. So I initially started looking at standard rb in RuboCop because at first, I was wondering if this was something I could solve via linting if it was something that RuboCop…if I could say, "Hey, RuboCop, if you notice that this file changed…" I didn't know if they had a hook into Git as they're looking for files to analyze. So I first leaned on RuboCop standard rb, which essentially then uses RuboCop under the hood, and I didn't find anything there. So then that's when I was like, okay, maybe Ruby has something, and that's when I found the file mtime. So at that point, once I'd gotten the test to pass, I'm like, you know, this is good. There's a very nice, friendly test description that goes along with if this fails; this is the reason why. But I do think that would be like cherry on the top addition to the test to have a very nice error message that goes along with this. So if I were the one that was adding this to the codebase, I would take a few more minutes to do that myself. It definitely felt like one of those moments where I had gone far enough into an experimental mode, and I felt like I had just reached that point where this is useful, and I want to share it with the person who's actually working on this. But then I pulled back going further because I'm like, I don't actually know if they want to use this and if they're going to implement it. So it felt like that right friendly balance of like, here's something that works. Feel free to use as is, make it better, don't use it, totally up to you. CHRIS: Yeah, I think given that context, that's definitely I feel like a good line to draw, not like, “Here's fully completed code that you can now just drop in. I did all the work, but here it is.” Versus like, “Oh, here's a kernel of an idea if you want, run with it, but if not...”But yeah, [chuckles] if you went to the length of writing a nice paragraph summary message to the end-user, that feels like you're really taking over the show. So cool. Well, yeah, interested again to hear how that goes and hear if it does, in fact, stop. That's the other thing. It's like, if it never actually fails, then everybody was just fine with the human process. But I'm intrigued to see how many times it actually does stop unwanted modifications of the file. So that's an interesting measure to track. STEPH: Yeah, that would be an interesting thing to track because if we do have it, then we may have less visibility into knowing if it failed because then someone will see it fail locally, but then we will have prevented it from getting to that PR state. It is one of those “did someone not change it because we added the test, or could we have skipped that process?” It feels like one of those nice safety measures, but that would be a fun thing to measure, I agree. CHRIS: Yeah, especially if it's a small change; in this case, I think it's totally worth it. But now, as I said it, I didn't mean it to be more of a thing. But now that I think about the question, I wonder if all tests should fail at some point. Like, all tests have a cost, both in terms of development and then thinking about them in runtime and all of that. And a good test is one that eventually fails because you change the system in a way that broke some constraint. And so, therefore, I'm now asking the question, like, should every test fail at some point? Are tests that only ever pass actually not that useful? I don't think so. Now there's a story running in the back of my head that's like, I kind of want to look at the CI stats. And feature specs will occasionally fail for unrelated reasons. But unit-level tests that never break, that never fail and catch something that was broken…I don't know that I actually believe this, but I'm just intrigued. As I asked the question, I was like, huh, should all tests fail? Sort of like one hand clapping kind of thing, anyway. STEPH: I like the question, or it's making me stop and think because my initial answer is yes, as long as it's failing for a meaningful reason, as long as it's not a flaky test or something along those lines. But otherwise, as you're working on the system and you're making changes, then I'm inclined to say that yes, every test should fail at some point. But I agree, if we're getting into existential test area, then I don't have concrete feelings about this yet. CHRIS: Yeah, and I feel like it's one of those sorts of questions. So pivoting off of that ever so slightly to bring us to something much more practical, I have a tiny utility that I want to chat about. And then I think we have a listener question that we want to discuss. But the utility, I think I brought this up on a previous Bike Shed episode, but the tool it's a little JavaScript library, but it's called Quicklink. And so the heading is instant next-page navigations. And so the way it works is it's just a little snippet of JavaScript that you'll include from a CDN, or you can NPM install it or any number of ways. But it's a tiny, little one kilobyte JavaScript thing that basically what it does is it attaches to every link on the page whenever you use that link. So you click on it or if you're on mobile if you tap, or however you're interacting with it, if it's an internal link, so not external to your site and not going to a different domain, but if it's internal to your domain, what it's going to do is it's actually going to prefetch in the background as you hover on that link. So it's going to say, "Hover is a good indication of intent to follow this link. So we're going to prefetch it in the background." And then when the user actually subsequently clicks it, which is often a couple of 100 milliseconds later, that's often enough time actually for the page to load in the background. And then, when they click the link, it almost feels like instant navigation. There's a similar thing that happens based on when you tap and when the actual firing of the link happens on mobile. So there's another delay that they can take advantage of there that's not quite the same as hover. But overall, it just takes basically any webpage, any website, and makes it feel very much faster. And it's cheap, easy, just kind of works. I really like it. It's a very interesting little project. STEPH: I'm fascinated by how that would feel as a user because if I'm hovering over a link, I'm thinking through my specific navigation habits. So if I'm going to a link, like, I don't hover very long. I don't think of myself as a hovering internet user. [laughs] I'm probably going to click on it right away. So I wonder if I would still feel that same speediness versus...yeah, I am interested in the metrics if they have something around like...I don't know why they would know this or have this, but like, most people hover for this long. And so then it speeds up their feeling of the page load. I'd be interested in that. CHRIS: I like the idea that you're bracketing yourself into the quickest click of a link in the west. I'm looking around on their website, seeing they have a quote from NewEgg at the top, which is, "We implemented Quicklink and saw a 50% increase in conversions and 4x faster page transitions." So it sounds like I'm reading an ad for this now, which I'm not because it's a free project. So you can use it or not and pay the $0. They have a demo, and then they have a measure page. So I think you can actually get to...I think they're just talking about how to measure it. But I've definitely seen another page where you can click on a link, and it will tell you what was the difference between hover and active when you actually interacted with it. And it turns out the bounding box for a link is bigger than what you see. And you're often moving your mouse not entirely to the center, but you're not just getting to the edge of it and clicking. And so that period of time where you're moving your mouse onto the link, there's actually often a couple of hundred milliseconds, which is enough to really make a difference if you've got a speedy site. You can take what feels like a couple of hundred milliseconds and turn it into nothing. STEPH: All I can think of right now is the image of a little mouse that's moving closer to a link with the Jaws' theme song playing. So it's ta-dum ta-dum. [vocalization] And this whole time, Quicklink is getting ready to then load as soon as the mouse reaches that perfect zone to then start loading. That's what I'm getting is Jaws and Quicklink. [laughs] CHRIS: I like the...it's not personification, but it's jawsification that you're doing of this JavaScript library where it's like, I just imagine them hovering on the side really watching intently. But on the sites that I've used it, it does make a noticeable difference. I feel the difference even with very active clicking. STEPH: That sounds really neat. I'll have to look into it. Maybe I think I'm the quickest click in the west. That's very hard to say. And it turns out that I'm actually quite slow, who knows? CHRIS: You might just be average; that’s fine. STEPH: No way. CHRIS: Most people are, mathematically speaking at least. [laughter] STEPH: Not possible. I'm certain that I'm special. I hope listeners get a kick out of my oddities, [laughs] my very honest self that's coming through on the mic today. CHRIS: We're all a little special. But pivoting one more time… STEPH: That means no one's special. [laughs] CHRIS: Are you just doing the quote from Incredibles, or are you actually trying to say that? [laughs] STEPH: I wasn't intentionally quoting The Incredibles, but I did just watch that movie recently, and you're totally right. I am quoting The Incredibles. CHRIS: This is our second episode in a row then with a Pixar theme, which is always fun. But pivoting ever so slightly, I think our final pivot for the episode, we have a listener question today. So this question comes in from Matt Swanson, and he is asking about consulting first versus software first. So his question is, "One of the biggest turning points in my career was realizing that software consulting is, well, consulting. Do you think about your work as 'consulting first' or as building great software first and good experience for your clients will follow naturally?" So, Steph, what do you think? STEPH: I liked this question because it really made me stop and think about the differences in how I approach my client work. So I will say that I do think it varies slightly for each client, but most of the time, I do think of my work as first building great software. And then, once I've had time to understand how the team works and then identify opportunities for improvement, then I'll put on my consultant blazer and start scheduling meetings. I'm just kidding. I don't like meetings, so I don't do that part. But I do find that most of my engagements are looking for initially a strong developer to help contribute to the team and mentor. And then, I find that a lot of my consulting skills can then start to shine once I have that opportunity to build trust and then share outsider views with the team and then coach them in other directions. So I do take the approach of building great software first. Although this question really made me pause and think about it because I do think of the consulting and building software as so tightly coupled. It's a little hard for me to define when am I switching from my developer hat over to more of my consulting hat. CHRIS: Yeah, I think my initial reaction to the question was similar where I don't view these as two different modes that I'm fundamentally operating in. It's a continuum, or it's like a two by two grid thing, and I'm sort of moving around between the different spaces, but there's always a little bit of both. And I think if I were to answer the question directly, I would lean towards building great software. That's always the thing that I'm trying to do but often that requires some other more human-centric interactions. So having a difficult discussion around a feature and why we may not reach a deadline that we're going for or talking about ways in which the workflow is not necessarily going as well as it could, and we're ending up losing information along the way or different process things, all of that is a little bit removed from building great software. But at the same time, it's...actually, this is true of me now. I'm not technically a consultant anymore. I've stopped doing that, and I'm now full-time at an organization. And I'm not imagining my role changing fundamentally. I was consulting with them. I've now come on as a full-time employee, and I'm still viewing my work as very much the same thing. Maybe that's because I spent so long consulting that that's sort of the mode that I think of as how I work. But I think yeah, it's not necessarily two different modes. It's definitely a continuum that I'm operating across. STEPH: Yeah, I think that's why for me, it often varies. I like that word that you're using around how it's a continuum and that you're constantly sliding back and forth between one mode and the other. And if I think back to earlier days when I was working specifically with product teams before then, I joined thoughtbot and trying to think, well, what are some of the differences? How would I define what is more of my consulting mode versus then the building great software mode? Although I think the latter does encompass the consulting skills. But thinking back to when I was working on a product team, I found...and this may also just be because I was new in my career. But I found that I often referred to whoever was more senior on the team to handle a lot of those more human-centric topics, as you phrased it earlier. So if there was some communication that we needed to share in regards to why we were delayed on implementing a feature, if we needed to run a retro, if there were some meetings that needed to be scheduled, it always felt something like, oh, this leader of the team is going to take care of that. I am more in the development role, so I will do my job but then defer a lot of that to them. And then since joining thoughtbot with the way that we operate, I feel like I have more ownership in the process, and I want more ownership in the process. I want to be someone that is very aware of what are the specific goals that we're looking to reach? What are the deadlines? What's behind those deadlines that's encouraging us to push hard? And then also understanding how is the team functioning? What's something that we could do to improve the team's efficacy? Is the team happy? Are there areas there that we could improve? So I think for me, that is one of the core parts where I feel like I transitioned from being more focused on development to being more...you know, I don't have a great word for it. I often referred to it as being more of like a product owner. And since then, I feel like I have more ownership around the code that I'm working with and the team, and then the processes and the decisions for the product. But I actually don't have a great word that encompasses that sense of I want to be part of this and help make decisions and look out for everyone else that's around me. Does that resonate with you? Do you have any particular way that you would describe that or a word for it? CHRIS: I don't have a specific word for it. In my mind, this is just how we build software. But I think that that speaks to the culture that we grew up in as software developers. It's so strongly in our minds to think this way. A thing that we've talked about in the past is encouraging software developers to observe the sales demo, to see what it looks like when we're talking to end-users, or, similarly, to sit on customer support calls or listen to user interviews or things like that. And the reason for that is we want...I believe strongly that developers will do better work if they understand the context of the end-user of the application. But I think fundamentally, that sort of loads things up in someone's mind that might encourage them to push back or to suggest a different way of working down the road, and I think that's a good thing. I think every software developer should have some amount of that going on. And so that idea that consulting is this other thing that you sometimes do I feel like that stuff fits under the umbrella of consulting and, therefore, I think it's just part of how we build good software, but maybe it's a nomenclature thing, and I'm just thinking about it wrong. STEPH: Well, I want to pull at that thread a little bit because I was having that internal discussion with myself when I was thinking about this question is in regards to that being more aware of how the other teams are working to then help inform our decisions around the software that we're helping build, and implement advocating for a new process or advocating for how to build great software, is that consulting? I think you and I fall more into the camp of that's just how you build great software is; you have to be part of those decisions to be able to have more insights into the work that's being done. So I don't know if I could even really classify that as a consulting skill. CHRIS: Yeah, that matches my thinking. There is a distinction between consultant and contractor that I'll sometimes push on a little bit where I see consultants as being perhaps a bit more strategic and not necessarily being handed the work to do. I see that perhaps more on the contractor end. It's like, "We need a website built. Here are the specs. Here's the design mock-up. Please build it," and that's that. Versus a consultant being like, "We need a website, but we're not even sure exactly what that means. Can you help us think about the features and prioritize? Do we need a mobile app or not?" And a consultant potentially working more in that space of helping to determine what is the work that we're even going to do. But again, that's a question of like, how do we build good software? We have to answer those questions, and maybe not everyone on the team is always answering those questions. But the more people feel empowered to and feel like they've got the context to be able to make those sorts of at least suggestions around those sort of decisions, I think the better. STEPH: Yeah. I agree with the distinction in regards to being a consultant or a developer versus being a contractor because one definitely feels more removed from that decision or with that team collaboration process where you are more handed work, and then you implement that work, but you don't necessarily ask questions and be like, "Well, what are the benefits of adding this particular feature? Are we tracking to know that we've added the right thing?" those types of things that I would naturally include as part of my work. Versus if you're doing more of the contract work, then maybe you just implement and then don't ask those questions. Thinking back to then, what's different about being a consultant versus then doing development work…and I'm totally sidestepping all the financial stuff here. Like, if you're a consultant, then your world may be very different in terms of how you are acquiring jobs and then your marketing. So I am sidestepping that big conversation there but then focusing more on your day-to-day, how it may be different. And the times that I do feel that I'm wearing more of my lower-casey consulting hat is where I am joining teams that have a very specific goal that they have brought thoughtbot on to help with. So maybe there is a particular certification that they want their software to achieve, or maybe they're looking to level up their team and a particular tech stack, maybe it's Rails, maybe it's testing. And that one feels more focused on I am here to help provide an outsider opinion, to help evaluate your team, to help you provide advice, to communicate more with leadership that's on the team so then they know how things are going. That feels more like a consulting engagement that is less focused on building great software. But I feel like that often still starts with we want that stuff, but we also still want great software. So I always feel like I'm in both, and I really can't be as effective at the consulting part without actually working with the team and understanding the struggles that they're going through. So I still feel like they fit very hand in hand, but I do find that there are certain engagements that do require more external communication versus the others are often more internal with the team that I'm helping build software with. CHRIS: Well, I like that as a framing, the internal versus external communication and sort of the ratio of those. That's an interesting one. STEPH: To me, that's really what then sort of differentiates the consulting versus the just focused on building great software is if I'm doing more external communication, I'm focused less on the building part of the software but more on the guidance part. CHRIS: Yeah, I think that's a really good encapsulation or perhaps a way to differentiate the two ends of this. But I think both you and I probably feel that this just varies project to project. In some cases, we need more of what would fall into the consulting bucket, and other days, it's just nope, we got to go in. We got to implement. We got to build a bunch of features. We've got to get to the MVP launch and whatnot. And that often requires a little bit less on the consulting or the external communication side. But I think it's a case-by-case thing. And it's not that I think of myself as one or the other; it's I'll scale up or down as necessary based on the context of the situation. So I am both, I think. STEPH: Two for one, consulting and building great software. [laughs] CHRIS: One-stop shopping, everything you need. STEPH: So, I do have a couple of examples that I can provide that may provide some insight as to how we view consulting a little differently than necessarily focusing on implementation. I feel that I'm still reaching for that separation between consulting and developing. So I'm going to focus on the external communication and the implementation. I feel like those are the two areas that are trying to be divided in this particular question. But I do have some examples from thoughtbot discussions around consulting. So every so often, we get together at thoughtbot, and we have these internal discussions where we talk about the different consulting challenges that we have faced. And it's a really nice time where we get together, and we may discuss ongoing active consulting challenges and questions that we have, or it may be scenarios that have happened in the past. And so then we present that scenario to groups, and then we break off into smaller groups, and then everybody has an opportunity to talk through how they would react, what advice they would give, how they would approach it. And I have found those sessions to be incredibly helpful, but I think it could be fun to share some of those examples. Folks can think about them as to how they would react to them. But I think this helps highlight why those consulting skills and then also building great software are so tightly coupled together. So this first example focuses on building MVPs. So let's say that you're working with a client, and you've been focused on building an MVP, and the engagement is coming to a close in a few weeks. But the client is disappointed that there is a particular feature that they're really excited about that's not being included in the MVP, and they'd really like to know why that particular feature was cut. And they are worried that that will actually cause the business to fail if they don't have that feature in the MVP. So that's something that often comes up when we are focused on scoping MVPs to make sure that we are aligned with the client team to understand what is very important for the MVP and what can be a fast follow. And that can be a thorny one, especially if someone feels emotionally attached to a feature that is something that can be tricky to navigate. And how do you help the team reach a consensus that this feature really does need to be in the MVP, or it's okay that it doesn't need to go out now, and it can be in a future iteration? And for another example, this one is more focused on communicating the progress of particular work and how it's going. So you can imagine this scenario coming from the client saying that they have been working with you for a few weeks and you've made good progress, but it feels like the last week things have stalled. And they don't understand why a particular feature is taking longer than expected to ship. And they haven't had any communication from the team regarding what's taking that feature a longer time to get out. So, again, these are just some scenarios that you can think through and imagine how then you would respond or handle each of these situations. But I think both of those are really great examples that focus on the more consulting aspect of our work and then when we need to have more external communication with teams, so then they feel confident that we are developing great software. CHRIS: I think this is the first time that I've observed us giving homework to the listeners. But I think one thing that I'll highlight is we are talking about this in the context of consulting or being a consultant. But I think both of those examples that you gave, and more generally, most of these sort of conversations, actually apply pretty equally to working within an organization as an employee. You're still working on projects. You still have deadlines. You still need to ship things. You maybe aren't shipping as quickly as you need to; that maybe needs to get communicated to both internally within your team and externally within your larger organization. So yeah, I think these are broadly applicable, and I think, yeah, rolling them around in your head, let us know if you come up with any great solutions. STEPH: And if folks are interested in these types of scenarios, then I'm happy to share some more of them. I could share them on Twitter or anywhere else that folks find helpful. But I really like that nuance where I feel like is a nuanced discussion between building some great software and then those consulting skills. So thanks, Matt, for submitting such a great question. CHRIS: And as an aside, just to give a little more context on Matt, he runs a blog called the Boring Rails, which,, if you are not following it, it is a wonderful, straightforward summary of small, useful tidbits of information in the Rails world that are boring, but that's part of what we love about Rails. So I highly recommend that as well, and we'll include a link in the show notes. But yeah, thank you so much, Matt. And on that note, shall we wrap up? STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I’m @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Support The Bike Shed

Chris gives the deets on that new new – (he joined a startup!) and laments about the back button being so complicated. Steph talks about extracting an untrustworthy service and likens the scenario to making a Pixar movie. You don't wanna miss this hero's journey! Eric Bailey's bunny updates Katrina Owen's Therapeutic Refactoring Talk EnjoyHQ User research platform Aurelius also a user research platform Dry Monad (part of dry-rb) Previous Bike Shed discussing dry-monads Railway Oriented Programming Bike Shed "Seeking Calm" Episode Previous Episode Discussing Multi-Step Forms Discussion thread on Inertia repo re: back button cache Transcript: STEPH: Yes, I was getting text messages from you where you were like, “Go on without me.” CHRIS: [laughs] Leave me behind! STEPH: [laughs] No developer left behind!! 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, how's your week going? STEPH: Hey, Chris. It's been a very busy week. There's been a lot going on. But the most delightful part of my week has been that Eric Bailey, another thoughtboter and also a former guest on this show, has a tiny, little baby bunny living in his backyard, and so he has been sharing updates about this little baby bunny. In fact, he's been sharing some pictures on Twitter as well. So I'll include a link in the show notes so other people can experience the joy. Also, the name of the bunny gets me every time. But they have named the bunny “Corndog.” CHRIS: Checks out. It seems like a very obvious name for a small bunny. STEPH: It gets me because that's such a big name. I don't know why it's a big name, but it feels like a big name for a little bunny. CHRIS: I can say yeah, it's a cornball. Yeah, that's a large name. And so a tiny bunny is a...it's like Little John from Robin Hood. It's perfect. STEPH: [chuckles] I kept referring to him as Corn Nugget, I guess, because of size. But yes, it’s not corn nugget; it’s Corndog. [chuckles] So watching Eric's little bunny has been delightful and a wonderful addition to the week. How about you? How has your week been? CHRIS: My week has been great. I was off on vacation last week (so you had a guest on), which was fun to just take a week off and reset the system. But actually, this week has been interesting. It was my first full-time week with a new startup that I have joined. I think, yeah, that seems to be the truth in the world. So a bit of a shift from what I've been doing for the last year and a half, almost something like that. The reason there's hesitance in my voice is because I've actually been working with this organization for six months-ish, depending on how you count it. I've been having conversations, and then it’s slowly grown over time where it was just conversations, and then it was an afternoon a week, and then one day a week, and then two, and three. And finally, we decided we think we've got an idea. We've got a thing that we want to build. And so I am the developer on this team, but we are an early-stage startup trying to build something. I'm now full-time on the project. I rotated down the other projects that I was working on from a freelance consulting perspective, and now I'm trying something new. So it's a very different vibe. Even though I'd been working with the organization for a long time, this week just felt so much more real. And there was so much more space, so much more room for activities, having a full week to actually work on things. So yeah, it's very exciting, it’s very new, it's very early stage, so all of those things are true. But there are a lot of great aspects to that, and I'm super excited about it. STEPH: That is some big news. That's a big change too. Well, I guess with consulting, there are the stresses that go into consulting and then changing projects and managing the projects that you're taking on. But then to joining a team and such an early startup team too...anytime, someone says startup life, I'm always like, well, tell me more. How calm is the startup life, or how uncalm is this startup life? CHRIS: It's somewhere between calm and uncalm, I would say, but in a, I would say purposeful and intentional way. I was looking for...this has largely been true over the entire time that I was freelancing, but freelancing was a way for me to keep the lights on, and stay engaged with tech, and continue working, and frankly, have more conversations and meet more organizations. But I was looking for something that I could engage with a bit more. I was looking for, largely, something like this. So it definitely is occupying a different space in my head than, say, any individual consulting client where with consulting, I was pretty rigid, you know, these are the hours that I'm working. When I'm off the clock, I'm really not thinking about it too much. I'm responsive if I see an incident or something like that or if the database falls over; I’m going to look at that on the weekend but otherwise, largely not doing anything. Whereas with this project, I'm somewhat purposefully allowing it to have a little bit more space in my head off-hours, that sort of thing. And I'm more invested in the work. It's not just a thing that I'm doing, but it's a project that I believe in. It's something that I want to exist in the world. And so, I'm engaged with it in a different way in that manner. I'm also engineer number one, so I'm choosing all of the technologies and setting the standards. Thankfully, there's a lot of good thoughtbot material out there that I can link to, which is great. But yeah, so it's mostly within the context of what I think startups can be. The expectations and the way that the team is working is very reasonable. And I think it's more for my own self. I'm allowing it to occupy a little bit more of my space, but in a fun way so far. STEPH: Well, along that line, in terms of choosing the tech stack and starting greenfield, I am curious to hear more about the type of project that you're going to be working on. But I'm also recognizing y'all may be in stealth mode. Is that where you're at, or can you talk a bit more about the type of work you'll be doing? CHRIS: We're stealth-ish right now, I would say, partly because we're likely in the process of rebranding, and renaming, and things like that. So partly it's just like, oh, I probably shouldn't say that. But at some point, this will become public, and so at that point, I can probably be a little bit more open about it. But at the end of the day, we're building a financial product, FinTech sort of thing. And the tech stack is relatively straightforward. I'm actually using my preferred tech stack is...I got to choose, so it's Rails, Inertia, and Svelte with some TypeScript because why not? And I love it, and it's fantastic. I continue to believe deeply in that tech stack. So, yeah, that's most of what I think is good to say now. But I think over the coming weeks, I'll be able to say more and share more. And I certainly will be able to talk about the details of building and growing a team and things like that. STEPH: Awesome. Yeah, you answered my other question too. I was going to ask what tech stack you chose. CHRIS: I chose the tech stack, the one with the acronym, which I don't even know...the STIR stack I think we went with or something. STEPH: I was about to say I don't remember the acronym. [laughs] CHRIS: I think I never committed to an acronym previously, and then that was the one that got thrown around on the internet. I think I just was like, in the next episode of The Bike Shed, I'll choose an acronym so STIR, why not? STEPH: I like it, causing a stir. CHRIS: But yeah, so it's a pretty sizable shift in my life. But frankly, I don't even know exactly the shape that the coming weeks will have. So it will be interesting to report back as things evolve and as new concerns and considerations come up. But, yeah, we'll save that for future weeks. For now, what else is up in your world? STEPH: Yeah, it's been an interesting week. There have been really two things on my mind, so one of them has been focused on writing a task that's going to process a sizable CSV. And then it's going to essentially enqueue a bunch of jobs and send off a bunch of data to other third-party systems. So that's been a big focus of the week. The other topic is what I'm going to call extracting an untrustworthy service into its own service. And I know that’s a bit vague, but I've got both of those topics. So which one would you want to hear about first? CHRIS: I definitely want to hear about both. But because you veiled it in mystery and said, “An untrustworthy,” that one's just going to call to me a little bit more. So yeah, what about this extracting and untrustworthy service? What more can you say there? STEPH: Good question. I'm glad that you picked the mysterious one and started there. That feels right. So this is a part of our codebase, and it's very related to also the task that I'm writing. So to provide a bit of context, this particular portion of the codebase manages a big part of where we are sending data from our application over to third-party systems. And it's a very important feature of our application. And it's also probably one of the gnarliest sections of our application in terms of there are tons of conditionals based on which type of service we're sending to or the discreet customer that we're sending it to, and any particular preferences that they need and how we're sending that data. And then there's also just a lot of room for ambiguity and errors. And when we are sending that data, was it actually successful? And what if it was successful, but we still got back error messages? What does that mean? Is that successful with warning? And so there are just a lot of unknowns. It's also one of the less tested areas of the codebase. So even though it's important, we really don't feel confident making changes at this point until we've added some more test coverage. And testing it can be a beast because right now, we really just want to add some security around that section of the codebase. So we're often going for high-level tests, which are then our slower tests, but then also means it's hard to test the more granular aspects of that code. This is that untrustworthy section of the code in terms that we're a bit skittish to make changes, but yet it's a very active part of the codebase, so not the best place to be. But we also recognize that this part of the codebase would be really well-fitted to live outside of the application. It really doesn't need to live with the rest of the application. And there are other services that need to be able to talk to the service as well. So instead of having it grouped together, which -- It's funny. I see your eyebrows go up when I talk about -- For people who can't see, Chris raised his eyebrows when I talked about extracting this to another service. [chuckles] CHRIS: That doesn't sound like me at all. I don't ever… STEPH: [chuckles] And since we do have other services that need to be able to pull data or to talk to this particular portion of the codebase, we are looking to then move it out into its own application, so that way, it can stand alone. It can focus on this one task, and then other services can benefit from it as well. And there's been an interesting discussion around, well, we need to make changes to this codebase. And we also have some recognition that we need to make improvements. Do we go ahead and go heads down for a bit and improve the section of the codebase, add more test coverage, get to understand more of what this code does, where the risks are? Or do we go ahead and extract it in its current form to the new greenfield space and just essentially port it, and then we work on it from that space? And so, there's been a conversation around which one do we do first? And I'll tell you my thoughts, and then I'd love to hear yours. As one of the primary individuals that's been working in this codebase, my stance has been let's leave it in place for now because I want to build some confidence around what this does. So I really want to have some confident understanding about the requirements, about when we extract this, what is that going to look like? But also, I feel like I'm in a place where I'm starting to understand the beast enough that I want to continue that progress and add some testing around it before then we just move it to this new location. And I can't decide if that's one of those decisions where like, I just feel too close to it, and extracting it feels risky to me. So I feel like we're adding on this extra level of complexity. Like, this is already code that's hard to understand. And then we're going to add this network connection on top of that where then we have to talk to it in a different way. And in my mind, that's adding another level of risk and another level of having to debug this service. So my current approach is let's leave it in place. Let's try to identify some low-hanging fruit. Let's go ahead and add some more tests. And I feel pretty good about that decision. I'm curious, what are your thoughts? CHRIS: I have a bunch of them. The first is that the story that you're telling here feels like the hero's journey of software development. Like, all right, we got this gnarly bit of the code. It's super important. It's super complicated. It doesn't really have any test coverage for historical reasons that are complicated, but here we are. What do we do? That story feels so true. It feels like there are nine Pixar movies about it if Pixar made movies about writing code, and they would be great movies. STEPH: That's amazing. [laughs] I would watch those movies. CHRIS: I think of it like Katrina Owen’s therapeutic refactoring, which I feel like is probably my most referenced...It's one of my two most referenced talks that I bring up on the show all the time, but it is almost exactly about that sort of thing. We've got this gnarly piece of code. It's super important, but nobody really knows how it works. But we know it does work, which is an interesting bit. And so to the question of would you extract as is or would you try and shore it up before you extract it? I am 100% on the side that you are on, which is let's shore this thing up before we move it over. Because moving it over, like you said, that's going to add the additional complexity and failure modes of network latency, network timeouts, async disconnects, whatever, any of those complexities. That's another set of failure modes that you'll be introducing or just complexity and things that you have to think about. So that feels complicated. Also, there's probably a poor analogy that I have in my head. But imagine that you're moving, and your bedroom is just a complete mess, and you're like, oh, there are some old to-go food containers over there. And I haven't done my laundry in a couple of weeks. I'm just going to throw it all on a blanket and take it to the new house, and I'll figure out what I want to keep on the other side. It's like, that doesn't feel like the right move. I would definitely throw some things out before I move to a new house. So I definitely lean in to let's clean this up and understand it so that when it's in the new place, we have a slightly more contained, understood, manageable version of the software to try and extract to a service. STEPH: I feel very judged for my moving style. CHRIS: [laughs] I mean, obviously, with software, you're doing the one thing. But did I just describe exactly how you move house? STEPH: [laughs] CHRIS: To each their own now, you know, whatever works for you. STEPH: No, I'm with you. I'm definitely the person that's going to clean up first before I put stuff in boxes. I'm going to try to give away as much stuff as possible. CHRIS: It's a great time to just figure out what's true in your life or what's true in your software. I am intrigued. So yes, I did raise my eyebrows when you mentioned extracting a service and other services talking to each other. In particular, the way you described this piece of the system, I would be surprised if there weren't data requirements and/or transactional consistency things that you wanted to uphold. And that's one of the main things that causes me concern when we're extracting services is if this thing still needs to know about a bunch of different pieces of data and if it's going to make multiple updates to different records where if one succeeds and the other doesn't, we should roll back the whole thing. You lose all of that by moving to a service. And so that's where my broad…like, I'm always going to question if we're going to surface this. So I'm intrigued. Is this thing a very functional piece of your system where some data comes in, some stuff happens, and you get data out at the end of the day? Or is it more operating on related data within your system and potentially updating records after the fact? STEPH: Yeah, that's a great point. For this area of the codebase, it does feel more functional in terms that we have data, and we essentially want to notify other people that we have this data, and then we want to share it with them. So there is still that coupling of where we need access to those values. So if we're sending it over to the new system, either that new system needs to be able to read from the same database, or we have to send all of those details over to the new system. So then it can build up the message and then send it over to the other third-party systems. So it feels more functional, but there are still some of those requirements that we need to think about. CHRIS: Okay. That definitely clarifies things. And I wouldn't say that I have a unified theory of services. But what you're describing feels like the type of service that I'm more open to. It sounds almost like a SendGrid where I want to deal with all of my application data. And then I send a bunch of structured data over to SendGrid, and their job is to send an email and retry as necessary or send a text message or even do a voice call if it's Twilio or something like that. And so they're really good at those weird things and the failure modes that exist in those communication channels. But that's not logic that I need to live in my app. And so what you're describing there definitely makes sense as something that could comfortably be extracted to a service and not have more complexity be introduced by that. You did mention something about services talking to services and other things. So is the idea that this would be extracted, then other parts of the system would also use it to communicate out messages or something like that. STEPH: Yeah, one of the motivations for extracting this is because we have another application that also wants to perform similar behavior. So now we have two applications that need to do similar work, and they feel more in that line of functional work where it would be great if we could share this. But it doesn't fit in the space that we want to extract it in regards to extract it to a gem and make it shareable. It feels more appropriate for it to be its own service and then also capture. Because the other nice thing that we want to include that we're doing now as well is we want to capture feedback from whenever we are sending that data over to other systems. We want to know, hey, how did it go? Did you give us back that successfully, but maybe with some warnings or some errors? Maybe you accepted the data, but then you also gave us a response about something else. I think one really important question to consider is when is it trustworthy enough to extract? Because we know we're headed down this path. So at what point are we ready to then go ahead and extract this over to its own service? And that was the more interesting conversation because I think those who were in favor of extracting it now had the concern that we can't add test coverage in its current form. So my first response was if I need to make changes and I can't add test coverage, I will sound the alarm, and we will reconsider. But my goal right now is to turn this untrustworthy service into a little more trust. Just dial up the trust a little bit further, and then we can port this over. So then, as we do add some network complexities on top of this, we will at least have more faith and understanding the underlying behavior of the system. But then we still want to understand that it's not going to be perfect. And we're not going to wait until it's perfect before we do extract it. But that's the tale or the mysterious extracting an untrustworthy service. So I think it will be an interesting journey. And it was a very interesting conversation that I was excited to have your thoughts because I know you and I often lean so far away from extracting stuff to a service that it was an interesting conversation to have around; well, this code is a bit of a mess. When do we start to tackle that mess? CHRIS: I like that you didn't even frame it necessarily in terms of that, but I still definitely got there. I was like, wait, wait, wait, but let's actually talk about whether or not. But this is definitely the sort of thing that I think makes sense to consider as a service extraction. I think the question that you're asking around when do we feel good enough in its current state to do the extraction? That's right on the line of art in the software world as opposed to the science of this is how we connect HTTP. So I'm very interested to see where you get to both with that question and how you actually make that decision and then how the extraction goes. And I imagine this will be the sort of thing that goes on for a bit of time. So it feels like we could make a mini-story arc that'll span a couple of episodes, and you can follow the characters on their journey. This is the Pixar movie. We're making a Pixar movie. STEPH: We're making a Pixar movie. They're missing an entire genre for their Pixar movies. If they just appeal to developers, that'd be wonderful. I’m so in for that. We should write Pixar. CHRIS: There are more developers every day, so think Hackers meets Up. That's what we're going for. We're just going to fuse those two together. It's going to pull at your heartstrings, but it's also going to talk about hacking the Gibson. It's going to be great. STEPH: Oh man, you reached for the most heartfelt one going for Up. That one has the toughest beginning. [laughs] CHRIS: That's what I'm going for here. STEPH: For anyone that hasn't seen Up, you can go watch the beginning of it. Just be prepared. CHRIS: And if anyone hasn't seen Hackers, also be prepared. [laughs] STEPH: Which is me. I haven't seen Hackers. CHRIS: All right. You still haven’t. All right, that's a thing we need to work on. STEPH: [chuckles] CHRIS: But cool. Okay. So we're going to work on the Pixar movie. You're going to update us because we need to actually gather the information. But yeah, we'll come back to that in future episodes. But shifting gears just a little bit, actually, I have a couple of things, two small things, and then one more sizable thing that is more just like, I'm confused. So yeah, we're going to go in that order. Thing number one is, we are, again, it's a very early-stage startup that I'm working with. And part of what we're doing that I really like is that we are talking to potential customers, potential end-users of the application doing lots of user interviews, which is a thing that I have more from a distance seen often. But now, because we're actually working as a distributed team, we're remote because that's the nature of the world right now. We'll probably meet each other in person at some point, but that's down the road. But all of these conversations are happening over Zoom calls, all of these user interviews. And so I made the suggestion that we use a tool to actually manage those. And so we're using a tool called EnjoyHQ, I think is the name of it. There's another similar tool called Aurelius. We can put the links in the show notes for both of those. But what it does is it basically makes the video available after the fact. I think it automatically transcribes it, and then it allows you to annotate and add notes and things like that, which is great for aggregating this body of information that we're collecting over time as we do all of these user interviews and start to tag common themes that we're seeing. And bringing them together will also allow us to revisit them. But for me as the developer, I've been to a few of them, but not as many as the rest of the team. And what's great is I've now taken to...as I'm doing more mundane…cleaning up email or whatever sort of tasks, I will just put on one of these videos in the background at 2X. And what's great is I can now just hear literally the voice of the users of the application. What are the words that they're choosing? How are they talking about it? What matters to them? What doesn't matter to them? What do they get really passionate about? And it's been just such a wonderful thing to have available. It's almost like a podcast of our app that we're building, and it's like, that's awesome. STEPH: I love that. Yeah, I would love to be able to hear from people that are using the application. And like you mentioned, just turn it on in the background so that way I can process what they're saying. But then, I don't know, depending on what they're saying, maybe it needs full attention or otherwise, maybe you're able to just absorb little bits and pieces while you're hacking away on something else. And now I've got the word hacking stuck in my mind. [laughs] CHRIS: It's the best word to describe what we do. Yeah, there's definitely a version of someone should be reviewing...someone's actually doing the interview, so they're going to be very close to it. And then there maybe is a secondary someone's watching it closely and trying to glean, and categorize, and all of that. And I could potentially be any one of those, but I really like this version of this is just a background soundtrack that I'm exposing myself to so that I'm all the more immersed in the problem space that we are working on. And it's one of the things that I fundamentally believe about software development is developers shouldn't be hidden in the corner just writing code. We should always care about what the end-user wants, and what better way to get there than to actually hear their voice and hear the words that they're using. So this is a magical little trick that I have now found that I'm like, oh my God, this is amazing. STEPH: Funny enough, I had a similar experience this past week where I realized I was feeling very disconnected from the people that are using the application and also the people that are setting priorities for the work that our team is doing. And that is something that I'm very accustomed to with thoughtbot that we always want to be part of the team. We're not necessarily just we can churn through a backlog. But we also really want to be in touch with product decisions, and share opinions, and then also be in touch with users too. So I had some similar revelations this week where I realized I was feeling very disconnected where I was picking up tickets, and I was like, I don't really understand why this is great or how this is helpful. And so, I shared that with the team, and someone encouraged me to attend a specific meeting. And that was wonderful because then I got to hear from the people who were creating those tickets and then giving them a high priority because something was urgent and why it was urgent. And having that insight was huge to me. And I realized that it was incredibly motivational as well. Because then I'm like, yes, okay, I understand how this is going to impact someone. And I'm now very encouraged to get this done. CHRIS: I think that idea, that ethos of wanting to get into the user persona and understand that better is a very strong thoughtbot ideal. So it’s unsurprising both of us share that. But yeah, that was a really great thing and particularly a tool that facilitated that in a really straightforward way, which I appreciated. Another thing that I used this week, which I've talked about at length in a previous episode, so we can link to that episode, but it's a project called dry-monad. So there's dry-rb is the collection of, I think, a set of gems, but dry-monad is one that allows for defining sequential tasks, so tasks that you have to do a bunch of steps in order and the outcome of a previous step will be the input of the next part of the process. So it can fail in a bunch of ways like, okay, fetch this thing from the network and then look up a user based on that. And then get the user's profile, which may or may not exist, and then assuming that all of that's gone well, actually persist to this new record, to the database. And they're really finicky to write that sort of sequential processing. And so I actually had written that thing manually. And part of it was I'd wrapped the whole thing in a database transaction, but I was trying to make it so that if something went wrong, I would manually roll back the transaction. And then I wanted to return an object to the caller that indicated that things had failed and an error message or something like that. And that was actually really hard to do because of the way transactions work. The mechanism that I was using was apparently deprecated in Rails. And so the whole thing was just kind of confusing, and it was a bit messy in the code. And I knew in the back of my mind that dry-monad exists. I've used it before. I've really enjoyed it. But I was trying to minimize the amount of new technologies that I'm bringing in this early on in the project. It's like, yeah, I'll bring that in when I need it. But finally, I was like, you know what? I think I've reached that point. I grabbed it, brought it in, and I haven't worked with it in a while, but I was very quickly able to refactor my class to use dry-monad. It cleaned it up immensely. The tests remained identical, which was really interesting. I didn't have to change anything on the test side. And one of my tests was failing before and then passed because of the introduction of dry-monad. And yeah, it was just like a win-win-win, and also the fact that I was able to revisit dry-monad as a library and just get running with it again was really interesting to me because it is a bit complicated and interesting in how it works. But again, I was able to just sort of pick it up and run with it. So that was wonderful. And I will now all the more staunchly suggest that folks reach for that when they have more complex, procedural type code that they need to write. STEPH: I remember you highlighting dry-monad before in previous episodes and talking about the pain of writing that sort of procedural code, but then we also want to return something helpful. And I looked at it briefly, but I haven't used it. But now that you are reminding me of it, I'm very interested in it because I agree that process is difficult to write, at least in Ruby it's difficult to write. I understand the hesitancy that you have around bringing something in that's new. But then if you recognize that it's going to be a theme in your application around this is something that we're going to do a fair amount, and we want to do it in a clean, efficient way, then it starts to feel more reasonable to say, “Okay, I'm bringing in something new, but it is representative of how we want to handle this step or this type of process in our application.” So it's not just bringing in a gem to handle one small area of the code, something that we could have written, but it is elevating our process and our system. CHRIS: Yup. Indeed. In this case, these are command objects within the system. That's actually the name that I got from the creator of the project. That was his suggestion on Twitter as to what to call these objects. And it's a pattern that I do want to encode and has become the standard within the application for any of these more complex processing tasks. So, again, we'll link to the previous episode. I talked about it in more depth and the ideas behind it. Railway Oriented Programming is a phrase that's used, which talks about how to sequence failures or successes and whatnot together. And there's some good material behind it, more general, but yeah, wonderful, little library. STEPH: What is Railway Oriented Programming? I'm not familiar with that term. CHRIS: That refers to the sequential processing that I was describing. So imagine that you have a bunch of different steps where first you fetch from the network to get this record, then using what you got back, you look up a user in your database, then you fetch that user's profile. Then you do something else. Each of those steps along the way could fail. And so the railway metaphor is the track is going forward, but if at any point you branch off the track because of a failure, then you're in the failure track, and that's a different thing. And so it's a very...the dry-monad or other similar Railway Oriented Programming or monads generally I think is the actual...it's the words in there. And I wish it wasn't in there because it's such a complicated word. But that idea is the fundamental, underlying thing that's going on there. And it is conceptually somewhat complicated, but if you don't try and think about the category theory behind it, and you're just like, well, I want to do a bunch of stuff, and it may fail at any point, and I want to return either a success message with everything having gone well or an error message at the point that it failed and stopped processing, then that's what this thing does, and it's fantastic at it. STEPH: Okay, cool. Thank you. CHRIS: You are welcome. And I think there's a bit more in the previous episode as well. So if that sounded interesting to anyone, I think I rambled more in a previous episode about it and probably better because I feel like I was more prepared that time than this time. STEPH: Well, along those lines of running a process and then being able to fail at any moment, I'm going to circle back to that other topic that I highlighted where most of my week has been focused on writing a task that is processing a CSV, something probably a number of us have done at some point in our career but processing a number of rows, and then sending and queuing jobs to then send data to a third party system. And it was really interesting less so because of the processing of the CSV and then enqueuing jobs. But it was more of the reporting that went behind it and the process that went into writing this task. So Joël and I were pairing on this task. Joël being another thoughtboter and also a former guest on this show. And we had an interesting process of where we started with one, let's do the simplest thing. Let's get it done. Let's also check through the CSV because you're often going to find stuff that doesn't align with what you expect it to when it's a CSV that's provided from an external source. One of the risks that we highlighted right away was how are we going to get the CSV on the server? Because we just have this one CSV that we need to run. We don't want to add it to the repo, and we can't generate it ourselves. So how are we actually going to get the CSV in a place that we can run this in a production mode? I learned that I could pass a CSV as standard input into the Rake task. So then I could actually run it locally because we're using AWS. So I could inform AWS to run this task, but then I could actually stream the CSV into the task that way. And that was really nice because then we no longer had the question of how are we going to get this file on the server? CHRIS: That's interesting. I didn't know...Yeah, the streaming of it from local to remote is an interesting one. On Heroku, I will typically open up a bash prompt, so Heroku run bash. And then, I will curl the file down onto the server and then run it locally. But that’s an ephemeral dyno. It may die at any point. There are various things that could go wrong there. So that's always interesting. I imagine a similar thing could be done, but I don't know, actually, if you can directly stream into a Heroku dyno like that, which is an even more straightforward one because I end up having to bounce a file off of a random. Like, I'll often put it in a Gist or a Pastebin or something like that. And then I'll curl it down to the server, and yeah, this is interesting. STEPH: Yeah, I'm also not sure the specifics of how it would work with Heroku. But it was a really nice process for us to be able to use versus having to then read the file from, like you mentioned, curl it from somewhere else and then be able to parse it that way. Two other things that were top of mind for working on this task is one, idempotency. You're going to rerun it, friends. At some point, your task is either going to bomb, and it's going to err. And then you're going to have to triage and run it again. Or whoever requested that you run this task and they said, “Oh, it's just temporary. We're just going to run the once,” that's not true. You're going to run it again. So keep in mind how to make that safe, that you can rerun it. And then that won't be its own scenario that then you have to triage and figure out. CHRIS: Idempotency is one of those critical ideas, and I just wish the word were different. I feel ridiculous every time I say it. And I feel like I have to push my glasses up on my nose, and I'm like, well, have we considered idempotency for this? But it's such a good idea. And it's the sort of thing that...you're totally right. Every time you're doing this sort of thing, it is something that you should consider. And we use GET requests, and they have rules about it. And it's such a good idea and such an important idea. And I just wish the word were different so that I felt more comfortable using it in polite conversation. STEPH: [laughs] I don't know why… and this may be sharing too much of myself. But the song Under Pressure by Queen and David Bowie the Under Pressure song has been in my head. But I've been replacing the under pressure part with idempotent. So it's [singing] under pressure, and I've been [singing] idempotent. [laughter] And that has just been my song for the week. CHRIS: You've normalized it enough for me now that I'll just hear you singing it every time, and I'll be like, this is a nonsense word. We're fine. We can just go – [laughs] STEPH: That's what I'm here for, to turn technical terms into nonsense. [laughs] CHRIS: It's really what this show is about at the end of the day. So you are our hero. STEPH: I just have to work on more lyrics for the song. I really just have that one line, that one hook. [laughs] CHRIS: Now I just want to scrap the rest of the episode and just come up with lyrics to idempotent. [chuckles] But maybe we don't do that. STEPH: [laughs] CHRIS: Maybe that'll be after the credits B-roll, something like that. STEPH: The other way I do phrase that question is I'm like, what happens when it fails? And that always feels like a safe way. Because if I ask someone like, “Hey, is the idempotent?” It feels more natural for people to be like, “Oh, it's fine. It doesn't need to be.” But if you say, “What happens when it fails?” It's harder for someone to say, “Oh, it's never going to fail. [laughs] There is nothing that could go wrong.” So it feels like a more intentional question in regards to how are we going to handle this when we need to rerun it? The other part that really came in handy was the fact that we spent more time on the reporting as well. So we really wanted to know what happened when we are processing all of these rows. So were there any invalid rows? And if we do encounter an invalid row, do we want to just stop processing and stop right there, or do we want to keep moving? Do we have any rows that didn't match, a row in our database, and how do we capture those? And because it's idempotent, maybe we want to capture skipped rows so then that way when we rerun it, we can see okay, well, we skipped, you know, a thousand rows because we'd already run them before. And all of that reporting has been so handy because we're also using this to triage. Like, hey, we're sending a bunch of messages to this third-party system. We reach out to that third-party group, and we say, “Hey, we sent you all of this. This is how it went. Let us know how it went on your end.” And then, we can have a more collaborative discussion around what happened on their end versus what happened on our end, and then we can make tweaks to each system. So overall, it felt more of that run-of-the-mill task where you're going to write a Rake task, you're going to parse a CSV. But something about the reporting really resonated with me because in the past, when I've written Rake tasks, I've leaned more on the this is temporary, so it's okay if it's not great. But the reporting has been so crucial that from now on, I always want reporting from any Rake tasks that I run, and I want to know what happened. And then I also want to be able to rerun it. And I'm very wary of any time that someone says, “Oh, this is temporary,” because then I also think that leads to interesting discussions around testing. Because initially, when we started this, we were under some pressure. Hey, that goes back to my song. We were under some pressure for writing this particular task. And then the question came up: do we want to test it? And to be frank, testing a Rake task isn't great; it’s not fun, which is one of the reasons we get out of a Rake task as quickly as possible and put it into a class. So that was also one of the drivers or one of the conversations that went against, like, oh, this is temporary. So it's okay if it's not the best code. It's okay if it's not tested. And then I was more of an advocate for, like, well, I don't feel good about this. And I'm rerunning the Rake task every time I want to confirm that the changes that I've made are correct. And so once I hit that manual labor point where I'm like, okay, I'm testing this. I just don't have automated tests for this, that then I actually started adding test coverage around it. CHRIS: I'm so excited that we have transcripts, particularly for that last minute that you were just talking about, because I feel like that was a mini master class in software development. And more generally, there's been almost like a poetic something to the two different topics that you’ve brought up today are the sort of mundane, very real things that actual software development is made almost entirely of. It's not often that we're just starting with a greenfield app and building a new thing. I happen to be doing that this week, but it's rare. It's going to be over very soon. And then I'm going to be in the world of oh; we have to backfill a bunch of data. How are we going to do that? Or we have this portion of the code that, frankly, we should have been testing more, but we didn't. How do we deal with that? And these murky, gray areas where there isn't a clear answer and you have to go with intuition, and you have to...a bunch of the things that you just listed as these good heuristics that you have around how you think about software. I'm just really excited for the transcript to that because that was awesome. STEPH: I'm so glad you enjoyed it because I think it's not until right now where I'm processing this and talking about it with you that it is...I was trying to think earlier, like, why is this so interesting? Why am I so excited to bring this here to this conversation? And I think it is for the reasons exactly that you said, that it does feel like one of these...this is a mundane task. We write a task; we process some things; we send some data. We do that all the time. But then it's all the other bits around it, and the other ways that we've been bitten, and how we avoid those scenarios, and then how we identify a risk like when someone says, “Oh, it's temporary. It's fine.” That part, I think, is always the very interesting aspect of writing software. CHRIS: Do you consider this sort of stuff the distraction from the work or actually the work? And in my experience, this makes up a lot of the work. And treating it like what you were saying about testing like, “Yeah, that thing where you're telling me that it's going to be temporary and we probably don't need to test it, I've been told that before,” and I just want to spot-check that real quick. Or what you said of the when I was manually testing, and I crossed a threshold where I'd done that enough, that now adding a test harness around that totally makes sense. It's worth the investment at that point. Those little heuristics that we build up over time are the things that are hard to get. And so, yeah, I love that conversation. STEPH: I really like how you also asked and then responded to that question around is this distraction, or is this the work? And I am wholeheartedly with you that this is the work. This is the part of the work that I do find interesting, and knowing when to make those trade-offs, and when you've hit a decision point, and which direction you're going to go, and being able to recognize something that otherwise could have been a fire. It could have been much worse in terms of if we'd built a task that wasn't robust. Because of course, then the second time that I ran it, you know, emphasis on the second time that I ran it because we needed to do it again to process more data. It erred halfway through, and I panicked in the moment. But then I was like, oh yeah, this is fine. We planned for this. This was in the game plan. So it goes back to that we want the calm execution. We want to plan so we are back in that calm state. We want calm software. And this feels very in line with how do we make this more calm? CHRIS: I love that theme that you're bringing up there, which I think is a theme that we've touched on a bunch of times. I think we actually have an episode called Seeking Calm. And I think that little title there, as much as I love the nonsense titles that we have for most of the episodes, that one I think really captures the theme that a lot of what we talk about is in orbit around yeah, we want it to be calm. We don't want things to be on fire every day. And what does it look like to build software with that in mind? STEPH: Yeah. I also love that theme. And I like that it's something that we have surfaced and then really stuck to because it resonates deeply with me. But that's pretty much all I have for my Rake task adventure. What else is new in your world? CHRIS: Well, I have one more hopefully quick thing. I'm going to try and boil this down to its essence, but I ran into, let's call it, a subtlety. It's not an issue. It wasn't a bug per se. But looping back to the previous episode that you and I recorded together, we talked a bunch about multi-step forms, which was a great conversation in and of itself. But I eventually completed the feature that I was working on, put it up for acceptance. And the product manager who was reviewing it highlighted a couple of different things. They recorded a video which, as an aside, I love that as a way to do acceptance and show what's going on and talk through it. There were a couple of smaller issues, which I was able to resolve very quickly, but there was one more interesting one that I've extracted this as future work because it was too complex to try and solve in the moment. But basically, what's happening is imagine that we have a two-step form. So there's the first page of the form. The first form that you see is for your name. So it's just an input that says, “Name,” and you fill in your name and then you hit continue. That posts to the server. We save off that data. And then, we redirect you to the next page on the form, which is, say, phone number. So two steps. We start with name; we go to phone number. What happens if you type in your name, you hit continue, everything processes correctly. You end up on the phone number page, but you hit back. What do you think happens? STEPH: I would expect to go back to the name field and probably expect my name to be populated but would also be fine if it's not. CHRIS: I like that you would be fine with the fact that it's not, if it's not, because it's not is the answer. And what's unfortunate is so if someone goes back, they will see the unpopulated form, so not filled out. But if they reload at that point, we will serialize down the value and pre-fill the input with their saved data. And so that inconsistency is not great. It's all the more unfortunate because as I tried to resolve it, I'm like, oh, okay, this feels like a solvable thing. I just need to tell Chrome, “Hey, if someone hits the back button, do a better thing than what you're doing.” I needed a way to instruct Chrome or whichever browser because this should be a standards-level thing. And there are things in the HTTP spec about this. So there's the Cache-Control Header is one of the headers that you can send down with a response. And there's a bunch of different values that can be in there, no-cache, no-store. There's also the…I want to say it's the max-age, or I think it's Expires. That's a different header. But you can set it to have an expiry that's just already expired. There's also a Pragma, which you can say no-cache. Some of these are standard. Some of these are not standard. Chrome ignores all of them. Chrome’s just like, “Nevermind.” So the idea is that those headers are intended to inform intermediate proxies. Say you have a caching layer, so you're using Fastly or CloudFront or something like that. When that service fetches the page from your backend, from your actual, say, Rails app, then it will look at that header and say, “Should I hold onto this for a little while or not? Is it public, or is it private? What should I do as an intermediate caching proxy?” Ideally, Chrome would also look at those and say, like…there should be a version of me being able to tell Chrome, “Listen, if someone hits the back button, please go to the server and ask for it.” Like, I'll take the second of latency that that introduces in navigating back because I always want to show them the correct data. Unfortunately, I have not found a way to do that. There's a bunch of things on Stack Overflow and other places of JavaScript solutions where I can listen to the window.popstate event and then force location.reload. But that feels like a pile of hacks that I don't want to get into. It feels like it will be very inconsistent between browsers. So I am still searching for a solution. But I would like to figure something out here. As a more pointed version of this to try and explain an example where this could happen, imagine that you've got the header of your application, and in it, you have a sign-out button. And so that sign out is going to delete to the session's endpoint. So you're deleting your session. And after that, you get redirected to the login form. If you then hit back, you will be taken back to the browser’s cached version of the previous logged-in state page that you were at. This is probably fine in a lot of cases. If you reload, you can't do any nefarious action at that point because you are logged out. But you are seeing potentially sensitive information. So imagine that you log in in a cafe, you go through Gmail, or whatever, or your bank, then you log out, you walk away. If you leave that page up and someone hits back, they can now see what was on the page. And part of that particular version, I read a bunch of backstory about that on the Inertia repo because someone posted this as an issue against Inertia as a framework. And the Inertia team...and I really love how they handle these sorts of things. So they were very kind, very welcoming to the issue but also said, “Actually, we're doing...like, this isn't us. But let's talk about it,” and gave a ton of detail and went through the HTTP spec. And it's a fantastic issue as a read. It's like a fun bedtime reading sort of thing to learn about how the internet works. But the Inertia crew really, really cares about being spec-compliant and doing the right thing. So, unfortunately, this is outside of their purview as well. But yeah, I don't have a solution, and it makes me sad. STEPH: I liked that second example that you provided because I feel like I see that one more commonly when I'm on an application, and I don't know why. But I hit back, and then it shows that I'm signed in, and I'm like, that's a lie, I'm not signed in. I also really appreciate how Inertia is responding so kindly and welcoming to folks and then providing such thoughtful responses. That sounds immensely helpful. I don't know, yeah, I am also interested in this. It's something that I haven't worked with in a while, so I don't have any grand ideas at the moment. So I'm also curious if other people have run into this and how they've approached it. CHRIS: Yeah. If we're being honest, partly I wanted to share this with you, but also I wanted to say this into a microphone, and then hopefully someone out there on the internet knows an answer. I've tried, I think, all of the normal things, all of the different variations of headers. I haven't actually poked at the JavaScript things yet, but that's probably the direction I'm going. But if anyone out there has an idea, I would absolutely love it. I think in my mind, the ideal version of this is if I'm making GET requests and I'm clicking around on a page, it's perfectly fine for Chrome to use its cache version of the previous page because, sure, that's fine. It may actually be stale just based on it's been a few seconds, and something's changed on the server, but I'm willing to accept that. But if I've posted, or patched, or deleted, or done any action that by definition should be changing data on the server, then I would love for a way to invalidate Chrome's back cache, so its version of the pages that it's restoring when I'm hitting back. I'd love that as the heuristic to get to. I don't know if I can get there. My sense says chrome’s like, “No, I want to go fast. That's all I care about.” [chuckles] I’m like, all right. Well, I get that vibe but -- STEPH: Yeah, that’s a nice, succinct way to say that if I've changed data, then I want to invalidate that browser cache, so then we don't show them a fresh page and we actually show them the name that they entered on the form. CHRIS: As we know, though, cache invalidation is one of the very easy things to do in software development. So I'm sure my naive, quick idea is very easy to implement and will have no edge cases of its own. STEPH: Well, this will be our parallel Pixar movie. We have one that we highlighted earlier, and this will be the other one, The Cache Buster. I'm not great with titles. [laughs] This will be our other Pixar movie. CHRIS: Buster the Lonely Cache. Yep. STEPH: All right. Well, in parallel, we'll work on Buster the Lonely Cache. Is that the name of this? CHRIS: Yep. STEPH: Cool. We'll work on that script. And in the meantime, I'll also think about it if I encounter this or come up with some ideas and share them with you. And then also if other people have any ideas, that'd be fantastic. CHRIS: That would be fantastic. STEPH: Yes. Please write in to help Buster with the lonely cache, which, wait; I don't get it. Why is it the lonely cache? CHRIS: Because the cache has been busted and evicted. So he's got no friends. There's nothing...There's no data left. I don't know. STEPH: [laughs] CHRIS: I came up with it real quick. I don't stand by it. It's not a great idea, but we'll workshop it. It'll be fine. STEPH: That's true. Yeah, we'll go through it. I'm asking too many questions for a very quick creative. We're in the creative space, not the critical space. But please write in to help Buster figure out [laughs] the lonely cache or how to bust the cache. Oh, goodness. I'm done with my jokes for today. I'll try to stop. CHRIS: I believe that's a perfect note. Shall we wrap up? STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I’m @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Support The Bike Shed

Nate Berkopec is the author of the Complete Guide to Rails Performance, the creator of the Rails Performance Workshop, and the co-maintainer of Puma. He talks with Steph about being known as "The Rails Speed Guy," and how he ended up with that title, publishing content, working on workshops, and also contributing to open source projects. (You could say he's kind of a busy guy!) Speedshop Puma The Rails Performance Workshop The Complete Guide to Rails Performance How To Use Turbolinks to Make Fast Rails Apps Sidekiq Follow Nate Berkopec on Twitter Visit Nate's Website Sign up for Nate's Speedshop Ruby Performance Newsletter Transcript: STEPH: All right. I'll kick us off with our fancy intro. 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 this week, Chris is taking a break. But while he's away, I'm joined by Nate Berkopec, who is the owner of Speedshop, a Ruby on Rails performance consultancy. And, Nate, in addition to running a consultancy, you're the co-maintainer of Puma. You're also an author as you wrote a book called The Complete Guide to Rails Performance. And you run the workshop called The Rails Performance Workshop. So, Nate, I'm sensing a theme here. NATE: Yeah, make code go fast. STEPH: And you've been doing that for quite a while, haven't you? NATE: Yeah. It's pretty much been since 2015, or so I think. It all started when I actually wrote a blog post about Turbolinks that got a lot of pick up. My hot take at the time was that Turbolinks is actually a good thing. That take has since become uncontroversial, but it was quite controversial in 2015. So I got a lot of pick up on that, and I realized I liked working on performance, and people seem to want to hear about it. So I've been in that groove ever since. STEPH: When you started down the path of really focusing on performance, were you running your own consultancy at that point, or were you working for someone else? NATE: I would say it didn't really kick off until I actually published The Complete Guide to Rails Performance. So after that came out, which was, I think, March of 2016…I hope I’m getting that right. It wasn't until after that point when it was like, oh, I'm the Rails performance guy now. And I started getting emails inbound about that. I didn't really have any time when I was actually working on the CGRP to do that sort of thing. I just made that my full-time job to actually write, and market, and publish that. So it wasn't until after that that I was like, oh, I'm a performance consultant now. This is the lane I've driven myself into. I don't think I really had that as a strategy when I was writing the book. I wasn't like, okay, this is what I'm going to do. I'm going to build some reputation around this, and then that'll help me be a better consultant with this. But that's what ended up happening. STEPH: I see. So it sounds like it really started more as a passion and something that you wanted to share. And it has manifested to this point where you are the speed guy. NATE: Yeah, I think you could say that. I think when I started writing about it, I just knew...I liked it. I liked the work of performance. In a lot of ways, performance is a much more concrete discipline than a lot of other sub-disciplines of programming where I joke my job is number go down. It's very measurable, and it's very clear when you've made a difference. You can say, “Hey, this number was this, and now it's this. Look what I did.” And I always loved that concreteness of performance work. It makes it actually a lot more like a real kind of engineering discipline where I think of performance engineering as clarifying requirements and the limitations and then building a project that meets the requirements while staying within those limitations and constraints. And that's often not quite as clear for other disciplines like general feature work. It's kind of hard to say sometimes, like, did you actually make the user's life better by implementing such and such? That's more of a guess. That's more of a less clear relationship. And with performance, nobody's going to wake up ten years from today and wish that their app was slower. So we can argue about the relative importance of performance in an application, but we don't really argue about whether or not we made it faster because we can prove that. STEPH: Yeah. That's one area that working with different teams (as I tend to shift the clients that I'm working with every six months) where we often push hard around feature work to say, “How can we measure this? How can we know that we are delivering something valuable to users?” But as you said, that's really tricky. It's hard to evaluate. And then also, when you add on the fact that if I am leaving that project in six months, then I don't have the same insights to understand how something went for that team. So I can certainly appreciate the satisfaction that comes from knowing that, yes, you are delivering a faster app. And it's very measurable, given the time that you're there, whether it's a short time or if it's a long time that you're with that team. NATE: Yeah, totally. My consulting engagements are often really short. I don't really do a lot of super long-term stuff, and that's usually fine because I can point to stuff and say, “Yep. This thing was at A, and now it's at B. And that's what you hired me to do, so now it's done.” STEPH: I am curious; given that you have so many different facets where you are running your consultancy, you are also often publishing a lot of content and working on workshops and then also contributing to open source projects. What does a typical week look like for you? NATE: Well, right now is actually a decent example. I have client work two or three days a week. And I'm actually working on a new product right now that I'm calling Sidekiq in Practice, which is a course/workshop about scaling Sidekiq from zero to 1000 jobs per second. And I'll spend the other days of the week working on that. My content is...I always struggle with how much time to spend on blogging specifically because it takes so much time for me to come up with a post and publish that. But the newsletter that I write, which I try to write two once a week, I haven't been doing so well with it lately. But I think I got 50 newsletters done in 2020 or something like that. STEPH: Wow. NATE: And so I do okay on the per-week basis. And it's all content I've never published anywhere else. So that actually is like 45 minutes of me sitting down on a Monday and being like rant, [chuckles] slam keyboard and rant and then hit send. And my open source work is mostly 15 minutes a day while I'm drinking morning coffee kind of stuff. So I try to spread myself around and do a lot of different stuff. And a lot of that means, I think, pulling back in terms of thinking how much you need to spend on something, especially with newsletters, email newsletters, it was very easy to overthink that and spend a lot of time revising and whatever. But some newsletter is better than no newsletter. And especially when it comes to content and marketing, I've learned that frequency and regularity is more important than each and every post is the greatest thing that's ever come out since sliced bread. So trying to build a discipline and a practice around doing that regularly is more important for me. STEPH: I like that, some newsletter is better than no newsletter. I was listening to your chat with Brittany Martin on the Ruby on Rails podcast. And you said something very honest that I appreciated where you said, “Writing is really hard, and writing sucks.” And that made me laugh in the moment because even though I do enjoy writing, I still find it very hard to be disciplined, to sit down and make it happen. And then you go into that editor mode where you critique everything, and then you never really get it published because you are constantly fixing it. It sounds like...you've mentioned you set aside about 45 minutes on a Monday, and you crank out some work. How do you work through that inner critic? How do you get past it to the point where then you just publish? NATE: You have to separate the steps. You have to not do editing and first drafting at the same time. And the reason why I say it sucks and it's hard is because I think a lot of people don't do a lot of regular writing, maybe get intimidated when they try to start. And they're like, “Wow, this is really hard. This is not fun.” And I'm just trying to say that's everybody's experience and if it doesn't get any better, because it doesn't, [chuckles] there's nothing wrong with you, that's just writing, it's hard. For me, especially with the newsletter, I just have to give myself permission not to edit and to just hit send when I'm done. I try to do some spell checking,, and that's it. I just let it go. I'm not going back and reading it through again and making sure that I was very clear and cogent in all my points and that there's a really good flow through that newsletter. I think it comes with a little bit of confidence in your own ideas and your own experience and knowledge, believing that that's worth sharing and that's worth somebody's time, even if it's not a perfect expression of what's in your head. Like, a 75% expression is good enough, especially in a newsletter format where it's like 500 to 700 words. And it's something that comes once a week. And maybe not everyone's amazing, but some of them are, enough of them are that people stay subscribed. So I think a combination of separating editing and first drafting and just having enough confidence and the basis where you have to say, “It doesn't have to be perfect every single time.” STEPH: Yeah, I think that's something that I learned a while back to apply to my coding process where I had to separate those two steps of where I have to let the creator in me just create and write some code and make it work, and then come back to the editing process, and taking a similar approach with writing. As you may be familiar with thoughtbot, we're big advocates when it comes to sharing content and sharing things that we have learned throughout the week and different projects that we're working on. And often when people join thoughtbot, they're very excited to contribute to the blog. But it is daunting for that first post because you think it has to be this really grand novel. And it has to be something that is really going to appeal to everybody, and it's going to help everyone. And then over time, you learn it's like, oh well, actually it can be this very just small thing that I learned that maybe only helps 20 people, but it still helped those 20 people. And learning to publish more frequently versus going for those grand pieces is more favorable and often more helpful for people. NATE: Yeah, totally. That's something that is difficult for people at first. But everything in my experience has led me to believe that frequency and regularity is just as, if not more important than the quality of any individual piece of content that I put out. So that's not to say that...I guess it's weird advice to give because people will take it too far the other way and think that means he's saying quality doesn't matter. No, of course, it does, but I think just everyone's internal biases are just way too tuned towards this thing must be perfect. I've also learned we're just really bad judges internally of what is useful and good for people. Stuff that I think is amazing and really interesting sometimes I'll put that out, and nobody cares. [chuckles] And the other stuff I put out that's just like the 45-minute banging out newsletter, people email me back and say, “This is the most helpful thing anyone’s ever read.” So that quality bias also assumes that you know what is good and actually we're not really good at that, knowing every time what our audience needs is actually really difficult. STEPH: That's totally fair. And I have definitely run into that too, where I have something that I'm very proud of and excited to share, and I realize it relates to a very small group of people. But then there's something small that I do every day, and then I just happen to tweet about it or talk about it, and suddenly that's the thing that everybody's really excited about. So yeah, you never know. So share it all. NATE: Yeah. And it's important to listen. I pay attention to what people get interested in from what I put out, and I will do more of that in the future. STEPH: You mentioned earlier that you are working on another workshop focused on Sidekiq. What can you tell me about that? NATE: So it's meant to be a guide to scaling Sidekiq from zero to 1000 requests per second. And it's meant to be a missing guide to all the things that happen, like the situations that can crop up operationally when you're working on an application that does a lot of work with Sidekiq. Whereas Mike Sidekiq, Wiki, or the docs are great about how do, you do this? What does this setting mean? And the basics of getting it just running, Sidekiq in practice, is meant to be the last half of that. How do you get it to run 1,000 jobs per second in a day-to-day application? So it's the collected wisdom and collected battle scars from five years of getting called in to fix people's Sidekiq installations and very much a product of what are the actual problems that people experience, and how do you fix and deal with those? So stuff about memory and managing Sidekiq memory usage, how to think about queues. Like, what should your queue structure be? How many should you have? Like, how do you organize jobs into queues, and how do you deal with problems like some client is dropping 10,000, 20,000 jobs into a queue. And now the other jobs I put in that queue have 20,000 jobs in front of them. And now this other job I've got will take three hours to get through that queue. How do you deal with problems like that? All the stuff that people have come to me over the years and that I've had to help them fix. STEPH: That sounds really great. Because yeah, I find that teams who are often in this space with Sidekiq we just let it run until there's a fire. And then suddenly, we start to care as to how it's processing, and we care about our queue structure and how many workers that we have that are pulling from that queue. So that sounds really helpful. When you're building a workshop, do you often go back to any of those customers and pull more ideas from them, or do you find that you just have enough examples from your collective work with clients that that itself creates a course? NATE: Usually, pretty much every chapter in the workshop I've probably implemented like three-plus times, so I don't really have to go back to any individual customer. I have had some interesting stuff with my current client, Gusto. And Gusto is going through some background job reorganization right now and actually started to implement a lot of the things that I'm advocating in the workshop actually without talking to me. It was a good validation of hey, we all actually think the same here. And a lot of the solutions that they were implementing were things that I was ready to put down into those workshops. So I'd like to see those solutions implemented and succeed. So I think a lot of the stuff in here has been pretty battle-tested. STEPH: For the Rails Performance Workshop, you started off doing those live and in-person with teams, and then you have since switched to now it is a CLI course, correct? NATE: That's correct. Yep. STEPH: I love that very much. When you’ve talked about it, it does feel very appropriate in terms of developers and how we like to consume content and learn. So that is really novel and also, it seems like a really nice win for you. So then other people can take this course, but you are no longer the individual that has to deliver it to their team, that they can independently take the course and go through it on their own. Are you thinking about doing the same thing for the Sidekiq course, or what are your plans for that one? NATE: Yeah, it's the exact same structure. So it's going to be delivered via the command line. Although I would say Sidekiq in practice has more text components. So it's going to be a combination of a very short manual or book, and some video, and some hands-on exercises. So, an equal blend between all three of those components. And it's a lot of stuff that I've learned over having to teach; I guess intermediate to advanced programming concepts for the last five years now that people learn at different paces. And one of the great things about this kind of format is you can pick it up, drop it off, and move at your own speed. Whereas a lot of times when I would do this in person, I think I would lose people halfway through because they would get stuck on something that I couldn't go back to because we only had four hours of the day. And if you deliver it in a class format, you're one person, and I've got 24 other people in this room. So it's infinitely pausable and replayable, and you can go back, or you can just skip ahead. If you've got a particular problem and you're like, hey, I just want to figure out how to fix such and such; you can do that. You can just come in and do a particular thing and then leave, and that's fine. So it's a good format that way. And I've definitely learned a lot from switching to pre-recorded and pre-prepared stuff rather than trying to do this all live in person. STEPH: That is one of the lessons that I've learned as well from the couple of workshops that I've led is that doing them in person, there's a lot of energy. And I really enjoy that part where I get to see people respond to the content. And then I get a lot of great feedback from people about what type of questions they have, where they are getting stuck. And that part is so important to me that I always love doing them live first. But then you get to the point, as you'd mentioned, where if you have a room full of 20 people and you have two people that are stuck, how do you help them but then still keep the class going forward? And then, if you are trying to tailor this content for a wide audience…so maybe beginners could take the Rails Performance Workshop, or they could also take the Sidekiq course. But you also want the more senior engineers to get something out of it as well. It's a very challenging task to make that content scale for everyone. NATE: Yeah. What you said there about getting feedback and learning was definitely something that I got out of doing the Rails Performance Workshop in person like three dozen times, was the ability to look over people's shoulders and see where they got stuck. Because people won't email me and say, “Hey, this thing is really confusing.” Or “It doesn't work the way you said it does for me.” But when I'm in the same room with them, I can look over their shoulder and be like, “Hey, you're stuck here.” People will not ask questions. And you can get past that in an in-person environment. Or there are even certain questions people will ask in person, but they won't take the time to sit down and email me about. So I definitely don't regret doing it in person for so long because I think I learned a lot about how to teach the material and what was important and how people...what were the problems that people would encounter and stuff like that. So that was useful. And definitely, the Rails Performance Workshop would not be in the place that it is today if I hadn't done that. STEPH: Yeah, helping people feel comfortable asking questions is incredibly hard and something I've gone so far in the past where I've created an anonymous way for people to submit questions. So during class, even if you didn't want to ask a question in front of everybody, you could submit a question to this forum, and I would get notified. I could bring it up, and we could answer it together. And even taking that strategy, I found that people wouldn't ask questions. And I guess it circles back to that inner critic that we have that's also preventing us from sharing knowledge that we have with the world because we're always judging what we're going to share and what we're going to ask in front of our peers who we respect. So I can certainly relate to being able to look over someone's shoulder and say, “Hey, I think you're stuck. We should talk. Let me walk you through this or help you out.” NATE: There are also weird dynamics around in-person, not necessarily in a small group setting. But I think one thing I really picked up on and learned from RailsConf2021 which was done online, was that in-person question asking requires a certain amount of confidence and bravado that you're not...People are worried about looking stupid, and they won't ask things in a public or semi-public setting that they think might make them look dumb. And so then the people that do end up asking questions are sometimes overconfident. They don't even ask a question. They just want to show off how smart they are about a particular issue. This is more of an issue at conferences. But the quality of questions that I got in the Q&A after RailsConf this year (They did it as Discord chats.) was way better. The quality of questions and discussion after my RailsConf talk was miles better than I've ever had at a conference before. Like, not even close. So I think experimenting with different formats around interaction is really good and interesting. Because it's clear there's no perfect format for everybody and experimenting with these different settings and different methods of delivery has been very useful to me. STEPH: Yeah, that makes a ton of sense. And I'm really glad then for those opportunities where we're discovering that certain forums will help us get more feedback and questions from people because then we can incorporate that and to future conferences where people can speak up and ask questions, and not necessarily be the one that's very confident and enjoys hearing their own voice. For the Rails Performance Workshop, what are some of the general things that you dive into for that workshop? I'm curious, what is it like to attend that workshop? Although I guess one can't attend it anymore. But what is it like to take that workshop? NATE: Well, you still can attend it in some sense because I do corporate bookings for it. So if you want to buy 20 seats, then I can come in and basically do a Q&A every week while everybody takes the workshop. Anyway, I still do that. I have one coming up in July, actually. But my overall approach to performance is to always start with monitoring. So the course starts with goals and monitoring and understanding where you want to go and where you are when it comes to performance. So the first module of the Rails Performance Workshop is actually really a group exercise that's about what are our performance requirements and how can we set those? Both high-level and low-levels. So what is our goal for page load time? How are we going to measure that? How are we going to use that to back into lower-level metrics? What is our goal for back-end response times? What is our goal for JavaScript bundle sizes? That all flows from a higher-level metric of how fast you want the page to load or how fast you want a route to change in a React app or something, and it talks about those goals. And then where should you even start with where those numbers should be? And then how are you going to measure it? What are the browser events that matter here? What tools are available to help you to get that data? Because without measurement, you don't really have a performance practice. You just have people guessing at what stuff is faster and what is not. And I teach performance as a scientific process as science and engineering. And so, in the scientific method, we have hypotheses. We test those hypotheses, and then we learn based on those tests of our hypotheses. So that requires us to A, have a hypothesis, so like, I think that doing X makes this faster. And I talk about how you generate hypotheses using profiling, using tools that will show you where all the time goes when you do this particular operation of your software—and then measuring what happens when you do that? And that's benchmarking. So if you think that getting rid of method X or changing method X will speed up the app, benchmarking tells you did you actually speed it up or not? And there are all sorts of little finer points to making sure that that hypothesis and that experiment is tested in a valid way. I spend a lot of time in the workshop yapping about the differences between development/local environments and production environments and which ones matter. Because what differences matter, it's not often the ones that we think about, but instead it's differences like actually in Rails apps the asset packaging and asset pipeline performs very differently in production than it does in development, works very differently. And it makes it one of the primary reasons development is slower than production, so making sure that we understand how to change those settings to more production-like settings. I talk a lot about data. It’s the other primary difference between development and production is production has a million users, and development has 10. So when you call things like User.all, that behavior is very different in production than it is locally. So having decent production-like data is another big one that I like to harp on in the workshops. So it's a process in the workshop of you just go lesson by lesson. And it's a lot of video followed up by hands-on exercises that half of them are pre-baked problems where I'm like, hey, take a look at this Turbolinks app that I've given you and look at it in DevTools. And here's what you should see. And then the other half is like, go work on your application. And here are some pull requests I think you should probably go try on your app. So it's a combination of hands-on and videos of the actual experience going through it. STEPH: I love how you start with a smaller application that everyone can look at and then start to learn how performant is this particular application that I'm looking at? Versus trying to assess, let’s say, their own application where there may be a number of other variables that they have to consider. That sounds really nice. You'd mentioned one of the first exercises is talking about setting some of those goals and perhaps some of those benchmarks that you want to meet in terms of how fast should this page load, or how quickly should a response from the API be? Do you have a certain set of numbers for those benchmarks, or is it something that is different for each product? NATE: Well, to some extent, Google has suddenly given us numbers to work with. So as of this month, I think, June 2021, Google has started to use what they're calling Core Web Vitals in their ranking of search results. They've always tried to say it's not a huge ranking factor, et cetera, et cetera, but it does exist. It is being used. And that data is based on Chrome user telemetry. So every time you go to a website in Chrome, it measures three metrics and sends those back to Google. And those three metrics are Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). And First Input Delay and Cumulative Layout shift are more important for your single-page apps kind of stuff. It's hard to screw those up with a Golden Path Rails app that just does Turbolinks or Hotwire or whatever. But Largest Contentful Paint is an easy one to screw up. So Google's line in the sand that they've drawn is 2.5 seconds for Largest Contentful Paint. So that's saying that from clicking on your website in a Google search result, it should take 2.5 seconds for the page to paint the largest component of that new page. That's often an image or a video or a large H1 tag or something like that. And that process then will help you to...to get to 2.5 seconds in Largest Contentful Paint; there are things that have to happen along the way. We have to download and execute all JavaScript. We have to download CSS. We have to send and receive back-end responses. In the case of a simple Hotwire app, it's one back-end response. But in the case of a single-page app, you got to download the document and then maybe download several XHR fetches or whatever. So there's a chain of events that has to happen there. And you have to walk that back now from 2.5 seconds in Largest Contentful Paint. So that's the line that I'm seeing getting drawn in the sand right now with Google's Core Web Vitals. So pretty much any meaningful web application performance metric can be walked back from that. STEPH: Okay. That's super helpful. I wasn't aware of the Core Web Vitals and that particular stat that Google is using to then rank the sites. I was going to ask, this kind of blends in nicely into when do you start caring about performance? So if you have a new application that you are just starting to get to market, based on the fact that Google is going to start ranking you right away, you do have to care some right out of the gate. But I am curious, when do you start caring more about performance, and are there certain tools and benchmarking that you want to have in place from day one versus other things that you'll say, “Well, we can wait until we have X numbers of users or other conditions before we add more profiling?” NATE: I'd say as an approach, I teach people not to have a performance strategy of monitoring. So if your strategy is to have dashboards and look at them regularly, you're going to lose. Eventually, you're not going to look at that dashboard, or more often, you just don't understand what you're looking at. You just install New Relic or Datadog or whatever, and you don't know how to turn a dashboard into actual action. Also, it seems to just wear teams out, and there's no clear mechanism when you just have a dashboard of turning that into oh, well, this has to now be something that somebody on our team has to go work on. Contrast that with bugs, so teams usually have very defined processes around bugs. So usually, what happens is you'll get an Exception Notification through Sentry or Bugsnag or whatever your preferred Exception Notification service is. That gets read by a developer. And then you turn that into a Jira ticket or a Kanban board or whatever. And then that is where work is done and prioritized. Contrast that with performance; there’s often no clear mechanism for turning metrics into stuff that people actually work on. So understanding at your organization how that's going to work and setting up a process that automatically will turn performance issues into actual work that people get done is important. The way that I generally teach people to do this is to focus instead of dashboards and monitoring, on alerts, on automated thresholds that get tripped and then sends somebody's an email or put something in the Kanban board or whatever. It just has to be something that automatically gets fired. Different tools have different ways of doing this. Datadog has pretty much built their entire product around monitoring and what they call monitors. That's a perfectly fine way to do it, whatever your chosen performance monitoring tool, which I would say is a required thing. I don't think there's really any good excuse in 2021 for not having a performance monitoring tool. There are a million different ways to slice it. You can do it yourself with OpenTelemetry and then like statsD, I don't know, or pay someone else like everyone else does for Datadog or New Relic or AppSignal or whatever. But you got to have one installed. And then I would say you have to have some sort of automated alerting. Now that alerting means that you've also decided on thresholds. And that's the hard work that doesn't get done when your strategy is just monitoring. So it's very easy to just install a dashboard and say, “Hey, I have this average page time load dashboard. That means I'm paying attention to performance.” But if you don't have a clear answer to what number is good and what number is bad, then that dashboard cannot be turned into real action. So that's why I push monitoring so hard is because it allows people to ignore performance is all that matters, and it forces you to make the decision upfront as to what number matters. So that is what I would say, install some kind of performance monitoring. I don't really care what kind. Nowadays, I also think there's probably no excuse to not have Real User Monitoring. So there's enough GDPR compliance Real User Monitoring now that I think everyone should be using it. So for industry terms, Real User Monitoring is just performance monitoring in the browser. So it's just users’ browser APIs and sends those back to you or your third-party provider, so having that so you actually are collecting back-end and front-end performance metrics. And then making decisions around what is bad and what is good. Probably everybody should just start with a page load time monitor, Largest Contentful Paint monitor. And if you've got a single-page app, probably hooking up some stuff around route changes or whatever your app...because you don't actually have page loads on every single time you navigate. You have to instrument whatever those interactions are. So having those up and then just drawing some lines that say, “Hey, we want our React route changes to always be one second or less.” So I will set an alert that if the 95th percentile is one second or more, I'm going to get alerted. There's a lot of different ways to do that, and everybody will have different needs there. But having a handful of automated monitors is probably a place to start. STEPH: I like how you also focus on once you have decided those thresholds and have that monitoring in place, but then how do you make it actionable? Because I have certainly been part of teams where we get those alerts, but we don't necessarily...what you just mentioned, prioritize that work to get done until we have perhaps a user complaint about it. Or we start actually having pages that are timing out and not loading, and then they get bumped up in the priority queue. So I really like that idea that if we agree upon those thresholds and then we get alerted, we treat that alert as if it is a user that is letting us know that a page is too slow and that they are unable to use our application, so then we can prioritize that work. NATE: And it's not all that dissimilar to bugs, really. And I think most teams have processes around correctness issues. And so, all that my strategy is really advocating for is to make performance fail loudly in the same way that most exceptions do. [chuckles] Once you get to that point, I think a lot of teams have processes around prioritization for bugs versus features and all that. And just getting performance into that conversation at least tends to make that solve itself. STEPH: I'm curious, as you're joining teams and helping them with their performance issues, are there particular buckets or categories of performance issues that are the most common in terms of, let's say, 50% of issues are SQL-related N+1 issues? What tends to be the breakdown that you see? NATE: So, when it comes to why something is slow in a Ruby application, I teach a method that I call DRM. And that doesn't have anything to do with actual DRM. It's just memorable because it reminds me of things I don't like. DRM stands for Database Ruby and Memory and in that order. So the most common issue is database, the second most common issue is issues with your Ruby code. The least common issue is memory. Specifically, I'm talking about allocation of objects, creating lots of objects. So probably 80% of your issues are in some way database-related. In Rails, it's 50% of those are probably N+1. And then 30% of database issues are probably what I would call unnecessary SQL. So it's not necessarily N+1, but it's a SQL query for information that you already had, or you could do in a more efficient way. So a common thing for unnecessary SQL would be people will filter an ActiveRecord::Collection like ten different ways when they could have just loaded the whole collection, filtered it with Ruby in the ten different ways afterwards, and that works really well if the collection that you're loading is like 10, 20. Turning that into one database query, plus a bunch of calls to innumerable methods is often way faster than doing that as ten separate database queries. Also, that tends to be a more robust approach. This doesn't happen in most companies, but what could happen is the database is like a shared resource. It's a resource that everybody is affected by. So a performance degradation to the database is the worst possible scenario because everything is affected. But if you screw up what's happening at an individual Rails process, then only that Rails process is affected. The blast radius is tiny. It's just that one request. So doing less stuff in the database while it can actually seem like, oh, that doesn't feel right. I'm supposed to do a lot of stuff in the database. It actually can reduce blast radiuses of performance issues because you're not doing it on this database that everyone has to have access to. There are a lot of areas of gray here. And I talk a lot in all my other material like why -- There's a lot of nuance here. So database is the main stuff. Issues in how you write your Ruby code is probably the other one. Usually, that's just what I would call code that goes bump in the night. It's code that you don't know is running but actually is. Profilers are what help us figure that out. So oftentimes, I'll have someone open up a profiler on their controller action for the first time. And they're like, wait a minute, I had no idea that such and such was running during this controller action, and actually, we don't need to do that at all. So why is it here? So that's the second most common issue. And then the third issue that really doesn't actually come up all that often is object allocation, numbers of objects that get created. So primarily, this is a problem in index actions or actions transactions that deal with big collections. So in Ruby, we often get overly focused on garbage collection, but garbage collection doesn't take any time if you just don't create objects. And object creation itself takes time. So looking at code through the lens of what object does this code create? And trying to get rid of those object allocations can often be a pretty productive way to make stuff faster. STEPH: You said a lot of amazing things there. So I'm debating on which one to follow up on. I think the one that stuck out to me the most where I have felt pain around this is you mentioned identifying code that goes bump in the night or code that is running, but it doesn't need to be run. And that is something that I've run into with applications where we have a code path that seems important, but yet I can't prove that it's being executed and exactly why it's there and what flow it's supporting. And I'm curious, do you have any tips or tricks in how you’ve helped teams identify that this code path isn't used and it's something that we can remove and then that itself will help speed up the performance of that particular endpoint? NATE: Like, there's no performance cost to like 100 models in an application that never actually get used. There's really no performance downside to code in an app that doesn't actually ever get run. But instead, what happens is code gets added into callbacks that usually is probably the biggest offender that’s like, always do this thing after you do X. But then, two years later, you don't always need to do that thing after you do X. So the callbacks always run, but sometimes requirements change, and they don't always need to be run. So usually, it's enough to just pop the profiler now on something. And I have people look at it, and they're like, “I don't know why any of this is happening.” Like, it's usually a pretty big Eureka moment once we look at a flame graph for the first time and people understand how to read those, and they understand what they're looking at. But sometimes there's a bit of a process where especially in a bigger app where it's like, “Such and such is running, and this was an entire other team that's working on this. I have no idea what this even does.” So on bigger apps, there's going to be more learning that has to get done there. You have to learn about other parts of the application that maybe you've never learned about before. But profiling helps us to not only see what code is running but also what that relative importance is. Like, okay, maybe this one callback runs, and you don't know what it does, and it's probably unnecessary. But if it only takes 1% of the total time to run this action, that's probably less important than something that takes 20% of total time. And so profilers help us to not only just see all the code that's being run but also to know where that time goes and what time corresponds to what parts of the code. STEPH: Yeah, that's often the code that makes me the most nervous is where it's code that I suspect is being run or maybe being run, but I don't understand why it's there and then figuring out if it can be removed and then figuring out ways to perhaps even log when a call is being made to that code to determine if it's truly in use or not or at least supported by a code path that a user is hitting. You have a blog post that I read recently that I really appreciated that talks about essentially gaming benchmarking where you talk about the importance of having context around benchmarks. So if someone says, “I've improved something where it is now 10% faster.” It's like, well, what is that 10% relative to? And if it's a tool that other people are using, what does that mean for them? Or did you improve something that was already very fast, and you made it 10% faster? Was that a really valuable use of your time? NATE: Yeah. You know, something that I read recently that made me think of that again was this Hacker News post that went viral. That was like, how I optimize an AWS EC2 instance to take 1.5 million requests per second on my JSON API. And out of the box, it was like 500 requests per second, and then he got it to 1.5 million. And the whole article was presented with relative numbers. So it was like, “I made this change, and things got 33% faster. And if you do the whole thing right, 500 to 1.5 million requests per second, it's like my app is three times faster now,” or whatever. And that's true, but it would probably be more accurate to say, “I've taken three-millionth of a second out of every request in my app.” That's two ways of saying the same thing because latency and throughput are just related that way. But it's probably more accurate and more useful to say the absolute number, but it doesn't make for great blog posts, so that doesn't tend to get said. The kinds of improvements that were discussed in this article were really, really low-level stuff. That was like if you turn off...I think it was like turn off iptables or something like that. And it's like, that shaves a microsecond off of every time we make a syscall or something. And that is useful if your performance goal is to serve 1.5 million requests per second Hello World responses off of my EC2 instance, which is what this person admittedly was doing. But there's a tendency to walk that back to if I do all things in this article, my application will be three times faster. And that's just not what the evidence says. It's not what you were told. So there's just a tendency to use relative numbers when absolute numbers would be more useful to giving you the context of like, oh, well, this will improve my app or it won't. We get this a lot in Puma. We get benchmarks that are like, hey, this thing is going to help us to do 50,000 requests per second in Puma instead of 10,000. And another way of saying that is you took a couple of nanoseconds off of the overhead of every single request to Puma. And most Puma applications have a hundred millisecond response time. So it's like, yeah, I guess it's cool that you took a nanosecond off, and I’m sure it's going to help us have cool benchmarks, but none of our users are going to care. No one that's used Puma is going to care that their requests are one nanosecond faster now. So what did we really gain here? STEPH: Yeah, it makes sense that people would want to share those more...I want to call them sparkly stats and something that catches your attention, but they're not necessarily something that's going to translate to us in the way that we hoped that they will in terms of it's not going to speed up our app 30% or have those same rewards or benefits. Speaking of Puma, how is it being a co-maintainer of Puma? And how do you balance that role with all of your other work? NATE: Actually, it doesn't take all that much of my time. I try to spend about 15 minutes a day on it. And that's really possible because of the philosophy I have around open-source maintenance. I think that open source projects are fundamentally about collaboration and about sharing our hard-fought extractions and fixes and knowledge together. And it's not about a single super contributor or super maintainer who is just out of the goodness of their heart releasing all of their incredible work and time into the public domain or into a free software license. Puma is a pretty popular piece of Ruby software, so a lot of people use it. And I have things on my back burner of if I ever got 20 hours to work on Puma, here’s stuff I would do. But there are a lot of other people that have more time than me to work on Puma. And they're just as smart, and they have other tools they've got in their locker that I don't have. And I realized that it was more important that I actually find ways to recruit and then unblock those people than it was for me to devote as much time as I could to Puma. And so my work on Puma now is really just more like management than anything else. It's more trying to recruit new contributors and trying to give them what they need to help Puma. And contributing to open source is a really fraught experience for a lot of people, especially their first time. And I think we should also be really conscious of that. Like, 95% of software developers have really never contributed to open source in a meaningful way. And that's a huge talent pool of people that could be helping us that aren't. So I'm less concerned about the problems of the 5% that are currently contributing than I am about why there are 95% of us that don't do anything. So that's what gets me excited to work on Puma now, is trying to change that ratio. STEPH: I really like that mindset of where you are there to provide guidance but then essentially help unblock others as they're making contributions to the project but then still be there to have the history and full context and also provide a path forward of a good direction for Puma to head. In regards to encouraging more people to contribute to open source projects, I've often heard people say how challenging that is, where they have an open-source project that they would really love people to contribute to but finding people is really hard or just letting people know that they're interested in contributions. Have you had any strategies that have been successful for you in encouraging people to contribute? NATE: Yeah. So first thing, the easiest thing is we have a contributing.md file. So that's something I think more projects should adopt is have an actual file in your project that says everything about how to contribute. Like, what kinds of contributions do you want? Different projects have different things that they want. Like, Rails doesn't want to refactor PRs. Don't send a refactor PR to Rails because they'll reject it. Puma, I'm happy to accept those. So letting people know like, “Hey, here's how we work here. Here's the community we're creating, and here's how it works. Here's how to get involved.” And I think of it as hanging out the shingle and saying, “Yes, I want your contributions. Here's how to do it.” That alone puts you a step above other projects. The second thing I would say is you need to have contributor-only communication channels. So we have Matrix chat. So Matrix is like this successor to IRC. So we have a chat channel basically, but it's like contributors only. I don't enforce that, but I just don't want support requests in there. I don't want people coming in there and being like, “My Puma config doesn't work.” And instead, it's just for people that want to contribute to Puma, and that want to help out. If you have a question and come in there, anyone can answer it. And then finally, another thing that I've had success with is doing one-on-one stuff. So I will actually...I have a Calendly invite that I think is in contributing.md now that you can just book 30 minutes with me anytime about contributing to Puma. And I will get on a Zoom call with you and talk to you about what are your concerns? Where do I think you can help? And I give my time away that way. The way I see it is like if I do that 20 times and I create one super contributor to Puma, that is worth more than me spending 10 hours on Puma because that person can contribute 100, 200, 1,000 hours over their lifetime of contributing to Puma. So that's actually a much more higher leverage contribution, really from my perspective. It's actually helping other people contribute more. STEPH: Yeah, that's huge to offer people to say, “Hey, you can book time with me, and I will walk you through and let you know where you can start making an impactful contribution right away,” or “Here are some areas that I think you'd be interested, to begin with.” That seems like such a nice onboarding for someone who says, “I'm interested, but I'm nervous,” or “I'm just not sure about where to get started.” Also, I love your complaint department voice for the person who their Puma config doesn't work. That was delightful. [chuckles] NATE: I think it's a little bit part of my open-source philosophy that, especially at a certain scale like Puma is at that we really kind of over-prioritize users. And I'm not really here to do support; I'm here to make the project better. And users don't actually contribute to open source projects. Users use the thing, and that's great. That's the whole reason we're open-sourcing is so more people use it. But it's important not to prioritize that over people who want to make the project better. And I think a lot of times; people get caught up in this almost clout chasing of getting the most GitHub stars that they think they need and users they think they need. And you don't get paid for having users, and the product doesn't get any better either. So I don't prioritize users. I prioritize the quality of the project and getting contributors. And that will create a better project, which will then create more users. So I think it's easy to get sidetracked by people that ask for your time when they're not giving anything back to the project in return. And especially at Puma’s scale, we have enough people that want my time or the time of other maintainers at Puma so that they can contribute to the project. And putting user support requests ahead of that is not good for the project. It's not the biggest, long-term value increase we could be making, so I don't prioritize them anymore. STEPH: Yep. That sounds like more the pursuit of sparkly stats and looking for all those GitHub stars or all of those likes. Well, Nate, if you're game, I have two listener questions that I'd like to run by you because I shared with some folks that you are going to be on The Bike Shed today. And they're very excited and have two questions that they'd like me to run by you. How does that sound? NATE: Yeah, all right. STEPH: So the first question is, are there any paradigms or trends in Rails that inherently hurt performance? NATE: Yeah. I get this question a lot, and I will preface it with saying that I'm the performance guy, and I'm not the software design guy. And I get a lot of questions about does such and such software design...how does that impact performance? And usually, there's like a way to do anything in a performant way. And I'm just here to help people to find the performant way and not to prescribe “You must always do X, Y, or Z,” or “ActiveRecord is bad. Never use it.” That's not my job here. And in my experience, there's a fast way to do almost anything. Now, one thing that I think is dying, I guess, or one approach or one common...I don't know what to call it. One common mistake that is clearly wrong is to not do any form of server-side rendering in a web application. So I am anti-client-side app. But there are ways to do that and to do it quickly. But rendering a basically blank document, which is what most of these applications will do when they're using Rails as a back-end…you'll serve this basically blank document or a document with maybe some Chrome in it. And then, the client-side app has to execute, compile JavaScript, make XHR requests, and then render the page. That is just by definition slower than serving somebody a server-side rendered page. Now, I am 100% agnostic on how you want to generate that server-side rendering. There are some people that are working on better ways to do that with Rails and client-side apps. Or you could just go the Hotwire Turbolinks way. And it's more progressive enhancement where the back-end is always just serving the server-side rendered response. And then you do some JavaScript on top of that. So I think five years from now, nobody will be doing this approach of serving blank documents and then booting client-side apps into that. Or at least it will be seen as outdated enough that you should never design a project that way anymore. It's one of those few things where it's like, yeah, just by definition, you're adding more steps into a rendering flow. That means, by necessity, it has to be slower. So I think everybody should be thinking about server-side rendering in their project. Again, I’m totally agnostic on how you want to implement that. With React, whatever front-end flavor of the month you want to go with, there's plenty of ways to do that, but I just think you have to be prioritizing that now. STEPH: All right. Well, I like that five-year projection of where we're headed. I have found that it's often the admin-side where people will still bring in a lot of JavaScript rendering, just to touch on a bit of what you're saying, in terms of let's favor the server-rendered HTML versus over-optimizing a space that one, probably isn't a profitable space in terms that we do want our admins to have a great experience for our product. But if they are not necessarily our users, then it also doesn't need to be anything that is over the top or fancy or probably uses a lot of JavaScript. And instead, we can start simple. And there's a number of times that I've been on projects where we have often walked the admin back to be more server-rendered because we got to a point where someone was very excited to make the admin very splashy and quick but then couldn't keep up with the requests because then they were having to prioritize the user experience first. So it was almost like optimizing the admin, but then it got left out in the cold. So then it's just sort of this poor experience. NATE: Yes. Shopify famously walked back their admin from I think it was Backbone to Turbolinks. And I think that that has now moved back to React is my understanding. But Shopify is a huge company, so they have plenty of time and resources to be able to do that. But I just remember that happening at the time where I was like, oh wow, they just rolled the whole thing back to Turbolinks again. And now, with the consolidation that's gone on in the React world, it's a little bit easier to pipe a server-side rendering into a React app. Whereas with Backbone, it was like no one knew what you were doing. So there was less knowledge about how to server-side render this stuff. Now it doesn't seem to be so much of a problem. But yeah, I mean, Rails is really good at CRUD apps, and admin is like 99% CRUD. And adhering as closely as possible to the Rails Golden Path there in an admin seems to be the most productive way to work on that kind of feature. STEPH: All right. Ready for your second question? NATE: Yes. STEPH: Okay. This one's a bit more in-depth. They also mentioned a particular project name. So I am going to swap it out with a different name. So on project cinnamon roll, we found a really gnarly time-consuming API endpoint that's getting hammered. And on a first pass, we addressed a couple of N+1 issues and tuned the performance, and felt pretty confident that they had addressed the issue. But it was still fairly slow. So then they took some additional incremental steps. So they swapped out to use OJ for serialization that shaved off an additional 10% but was still slow. They also went the route of going straight to Rails cache with a one-minute expiration. So that way, they could avoid mucking with cache busting because they confirmed with the client that data could be slightly stale. And this was great. It worked out well. So it dropped their average response time down to less than 70 milliseconds. With all that said, that journey took a few hours over a few days, and multiple production deploys. And had they gone straight to the cache, then they would have had a 15-minute fix with a single deploy. So this person's wondering, are there any other examples like that where, rather than taking these incremental seemingly obvious performance whims, there are situations where you want to be much more direct with your path? NATE: I guess I'd say that profiling can help you to understand and form better hypotheses about what will make things faster and what won't. Because a profiler can't really lie to you about where time goes, either you spent 20% of your time in this method, or you didn't. So I don't spend any time in any of my material talking about what JSON serializer you use. Because really that's actually never...that's really never anybody's bottleneck. It's never a huge proportion of people's total percentage of time. And I know that because I've looked at enough profiles that the issues are usually in other places. So I would say that if your hypotheses that you're generating are not working, it's because you're not generating good enough hypotheses. And profiling is the place to do that. So having profilers running in production is probably the biggest level-upscale-like that most teams could take. So having profilers that you can access as on production servers as a user is probably the biggest level up that you could make to generating the hypotheses because that'll have real production data, real production servers, real production environment. And it's pretty common now that pretty much every team that I work with either has that already, or we work on implementing it. It's something that I've seen in production at GitHub and Shopify. You can do it yourself with rack-mini-profiler. It's all about setting up the authorization, just making sure that only authorized users get to see every single SQL query generated in the flame graph and all that. But other than that, there's no reason you shouldn't do it. So I would say that if you're not generating the right hypotheses or you don't...if the last hypothesis out of 10 is the one that works, you need better hypotheses, and the best way to do that is better profiling. STEPH: Okay, better profiling. And yeah, it sounds like there's also a bit of experience in there in terms of things that you're used to seeing, that you've noticed that could be outliers in terms of that they're not necessarily the thing that you want to improve. Like you mentioned spending time on how you're serializing your JSON is not somewhere that you would look. But then there are other areas that you've gained experience that you know would be likely more beneficial to then focus on to form that hypothesis. NATE: Yeah, that's a long way of saying experience pays off. I've had six years of doing this every single day. So I'm going to be pretty good at...that's what I get paid for. [laughs] So if I wasn't very good at that, I probably wouldn't be making any money at it. STEPH: [laughs] All right. Well, thanks, Nate, so much for coming on the show today and talking so much about performance. On that note, I think it's a good place for us to wrap up. If people are interested in following along with what you're working on and they want to keep up with your latest and greatest workshops that are coming out, where can they find you on the internet? NATE: speedshop.co is my site. @nateberkopec on Twitter. And speedshop.co has a link to my newsletter, which is where I'm actively thinking every week and publishing stuff too. So if you want to get the drip of news and thoughts, that's probably the best place to go. STEPH: Perfect. All right. Well, thank you so much. NATE: No problem. STEPH: The show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey. STEPH: And I’m @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. Together: Bye. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Support The Bike Shed