Podcast appearances and mentions of sandi metz

Ravi Ram is a software engineer specializing in .NET, Azure, and intensive, high-stakes software. He started developing in 1998 with basic websites. Moved from Classic ASP with Cart.ASP. After learning about SQL injections after a client hack, he was hired by the California Department of Justice to do that work. Ravi is completely self-taught and has contributed to countless software projects over 30 years.   Topics of Discussion: [3:24] Ravi shares his career journey, starting with web design for a neighbor, moving to classic ASP, and eventually to .NET. [5:12] TechBash is a .NET conference in Pennsylvania, emphasizing its family-friendly atmosphere and the high attendance of families. [8:00] A few of Ravi's favorite moments and sessions from TechBash. [12:57] Going through code in real-time with one of the TechBash speakers. [16:51] How approachable, diverse, and friendly TechBash is. [17:11] Ravi talks about a session on scope logging with OpenTelemetry, which impressed him with its configuration capabilities. [27:49] Why the duo loves the word “seam”! [28:07] Encouragement for first-time speakers who may be interested in TechBash.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Ravi Ram on LinkedIn https://www.linkedin.com/in/dhali/ Sandi Metz' Rules For Developers https://thoughtbot.com/blog/sandi-metz-rules-for-developers Llewellyn Falco refactoring https://www.youtube.com/watch?v=aWiwDdx_rdoSandi  Metz' Rules For Developers https://thoughtbot.com/blog/sandi-metz-rules-for-developers Llewellyn Falco refactoring https://www.youtube.com/watch?v=aWiwDdx_rdo   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Joël conducted a thoughtbot mini-workshop on query plans, which Stephanie found highly effective due to its interactive format. They then discuss the broader value of interactive workshops over traditional talks for deeper learning. Addressing listener questions, Stephanie and Joël explore the strategic use of if and else in programming for clearer code, the importance of thorough documentation in identifying bugs, and the use of Postgres' EXPLAIN ANALYZE, highlighting the need for environment-specific considerations in query optimization. Episode mentioning query plans (https://bikeshed.thoughtbot.com/418) Query plan visualizer (https://explain.dalibo.com/) RailsConf 2024 (https://railsconf.org/) Episode 349: Unpopular Opinions (https://bikeshed.thoughtbot.com/349) Squint test (https://www.youtube.com/watch?v=8bZh5LMaSmE) Episode 405: Retro on Sandi Metz rules (https://bikeshed.thoughtbot.com/405) Structuring conditionals in a wizard (https://thoughtbot.com/blog/structuring-conditionals-in-a-wizard) Episode 417: Module docs (https://bikeshed.thoughtbot.com/417) Episode 416: Multidimensional numbers (https://bikeshed.thoughtbot.com/416) ruby-units gem (https://github.com/olbrich/ruby-units) Solargraph (https://marketplace.visualstudio.com/items?itemName=castwide.solargraph) parity (https://github.com/thoughtbot/parity) Transcript: STEPHANIE:  Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville, and together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: Just recently, I ran a sort of mini workshop for some colleagues here at thoughtbot to dig into the idea of query plans and, how to read them, how to use them. And, initially, this was going to be more of a kind of presentation style. And a colleague and I who were sharing this decided to go for a more interactive format where, you know, this is a, like, 45-minute slot. And so, we set it up so that we did a sort of intro to query plans in about 10 minutes then 15 minutes of breakout rooms, where people got a chance to have a query plan. And they had some sort of comprehension questions to answer about it. And then, 15 minutes together to have each group share a little bit about what they had discovered in their query plan back with the rest of the group, so trying to balance some understanding, some application, some group discussion, trying to keep it engaging. It was a pretty fun approach to sharing information like that. STEPHANIE: Yeah. I wholeheartedly agree. I got to attend that workshop, and it was really great. Now that I'm hearing you kind of talk about the three different components and what you wanted people attending to get out of it, I am impressed because [laughs] there is, like, a lot more thought, I think, that went into just participant engagement that reflecting on it now I'm like, oh yeah, like, I think that was really effective as opposed to just a presentation. Because you had, you know, sent us out into breakout rooms, and each group had a different query that they were analyzing. You had kind of set up links that had the query set up in the query analyzer. I forget what the tool was called that you used. JOËL: I forget the name of it, but we will link it in the show notes. STEPHANIE: Yeah. It was helpful for me, though, because, you know, I think if I were just to have learned about it in a presentation or even just looked at, you know, screenshots of it on a slide, that's different still from interacting with it and feeling more confident to use it next time I find myself in a situation where it might be helpful. JOËL: It's really interesting because that was sort of the goal of it was to make it a bit more interactive and then, hopefully, helping people to retain more information than just a straight up, like, presentation would be. I don't know how you feel, I find that often when I go to a place like, let's say, RailsConf, I tend to stay away from more of the workshop-y style events and focus more on the talks. Is that something that you do as well? STEPHANIE: Yeah. I have to confess that I've never attended a workshop [laughs] at a conference. I think it's partly my learning style and also partly just honestly, like, my energy level when I'm at the conference. I kind of just want to sit back. It's on my to-do list. Like, I definitely want to attend one just to see what it's like. And maybe that might even inspire me to want to create my own workshop. But it's like, once I'm in it, and, you know, like, everyone else is also participating, I'm very easily peer pressured [laughs]. So, in a group setting, I will find myself enjoying it a lot more. And I felt that kind of same way with the workshop you ran for our team. Though, I will say a funny thing that happened was that when I went out into my breakout group with another co-worker, and we were trying to grok this query that you gave us, we found out that we got the hardest one, the most complicated one [laughs] because there were so many things going on. There was, like, multiple, like, you know, unions, some that were, like, nested, and then just, like, a lot of duplication as well, like, some conditions that were redundant because of a different condition happening inside of, like, an inner statement. And yeah, we were definitely scratching our heads for a bit and were very grateful that we got to come back together as a group and be like, "Can someone please help? [laughs] Let's figure out what's going on here." JOËL: Sort of close that loop and like, "Hey, here's what we saw. What does everybody else see?" STEPHANIE: Yeah, and I appreciated that you took queries from actual client projects that you were working on. JOËL: Yeah, that was the really fun part of it was that these were not sort of made-up queries to illustrate a point. These were actual queries that I had spent some time trying to optimize and where I had had to spend a lot of time digging into the query plans to understand what was going on. And it sounds like, for you, workshops are something that is...they're generally more engaging, and you get more value out of them. But there's higher activation energy to get started. Does that sound right? STEPHANIE: Yeah, that sounds right. I think, like, I've watched so many talks now, both in person and on YouTube, that a lot of them are easily forgettable [laughs], whereas I think a workshop would be a lot more memorable because of that interactivity and, you know, you get out of it what you put in a little bit. JOËL: Yeah, that's true. Have you looked at the schedule for RailsConf 2024 yet? And are there any workshops on there that you're maybe considering or that maybe have piqued your interest? STEPHANIE: I have, in fact, and maybe I will check off attending a workshop [laughs] off my bucket list this year. There are two that I'm excited about. Unfortunately, they're both at the same time slot, so I -- JOËL: Oh no. You're going to have to choose. STEPHANIE: I know. I imagine I'll have to choose. But I'm interested in the Let's Extend Rails With A Gem by Noel Rappin and Vision For Inclusion Workshop run by Todd Sedano. The Rails gem one I'm excited about because it's just something that I haven't had to do really in my dev career so far, and I think I would really appreciate having that guidance. And also, I think that would be motivation to just get that, like, hands-on experience with it. Otherwise, you know, this is something that I could say that I would want to do and then never get [chuckles] around to it. JOËL: Right, right. And building a gem is the sort of thing that I think probably fits better in a workshop format than in a talk format. STEPHANIE: Yeah. And I've really appreciated all of Noel's content out there. I've found it always really practical, so I imagine that the workshop would be the same. JOËL: So, other than poring over the RailsConf schedule and planning your time there, what has been new for you this week? STEPHANIE: I have a really silly one [laughs]. JOËL: Okay. STEPHANIE: Which is, yesterday I went out to eat dinner to celebrate my partner's birthday, and I experienced, for the first time, robots [laughter] at this restaurant. So, we went out to Hot Pot, and I guess they just have these, like, robot, you know, little, small dish delivery things. They were, like, as tall as me, almost, at least, like, four feet. They were cat-themed. JOËL: [laughs] STEPHANIE: So, they had, like...shaped like cat...they had cat ears, and then there was a screen, and on the screen, there was, like, a little face, and the face would, like, wink at you and smile. JOËL: Aww. STEPHANIE: And I guess how this works is we ordered our food on an iPad, and if you ordered some, like, side dishes and stuff, it would come out to you on this robot cat with wheels. JOËL: Very fun. STEPHANIE: This robot tower cat. I'm doing a poor job describing it because I'm still apparently bewildered [laughs]. But yeah, I was just so surprised, and I was not as...I think I was more, like, shocked than delighted. I imagine other people would find this, like, very fun. But I was a little bit bewildered [laughs]. The other thing that was very funny about this experience is that these robots were kind of going down the aisle between tables, and the aisles were not quite big enough for, like, two-way traffic. And so, there were times where I would be, you know, walking up to go use the restroom, and I would turn the corner and find myself, like, face to face with one of these cat robot things, and, like, it's starting to go at me. I don't know if it will stop [laughs], and I'm the kind of person who doesn't want to find out. JOËL: [laughs] STEPHANIE: So, to avoid colliding with this, you know, food delivery robot, I just, like, ran away from it [laughs]. JOËL: You don't know if they're, like, programmed to yield or something like that. STEPHANIE: Listen, it did not seem like it was going to stop. JOËL: [laughs] STEPHANIE: It got, like, I was, you know, kind of standing there frozen in paralysis [laughs] for a little while. And then, once it got, I don't know, maybe two or three feet away from me, I was like, okay, like, this is too close for comfort [laughs]. So, that was my, I don't know, my experience at this robot restaurant. Definitely starting to feel like I'm in the, I don't know, is this the future? Someone, please let me know [laughs]. JOËL: Is this a future that you're excited or happy about, or does this future seem a little bit dystopian to you? STEPHANIE: I was definitely alarmed [laughter]. But I'm not, like, a super early adopter of new technology. These kinds of innovations, if you will, always surprise me, and I'm like, oh, I guess this is happening now [laughs]. And I will say that the one thing I did not enjoy about it is that there was not enough room to go around this robot. It definitely created just pedestrian traffic issues. So, perhaps this could be very cool and revolutionary, but also, maybe design robots for humans first. JOËL: Or design your dining room to accommodate your vision for the robots. I'm sure that flying cars and robots will solve all of this, for sure. STEPHANIE: Oh yeah [laughter]. Then I'll just have to worry about things colliding above my head. JOËL: And for the listeners who cannot see my face right now, that was absolutely sarcasm [laughs]. Speaking of our listeners, today we're going to look at a group of different listener questions. And if you didn't know that, you could send in a question to have Stephanie and I discuss, you can do that. Just send us an email at hosts@bikeshed.fm. And sometimes, we put it into a regular episode. Sometimes, we combine a few and sort of make a listener question episode, which is what we're doing today. STEPHANIE: Yeah. It's a little bit of a grab bag. JOËL: Our first question comes from Yuri, and Yuri actually has a few different questions. But the first one is asking about Episode 349, which is pretty far back. It was my first episode when I was coming on with Chris and Steph, and they were sort of handing the baton to me as a host of the show. And we talked about a variety of hot takes or unpopular opinions. Yuri mentions, you know, a few that stood out to him: one about SPAs being not so great, one about how you shouldn't need to have a side project to progress in your career as a developer, one about developer title inflation, one about DRY and how it can be dangerous for a mid-level dev, avoiding let in RSpec specs, the idea that every if should come with an else, and the idea that developers shouldn't be included in design and planning. And Yuri's question is specifically the question about if statements, that every if should come with an else. Is that still an opinion that we still have, and why do we feel that way? STEPHANIE: Yeah, I'm excited to get into this because I was not a part of that episode. I was a listener back then when it was still Steph and Chris. So, I am hopefully coming in with a different, like, additional perspective to add as well while we kind of do a little bit of a throwback. So, the one about every if should come with an else, that was an unpopular opinion of yours. Do you mind kind of explaining what that means for you? JOËL: Yeah. So, in general, Ruby is an expression-oriented language. So, if you have an if that does not include an else, it will implicitly return nil, which can burn you. There may be some super expert programmers out there that have never run into undefined method for nil nil class, but I'm still the kind of programmer who runs into that every now and then. And so, implicit nils popping up in my code is not something I generally like. I also generally like having explicit else for control flow purposes, making it a little bit clearer where flow of control goes and what are the actual paths through a particular method. And then, finally, doing ifs and elses instead of doing them sort of inline or as trailing conditionals or things like that, by having them sort of all on each lines and balancing out. The indentation itself helps to scan the code a little bit more. So, deeper indentation tells you, okay, we're, like, nesting multiple conditions, or something like that. And so, it makes it a little bit easier to spot complexity in the code. You can apply, and I want to say this is from Sandi Metz, the squint test. STEPHANIE: Yeah, it is. JOËL: Where you just kind of, like, squint at your code so you're not looking at the actual characters, and more of the structure, and the indentation is actually a friend there rather than something to fight. So, that was sort of the original, I think, idea behind that. I'm curious, in your experience, if you would like to balance your conditionals, ifs with something else, or if you would like to do sort of hanging ifs. STEPHANIE: Hanging ifs, I like that phrase that you just coined there. I agree with your opinion, and I think it's especially true if you're returning values, right? I mean, in Ruby, you kind of always are. But if you are caring about return values, like you said, to avoid that implicit nil situation, I find, especially if you're writing tests for that code, it's really easy, you know, if you spot that condition, you're like, okay, great. Like, this is a path I need to test. But then, oftentimes, you don't test that implicit path, and if you don't enter the condition, then what happens, right? So, I think that's kind of what you're referring to when you talk about both. It's, like, easier to spot in terms of control flow, like, all the different paths of execution, as well as, yeah, like, saving you the headaches of some bugs down the line. One thing that I thought about when I was kind of revisiting that opinion of yours is the idea of like, what are you trying to communicate is different or special about this condition when you are writing an if statement? And, in my head, I kind of came up with a few different situations you might find yourself in, which is, one, where you truly just have, like, a special case, and you're treating that completely differently. Another when you have more of a, like, binary situation, where it's you want to kind of highlight either...more of a dichotomy, right? It's not necessarily that there is a default but that these are two opposite things. And then, a third situation in which you have multiple conditions, but you only happen to have two right now. JOËL: Interesting. And do you think that, like, breaking down those situations would lead you to pick different structures for writing your conditionals? STEPHANIE: I think so. JOËL: Which of those scenarios do you think you might be more likely to reach for an if that doesn't have an else that goes with it? STEPHANIE: I think that first one, the special case one. And in Yuri's email, he actually asked, as a follow-up, "Do we avoid guard clauses as a result of this kind of heuristic or rule?" And I think that special case situation is where a guard clause would shine because you are highlighting it by putting it at the top of a method, and then saying like, you know, "Bail out of this" or, like, "Return this particular thing, and then don't even bother about the rest of this code." JOËL: I like that. And I think guard clauses they're not the first thing I reach for, but they're not something I absolutely avoid. I think they need to be used with care. Like you said, they have to be in the top of your method. If you're adding returns and things that break out of your method, deep inside a conditional somewhere, 20 lines into your method, you don't get to call that a guard clause anymore. That's something else entirely. I think, ideally, guard clauses are also things that will break out of the method, so they're maybe raising exception. Maybe they're returning a value. But they are things that very quickly check edge cases and bail so that the body of the method can focus on expecting data in the correct shape. STEPHANIE: I have a couple more thoughts about this; one is I'm reminded of back when we did that episode on kind of retroing Sandi Metz's Rules For Developers. I think one of the rules was: methods should only be five lines of code. And I recall we'd realized, at least I had realized for the first time, that if you write an if-else condition in Ruby, that's exactly five lines [laughs]. And so, now that I'm thinking about this topic, it's cool to see that a couple of these rules converge a little bit, where there's a bit of explicitness in saying, like, you know, if you're starting to have more conditions that can't just be captured in a five-line if-else statement, then maybe you need something else there, right? Something perhaps like polymorphic or just some way to have branched earlier. JOËL: That's true. And so, even, like, you were talking about the exceptional edge cases where you might want to bail. That could be a sign that your method is doing too much, trying to like, validate inputs and also run some sort of algorithm. Maybe this needs to be some sort of, like, two-step thing, where there's almost, like, a parsing phase that's handled by a different object or a different method that will attempt to standardize your inputs and raise the appropriate errors and everything. And then, your method that has the actual algorithm or code that you're trying to run can just assume that its inputs are in the correct shape, kind of that pushing the uncertainty to the edges. And, you know, if you've only got one edge case to check, maybe it's not worth to, like, build this in layers, or separate out the responsibilities, or whatever. But if you're having a lot, then maybe it does make sense to say, "Let's break those two responsibilities out into two places." STEPHANIE: Yeah. And then, the one last kind of situation I've observed, and I think you all talked about this in the Unpopular Opinions episode, but I'm kind of curious how you would handle it, is side effects that only need to be applied under a certain condition. Because I think that's when, if we're focusing less on return values and more just on behavior, that's when I will usually see, like, an if something, then do this that doesn't need to happen for the other path. JOËL: Yes. I guess if you're doing some sort of side effect, like, I don't know, making a request to an API or writing to a file or something, having, like, else return nil or some other sentinel value feels a little bit weird because now you're caring about side effects rather than return values, something that you need to keep thinking of. And that's something where I think my thing has evolved since that episode is, once you start having multiple of these, how do they compose together? So, if you've got if condition, write to a file, no else, keep going. New if condition, make a request to an API endpoint, no else, continue. What I've started calling independent conditions now, you have to think about all the different ways that they can combine, and what you end up having is a bit of a combinatorial explosion. So, here we've got two potential actions: writing to a file, making a request to an API. And we could have one or the other, or both, or neither could happen, depending on the inputs to your method, and maybe you actually want that, and that's cool. Oftentimes, you didn't necessarily want all of those, especially once you start going to three, four, five. And now you've got that, you know, explosion, like, two to the five. That's a lot of paths through your method. And you probably didn't really need that many. And so, that can get really messy. And so, sometimes the way that an if and an else work where those two paths are mutually exclusive actually cuts down on the total number of paths through your method. STEPHANIE: Hmm, I like that. That makes a lot of sense to me. I have definitely seen a lot of, like, procedural code, where it becomes really hard to tell how to even start relating some of these concepts together. So, if you happen to need to run a side effect, like writing to a file or, I don't know, one common one I can think of is notifying something or someone in a particular case, and maybe you put that in a condition. But then there's a different branching path that you also need to kind of notify someone for a similar reason, maybe even the same reason. It starts to become hard to connect, like, those two reasons. It's not something that, like, you can really scan for or, like, necessarily make that connection because, at that point, you're going down different paths, right? And there might be other signals that are kind of confusing things along the way. And it makes it a lot harder, I think, to find a shared abstraction, which could ultimately make those really complicated nested conditions a little more manageable or just, like, easier to understand at a certain complexity. I definitely think there is a threshold. JOËL: Right. And now you're talking about nested versus non-nested because when conditions are sort of siblings of each other, an if-else behaves differently from two ifs without an else. I think a classic situation where this pops up is when you're structuring code for a wizard, a multi-step form. And, oftentimes, people will have a bunch of checks. They're like, oh, if this field is present, do these things. If this field is present, do these things. And then, it becomes very tricky to know what the flow of control is, what you can expect at what moment, and especially which actions might get shared across multiple steps. Is it safe to refactor in one place if you don't want to break step three? And so, learning to think about the different paths through your code and how different conditional structures will impact that, I think, was a big breakthrough for me in terms of taking the next logical step in terms of thinking, when do I want to balance my ifs and when do I not want to? I wrote a whole article on the topic. We'll link it in the show notes. So, Yuri, thanks for a great question, bringing us back into a classic developer discussion. Yuri also asks or gives us a bit of a suggestion: What about revisiting this topic and doing an episode on hot takes or unpopular topics? Is that something that you'd be interested in, Stephanie? STEPHANIE: Oh yeah, definitely, because I didn't get to, you know, share my hot topics the last episode [laughs]. [inaudible 24:23] JOËL: You just got them queued up and ready to go. STEPHANIE: Yeah, exactly. So, yeah, I will definitely be brainstorming some spicy takes for the show. JOËL: So, Yuri, thanks for the questions and for the episode suggestion. STEPHANIE: So, another listener, Kevin, wrote in to us following up from our episode on Module Docs and about a different episode about Multi-dimensional Numbers. And he mentioned a gem that he maintains. It's called Ruby Units. And it basically handles the nitty gritty of unit conversions for you, which I thought was really neat. He mentioned that it has a numeric class, and it knows how to do math [laughs], which I would find really convenient because that is something that I have been grateful not to have to really do since college [laughs], at least those unit conversions and all the things that I'd probably learned in math and physics courses [laughs]. So, I thought that was really cool, definitely is one to check out if you frequently work with units. It seemed like it would be something that would make sense for a domain that is more science or deals in that kind of domain. JOËL: I'm always a huge fan of anything that tags raw numbers that you're working with with a quantity rather than just floating raw numbers around. It's so easy to make a mistake to either treat a number as a quantity you didn't think of, or make some sort of invalid operation on it, or even to think you have a value in a different size than you do. You think you're dealing with...you know you have a time value, but you think it's in seconds. It's actually in milliseconds. And then, you get off by some big factor. These are all mistakes that I have personally made in my career, so leaning on a library to help avoid those mistakes, have better information hiding for the things that really aren't relevant to the work that I'm trying to do, and also, kind of reify these ideas so that they have sort of a name, and they're, like, their own object, their own thing that we can interact with in the app rather than just numbers floating around, those are all big wins from my perspective. STEPHANIE: I also just thought of a really silly use case for this that is, I don't know, maybe I'll have to experiment with this. But every now and then, I find the need to have to convert a unit, and I just pop into Google, and I'm like, please give me, you know, I'll search for 10 kilometers in miles or something [laughs]. But then I have to...sometimes Google will figure it out for me, and sometimes it will just list me with a bunch of weird conversion websites that all have really old-school UI [laughs]. Do you know what I'm talking about here? Anyway, I would be curious to see if I could use this gem as a command-line interface [laughs] for me without having to go to my browser and roll the dice with freecalculator.com or something like that [laughs]. JOËL: One thing that's really cool with this library that I saw is the ability to define your own units, and that's a thing that you'll often encounter having to deal with values that are maybe not one of the most commonly used units that are out there, dealing with numbers that might mean a thing that's very particular to your domain. So, that's great that the library supports that. I couldn't see if it supports multi-dimensional units. That was the episode that inspired the comment. But either way, this is a really cool library. And thank you, Kevin, for sharing this with us. STEPHANIE: Kevin also mentions that he really enjoys using YARD docs. And we had done that whole episode on Module Docs and your experience writing them. So, you know, your people are out there [laughs]. JOËL: Yay. STEPHANIE: And we talked about this a little bit; I think that writing the docs, you know, on one hand, is great for future readers, but, also, I think has the benefit of forcing the author to really think about their inputs and outputs, as Kevin mentions. He's found bugs by simply just going through that process in designing his code, and also recommends Solargraph and Solargraph's VSCode extension, which I suspect really kind of makes it easy to navigate a complex codebase and kind of highlight just what you need to know when working with different APIs for your classes. So, I recently kind of switched to the Ruby LSP, build with Shopify, but I'm currently regretting it because nothing is working for me right now. So, that might be the push that I need [laughs] to go back to using Solargraph. JOËL: It's interesting that Kevin mentions finding bugs while writing docs because that has absolutely been my experience. And even in this most recent round, I was documenting some code that was just sort of there. It wasn't new code that I was writing. And so, I had given myself the rule that this would be documentation-only PRs, no code changes. And I found some weird code, and I found some code that I'm 98% sure is broken. And I had to have the discipline to just put a notice in the documentation to be like, "By the way, this is how the method should work. I'm pretty sure it's broken," and then, maybe come back to it later to fix it. But it's amazing how trying to document code, especially code that you didn't write yourself, really forces you to read it in a different way, interact with it in a different way, and really, like, understand it in a deep way that surprised me a little bit the first time I did it. STEPHANIE: That's cool. I imagine it probably didn't feel good to be like, "Hey, I know that this is broken, and I can't fix it right now," but I'm glad you did. That takes a lot of, I don't know, I think, courage, in my opinion [laughs], to be like, "Yeah, I found this, and I'm going to, you know, like, raise my hand acknowledging that this is how it is," as supposed to just hiding behind a broken functionality that no one [laughs] has paid attention to. JOËL: And it's a thing where if somebody else uses this method and it breaks in a way, and they're like, "Well, the docs say it should behave like this," that would be really frustrating. If the docs say, "Hey, it should behave like this, but it looks like it's broken," then, you know, I don't know, I would feel a little bit vindicated as a person who's annoyed at the code right now. STEPHANIE: For sure. JOËL: Finally, we have a message from Tim about using Postgres' EXPLAIN ANALYZE. Tim says, "Hey, Joël, in the last episode, you talked a bit about PG EXPLAIN ANALYZE. As you stated, it's a great tool to help figure out what's going on with your queries, but there is a caveat you need to keep in mind. The query planner uses statistics gathered on the database when making decisions about how to fetch records. If there's a big difference between your dev or staging database and production, the query may make different decisions. For example, if a table has a low number of records in it, then the query planner may just do a table scan, but in production, it might use an index. Also, keep in mind that after a schema changes, it may not know about new indexes or whatever unless an explicit ANALYZE is done on the table." So, this is really interesting because, as Tim mentions, EXPLAIN ANALYZE doesn't behave exactly the same in production versus in your local development environment. STEPHANIE: When you were trying to optimize some slow queries, where were you running the ANALYZE command? JOËL: I used a combination. I mostly worked off of production data. I did a little bit on a staging database that had not the same amount of records and things. That was pretty significant. And so, I had to switch to production to get realistic results. So, yes, I encountered this kind of firsthand. STEPHANIE: Nice. For some reason, this comment also made me think of..., and I wanted to plug a thoughtbot shell command that we have called Parity, which lets you basically download your production database into your local dev database if you use Heroku. And that has come in handy for me, obviously, in regular development, but would be really great in this use case. JOËL: With all of the regular caveats around security, and PII, and all this stuff that come with dealing with production data. But if you're running real productions on production, you should be cleared and, like, trained for access to all of that. I also want to note that the queries that you all worked with on Friday are also from the production database. STEPHANIE: Really? JOËL: So, you got to see what it actually does, what the actual timings were. STEPHANIE: I'm surprised by that because we were using, like, a web-based tool to visualize the query plans. Like, what were you kind of plugging into the tool for it to know? JOËL: So, the tool accepts a query plan, which is a text output from running a SQL query. STEPHANIE: Okay. So, it's just visualizing it. JOËL: Correct. Yeah. So, you've got this query plan, which comes back as this very intimidating block of, like, text, and arrows, and things like that. And you plug it into this web UI, and now you've got something that is kind of interactive, and visual, and you can expand or collapse nodes. And it gives you tooltips on different types of information and where you're spending the most time. So, yeah, it's just a nicer way to visualize that data that comes from the query plan. STEPHANIE: Gotcha. That makes sense. JOËL: So, that's a very important caveat. I don't think that's something that we mentioned on the episode. So, thank you, Tim, for highlighting that. And for all of our listeners who were intrigued by leaning into EXPLAIN ANALYZE and query plan viewers to debug your slow queries, make sure you try it out in production because you might get different results otherwise. STEPHANIE: So, yeah, that about wraps up our listener topics in recent months. On that note, Joël, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

In this episode of Ruby for All, Andrew and Julie reconnect after a three-week break to share how they spent their vacation and their plans for the new year, as Julie talks about her family's newest addition, a Whippet named Lucy, and Andrew getting plenty of rest, some rock climbing, and a hot yoga class. Then, they dive into the topic of burnout, sharing their personal experiences and strategies for managing burnout effectively. They discuss looking forward to Ruby 3.3, upcoming conferences, and a collective aim to level up their careers. Join Andrew and Julie as they kick off the new year with optimism and hit download now![00:00:17] Andrew and Julie catch up and discuss their Christmas breaks. Julie reveals they have a new family dog and Andrew reveals he would like to get a dog one day. [00:02:10] Andrew discusses his restful break, hibernating, visiting Virginia, rock climbing, and enjoyed a hot yoga class. [00:04:50] Over break, Julie started reading the book, “99 Bottles of OOP” by Sandi Metz and catching up on conference talks. She considers redoing her app with Turbo and Rails. [00:05:56] Andrew started reading “Practical VIM” but he's ready to switch to Neovim. He's been reading multiple books, trying to regain his love for reading, and he sets goals to read more and started using book summaries on Blinkist.[00:07:30] Andrew and Julie reminisce about their childhood reading habits. Julie talks about her struggles with reading comprehension and trying to pick it up again.[00:10:36] Andrew discusses his experience with speed reading techniques and explains how speed reading doesn't necessarily impact his ADHD. He discusses extracting key points from books without reading every word. [00:12:37] Julie feels burned out from work and finds reading “99 Bottles of OOP” refreshing, and she expresses her ongoing burnout and asks Andrew's thoughts on this.Andrew shares his personal warning signs of burnout, which includes losing the joy of programming, neglecting health, and feeling stuck and discouraged. [00:15:06] Julie acknowledges the importance of recognizing burnout signs and relates to the difficulty in identifying them, especially when juggling work and family. Andrew shares the challenge is addressing burnout once it's recognized, emphasizing the need to focus on self-care and potentially making changes if the job is the cause.[00:16:11] Andrew suggests restoring sleep, exercise, and diet are crucial first steps to combat burnout, and he shares strategies for improvement, like focusing on sleep and reducing screen time.[00:17:56] Julie has replaced watching stimulating YouTube videos before bed with reading to cut down on screen time. Andrew set a goal for less screen time in 2024. [00:20:06] They shift the conversation to Ruby 3.3 and upcoming conferences and which ones they would like to attend. [00:21:13] Julie inquires if Andrew's desire to focus on becoming a better engineer is about “leveling up.” Andrew agrees and expresses feeling stuck in his career for the past couple of years and is now ready to advance. [00:21:41] Julie questions if Andrew has a plan for achieving his career growth. Andrew explains he intends to improve his database skills, particularly Postgres and architecture, dive into security, and learn more about iOS development.[00:22:10] Some personal goals Andrew wants is to increase his typing speed and become more proficient with the home row typing method. Panelists:Andrew MasonJulie J.Sponsors:GoRailsHoneybadgerLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. Website99 Bottles of OOP by Sandi MetzPractical VIM by Drew NeilNeovimHigh Performance PostgreSQL for Rails by Andrew AtkinsonThe Programmer's Brain by Felienne HermansBlinkist (00:00) - Intro and Welcome (00:17) - Catching up and Christmas breaks (02:10) - Andrew's restful break and activities (04:50) - Julie's reading and app plans (05:56) - Andrew's reading goals (07:30) - Childhood reading habits (10:36) - Andrew on speed reading (12:37) - Burnout and Julie's struggles (15:06) - Recognizing and addressing burnout (16:11) - Strategies for combating burnout (17:56) - Reducing screen time (20:06) - Ruby 3.3 and upcoming conferences (21:13) - Career growth and leveling up (21:41) - Andrew's career growth plan (22:10) - Personal goals and typing speed

In this conversation live from RubyConf San Diego, Andrew and Julie sit down with Elise Shaffer, host of The Ruby on Rails Podcast. They kick things off with sharing conference experiences, the joy of reconnecting with friends, and the unique energy the in-person events bring. The discussion shifts to the concept and practice of Test Driven Development (TDD), its benefits, and how it aids in problem-solving during coding.  An interesting point is discussed about whether tests or code should be written first, and whether it's okay to write tests after the code.  They also dive into the handling of tests on legacy codes within Rails. The conversation wraps up with gratitude to the organizers, speakers, volunteers, and attendees at RubyConf. Press download now to hear more! [00:00:24] Elise shares her conference experience mentioning enjoying the sessions and seeing friends from previous conferences, and Julie and Andrew share their joy of being in the company of friends, the conference atmosphere, and food.  [00:01:39] Elise shares the number of Ruby and Rails conferences she's attended and her most memorable one which was Steel City Ruby, highlighting the value of smaller conferences and tight-knit communities. [00:02:45] They discuss the difference between in-person and online conferences, agreeing that in-person events offer more energy and interaction. [00:03:50] The conversation shifts to memorable conferences as Andrew reminisces about his first conference experience at RailsConf in Pittsburgh. Julie talks about her first conference, RailsConf 2022 in Portland, where she met Elise and Andrew and where Ruby for All was conceived.[00:06:12] Andrew asks Julie about her rise in popularity withing a year, moving from a newcomer toa recognized member of the community. The group jokes about autographs and fame within the Ruby community. Elise shares her role in the community, especially with the podcast she hosts. [00:09:33] Elise and Andrew discuss the technical aspects of testing and continuous integration within software development. She explains her background in Ruby and Rails, where she focused on testing and its challenges in larger applications, and she discusses strategies for testing and the importance of testing not every permutation but preventing major issues, [00:12:46] Julie asks Elise to explain parallelized testing.  Elise details using CircleCl or other runners to break up many tests across multiple workers to speed up the process.[00:13:56] Elise explains what Test Driven Development (TDD) means to her, and Julie asks whether TDD is always applicable, like when fixing a bug rather than creating a new feature. [00:15:30] Elise wishes TDD was still popular and stresses that TDD is a skill that must be developed. She describes the advantages of TDD, particularly in large applications, where having a robust test suite allows for faster development and less worry about breaking something inadvertently. [00:18:58] Andrew challenges the concept of TDD, suggesting that for a talented engineer, tests might seem like a waste of time.  Elise responds by emphasizing that TDD is a thinking tool that aids in understanding the problem. [00:20:59] The discussion turns to reviewing tests.  Elise explains her approach to reviewing pull requests by checking the problem solved, reviewing commits one at a time, and comparing her list of tests with the submitted ones, placing higher importance on the tests than the code itself. [00:24:02] Elise and Andrew compare their personal styles in reviewing code and the importance of preparing commit messages for review. Julie is curious how Elise and Andrew manage their commit history and whether they use the command line for combining commits. Andrew mentions using interactive rebase. [00:24:47] If you're interested in getting into TDD, Elise tells us she's working on a course about test driving in Rails applications coming out on early next year , but also recommends reading two great books: Test Driven Development: By Example by Kent Beck and 99 Bottles of OOP by Sandi Metz.[00:25:33] Julie questions how to handle TDD in a legacy codebase with complex and nested tests. Elise suggests pairing with someone more knowledgeable to break up the tests into smaller, more manageable files. Panelists:Andrew MasonJulie J.Guest:Elise ShafferSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteElise Shaffer WebsiteElise Shaffer GitHubThe Ruby on Rails PodcastCircleCITest Driven Development: By Example by Kent Beck99 Bottles of OOP by Sandi Metz (00:24) - - Introduction and conference experience (01:39) - - Memorable conferences and tight-knit communities (02:45) - - In-person vs. online conferences (03:50) - - First conference experiences (06:12) - - Julie's rise in popularity and fame in the community (09:33) - - Testing and continuous integration in software development (12:46) - - Parallelized testing and speeding up test processes (13:56) - - Test Driven Development (TDD) and its applicability (15:30) - - Advantages of TDD and its role in understanding problems (18:58) - - Challenges to the concept of TDD (20:59) - - Reviewing tests and pull requests (24:02) - - Managing commit history and using interactive rebase (24:47) - - Recommendations for learning TDD (25:33) - - Handling TDD in legacy codebases

Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza. We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they've read and loved, and other highlights of 2023 (projects, conferences, etc). Olive Oil Sugar Cookies With Pistachios & Lemon Glaze (https://food52.com/recipes/82228-olive-oil-sugar-cookies-recipe-with-pistachios-lemon) thoughtbot's Blog (https://thoughtbot.com/blog) Episode 398: Developing Heuristics For Writing Software (https://www.bikeshed.fm/398) Episode 374: Discrete Math (https://www.bikeshed.fm/374) Episode 405: Sandi Metz's Rules (https://www.bikeshed.fm/405) Episode 391: Learn with APPL (https://www.bikeshed.fm/391) Engineering Management for the Rest of Us (https://www.engmanagement.dev/) Confident Ruby (https://pragprog.com/titles/agcr/confident-ruby/) Working with Maybe from Elm Europe (https://www.youtube.com/watch?v=43eM4kNbb6c) Sustainable Rails Book (https://sustainable-rails.com/) Episode 368: Sustainable Web Development (https://www.bikeshed.fm/368) Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) Simplifying Tests by Extracting Side Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) The Math Every Programmer Needs (https://www.youtube.com/watch?v=wzYYT40T8G8) Mermaid.js sequence diagrams (https://mermaid.js.org/syntax/sequenc) Sense of Belonging and Software Teams (https://www.drcathicks.com/post/sense-of-belonging-and-software-teams) Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) Digging through the ashes (https://everythingchanges.us/blog/digging-through-the-ashes/) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat. It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it. JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want? STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see. And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them. JOËL: Hearing you talk about this gave me an absolutely terrible idea. STEPHANIE: Terrible or terribly awesome? [laughs] JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops. STEPHANIE: [laughs] JOËL: You're on a network, and then you swap browser cookies randomly. STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one. JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see. STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party? JOËL: I 100% agree. STEPHANIE: [laughs] JOËL: I'm curious: where do you stand on raisins in oatmeal cookies? STEPHANIE: Ooh. JOËL: This is a divisive question. STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles]. JOËL: That is the correct answer. STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs]. JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies. STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world? JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done. I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why. STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result. JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created. STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog. JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like. STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes. JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun. I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out. STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that. You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one. Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk. And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs]. JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year? STEPHANIE: Yeah, absolutely. JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out. STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs]. JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested. So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023? STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool. So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values. And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that. JOËL: Would you recommend this book to others who are maybe not considering a management path? STEPHANIE: Yeah. JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people. STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in. Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool. JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things. But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody. STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer. JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there. STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year? JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps. And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise. STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working. JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book? So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea. STEPHANIE: Yeah, absolutely. JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening. STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts. JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that? STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there. So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year. JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk. And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it. STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023? JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar? STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years. And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great. And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river. JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled. STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs]. JOËL: What was the topic of your talk? STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change. JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference. STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there. One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024. I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of. So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year? JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience. Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore. The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO. And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn. STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun. JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team. And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live. And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that. STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat. JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people? STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool. She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported? And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles] JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot. So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item. Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation. STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs]. JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing? STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break. And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right? And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs]. JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there? STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too. JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that. So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work." STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January. JOËL: Cheers to a new year. STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024. JOËL: On that note, shall we wrap up the whole year? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/ referral. Or you can email us at referrals@thoughtbot.com with any questions.

Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness. Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I picked up a new book from the library [laughs], which that in itself is not very new. That is [laughs] a common occurrence in my world. But it was kind of a fun coincidence that I was just walking around the aisles of what's new in nonfiction, and staring me right in the face was an O'Reilly book, The Staff Engineer's Path. And I think in the past, I've plugged The Manager's Path by Camille Fournier on the show. And in recent years, this one was published, and it's by Tanya Reilly. And it is kind of, like, the other half of a career path for software engineers moving up in seniority at those higher levels. And it has been a really interesting companion to The Manager's Path, which I had read even though I wasn't really sure I wanted to be manager [laughs]. And now I think I get that, like, accompaniment of like, okay, like, instead of walking that path, like, what does a staff plus engineer look like? And kind of learning a little bit more about that because I know it can be really vague or ambiguous or look very different at a lot of different companies. And that has been really helpful for me, kind of looking ahead a bit. I'm not too far into it yet. But I'm looking forward to reading more and bringing back some of those learnings to the show. JOËL: I feel like at the end of the year, Stephanie, you and I are probably going to have to sit down and talk through maybe your reading list for the year and, you know, maybe shout out some favorites. I think your reading list is probably significantly longer than mine. But you're constantly referencing cool books. I think that would probably be a fun, either end-of-year episode or a beginning-of-year episode for 2024. One thing that's really interesting, though, about the contrast of these two particular books you're talking about is how it really lines up with this, like, fork in the road that a lot of us have in our careers as we get more senior. You either move into more of a management role, which can be a pretty significant departure from what you have to do as a developer, or you kind of go into this, like, ultra-senior individual contributor path. But how that looks day to day can be very different from your sort of just traditional sitting down and banging out tickets. So, it's really cool there's two books looking at both of those paths. STEPHANIE: Yeah, absolutely. And I think the mission that they were going for with these books was to kind of illuminate a little bit more about that fork and that decision because, you know, it can be easy for people to maybe just default into one or the other based on what their organization wants for them without, like, fully knowing what that means. And the more senior you get, the more vague and, like, figure it out yourself [laughs] the work becomes. And it can be very daunting to kind of just be thrown into that and be like, well, I'm in this leadership position now. People are looking to me, and I have all this responsibility, but, like, what do I do? Yeah, so I'm kind of enjoying this book, that is...it's not a technical book, which is actually kind of what I like about it. It's actually more of a leadership book, which is really important for that kind of role. Even though, you know, they are still in that IC track, but it does come with a lot of leadership responsibility. JOËL: Yes, leadership in a very different way than management. But—and this may be counterintuitive for some people, especially earlier on in their careers—going further up that individual contributor track doesn't just mean getting more intense technically. It often means you've got to focus on things more like leadership, like being a bit more strategic, aligning technical initiatives with strategic goals. STEPHANIE: Yeah, and having a bigger impact and being a force multiplier, even in both the manager and, like, the staff plus role, like, that, you know, is the thing that ties the rising level. JOËL: Yeah, in many ways, maybe the individual contributor track is slightly misnamed because while, yes, you're not managing a sort of sub-organization within the company, it's still about being a force multiplier. STEPHANIE: Yeah, that's a really great point [laughs]. Maybe we'll be able to come up with a better [laughs] name for that. JOËL: I've mentioned several times on this podcast that I've been enjoying playing Dungeons & Dragons, D&D, with some friends and some colleagues. And something that was particularly fun that some friends and I did this summer is we hired a professional DM to run one shot for us. And that was just an absolutely lovely experience. Well, as a result of that, I am now subscribed to this guy's newsletter. And he'll do, like, various D&D events at different times. One thing that was really cool that I found out recently...as we're recording this, it's the week before election day in the U.S. And because a lot of voting happens in schools, typically, schools have the day off. And so, this guy sent out an email saying he was offering to run a, like, all day...effectively, a little mini-D&D camp for school-age kids on election day so that you can do your work. You can go vote, and you don't have to...basically, he'll watch your kids for you and, like, get them introduced to playing D&D, which I think is just a really cool thing to do. STEPHANIE: I love that. It's so heartwarming [laughs]. And it's such a great idea because, oftentimes, people are still working, and so they need childcare, like, on those kinds of days. And yeah, I think D&D is such a fun thing for kids to get into, too. You know, it requires so much, like, imagination, and I can imagine it's such a blast. JOËL: I got that email, and I was like, that is such a perfect idea. I love it so much. STEPHANIE: I wanted to plug my D&D recommendation. I'm pretty sure I have mentioned it on the show before. But there is a podcast that I listen to called Not Another D&D Podcast, which is, you know, a live play Dungeons & Dragons podcast campaign that's hosted by these comedians, formerly of CollegeHumor, and it's very fun. I always laugh. They have this, like, a kind of offshoot of the main show that they do called D&D Court, which is very fun. Because, as you were saying, like, you know, you hired a DM to run your game. And I know that...I'm sure lots of people have fun stories about their home games and, like, the drama that happens [laughs] with their friends. JOËL: Absolutely. Absolutely. STEPHANIE: And so, with D&D Court, listeners can write in with their drama or their conflicts and get an official ruling from the hosts about who was right [laughs] in the situation that they write in about. JOËL: So, you get to bring your best rules lawyering to the D&D Court. STEPHANIE: Yeah, exactly [laughs]. JOËL: That sounds kind of amazing. Recently, I had someone reach out to me asking about an older blog post that we'd written about the Sandi Metz Rules. This blog post was initially published in 2013, so ten years ago, and was talking about some guidelines that Sandi Metz at the time was talking about that she was using in some of her code. And we talked about how our experience was applying those to some of our work as well. And so, the question was, you know, ten years later, is that still something that thoughtbot developers like to follow in their code? We'll link to the article in the show notes. But I'll just read out the rules here real quick. So, there's four of them. The first one is a class can be no longer than 100 lines of code. The second is a method can be no longer than five lines of code. The third is pass no more than four parameters into a method, and hash options count, so no getting clever with those. And then, finally, controllers can only instantiate one object. You only get one instance variable. And views can only talk to that one instance variable. Had you or are you familiar with these rules? Is that something that you think about or use in your daily writing of code? STEPHANIE: Yeah. So, when you proposed this topic, I had to revisit these rules. And I can't recall if I had seen them before. They seemed familiar. And I've read, you know, a couple of Sandi Metz's books, so maybe those were places where she had mentioned them. But the one thing that really struck me when I was first reading the rules was how declarative they were in terms of, like, kind of just telling you what the results should be without really saying how. So, for example, the one where you said, you know, a method should not be more than five lines [laughs], I had the silly thought of, like, well, you could just, you know, stuff everything into a single line [laughs] and just completely disregard line limit if you wanted, and it would technically still follow the rule. JOËL: If they didn't want us to do that, they wouldn't give us semicolons in Ruby. STEPHANIE: Exactly [laughs]. So, that is kind of what struck me at first. Is that something you noticed? JOËL: I think what is interesting with them is that there's not always a ton of rationale given behind them. Our article talks a little bit about some of the why that might be helpful and how that might look like in practice. I'm not sure what Sandi's original...I don't know if it was one of her books or maybe on a...it might have been on a podcast appearance she talked about them, so she might go more in-depth there. But yeah, they are a little bit declarative. It's just like, hey, here's...it's almost basically the kind of thing that can be enforced by a linter, which is perhaps the point. STEPHANIE: Ooh, that's really interesting. It's like, on one hand, I like how simple they are, right? It's like, they're very obvious. If you're not following them, you can tell. But on the other hand, they seem to be more of a supplement to the gained knowledge and experience that you kind of get from knowing how to implement those rules. I think you and I will both agree that we don't want to stuff everything [laughs] into a single line with semicolons. But if someone who maybe is newer to development and is coming to these rules, I think they might be wondering, like, how do I do this? JOËL: Do you follow these rules in your own code? STEPHANIE: I think the ones that are easier to follow, for me, and that I think I've come to do more instinctually, are the rules about class line length and method line length just because I'm kind of looking out for opportunities to pull out a method or, you know, make sure that this class is just doing one thing. And if it's starting to seem to cover a couple of different responsibilities, I'm a little bit more on the lookout. But I do like these rules as like, you know, like, hey, once you hit, you know, 100 lines in a class, like, maybe that's your cue to start thinking about opportunities for extraction. JOËL: Do you sort of consciously follow these rules or have them maybe even encoded in a linter? Or is it more you're following other things, and somehow, it just lines up with these principles? STEPHANIE: I would say that, like, I'm not thinking about them very actively. But that could be a very interesting exercise, and I think, you know, that's what folks did in the blog post. They were like, hey, we took these rules, and we really kept them in mind as we were developing. But I think kind of what we were talking about earlier about, like, what we've learned or the strategies we've learned to implement kind of converge on these rules. And the rules actually are more of the result of other ideas or heuristics that we follow. JOËL: I mean, you dropped the keyword heuristics there. And I think that brings me back to an earlier episode we did where we talked about heuristics. And one of the things that came up on that episode was the idea that, oftentimes, we use heuristics as a way to sort of flatten a lot of experience and knowledge into sort of one, like, short rule, or short phrase, or something, one guideline, even though it's sort of trying to just summarize a mountain of wisdom. And so, oftentimes, you can look at something like these rules and be like, okay, well, what's the point? Or maybe you even just follow it to the letter without really thinking about the why behind it, and that can sometimes be problematic. And on the other hand, you might know all of the ideas that go behind them. And without necessarily knowing the rule itself, you just kind of happen to follow it because you're intimately familiar with all of these other software principles that converge on those same ideas. STEPHANIE: Yeah, agreed. I think that the more interesting ones to me are the no more than four method arguments and only one instance variable per controller. JOËL: Interesting. STEPHANIE: I'm curious if those are sparking anything for you [laughs]. JOËL: I think the no more than four method arguments, to me, is probably the least controversial. It's generally accepted that having many arguments to a method is a code smell. And there's a few different code smells that are related to that. There's forms of coupling incandescence; there are data clumps, things like that. I've often heard a sort of rule of three. And so, if you're going more than three, then you might want to revisit the structure of what you're building. Four is a bit of an arbitrary cut-off, I'll agree. Most of these are arbitrary cut-offs. But I think the idea to maybe keep your method to fewer arguments is generally a good thing to do. STEPHANIE: I liked that the rule points out that hash options account because I think that's maybe where people get a little more hand-wavy, or you have your ops hash [laughs] that can be just a catch-all for anything. You know, it's like, once you start putting stuff in there, I don't know, I feel like it's a like a law of the universe. It's like, oh, people will just stuff more things in there [laughs]. And it takes obviously more effort or, like, specific energy to, like, think through what those things might represent, or some alternative ways of handling those arguments. We definitely do have, I think, a couple of episodes on value objects. But that's something that we have talked a lot about before in terms of, you know, how can we take some kind of primitive data, hashes included, and turn them into a richer object that can then be passed on its own? JOËL: Right. And an options hash is generally...it's too much of a catch-all to really have an identity as its own sort of value object. It doesn't really represent any single thing. It's just everything else bag of data. One thing that's interesting that the article notes is that a lot of the helpers in Rails take a lot of arguments and that it is absolutely not worth trying to fight the framework to try to follow these rules. So, the article does take a very pragmatic approach, I think, to the idea of these rules. STEPHANIE: Yeah. And I think there is even a caveat to the rules where it's like, you can break them if you have a good reason, or if you're working with someone else and they give you the thumbs up [laughs], which I really like a lot because it almost kind of compels you to stop and be like, do I have a good reason of doing this? Just making sure, or I'll run it by a friend. And shifting that, I guess, that focus from kind of just coding from, like, your default mode of thinking to a more active one. JOËL: Right. There is a rule zero, which says you can break any of the other rules as long as you convince either your pair or your reviewer to give you a thumbs up on breaking the rule. So, you'd mentioned the fourth rule about a single instance variable in a controller kind of was one of the ones that stood out to you. What is particularly striking about that rule? STEPHANIE: I think this one is hard to follow, and I think the blog post mentions that as well. Because at least I've seen our web applications grow more and more complex. And it can be really challenging to just be like, what is this page doing? Like, what, you know, data does it need to know? And have that be the single thing. Because really, a lot of our web apps have a lot of things [laughs] that they're doing, and sometimes it feels like you have to capture more than one object or at least, like, a responsibility in this way. I think that's the one that I, you know, in my ideal world, I'm like, yeah, like, we have all these, like, perfectly RESTful routes. And, you know, we're only dealing with, you know, a single resource. But once you start to have some more complexity, I think that can be a little more challenging. JOËL: I think it's interesting that you mentioned RESTful routing because I think that is maybe one of the bigger things that does trigger having more instance variables in your controller actions. If you're following sort of the traditional Rails RESTful routes, every page is generally focused on a singular resource. Now, that may not necessarily line up with a table in your database, and that's fine. But you're dealing with a singular thing or perhaps, you know, in the case of an index page, a singular collection of things, which can be represented with a single instance variable. Once you start adding custom routes that may not be necessarily tied to a particular resource, now you can very easily kind of have a proliferation of all sorts of different things that interact with each other because you're no longer centered on a single thing. STEPHANIE: Yeah, that's true, which actually reminds me of something we've talked about before, too, when we were both reading Sustainable Rails. The author talks about custom routes and actually advocates for making all routes RESTful. And if you need a vanity URL or something like that, you can always alias it. That I liked, right? It's like, okay, even if, you know, your resource is not something that's like, ActiveRecord-backed, is there some abstraction or concept of a resource in there? And I actually did really like in the blog post in the example; that is one that I've used before, too. They were dealing with this idea of a dashboard, which I would, you know, say is pretty common in a lot of web applications these days. And it's funny because a dashboard can hold so much data, right? It's really, like, a composite of a lot of different things, you know, what is most, like, useful for the user to see in one place. But they were in the blog post. And this, again, this is kind of something that I've done before. They were able to capture that with the idea of, like, a dashboard as an object and that being codified using a presenter or a facade. JOËL: Right. So, instead of having a group, and a status, and a user, and all these, like, separate things that your page that you're showing is a sort of collection of all these different types of objects, you wrap them together in a dashboard object that's kind of a facade. And I guess that really does line up with the idea of RESTful routing because you're likely going to have a dashboard's controller show action that's showing the user's dashboard. So, it makes sense, you know, that show page is rendering a dashboard object. STEPHANIE: Can we talk a little bit about things not to do, or maybe things that might be a little more questionable [laughs], and if you've seen them and how you felt about them? JOËL: I think it is sometimes tricky to define your boundaries right in that sometimes you create a facade object that really is just...it doesn't really represent anything. It's just there to wrap around some other things. And sometimes that can be awkward. I think the dashboard works partly because it lines up so neatly with the sort of RESTful routing and thinking in terms of resources that you want to do at the controller layer. But drawing boundaries incorrectly or just trying to throw everything in some kind of grab bag object can...it's not a magic bullet, right? You've got to put some thought into the data modeling, even when you are pulling the facade pattern. STEPHANIE: Yeah, I think other things that I've seen before that could theoretically follow this rule maybe [laughs], you know, I'd love to hear your thoughts about it. When you start, you're like, oh, like, my controller action method does just, you know, set one instance variable. But it turns out that there's all these other instance variables that either through a hook or, like, in the parent controller or even in the view I've seen before, too [laughs]. And I'm just kind of curious if that kind of raises your eyebrow at all or if you've seen any good reasons for doing so. JOËL: I think setting instance variables in a view would absolutely cause me to raise an eyebrow. STEPHANIE: [laughs] Agreed. JOËL: Generally, don't put logic in the view. I think that we definitely have in parent controllers; we'll set other instance variables for things like maybe a current user, right? That's how we store that state. And I think that is totally fine to have around. Typically, we don't access that instance variable directly. We're referencing some kind of helper method. But yeah, I would not consider that a violation of the rule. I think another common one that might come up is when you have some kind of nested resource. And so, in your URL, you might have a nested resource where you're saying, "Oh, I'm looking at specifically this comment under this article or something like that." And then, you want to have access to both objects in the controller. So, I think that's a pretty common scenario where you might want to have both instance variables. Something that I'm thinking about...this is not a fully formed thought, so I'm curious about your opinions here. Is there an interesting distinction between variables in code that you want to use within a controller versus variables that you want to be accessible from a view? Because instance variables in a controller are kind of overloaded. They're a way of having state in a controller, but they're also a way of passing data into a view. And so, that sort of dual purpose there maybe causes them to be a little bit trickier to reason about than instance variables in a random Ruby object. What do you think? STEPHANIE: Yeah, I was actually having the same thought as you were going there, which is that it is kind of interesting that the view, you know, is that level of what you want to display to your user. But it can have access to, like, whatever you put in the controller [laughs], and that is...and, you know, in some ways, it's like, that connection needs to happen somewhere, right? And it's here. But I think that can definitely be abused sometimes, too. So, this, you know, fourth rule that we're talking about really has to do with a more traditional Rails app. But, again, with the complexity of web apps in 2023 [chuckles], you know, we also see Rails used just as an API a lot with a separate front-end framework. And your controller is rendering some JSON, which I think has that harder boundary between what is the data that the server is involved with and what we want to send to our client. And I'm curious if you have any thoughts about how this rule applies in that situation. JOËL: I think I tend to see not really any difference there. If I'm building an API, typically, I'm trying to do so in a pretty RESTful manner. Maybe I'm doing a GraphQL API, and things might be different for that. But for a traditional REST API, yeah, typically, you're fetching one resource or some sort of compound resource, in which case, you're representing that with a facade object. And yep, you can generally get away, I think, with a single instance variable with, you know, a few exceptions around maybe some extra context about maybe something like the current user, or a parent object, or something like that. I guess the view is really you're using a different mechanism for rendering JSON, and there are a bunch out there that the community uses. I think I don't really see a difference between rendering to HTML versus rendering to JSON, or XML, or whatever. How about you? STEPHANIE: That's a good point. I think I'm with you where the rule still applies. But I have also seen things get really loosey-goosey [laughs] when we decide we're rendering JSON, and now we're suddenly putting the instance variables into a hash along with other stuff. But what you said was interesting about, like, sometimes you do need that extra context, right? And, like, figuring out what the best way to package that requires a bit of, like, sustained thought, I think, because it can, you know, be really easy to be like, oh well, this is the one interface that I have to get data from the server. So, if I just sneak this in here [laughs], what's the matter? But yeah, I think, you know, that's probably why rules like this exist [laughs] to help provide some guardrails and make us think a little deeper about it. JOËL: I think sometimes, as a community, we maybe exaggerate the differences between, like, RESTful HTML view and a RESTful JSON API. I tend to think of them as more or less the same. We just have, you know, a different representation the V layer of our MVC framework. Everything else still kind of lines up. STEPHANIE: Yeah, that's a really good point. I actually hadn't thought about it that way. Because I think maybe I have been influenced by the world of GraphQL [laughs] a little bit, or it's kind of hard to have a foot in both worlds, where you maybe have to context switch a little bit about, like, the paradigms, and then you find them influencing you in different ways. Because I have seen sometimes, like, what maybe initially were meant to be traditional more, like, RESTful JSON APIs kind of start to turn into that, like, how do we get what we need from this endpoint? JOËL: I'm curious how you feel in general about the facade pattern. Is that something that you've used, something that you like? STEPHANIE: I think I would say that I don't actually reach for it, like, upfront, right? Usually, I'm still trying to maybe put some things in my models [laughs]. But I have used it before once; it kind of became clear that, like, a lot of the methods on the model had to do with more really server-side concerns. And I was, like, wanting to just pull out some presentational pieces. I think the hardest part with the facade pattern is naming. I have really struggled sometimes to think of, like, it's not quite the component that makes it up. So, what is it instead? JOËL: Right. Right. I think, for me, sometimes the naming goes the other way around in that I'll start more to kind of, like, routing our resource level and try to think about, okay, this particular view of the data that I want to have, or this particular operation that I want to do, what am I actually dealing with? What is the resource here? So, maybe I'm viewing a dashboard. Or maybe what I'm doing is creating or destroying a subscription, even though those are not necessarily tables in the database. And once I have that underlying concept, then I can start creating an object that represents that, which might be a combination of multiple ActiveRecord models that represent tables. STEPHANIE: Yeah. You're actually pointing out, like, a really great use case that we see a lot, I think, is when you start to have to reach for resources, you know, that are different ActiveRecord classes. And how do you combine them together to represent the idea that you want, you know, for your feature? JOËL: I think it's more of, like, an outside-facing perspective rather than an inside-facing perspective. So, instead of looking at, hey, these are the set of ActiveRecord classes I have because these are my database tables, how can I, like, tack on to them to make this operation work? I'll sort of start almost from, like, a zoomed-out perspective, blank slate to say, "Hey, this is the kind of operation that I'm trying to do. What sort of resource am I dealing with ideally?" And, you know, maybe the idea is, okay, I'm dealing with a dashboard. I'm trying to subscribe to something...a newsletter, so the idea is I'm creating a subscription. Then, from there, I can start looking at, okay, do I have the concept of a subscription in this application? Oh, I don't. There is no subscriptions table because that's not a thing that we track in our data mode. That's fine. But I probably need at least some kind of in-memory object to track the idea of a subscription, and then maybe from there, that grows. So, I'm kind of working from the problem towards the database rather than from the database out. STEPHANIE: Yeah, I like that a lot. The outside-in phrase that you used really triggered something for me, which is being product engineers, right? Like, having a seat at the table when the feature is in that, like, ideation phase, I think is also really important because that's where you really learn what that like, abstraction is at the user level. And also, it could be a really good place to give your input if the feature is being designed in a way that doesn't really support the, you know, kind of quality of code and, like, separation that you would like. That's the part that I'm still working on and still learning how to do. But sometimes, you know, it's, like, really critical to the job to, like, be in that room and be like, these designs; what are some places that we could extract it at that level even? And kind of, like, separate things out from there rather than having to deal with it [laughs] deep in your codebase. JOËL: I think what I'm really kind of hearing and emphasizing in what you just said is the importance of not just writing code but being involved in the product and how that really enriches you because you know the problem domain. And that allows you to then write the code that you need at the different levels of the app to best model the situation you're working with. So, we've kind of gone through all the rules and talked about them. I'm curious, though, for you, are these rules that you follow in your code? How closely do you adhere to this set of rules? Is this still something that's relevant to you in 2023 as much as it was to the authors of that blog post in 2013? STEPHANIE: I have to say they're not ones that I have thought about on a daily basis, but after this conversation, maybe they will be. And I am kind of excited to maybe, like, bring this up to other people on my team and be like, "What do you think about these rules?" Just, like, revisiting them as a group or just, like, having that conversation. Because I think that's, you know, where I am most interested in is, like, is wondering how other people incorporate them into their work and hearing different opinions from the team. And I think there's a lot of, like, generative discussion that ultimately leads to better code as a result. JOËL: I think for myself, I'm not following the rules directly. But a lot of my code ends up approximating those rules anyway because of other principles that I follow. So, in practice, while my code doesn't strictly follow those rules, it does look pretty close to that anyway. STEPHANIE: I almost think this could be a great, you know, discussion for your team, too, like, if any listeners want to...not quite a book club but kind of an article club, if you will [laughs], and see how other people on your team feel about it. Because I think that's kind of where there is, like, a really sweet spot in terms of learning and development. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

In this new podcast episode we are excited to have Chris May back to delve deeper into the intricacies of refactoring.We talk about the significance of the Flocking Rules, a set of guidelines derived from "99 Bottles of OOP" by Sandi Metz and Katrina Owen. These rules provide developers with a systematic approach to refine their code by focusing on recognizing similarities, identifying minimal differences, and making straightforward changes. We also talk about the importance of taking small, incremental steps in refactoring, ensuring code health while mitigating the risks of accumulating technical debt. We reference some useful resources along the way. Last but not least, we talk about the book Chris recommended last time (episode 119): Building a Second Brain, and how it helps him stay organized and be more productive.Chapters:00:00 Intro00:20 Chris May and refactoring topic intro01:10 25% ratio refactoring02:14 Flocking rules (99 bottles of OOP)05:30 Continuously managing technical debt / Slack channel06:14 Why the flocking rules are great + 99 bottles backstory08:30 Code towards a design pattern vs go with the flow09:57 First draft - we often don't know the design upfront10:37 Python Design Patterns resource by Brandon Rhodes12:32 Take the smallest possible steps when refactoring13:57 Advantages of taking small steps15:18 'Building a second brain' book and how it works for you19:10 Obsidian as favorite note taking tool20:02 More inspiration and stories from the book22:16 Check out Refactoring Toolkit + how to reach out + thanks23:44 OutroResources:- 99 bottles of OOP book- Python Design Patterns- Building a second brain- Chris' Refactoring Toolkit- Previous episode with ChrisReach out to Chris:- Website- Mastodon- Twitter- LinkedIn- Pybites Community (we have a dedicated #refactoring channel

Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it. Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out: Adventure (try something new) Passion (topic) Profit (from recent learnings) Low-risk (applicable today) = APPL Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work. Elm (https://elm-lang.org/) Practical Object-Oriented Design in Ruby (https://www.poodr.com/) Design Patterns in Ruby (http://designpatternsinruby.com/) Quarter Life (https://www.penguinrandomhouse.com/books/579928/quarterlife-by-satya-doyle-byock/) Working Iteratively (https://thoughtbot.com/blog/working-iteratively) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: All right, I have a new-new thing and an old-new thing to share with you today. So the new-new thing is that I went to my first WNBA game [laughs] last week, which is also my third professional sports game ever, probably. I am not a sports person. But a rather new friend of mine invited me to go with her because they are fans, and so I was like, yeah, sure. I'll try anything once. And I went, and I had a great time. It was very exciting. I mean, I know the basic rules of basketball, right? Get the ball in the hoop. But I was very surprised to see how fast-paced it was. And, you know, I was like, wow, like, this is so much fun. There's so much going on, like, the music, you know, the crowd. It was very energizing. And then my friend actually told me that that was a pretty slow game, [chuckles] relative to how they normally go. And I was like, oh, wow, like, if that was slow, then I can't wait for a real competitive [laughs] game next time. So that's my new-new thing. I had a good time. Will do it again. I'm just, like, a 15-minute bike ride from the stadium for our team in Chicago. It's called The Sky. That's our WNBA team. So yeah, I'm looking forward to being basketball Stephanie, I guess. [chuckles] JOËL: That's really cool. How does the speed compare to other sports you've gone to see? STEPHANIE: I think this is why I was interested because I've really only seen baseball, for which I know very little. And that, I think, is, like, a much slower-paced kind of sport. Yeah, I have some memories of going to, like, college football games, which also, like, quite slow. I just remember standing around for a while. [laughs] So I think basketball might be the thing for me, at least in terms of engaging my interest. JOËL: You want something that actually engages you with the sport the whole time. It's not just a social event themed around occasionally watching someone do something. STEPHANIE: Yes, exactly. I also enjoyed the half-time performances, you know, there was just, like, a local dance team. And I thought that was all just very fun. And, yes, I had a lot to, you know, just, like, point to and ask questions about because there was just so much going on, as opposed to sitting and waiting, at least that was my experience [laughs] at other kinds of sports games. As for the old-new thing, now that it's summer, there is a local bar near me that does bingo every week. But it's not just normal bingo. It's called veggie bingo, which I realize is kind of confusing [chuckles] if you just, like, call it veggie bingo, but it's bingo where you win vegetables or, like, produce from local community gardens and other, you know, small batch food items. And I had a great time doing it last year. I met some new friends. It just became our weekly hangout. And so I'm looking forward to doing that again. And, I don't know, I'm just glad I have fun things to share about what's new in my world now that the weather is warm and I'm doing stuff again. I feel like there was one point in the winter where I was coming [chuckles] onto the show and sharing how I had just gotten a heated blanket in the middle of winter, and that was the most exciting thing going on for me. So it feels good to be able to bring up some new stuff. JOËL: Seasonality is a thing, right? And, you know, there are rhythms in life. And sometimes things are more fast-paced, sometimes they're a bit slower. That's really exciting. Did you take any produce home, or did you win anything when you went to play? STEPHANIE: I did. I won a big bag of produce the last time that I went. At this point, it was last season. But it was right before I was about to go on vacation. So I ended up -- JOËL: Oh no. STEPHANIE: [chuckles] Right. I ended up not being able to, you know, keep it in the fridge and just giving it away to my friends who did not win. So I think it was a good situation overall. That's my tip, is go to bingo or any kind of prize-winning hang out as a group, and then you can share the rewards. It's very exciting. Even if you don't win, you know, like, probably someone else at your table will win, and that is equally fun. JOËL: I think the closest I've been to that experience is going to play, like, bar trivia with some friends and then winning a gift card that covers our dinner and drinks for the evening. STEPHANIE: Yeah, yeah, that's great. I used to go to a local trivia around me too. The best part about bingo, though, is that it requires no skill at all. [laughs] I, yeah, didn't realize, again, how into these kinds of things I would be until I just tried it out. Like, that was...bingo is another thing I don't think I would have internally decided to go do. But yeah, my friends just have all these great ideas about fun things to do, and I will happily join them. So, Joël, what's new in your world? JOËL: So I've recently started a new client project. And one of the really interesting things that I've been doing on this project is trying to bring in multiple databases to back our ActiveRecord models. This is a Rails app. I've never done multi-database setups in Rails before. It's been a feature since Rails 6, but this is my first time interacting with that system. And, you know, it's actually pretty nice. STEPHANIE: Really? It ended up being pretty straightforward or pretty easy to set up? JOËL: Yeah. There's a little bit of futzing around you have to do with the database YAML configuration file. And then what you end up doing is setting up another base class for your ActiveRecord models to inherit from. So, typically, you have that application record that you would inherit from for your primary database. But for other databases, if you want a model to be backed by a table from that system, then you would have a separate base class that all of those models inherit from, and that's pretty much it. Everything else just works. A bunch of your Rake tasks get a little bit different. So you've got to, like, configure your setup scripts and your test scripts and all that thing a little bit differently. But yeah, you can just query, do all the normal things you do with an ActiveRecord model, but it's reading from a different database. STEPHANIE: That's really cool that it ended up being pretty painless. And I'm thinking, for the most part, as a developer, you know, working in that kind of codebase; maybe they don't really need to know too much about the details of the other databases. And they can just rely on the typical Rails conventions and things they know how to do via Rails. Do you suspect that there might be some future where that might become a gotcha or something that someone has to debug a little further because of the multi-database setup? JOËL: There are some infrastructure things, but I think I'm handling all of them upfront. So like I said, configuring various setup scripts, or test scripts, or CI, that kind of thing to make sure that they all work. Once that's all done, I think it should pretty much just work. And people can use them like they would normal ActiveRecord models. The one gotcha is that you can't join models across two different databases. You can't use ActiveRecord to write a query that would try to join two tables that are in different databases because the SQL won't allow for that. So, if you're ever trying to do something like that or you have some kind of association where you're trying to do some special join, that would not work. So, if somebody attempts that, they might get an unexpected error. Other than that, I think it just keeps working as normal, and people can treat it more or less as if it's one database. STEPHANIE: That's interesting. How do you model relationships between tables on the two different databases, then? Like, how would that work? JOËL: I've not gotten that far yet. For some things, I imagine just it's two queries. I'm not sure if the ActiveRecord associations handle that automatically for you. I think they probably will. So you probably can get away with an association where one model lives in one database. Let's say your article lives in one database, and it has many comments that live in a different database. Because then you would make one query to load the article, get the article ID, and then you would do another query to the second database and say, hey, find all the comments with this article ID, which is already, I think, what ActiveRecord does in one single database. It is making two queries. It's just that now those two queries are going to be two different databases rather than to a single one. STEPHANIE: Interesting. Okay. I did think that maybe ActiveRecord did some fancy join thing under the hood. And when you mentioned that that wouldn't be possible when the two tables are on different databases, I was kind of curious about how that would work. But that makes sense. That would be really cool if it is, you know, that straightforward. And, hopefully, it just doesn't become too big of an issue that comes back to haunt someone later. JOËL: Right. So pretty much, if there is a situation where you were relying on a JOIN, you will now have to make two separate queries and then combine the results yourself. STEPHANIE: Right. I also want to give you kudos for doing all the good work of setting it up so that, hopefully, future developers don't have to think about it. JOËL: Kudos to the Rails team as well. It's nice to have that just kind of built into the framework. Again, it's not something I've needed in, you know, a decade of doing Rails, but then, you know, now that I have run into a situation where I need that, it just works out of the box. So that's been really nice. So, a couple of weeks ago, we talked about the fact that we were going through review season and that we had to fill out reviews for ourselves then also fill out peer reviews for each other. You had brought up a really interesting conversation you had about reaching out to other people and trying to get feedback on what kind of review or feedback would be helpful for them. STEPHANIE: I did, yeah. Though, I think in this case, the person writing that feedback actually reached out to me, but certainly, it goes both ways. Spoiler alert - that person was Steph Viccari, former [laughs] host of The Bike Shed. JOËL: So Steph also reached out to me with similar questions. And that spawned a really interesting conversation around personal goals and what it looks like, particularly when it comes to what to learn next in technology. We started discussing things, and I listed out some different things that I was interested in. And then just kind of out of nowhere, Steph just pulls out this, like, oh, I noticed these four elements. And I'm going to list them out here because it's really cool. So these four elements were adventure, so trying something new. Passion, so something that's really exciting to you. Profit something where you can leverage some recent things that you've done to get more value out of some work you've already done. And then finally, low risk, something that would be applicable today. And it just kind of turns out that this makes a funny little acronym: APPL. And apples are often a symbol of learning. So that was kind of a fun coincidence. STEPHANIE: I love when someone is able to just pull apart or to tease out pieces of, you know, something that you might have just, like, kind of dumped all of into a message or something, and then to get, like, a second eye to really pick out the themes is so valuable, I think. And I'm obsessed with this framework. I think we might have come across something new that could really be helpful for a lot of other people. JOËL: It's definitely...I think it shows capacity for a higher level of thinking when someone's able to just look at a bunch of concrete things and say, wait a minute; I'm seeing some larger themes emerge from what you're talking about. And I always really appreciate it when I'm having a conversation with someone, and they're like, "Hey, I think what I'm hearing is this." And you're like, "Whoa, you're totally right. And I did not even know that that's where I was going." STEPHANIE: Absolutely. I'd love to go through this acronym and talk about a few different things that we've learned in our careers that kind of correspond with each of these elements. JOËL: Yeah, that sounds great. So I think, you know, the first one here is adventure, trying something new. So, what's something where you tried something new or adventurous that you think was worthwhile? STEPHANIE: Hosting this podcast. [laughs] It was a huge adventure for me and a really big stretch, I think. And that's what the idea of adventure evokes for me is, like, maybe it's uncharted territory for you, and you might have some reservations about it. But, you know, obviously, the flip side of an adventure is how fun and exciting and just new and stimulating it can be. And so I think, yeah, like, when I first started doing this with you, and even when you first asked me, I was pretty nervous. I was really hesitant. It took me a long time to, you know, think it over. I was like, do I want to commit to something that I have never done before, and it's, like, a pretty longer-term commitment? And I'm really glad I did it. It's certainly been an adventure. It's, you know, got its ups and downs. You know, not every week do I feel like that went really well, like, that was a great episode. Sometimes I'm like, that was just an okay episode, [laughs] and, you know, that's fine too. But I feel like this was really important in helping me feel more confident in sharing my technical opinions, helping me feel more comfortable just kind of, like, sharing where I am and not feeling like I should be somewhere else, like, some other level or have already known something. Like, the point is for us to share the journey week by week, and that was something that was really hard for me. So being on this Bike Shed adventure with you has been very valuable for me. JOËL: Yeah, it's sharing these new things we've learned along the way. STEPHANIE: Literally. Yes. What about you? Do you have something adventurous that you learned? JOËL: I think an important inflection point where I tried something new was when I learned the Elm programming language. So I had mostly done procedural languages back in the day. And then I got into Ruby, did a lot of OO. And then I got into Elm, which is statically-typed, purely functional, all these things that are kind of opposite of Ruby in some ways. But I think it shares with Ruby that same focus on developer happiness and developer productivity. So, in some ways, I felt really at home. But I had to learn just a whole new way of programming. And, one, it's cool. I have a new tool in my belt. And I think it's been a couple of years just learning how to use this language and how to be effective with it. But then afterwards, I spent a couple of years just kind of synthesizing the lessons learned there and trying to see, are there broader principles at play here? Are there ideas here that I can bring back to my work in Ruby? And then maybe even are there some ideas here that intersect with some theories and things that I know from Ruby? So maybe some ways of structuring data or structuring code from functional programming where some best practices there kind of converge on similar ideas as maybe some object-oriented best practices, or maybe some ideas from test-driven development converge on similar ideas from functional programming. And I think that's where, all of a sudden, I was unlocking all these new insights that made me a better Ruby developer because I'd gone on an adventure and done something completely out of left field. STEPHANIE: Yeah, absolutely. Do you remember what was hard about that when you first embarked on learning Elm? JOËL: All the things you're used to doing, you just can't do. So you don't have looping constructs in Elm. The only thing you can do is recursion, which, you know, it's been a long time since CS classes. And you don't typically write recursion in Ruby. So I had to learn a whole new thing. And then it turns out that most people don't write recursion. There's all these other ways of doing things that you have to learn. You have to learn to do folds or to use maps and things like that. Yeah, you're just like, oh, how do I do X in Elm? And you have to figure it out. And then maybe sometimes it turns out you're asking the wrong question. So it's like, oh, how do I do the equivalent of a for loop with array indexes in Elm to, like, iterate through a data structure? And it's like, well, kind of here's technically the way you could do that, but you would never solve a problem in that way. You've got to learn a new way of thinking, a new way of approaching problems. And I think it was that underlying new paradigm that was really difficult to get. But once I did get it, now that I have two paradigms, I think it made me a much more solid developer. STEPHANIE: Right. That sounds very humbling, too, to kind of have to invert what you thought you knew and just be in that, you know, beginner's mindset, which we've talked about a little bit before. JOËL: I think in some ways now being on the other side of it, it's similar to the insights you get from speaking multiple human languages, so being bilingual or trilingual or something like that where instead of just having assumptions about, oh, this is just how language works, because that's how your personal language works, now that you have more than one example to draw on, you can be like, oh, well, here's how languages tend to do things differently. Here's how languages are similar. And I think it gives you a much better and richer feeling for how languages work and how communication works. And similar to having multiple paradigms in programming, I think this has given me a much richer foundation now for exploring and building programs. STEPHANIE: That's really cool. I guess that actually leads quite well into the next element, which is passion. Because once you've tried some new things, you get the information of do I like this thing, or do I not like this thing? And then from there, you know, you gravitate towards the things you are passionate about to get a deeper understanding. And it becomes less about like, oh, just testing out the waters and like, knowing, hey, like, I constantly find myself thinking about this, like, let me keep going. JOËL: Yeah. Or sometimes, it's deciding what do I want to learn next? And you just pick something that's interesting to you without necessarily being like, oh, strategically, I think this is another paradigm that's going to expand my mind. Or this is going to make me, you know, help me get that promotion next quarter, purely based off of interest. Like, this sounds fun. STEPHANIE: That's really interesting because I think I actually came to it from a different angle, where one thing that I think was very helpful in my learning that came just, like, completely internally, like, no one told me to do this was reading books about design patterns. And that was something that I did a couple of years into my career because I was quite puzzled, I suppose, by my day-to-day experience in terms of wanting to solve a problem or develop a feature but not having a very good framework for steps to go about it, or not feeling very confident that I had a good strategy for doing it. It was very, for me, it felt very just kind of, like, throwing pasta to the wall and seeing what would stick. And I was really interested in reducing that pain, basically. And so that led me to read books. And, again, that was not something, like, someone was like, hey, I really think that you could benefit from this. It was just like, well, I want to improve my own experience. And, you know, some of the ones that I remember reading (And this was based off of recommendations from others kind of when I floated the idea.) was, you know, Sandi Metz's Practical Object-Oriented Design in Ruby. Design Patterns in Ruby by Ross Olsen. Those were just, like, purely out of interest. Yeah, I guess I'm curious, for you, what fun and passion look like. JOËL: Yeah, I think one thing that's a really fun side effect of passion learning is that I find that I tend to learn a lot faster and go a lot deeper, or I get more for every individual hour I put into learning just because passion or interest is such a multiplier. Similar to you, I think I went through a time where I was just gobbling up everything I could see on design patterns, and code structure, things like that. Yeah, I've always been really excited about data modeling in general and how to structure programs to make them easy to change while also not putting a high maintenance burden on it, learning those trade-offs, learning those principles, learning a lot of those ideas. I think that desire came out of some pain I felt pretty early on in my programming career, where I was just writing purely self-taught at this point from a few tutorials online. Code beyond a few hundred lines would just kind of implode under the weight of its own complexity. And so, like, I know that professional programmers are writing massively larger programs that are totally fine. So what am I missing? And so I think that sort of spurred an interest. And I've kind of been chasing that ever since. Even though I'm at the point where that is no longer a problem in my daily life, it is still an interest that I keep. STEPHANIE: Yeah. If I were to pull out another interest of yours that I've noticed that kind of seems in the same realm of, you know, you can just chase this forever, is working incrementally, right? And just all the ways that you can incorporate that into your day-to-day. And I know that's something we've talked about a lot. But I think that's really cool because, yeah, it just comes from just a pure desire on your own front to, like, see how far you can take it. JOËL: I think you pulled out something interesting there. Because sometimes, you have an interest in a whole new topic, and sometimes the interest is more about taking something I already know and just seeing can I take it to an extreme? What happens when I really go to the boundaries of this idea? And maybe I don't need to go there ever for a client project. But let me put up a proof of concept somewhere and try it out just for the fun of it to see can I take this idea, then push it to an extreme and see does it break at an extreme? Does it behave weirdly? And that is just an enriching journey in and of itself. Have you ever done, like, a...maybe not a whole learning journey but, you know, taken a few hours, or maybe even, like, some time on one of our investment Fridays to just explore some random idea and try it out? And it's like, huh, that was cool; that was a journey. And then maybe you move on to something next week because it's not like a big planned thing. But you're taking a few hours to dig into something totally random. STEPHANIE: I actually think I'm less inclined to do that than maybe you or other folks are. I find the things I choose to spend my time on do have to feel more relevant to me in the moment or at least in my day-to-day work. And I think that actually is another excellent transition into the last couple of elements in the APPL framework that we've now coined. The next being profit or, I guess, the idea of being valuable to you in your job in that moment, I suppose. Or I guess not even in that moment, but kind of connecting what you're learning to something that would provide you value. So I know you were talking about learning Elm, and now you're able to see all of the value that it has provided, but maybe at the time, that was a little bit less of your focus. But for me, I find that, like, a driver for how I choose to spend my time. Often it's because, yeah, for the goal of reducing pain. Being consultants, we work on a lot of different projects, sometimes in different frameworks, or languages, or new technologies. Like, you've mentioned having to, just now, on your new client project learning how to interact with different databases, and it sounds like older software that you might not have encountered before. And I think that ends up falling higher on my priority list depending on the timing of what I'm currently working on is, oh, like, you know, TypeScript is something that has, like, kind of come and go as my projects have shifted. And so when it comes back to working on something using it, I'm like, oh, like, I really want to focus on this right now because it has very clear value to me in the next three to six months, or however long. But I have also noticed that once I'm off of that project, that priority definitely recedes. JOËL: Yeah, I think that plays into that final element as well of the APPL, the low risk things that are applicable today that have value right now. Those tend to be things like, oh, I see that I'm going to be scheduled on a client that needs this technology next month. Maybe I should learn that, or maybe I should refresh this idea or go a little bit deeper because this is something new that I'm going to need. So, at some point, I knew that there was a Python project coming down the line. I was like, okay, well, maybe I'm going to spend a couple of Fridays digging into some Django tutorials and compare and contrast with Rails. STEPHANIE: The low-risk element is interesting to me because I found it to be a challenging balance to figure out how much time to invest in becoming really comfortable in a new technology. I find myself sometimes learning just enough to get what I need to get done. And then other times really feeling like, wow, like, I wish I knew this better because that would make my life easier, or I would just feel a lot better about what I'm doing. And kind of struggling with when to spend that time, especially when there's, you know, other expectations of me in terms of my delivery. JOËL: Yeah, that almost sounds like a contrast between technologies that fall in that low-risk bucket, like, immediately useful, versus ones that fall in the passion bucket that you're interested in taking deeply and maybe even to an extreme. STEPHANIE: That's really interesting. What I like about this list of themes that we've pulled out is that, like, one thing can fall into a number of different categories. And so it's really quite flexible. It actually reminds me of a book that I just finished reading. The book is called Quarterlife. And the thing that stuck out to me the most is the author, who is a psychotherapist; she has basically come up with two types of people, or at least two things, that end up being really big drivers of, like, human motivation and behavior. And that's stability types and meaning types, and the goal is to have a little bit of both. So you may be more inclined towards stability and wanting to learn the things that you need to know for your job, to do well in your role, kind of like we were talking about to reduce that pain, to feel a little more in control, or have a little more autonomy over your day to day and how you work. And then there's the seeking meaning, and when we talked about adventure and passion, it kind of reminded me of that. Like, those are things that we do because we want to feel something or understand something or because it's fun. And ironically, this list of four things has two that kind of fall into each category. And ultimately, the author, she, you know, was very upfront about needing both in our lives. And I thought that was a really cool distinction. And it was helpful for me to understand, like, oh yeah, like, in the early years of my career, I did really focus on learning things that would be profitable, or valuable, or low risk because those were the things that I needed in my job, like, right now. And I am now feeling stable enough to explore the meaningful aspects and feel excited by trying out things that I think I just wasn't ready for back in the day. But it actually sounds like you may kind of have a different leaning than I do. JOËL: That is really interesting. I think what was really fascinating as you mentioned those two sort of types of people. And, in my mind, now I'm immediately seeing some kind of two-dimensional graph, and now we've got four quadrants. And so are we leaning towards stability versus...was it adventure was the other one? Or meaning. STEPHANIE: Meaning, yes. JOËL: So now you've got, like, your quadrant that is high stability, high meaning, low stability, high meaning, like, all those four quadrants. And maybe these four things happen to fall into that, or maybe there's some other slightly different set of qualities that you could build a quadrant for here. One that is interesting, and I don't know how closely it intersects with this idea of stability versus meaning, is how quickly the things you learn become useful. So that low risk, like that L from APPL, those are things that are immediately useful. So you put a little bit of work learning this, and you can immediately use it on the job. In fact, that's probably why you're learning it. Whereas me going off and learning Elm is not because we've got any clients in the pipeline using Elm. It's purely for interest. Is it going to pay off? I think most learning pays off long-term, especially if it helps you build a richer understanding of the different ways software works or helps you have new mental models, new tools for doing things. And so I think, you know, 5, 6, 7 years later, learning Elm has been one of the highest payoff things that I've done to kind of take my coding career to the next level. That being said, I would not have seen that at the time. So the payoff is much more long-term. How do you kind of navigate when you're trying to learn something, whether you want something with a short-term payoff or a longer-term payoff? STEPHANIE: Yeah, that's so interesting. I wonder if there was maybe someone who could have helped you identify the ways that Elm could have possibly paid off. And I know, you know, you're looking back on it in retrospect, and it's easy to see, especially after many years and a lot of deep thinking about it. But kind of referring back to this idea of seeking meaning and that just being important to feeling happy at your job, like, maybe it was just valuable because you needed to scratch that itch and to experience something that would be interesting or stimulating in that way to prevent burning out or something like that. JOËL: Oh, I like that. So the idea that you're learning a thing, not specifically because you're expecting some payoff in the long term but because of the joy of learning, is reward in and of itself, and how that actually keeps you fresh in the moment to keep going on a career that might, you know, last 5, 10, 20, 30 years, and how that keeps you refreshed rather than like, oh, but, like, I'm going to see a payoff in five years where now, all of a sudden, I'm faced with a problem. And I can be like, ah, yes, of course, monads are what we need here. And that's a nice side effect, but maybe not the main thing you look for when you're going for something in that passion bucket. STEPHANIE: Yeah, absolutely. To go back to your question a little bit, I had mentioned that I was wondering if there was someone who could help point out ways that your interests might be useful. And I think that would be a strategy that I would try if I find myself in that conundrum, I suppose, of, like, being like, hey, like, this is really interesting to me. I'm not able to see any super immediate benefits, but maybe I can go find an expert in this who can share with me, like, from their experience, what diving deep into that topic helped them. And if that's something that I need to then kind of justify to a manager or just kind of explain, like, hey, this is why I'm spending my time doing this is because of this insight that I got from someone else. That would be, I think, a really great strategy if you find yourself needing to kind of explain your reasoning. But yeah, I also think it's, like, incredibly important to just have passion and joy in your work. And that should be a priority, right? Even if it's not immediately clear, the tangible or valuable to the company benefits in the current moment. JOËL: And I think what I'm hearing is that maybe it's a bit of a false premise to say there are some things that you follow for passion that only pay off in the long term. Because if you are in it for passion, then you're getting an immediate payoff regardless. You may also get an additional payoff in the long term. But you're absolutely getting some kind of payoff immediately as well. STEPHANIE: Yeah, I think that's true for adventure because knowing what you don't like is also really valuable information. So, if you try something and it ends up not panning out for you, you know, I think some people might feel a little bit disappointed or discouraged. They think, oh, like, they kind of wasted time. But I don't know; I think that's all part of the discovery process. And that brings you closer and closer to, yeah, knowing what you want out of your learning and your career. JOËL: So I'm really curious now. This whole, you know, APPL framework came out of a very random conversation. Is this something that maybe you're going to take into your own sort of goal-setting moving forward? Maybe try to identify, like, okay, what is something adventurous that I want to do, something I want to do for passion, something that I think for profit, and then something low risk? And then maybe have that inform where you put some energy in the next quarter, the next year, whatever timeline you're planning for. STEPHANIE: Yeah, I thought about this a little bit before we started recording. But one very loose goal of mine...and this actually, I think, came up a little more tangibly after coming back from RubyKaigi and being so inspired by all of the cool open-source tooling and hearing how meaningful it was for people to be working on something that they knew would have an impact on a lot of people in their development experience. Having an impact is something that I feel very passionate about and very interested in. And the adventure part for me might be, like, dabbling a little bit into open-source tooling and seeing if there might be a project that I would be interested or comfortable in dipping my feet into. What about you? Do you have anything in the near or long-term future that might fall into one of these buckets? JOËL: So I do have a list of things. I don't know that I will pursue all of them or maybe any of them. But here's my kind of rough APPL here. So something adventurous, something new would be digging into the language Rust. Again, the idea is to try a completely new paradigm, something low-level, something typed, something that deals with a lot of memory, something that does well with concurrency and parallelism. These are all things that I've not explored quite as much. So this would be covering new ground. Something that is a passion, something that's interesting to me, would be formal methods, so I'm thinking maybe a language like TLA+ or Alloy. Data modeling, in general, is something that really excites me. These techniques that I think build on some of the ideas that I have from types but that go, like, to an extreme and also in a slightly different direction are really intriguing to me. So, if there's something that maybe I'm staying up in the evenings to do, I think that might be the most intriguing thing for me right now. Something that might be more profitable, I think, would be digging into the world of data science, particularly looking at Notebooks as a technology. Right now, when I need to crunch data, I'm mostly just doing spreadsheets. But I think there are some really cool things that we could do with Notebooks that come up in client work. I manage to do them when you're with a random command-line script or sometimes with Excel. But I think having that tool would probably be something that allows me to do that job better. And then, finally, something low-risk that I know we could use on a client project would be digging in more into TypeScript. I know just enough to be dangerous, but we do TypeScript all the time. And so, mastering TypeScript would definitely be something that would pay off on a client project. STEPHANIE: I love that list. Thank you for sharing. JOËL: Also, I just want to note that there are only four things here. It doesn't fully spell APPL because there's no E at the end. And so when I see the acronym now, I think it looks like a stock ticker. STEPHANIE: It really does. But I think it's pretty trendy to have an acronym that's basically a word or a noun but then missing a vowel so... JOËL: Oh, absolutely. Time to register that applframework.com domain. STEPHANIE: Yeah, I agree. I also love what you said. You called it a rough APPL. And that was very [laughs] evocative for me as well. And just thinking about an apple that someone has, like, bitten into a little bit [laughs] and has some rough edges. But yeah, I hope that people, you know, maybe find some insight into the kinds of learnings and goals that they are interested in or are thinking about. And using these themes to communicate it to other people, I think, is really important, or even to yourself. Maybe yourself first and then to others because that's how your co-workers can know how to support you. JOËL: That's really interesting that you are thinking of it in terms of a tool for communication to others. I think when I first encountered this idea, it was more as a tool of self-discovery, trying to better understand why I was interested in different things and maybe better understanding how I want to divide up the energy that I have or the time that I have into different topics. But I can definitely see how that would be useful for communicating with team members as well. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sam and Ryan talk about updating Build UI to support lifetime memberships. They chat about the site's current architecture, the strengths and weaknesses of objects vs. functions, how the full stack JavaScript community could benefit from a proper model layer like ActiveRecord, the challenges of using GraphQL on the backend, Prisma, and more.Topics include:0:00 - Intro1:09 - Current architecture + single purchase6:30 - Rails model layer. OOP vs functional13:55 - What are classes good at, what are functions good at23:53 - Composition vs. inheritance31:44 - graphql. overfetching is not a problem on the backend. prisma.Links:Go Ahead, Make a Mess by Sandi Metz

What is Nick? Well, Nick has a thing! He tells Brittany all about his new project: Scarpe. From there, Brittany steals some free consulting from Nick when she presents an authentication problem she is trying to tackle on a side project. Nick shares his experience at a coveted Sandi Metz workshop and they wrap on a personal update from Brittany. Show Notes: Shoes! The easiest little GUI toolkit, for Ruby (http://shoesrb.com/) why-archive/nobody-knows-shoes.pdf at master - GitHub (https://github.com/whymirror/why-archive/blob/master/shoes/nobody-knows-shoes.pdf) Glimmer DSL for SWT 4.26.0.1 - GitHub (https://github.com/AndyObtiva/glimmer-dsl-swt) scarpe-team / scarpe (https://github.com/scarpe-team/scarpe) schwad (@schwad_rb) / Twitter (https://twitter.com/schwad_rb?lang=en) Hackety Hack - Wikipedia (https://en.wikipedia.org/wiki/Hackety_Hack) Bullet Train: The Ruby on Rails SaaS Template (https://bullettrain.co/) CanCanCan - The authorization Gem for Ruby on Rails (https://github.com/CanCanCommunity/cancancan) Sandi Metz (https://sandimetz.com/) Sponsored By: Honeybadger (https://www.honeybadger.io/) Recent studies found that downtime can cost $427 per minute for small businesses, and up to $9,000 per minute for medium-sized businesses. That's every single minute!  A monthly subscription with Honeybadger helps you prevent costly downtime by giving you all the monitoring you need in one easy-to-use platform so you can quickly understand what's going on and how to fix it, which helps you stay in business. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free! Miro (https://miro.com/ruby/) Brainstorm, solve problems, and reach better decisions faster as a team on Miro's visual collaboration platform. Whether you use it for Agile rituals, technical diagramming, or as a project hub, Miro brings together developers and their workflows in one shared space. Check out The Ruby on Rails Podcast community board at miro.com/ruby/ (https://miro.com/ruby/) where you can learn about the hosts, leave feedback, and more!

Joël has been pondering another tool for thought from Maggie Appleton: diagramming. What does drawing complex things reveal? Stephanie has updates on how Soup Group went, plus a clarification from last week's episode re: hexagons and tessellation. They also share the top most impactful articles they read in 2022. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Maggie Appleton tools for thought (https://maggieappleton.com/tools-for-thought) Squint test (https://www.youtube.com/watch?v=8bZh5LMaSmE&themeRefresh=1) Cardinality of types (https://guide.elm-lang.org/appendix/types_as_sets.html) Honeycomb hexagon construction (https://www.nature.com/articles/srep28341) Coachability (https://cate.blog/2021/02/22/coachability/) Strangler Fig Pattern (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) Finding time to refactor (https://thoughtbot.com/blog/finding-the-time-to-refactor) Parse don't validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) Errors cluster around boundaries (https://thoughtbot.com/blog/debugging-at-the-boundaries) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot that has basically become a two-person book club between me and Joël. [laughter] JOËL: I love that. STEPHANIE: I'm so sorry, I had to. I think we've been sharing so many things we've been reading in the past couple of episodes, and I've been loving it. I think it's a lot of the conversations we have off-air too, and now we're just bringing it on on-air. And I am going to lean into it. [laughs] JOËL: I like it. STEPHANIE: So, Joël, what's new in your world? JOËL: So, in a recent episode, I think it was two episodes ago, you shared an article by Maggie Appleton about tools for thought. And I've kind of been going back to that article a few times in the past few weeks. And I feel like I always see something new. And one tool for thought that Maggie explicitly mentions in the article is diagramming, and that's something that we've used as an industry for a long time to deal with conditional logic is just writing a flow diagram. And I feel like that's such a useful tool sometimes to move away from code and text into visuals and draw your problem rather than write your problem. It's often useful either when I'm trying to figure out how to structure some of my own code or when I'm reviewing a PR for somebody else, and something just feels not quite right, but I'm not quite sure what I want to say. And so drawing the problem all of a sudden might give me some insights, might help me identify why does something feel off about this code that I can't quite put into words? STEPHANIE: What does drawing complex things reveal for you? Is there a time where you were able to see something that you hadn't seen before? JOËL: One thing I think it can make more obvious is the shape of the problem. When we describe a problem in words, sometimes there's a sense of like, okay, there are two main paths through this problem or something. And then when we do our code, we try to make it DRY, and we try all these things. And it's really hard to see the flow of logic. And we might actually have way more paths through our code than are actually needed by the initial problem definition. I think we talked about this in a past episode as well, structuring a multi-step form or a wizard. And oftentimes, that is structured way more complex than it needs to be. And you can really see that difference when you draw out a flow diagram, the difference between forcing everything down a single linear flow with a bunch of little independent conditions versus branching up front three or four or five ways, however many steps you have. And then, from there, it's just executing code. STEPHANIE: I have two thoughts here. Firstly, it's very tragic that this is an audio medium only [laughs] and not also a visual one. Because I think we've joked in the past about when we've, you know, talked about complex problems and branching conditionals and stuff like that, like, oh, like, if only we could show a visual representation to our listeners. [laughs] And secondly, now that makes a lot more sense why there are so many whiteboards just hanging out in offices everywhere. [laughs] JOËL: We should use them more. It's interesting you mentioned the limitations of an audio format that we have. But even just describing the problem in an audio format is different than implementing it in code. So if I were to describe a problem to you that says, oh, we have a multi-step form that has three different steps to it, in that description, you might initially think, oh, that means I want to branch three ways up front, and then each step will need to do some processing. But if you look at the implementation in the code, maybe whoever coded it, and maybe that's yourself, will have done it totally differently with a lot more branching than just three up front because it's a different medium. STEPHANIE: That's a really good point. I also remember reading something about how you can reason about how many branches a piece of code might have if you just look at the structure of the lines of code in your editor if you either step away from it and are just looking at the code not really able to see the text itself but just the shape that it makes. If you have some shorter lines and then a handful of longer lines, you might be able to see like, oh, like these are multiple conditionals happening, which I think is kind of related to what you're saying about taking a piece of code and then diagramming it out to really see the different paths. And I know that that can also be obscured a little bit if you are stylistically using different syntax. Like, if you are using a guard clause to return early, that's a conditional, but it gets a bit hidden from the visual representation than if you had written out the full if statement, for example. JOËL: I think that's a really interesting distinction that you bring up because a lot of languages provide syntactic sugar for common conditional tasks that we do. And sometimes, that syntactic sugar will almost obfuscate the fact that there is a conditional happening at all, which can be great in a lot of cases. But when it comes to analyzing and particularly comparing different implementations, a second conversion that I like to do is converting all of the conditional code to some standardized form, and, for me, that's typically just your basic if...elsif...else expressions. And so any fancy Boolean operators we're doing, any safe navigation that we're doing around nil, maybe some inline conditionals, early returns, things like that, all of the implicit elses that are involved as well, putting them all into some normalized form then allows me to compare two implementations with each other. And sometimes, two approaches that we initially thought were identical, just with different syntax, turned out to have slightly different behavior because maybe one has this sort of implicit branch that the other one doesn't. And by converting to a normalized syntax, all of a sudden, this difference becomes super obvious. To be clear, this is not something I do necessarily in the actual code that I commit, not necessarily writing everything long-form. But definitely, when I'm trying to think about conditional code or analyzing somebody else's code, I will often convert it to long-form, some normalized shape so that I can then see some things about it that were not obvious in the final form. Or to make a comparison with something else, and then you can compare apples to apples and say, okay, both these approaches that we're considering in normalized form, here's what they look like. There's some difference here that we do care about or don't care about. STEPHANIE: That's really interesting. I find it very curious that there is a value in having the long-form approach of writing the code out and being able to identify things. But then the end result that we commit might not look like that and be shortened and be kind of, quote, unquote, "polished," or at least condensed with syntactic sugar. And I'm kind of wondering why that might be the case. JOËL: I think a lot of that will come down to your personal or your company's style guide. Personally, I think I do lean a little bit more towards a slightly more explicit form. But there are plenty of times that I will use syntactic sugar as well, as long as everybody knows what it does. But sometimes, it will come at the cost of other analysis techniques. You had mentioned the squint test earlier, which I believe is a term coined by Sandi Metz. STEPHANIE: I think it might be. That rings a bell. JOËL: And that is a benefit that you get by writing explicit conditionals all the time. But sometimes, it is much nicer to write code that is a little bit more terse. And so you have to do the trade-offs there. STEPHANIE: Yeah, that's a really good point. JOËL: So that's two of the sort of three formats that I was thinking about for converting conditional code to gain more insight. The other format is honestly a little bit weird. It's almost a stretch. But from my time spent working with the Elm language, I learned how to use its type system, which uses a concept called algebraic data types, or some languages will call these tagged unions, some languages will call these sum types. This concept goes by a lot of different names. But they're used to define types into model data. But there's a really fun property, which is that you can model conditional code using this as well. And so you can convert executable code into these algebraic data types. And now, you can apply a lot of tools and heuristics that you have from the data modeling world to this conditional code. STEPHANIE: Do you have a practical example? JOËL: So a classic thing that data modelers will say is you should make impossible states impossible. So in practice, this means that when you define a type using these algebraic data types, you should not be able to create more distinct values than are actually valid in this particular system. So, for example, if a value is required to always be present for something and there's no way in the system for a value to become not present, then don't allow it to be nullable. We do something similar when we design a database schema when we put a null false on a column because we know that this will never be null. And so, why allow nulls when you know they should never be there? So it's a similar thing with the types. This sort of analysis that you can do looking at...the fancy term is the types cardinality. I'll link to an article that digs into that for people who are curious. But that can show you whether a type can represent, let's say, ten possible values, but the domain you're trying to model only has 5. And so when there's that discrepancy, there are five valid values that can be modeled by your type and an additional extra five that are not valid that just kind of shake out from the way you implemented things. So you can take that technique and apply it to a conditional that you've converted to algebraic data type form. And that can help find things like paths through your conditional code that don't line up with the problem that you're trying to solve. So going back to the example I talked about earlier of a multi-step form with three different steps, that's a problem that should have three paths through your conditional. But depending on your implementation, if it's a bunch of independent if clauses, you might have a bit of a combinatorial explosion. And there might be 25 different paths through that chunk of code. And that means three of them are the ones that your problem wants, and then the extra 22 are things that should quote, unquote, "never happen," but we all know that they eventually will. So that kind of analysis can help maybe give you pointers to the fact that your current structure is not well-suited to the problem that you're trying to solve. STEPHANIE: I think another database schema example that came to mind for me was using an enum to declare acceptable values for a field. And, yeah, I know exactly what you mean when working with code where you might know, because of the way the business works, that this thing is impossible, and yet, you still have to either end up coding defensively for it or just kind of hold that complexity in your head. And that can lead to some gnarly situations, and it makes debugging down the line a lot more difficult too. JOËL: It definitely makes it really hard for somebody else to know the original intention of the code when a conditional has more paths through it than there actually are actual paths in the problem you're trying to solve. Because you have to load all of that in your head, and our programmer brains are trained to think about all the edge cases, and what if this condition fires but this other one doesn't? Could that lead to a bug? Is that just a thing that's like, well, but the inputs will never trigger that, so you can ignore it? And if there are no comments to tell you, and if there are comments, then do you trust them? Because it -- STEPHANIE: Yes. [laughter] I'll just jump in here and say, yeah, I have seen the comments then conflict with the code as well. And so you have these two sources of information that are conflicting with each other, and you have no idea what is true and what's not. JOËL: So I'm a big fan of structuring conditional code such that the number of unique paths through a set of conditions is the same as the sort of, you might say, logical paths through the problem domain that we haven't added extra paths, just sort of accidentally due to the way we implemented things. STEPHANIE: Yeah. And now you have three different ways to visualize that information in your head [laughs] with these mental models. JOËL: Right. So from taking code that is conditional code and then transforming it into one of these other representations, I don't always do all three, but there are tools that I have. And I can gain all sorts of new insights into that code by looking at it through a completely different lens. STEPHANIE: That's super cool. JOËL: So the last episode, you had mentioned that you were going to try a soup club. How did that turn out? STEPHANIE: It turned out great. It was awesome, the inaugural soup group. I had, I think, around eight people total. And I spent...right after work, I went straight to chopping celery [laughs] and onions and just soup prepping. And it was such a good time. I invited a different group of friends than normally come together, and that turned out really well. I think we all kind of had at least one thing in common, which was my goal was just to, you know, have my friends come together and meet new people too. And we had soup, and we had bread. Someone brought a spiced crispy chickpea appetizer that went really well inside of our ribollita vegetable bean soup. And then I had the perfect amount of leftovers. So after making a really big batch of food and spending quite a long time cooking, I wanted to make sure that everyone had their fill. But it was also pretty nice to have two servings left over that I could toss in the freezer just for me and as a reward for my hard work. And then it ended up working out really well because I went on vacation last week. And the night we got back home, we were like, "Oh, it's kind of late. What are we going to do for dinner?" And then I got to pull out the leftover soup from my freezer. And it was the perfect coming home from a big trip, and you have nothing in your fridge kind of deal. So it worked out well. JOËL: I guess that's the advantage of hosting is that you get to keep the leftovers. STEPHANIE: It's true. JOËL: You also have to, you know, make the soup. [laughs] STEPHANIE: Also true. [laughs] But like I said, it wasn't like I had so much soup that I was going to have to eat it every single day for the next week and a half. It was just the amount that I wanted. So I'm excited to keep doing this. I'm hoping to do the next soup group in the next week or two. And then some other folks even offered to host it for next time. So maybe we might experiment with doing a rotating thing. But yeah, it has definitely brought me joy through this winter. JOËL: That's so lovely. What else has been new in your world? STEPHANIE: I have a clarification to make from last week's episode. So last week, we were talking about hexagons and tessellation. And we had mentioned that hexagons and triangles were really strong shapes. And we mentioned that, oh yeah, you can see it in the natural world through honeycomb. And I've since learned that bees don't actually build the hexagon shape themselves. That was something that scientists did think to be true for a little bit, that bees were just geometrically inclined, but it turns out that the accepted theory for how honeycomb gets its shape is that bees build cylindrical cells that later transform into hexagons, which does have a lot of surface area for holding the honey, though the process itself is actually still debated by scientists. So there's some research that has supported the idea that it's formed through physical forces like the changing temperature of the wax that transforms it from a cylinder shape into a hexagon, though, yeah, apparently, the studies are still a bit inconclusive. And the last scientific paper I read about this, just to really get my facts straight [laughs], they were kind of exploring aspects of bee behavior that led to the hexagons eventually forming because that does require that the cylinders are perfectly the same size and are at least built in a hexagonal pattern, even though the cells themselves are not hexagons. JOËL: Fascinating. So it sounds like it's either a social thing where the bees do it based off of some behavior. Or if it's a physical thing, it's some sort of like hexagons are a natural equilibrium point that everything kind of trends to, and so as temperature changes, the beehive will naturally trend towards that. STEPHANIE: Yeah, exactly. I have a good friend who is a beekeeper, so I got to pick her brain a little bit about honeycomb. [laughs] MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: So in the past few episodes, we've talked about books we're reading, articles that we're reading. This is kind of turning into the Stephanie and Joël book club. STEPHANIE: I love it. JOËL: That got me thinking about things that I've read that were impactful in the past year. So I'm curious for both of us what might be, let's say, the top two or three most impactful articles that you read in 2022. Or maybe to put it another way, what are the top two or three articles that you reference the most in conversations with other people? STEPHANIE: So listeners might not know this, but I actually joined thoughtbot early last year in February. So I was coming into this new job, and I was so excited to be joining an organization with so many talented developers. And I was really excited to learn from everyone. So I kind of came in with really big goals around my technical growth. And the end of the year just passed, and I got to do a little bit of reflection. And I was quite proud of myself actually for all the things that I had learned and all the ways that I had grown. And I was reminded of this blog post that I think I had in the back of my mind around "Coachability" by Cate, and she talks about how coaching is different from mentorship. And she provides some really cool mental models for different ways of providing support to your teammates. Let's say mentorship is teaching someone how to swim, and maybe helping someone out with a task might be throwing them a life raft. Coaching is more like seeing someone in the water, but you are up on a bridge, and you are kind of seeing all of their surroundings. And you are identifying ways that they can help themselves. So maybe there's a branch, a tree branch, a few feet away from them. And can they go grab that tree branch? How can they help themselves? So I came to this new job at thoughtbot, and I had these really big goals. But I also knew that I wanted to lean on my new co-workers and just be able to not only learn the things that I was really excited to learn but also trust that they had my best interests in mind as well and for them to be able to point out things that could help my career growth. So the idea of coachability was really interesting to me because I had been coming from a workplace that had a really great feedback culture. But I think this article touches on what to do with feedback in a way that I hadn't seen before. So she also describes being coachable as having two axes, one of them being receptiveness to feedback and the other being actionability in response to feedback. So receptiveness is when you hear feedback; do you listen to it? Do you work through it? How does that feedback fit into your mental model of your goals and your skills? And then actionability is like, okay, what do you do with that? How do you change your behavior? How do you change the way you approach problems? And those two things in mind were really helpful in terms of understanding how I respond to feedback and how to really make the most of it when I receive it. Because there are times when I get feedback, and I don't know what to do with it, you know, maybe it just wasn't specific enough. And so, in that sense, I want to work on my actionability and figuring out, okay, someone said that testing would be a really great opportunity for me to learn. But what can I do to learn how to write better tests? And that might involve figuring that out on my own, like, what strategies work for me. Or that might involve asking them, being like, "What do you recommend?" So yeah, I had this really big year of growth. And I'm excited to keep this mental model in mind when I feel like I might be stuck and I'm not getting the growth that I want and using those axes to kind of determine how to move forward. JOËL: I think the first thing that comes to mind for me is the episode that you and I did a while back about the value of precise language. For example, you talked about the distinction between coaching and mentorship, which I think in sort of colloquial speech, we kind of use interchangeably. But having them both mean different things, and then being able to talk about those or at least analyze yourself through the lens of those two words, I think, is really valuable and may be helping to drive either insights or actions that you can take. And similarly, this idea of having two different axes for receptiveness versus...was it changeability you said was the other one? STEPHANIE: Actionability. JOËL: Actionability, I think, is really helpful when you're feeling stuck because now you can realize, oh, is it because I'm not accepting feedback or not getting good feedback? Or is it that I'm getting feedback, but it's hard to take action on it? So just all of a sudden, having those terms and having that mental model, that framework, I feel like equips me to engage with feedback in a way that is much more powerful than when we kind of used all those terms interchangeably. STEPHANIE: Yeah, exactly. I think that it's very well understood that feedback is important and having a good feedback culture is really healthy. But I think we don't always talk about the next step, which is what do you do with feedback? And with the help of this article, I've kind of come to realize that all feedback is valuable, but not all of it is good. And she makes a really excellent point of saying that the way you respond to feedback also depends on the relationship you have with the person giving it. So, ideally, you have a high trust high respect relationship with that person. And so when they give you feedback, you are like, yeah, I'm receptive to this, and I want to do something about it. But sometimes you get feedback from someone, and you might not have that trust in that relationship or that respect. And it just straight up might not be good feedback for you. And the way you engage with it could be figuring out what part of it is helpful for me and what part of it is not? And if it's not helpful in terms of helping your growth, it might at least be informative. And that might help you learn something about the other person or about the circumstances or environment that you're in. JOËL: Again, I love the distinction you're making between helpful and informative. STEPHANIE: Yeah. I think I had to learn that the hard way this year. [laughs] So, yeah, I really hope that folks find this vocabulary or this idea...or consider it when they are thinking about feedback in terms of giving it or receiving it and using it in a way that works for them to grow the way they want to. JOËL: I'm curious, in your interactions, and learning, and growth over the past year, do you feel like you've leaned a little bit more into the mentorship or the coaching side of things? What would you say is the rough percentage breakdown? Are we talking 50-50, 80-20? STEPHANIE: That's such a good question. I think I received both this year. But I think I'm at a point in my career where coaching is more valuable to me. And I'm reminded of a time a few months into joining thoughtbot where I was working and pairing with a principal developer. And he was really turning the workaround on me and asking, like, what do I want to do? What do I see in the code? What areas do I want to explore? And I found it really uncomfortable because I was like, oh, I just want you to tell me what to do because I don't know, or at least at the time, I was really...I found it kind of stressful. But now, looking back on it and with this vocabulary, I'm like, oh, that's what true coaching was because I gained a lot of experience towards my foundational skill set of figuring out how to solve problems or identifying areas of refactoring through that process. And so sometimes coaching can feel really uncomfortable because you are stretching outside of your comfort zone and that your coach is hopefully supporting you but not just giving you the help but teaching you how to help yourself. JOËL: That's a really interesting thing to notice. And I think what I'm hearing is that coaching can feel less comfortable than mentoring because you're being asked to do more of the work yourself. And you're maybe being stretched in some ways that aren't exactly the same as you would get in a more mentoring-focused scenario. Does that sound right? STEPHANIE: Yeah, I think that sounds right because, like I said, I was also receiving mentorship, and I learned about new things. But those didn't always solidify in terms of empowering me next time to be able to do it without the help of someone else. Joël, what was an article that really spoke to you this last year? JOËL: So I really appreciated an article by Adrianna Chang, who's a developer at Shopify, about "Refactoring Legacy Code with the Strangler Fig Pattern." And it talks about this approach to moving refactoring code from one implementation to another. And it's a longer-ranged process, and how to do so incrementally. And a big theme for me this year has been refactoring and incremental change. I've had a lot of conversations with people about how to spot smaller steps. I've written an article on working incrementally. And so I think this was really nice because it gave a very particular technique on how to do so with an example. And so, because these sorts of conversations kept coming up this year, I found myself referencing this article all the time. STEPHANIE: I really loved this article too. And this last year, I also saw a strangler fig tree for the first time in real life in Florida. And I think that was after I had read this article. And it was really cool to make the connection between something I was seeing in nature with a pattern in software development or technique. JOËL: We have this metaphor, and now you get to see the real thing. I was excited because, at RubyConf Mini this year, I actually got to meet Adrianna. So it was really cool. It's like, "Hey, I've been referencing your article all year. It's super cool to meet you in person." STEPHANIE: That's awesome. I love that, just being able to support members of the community. What I really liked about the approach this article advocated for is that it allowed developers to continue working. You don't have to halt everything and dedicate time to refactor and not get any new feature work done. And that's the beauty of the incremental approach that you were talking about earlier, where you can continue development. Sometimes that refactoring might be paused for some reason or another, but then you can pick back up where you left off. And that is really intriguing to me because I think this past year, I was working on a client where refactoring seemed like something we had to dedicate special time for. And it constantly became tough to prioritize and sell to stakeholders. Whereas if you incorporate it into the work and do it in a way that doesn't stop the show [laughs] from going on, it can work really well and work towards sustainability and maintenance, which is another thing that we've talked a lot about on the show. JOËL: Something that's really powerful, I think, with that technique is that it allows you to have all of the intermediate steps get merged into your main branch and get shipped. So you don't have to have this long-running branch with a big change that's constantly going stale, and you're having to keep in sync with the main branch. And, unfortunately, I've often seen even this sort of thing where you create a long-running branch for a big change, a big refactor, and eventually, it just gets abandoned, and you have not locked in any wins. STEPHANIE: Yeah, that's the worst of both worlds where you've dedicated time and resources and don't get the benefits of that work. I also liked that the strangler fig pattern kind of forces you to really understand the existing code. I think working with legacy code can be really challenging. And a lot of people don't like to do it because it involves a lot of spelunking and figuring out, okay, what's really going on. But in order to isolate the pieces to, you know, slowly start to stop making calls to the old code, it requires that you take a hard look at your legacy code and really figure it out. And I honestly think that that then informs the new code that you write to better support both the old feature and also any new features to come. JOËL: Definitely. The really nice thing about this pattern is that it also scales up and down. You can do this really small...even as part of a feature branch; maybe it's just part of your development process, even if you don't necessarily ship all of the intermediate steps. But it helps you work more incrementally and in a tighter scope. And then you can scale it up as big as changing out entire sections of a framework or...I think Adrianna's example is like switching out a data source. And so you can do some really large refactors. But then you could do it as well on just a small feature. I really like using this pattern anytime you're doing things like Rails upgrades, and you've got old gems that might not convert over where it's like, oh, the community abandoned this gem between Rails 4 and Rails 5. But now you need sort of a bridge to get over. And so I think that pattern is particularly powerful when doing something like a Rails upgrade. STEPHANIE: Very Cool. JOËL: So what would be a second article that was really impactful for you in the past year? STEPHANIE: So, speaking of refactoring, I really enjoyed a blog post called Finding Time to Refactor by a former thoughtboter, German Velasco. He makes a really great point that we should think of completeness in our work, not just when the code works as expected or meets the product requirements, but also when it is clear and maintainable. And so he really advocates for baking refactoring into just your normal development process. And like I said, that goes back to this idea that it can be incremental. It doesn't have to be separate or something that we do later, which is kind of what I had learned before coming to thoughtbot. So when I was also speaking about just my technical growth, this shift in philosophy, for me, was a really big part of that. And I just started kind of thinking and seeing ways to just do it in my regular process. And I think that has really helped me to feel better about my work and also see a noticeable improvement in the quality of my code. So he mentioned the three times that he makes sure to refactor, and that is one when he is practicing TDD and going through the red-green-refactor cycle. JOËL: It's in the name. STEPHANIE: [laughs] It really is. Two, when code is difficult to understand, so if he's coming in and fixing a bug and he pays the tax of trying to figure out confusing code, that's a really great opportunity to then reduce that caring cost for others by making it clear while you're in there, so leaving things better than you found it. And then three, when the existing design doesn't work. We, I think, have mentioned the adage, "Make the change easy, and then make the easy change." So if he's coming in to add a new feature and it's just not quite working, then that's a really good opportunity to refactor the existing design to support this new information or new concept. JOËL: I like those three scenarios. And I think that second one, in particular, resonated with me, the making things easier to understand. And in the sort of narrower sense of the word refactoring, traditionally, this means changing the structure of the code without changing its behavior. And I once had a situation where I was dealing with a series of early return expressions in a method that were all returning Booleans. And it was really hard because there were some unlesses, some ifs, some weird negation happening. And I just couldn't figure out what this code was doing. STEPHANIE: Did you draw a diagram? [laughs] JOËL: I did not. But it turns out this code was untested. And so I pretty much just tried, like, it took two Booleans as inputs and gave back a Boolean. So I just tried all the combinations, put it in, saw what it gave me out, and then wrote tests for them. And then realized that the test cases were telling me that this code was always returning false unless both inputs were true. And that's when it kind of hits me, it's like, wait a minute, this is Boolean AND. We've reimplemented Boolean AND with this convoluted set of conditional code. And so, at the end there, once I had that test coverage to feel confident, I went in and did a refactor where I changed the implementation. Instead of being...I think it was like three or four inline conditionals, just rewrote it as argument one and argument two, and that was much easier to read. STEPHANIE: That's a great point. Because the next time someone comes in here, and let's say they have to maybe add another condition or whatever, they're not just tacking on to this really confusing thing. You've hopefully made it easier for them to work with that code. And I also really appreciated, you know, I was mentioning how this article affected my thought process and how I approach development, but it's a really great one to share to then foster a culture of just continuous refactoring, I guess, is what I'm going to call it [laughs] and hopefully, avoiding having to do a massive rewrite or a massive effort to refactor. The phrase that comes to mind is many hands make light work. And if we all incorporated this into our process, perhaps we would just be working all around with more delightful code. Joël, do you have one more article that really stood out to you this year? JOËL: One that I think I really connected with this year is "Parse, Don't Validate" by Alexis King. Long-time listeners of the show will have heard me talk about this a little bit with Chris Toomey when he was a guest on the show this past fall. But the gist of the article is that the process of parsing is converting a broader type into a narrower type with the potential for errors. So traditionally, we think of this as turning a string which a string is very broad. All sorts of things are strings, and then you turn it into something else. So maybe you're parsing JSON. So you take a string of characters and try to turn it into a Ruby hash, but not all strings are valid hashes. So there's also the possibility for errors. And so, JSON.parse() could raise an error in Ruby. This idea, though, can be then expanded because, ideally, you don't want to just check that a value is valid for your stricter rules. You don't want to just check that a string is valid JSON and then pass the string along to the next person. You actually want to transform it. And then everybody else down the line can interact with that hash and not have to do a check again is this valid JSON? You've already validated that you've already converted it into a hash. You don't need to check that it's valid JSON again because, by the nature of being a hash, it's impossible for it to be invalid. Now, you might have some extra requirements on that hash. So maybe you require certain keys to be present and things like that. And I think that's where this idea gets even more powerful because then you can kind of layer this on top and have a second parsing step where you say, I'm going to parse this hash into, let's say, a shopping cart object. And so, not all Ruby hashes are valid shopping carts. And so you try to take a broader value and coerce it into a narrower value or transform it into a narrower value and potentially raise an error for those hashes that are not valid shopping carts. And then, whoever down the line gets a shopping cart object, you can just call items on it. You can call price on it. You don't need to check is this key present? Because now you have that certainty. STEPHANIE: This reminds me of when I was working with TypeScript in the summer of last year. And having come from a dynamically-typed language background, it was really challenging but also really interesting to me because we were also parsing JSON. But once we had transformed or parsed that data into this domain object, we had a lot more confidence about what we were working in. And all the functions we wrote down the line or used on the line, we could know for sure that, okay, it has these properties about it. And that really shaped the code we wrote. JOËL: So use the word confident here, which, for me, it's a keyword. And so you can now assume that certain properties are true because it's been checked once. That can be tricky if you don't actually do a transformation. If you're just sort of passing a raw value down, you'll often end up with code that is defensive that keeps rechecking the same conditions over and over. And you see this lot around nil in Ruby where somebody checks for a value for nil, and then inside that conditional, three or four other conditions deep, we recheck the same value for nil again, even though, in theory, it should not be nil at that point. And so by doing transformations like that, by parsing instead of just validating, we can ensure that we don't have to repeat those conditions. STEPHANIE: Yeah, I mean, that refers back to the analyzing conditional code that we spent a bit of time talking about at the beginning of this episode. Because I remember in that application, we render different components based on the status of this domain object. And there was a condition for when the status was something that was not expected. And then someone had left a comment that was like, technically, this should never happen. But I think that he had to add it to appease the compiler. And I think had we been able to better enforce those boundaries, had we been more thoughtful around our domain modeling, we could have figured out how to make sure that we weren't then introducing that ambiguity down the line. JOËL: I think it's interesting that you immediately went to talking about TypeScript here because TypeScript has a type system. And the "f, Don't Validate" article is written in Haskell, which is another typed language. And types are great for showing you exactly like, here's the boundary. On this side of it, it's a string, and on this side here, it's a richly-typed value that has been parsed. In Ruby, we don't have that, everything is duck-typed, but I think the principle still applies. It's a little bit more implicit, but there are zones of high or low assumptions about the data. So when I'm interacting directly with raw input from a third-party endpoint, I'm really only expecting some kind of raw string from the body of the response. It may or may not be valid. There are all sorts of checks I need to do to make sure I can do anything with it. So that is a very low assumption zone. Later on, in the business logic part of the code, I might expect that I can call a method on the object to get the price of a shopping cart or a list of items or something like that. Now I'm in a much higher assumption zone. And being self-aware about where we transition from low assumptions to high assumptions is, I think, a really key takeaway for how we interact with code in Ruby. Because, oftentimes, where that boundary is a little bit fuzzy or where we think it's in one place but it's actually in a different place is where bugs tend to cluster. STEPHANIE: Do you have any thoughts about how to adhere to those rules that we're making so we're not having to assume in a dynamically-typed language? JOËL: One way that I think is often helpful is trying to use richer objects and to not just rely on primitives all the time. So don't pass a business process a hash and be just like, trust me, I checked it; it's got the right keys because the day will come when you pass it a malformed hash and now we're going to have an error in the business process. And now we have a dilemma because do we want to start adding defensive checks in the business process to be like, oh, are all our keys that we expect present, things like that? Do we need to elsewhere in the code make sure we process the hash correctly? It becomes a little bit messy. And so, oftentimes, it might be better to say, don't pass a raw hash around. Create a domain object that has the actual method that you want, and pass that instead. STEPHANIE: Oh, sounds like a great opportunity to use the new data class in Ruby 3.2 that we talked about in an episode prior. JOËL: That's a great suggestion. I would definitely reach for something like that, I think, in a situation where I'm trying to model something a little bit richer than just a hash. STEPHANIE: I also think that there have been more trends around borrowing concepts from functional programming, and especially with the introduction of classes that represent nil or empty states, so instead of just using the default nil, having at least a bit of context around a nil what or an empty what. That then might have methods that either raise an error or just signal that something is wrong with the assumptions that we're making around the flexibility that we get from duck typing. I'm really glad that you proposed this topic idea for today's episode because it really represented a lot of themes that we have been discussing on the show in the past couple of months. And I am excited to maybe do this again in the future to just capture what's been interesting or inspiring for us throughout the year. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeeee!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Code with Jason is back! On this episode, TJ Stankus returns for a discussion of Object Oriented Programming and his book 99 Bottles of OOP.  We also discuss managing large applications with Rails, models, organizing by domain concept, and microservices.99 Bottles of OOP by Sandi Metz, Katrina Owen, and TJ StankusResponsibility-Driven Design by Rebecca Wirfs-BrockDesign Stamina Hypothesis by Martin FowlerThe Magic of Reality by Richard DawkinsDomain Driven Design by Eric EvansWhy I Organize my Tests by Domain Concept, not by Test Type by Jason SwettTJ.Stank.usTJ Stankus on Twittertjstankus@gmail.com

What did we talk about In this episode, we're talking about “The Wrong Abstraction" by Sandi Metz. We go against years of programming best practices and propose copy-pasting code….sometimes. Along the way, we mention "AHA Programming" by Kent Dodds and "The Wet Codebase" by Dan Abramov, and generally rail against speculative generality. If you listen long enough, you'll hear Joe mouth-coding something called a “bloom filter” and Evan makes an offer you can't refuse.

Inspired by a Slack thread, Joël invites fellow thoughtbotter Aji Slater on the show to talk about when you should use class methods and when you should avoid them. Are there particular anti-patterns to look out for? How does this fit in with good object-oriented programming? What about Rails? What is an "alternate constructor"? What about service objects? So many questions, and friends: Aji and Joël deliver answers! Backbone.js collections (https://backbonejs.org/#Model-Collections) Query object (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) Rails is a dialect (https://solnic.codes/2022/02/02/rails-and-its-ruby-dialect/) Meditations on a Class Method (https://thoughtbot.com/blog/meditations-on-a-class-method) Why Ruby Class Methods Resist Refactoring (https://codeclimate.com/blog/why-ruby-class-methods-resist-refactoring/) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined by fellow thoughtboter Aji Slater. AJI: Howdy. JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Aji, what's new in your world? AJI: Yeah, well, I just joined a new project, so that's kind of the newest thing in my day-to-day work world. I say just joined, but I guess it was about a month ago now. I'm on the Liftoff team at thoughtbot, which is different than the team that you're on. We do more closer to greenfield ideas and things like that. So there's actually not much to speak about there in that project just yet. Rails new is still just over the horizon for us. So I've been putting a lot of unused brain cycles toward a side project that is sort of a personal knowledge base concept, and that's a whole thing that I could probably host an entire podcast about. So we don't have to go too deep into my theories about that. But suffice it to say I've talked to some other ADHDers like myself who find that that space is not really conducive to the way that we think and have to organize ourselves and our personal knowledge stores. So sort of writing an app that can lend itself to our fast brains a little bit better. JOËL: Nice. I just recently recorded an episode of this podcast talking a little bit about note-taking approaches and knowledge-base systems. So, yeah, it's a topic that's very much top of mind for me right now. AJI: Yeah, what else is going on in your world? JOËL: I'm based in New England in the U.S. East Coast, and it is fall here. I feel like it happened kind of all of a sudden. And the traditional fall thing to do here is to go to an orchard and pick apples. It's a fun activity to do, and so I'm in the middle of planning that. Yeah, it's fun to go out into nature, very artificial space. AJI: [laughs] JOËL: But it's a fun thing to do every fall. AJI: Yeah, we do that here too. There's an orchard up north of us where my wife and I live in Chicago that we try to visit. And Apple Fest in Lincoln Square is this weekend, and we've been really looking forward to that. Try another time at making homemade hard cider this season, I think, and see how that goes. JOËL: Fun. When you say another time, does that mean there was a previous unsuccessful attempt? AJI: Yes. Did the sort of naive approach to it, and there is apparently a lot more subtlety to cidermaking than there is home-brew beer. And we got some real strong funk in that cider that did not make it necessarily an enjoyable experience. Like, it worked but wasn't the tastiest. JOËL: So it got alcoholic. It was just terrible to drink. AJI: Yeah, I would back that up. JOËL: So recently, at thoughtbot, we had a conversation among different team members about the use of Ruby class methods, when they make sense, when they are to be avoided. What is their use case? And different people had different opinions. So I'm curious what your take on class methods are. When do you like to use them? AJI: Yeah, I remember those conversations coming up. I think I might have even started one of those threads because this is something that comes up to me a lot. I'm a long-time listener, first-time caller to The Bike Shed. [laughs] I can remember awaiting new episodes from Sage and Derek to listen to on my way to and from my first dev job. And at one point, Sage had said, "Never put your business logic in something that you can't call .new on." And being a young, impressionable developer at the time, I took that to heart, and that seems something that just has been baked in and stayed very truthful to me. And I think one of the times that I asked that and got some conversation started was I was trying to figure out why did I feel that, and like, why did they say that? And I think, yeah, I try to avoid them. I like making instances of things. What is your stance on the Class Method, capital C, capital M? JOËL: I also generally avoid them. I have sort of two main scenarios that I like to use class methods, first is as an alternate constructor. So new is effectively a class method that's built into Ruby's object model. But sometimes, you want variations on your constructor that maybe sets values by default or that construct things with some slightly different inputs, things like that. And so those almost always make sense as class methods. The other thing that I sometimes use a class method for is as an alias for newing up an instance and then immediately calling an instance method on it. So it's just a slightly shorthand way to call some code. AJI: That's usually been my first line defense of when there's someone who might feel more comfortable doing class methods that sees me making an instance and says, "Well, you don't need an instance, just make a class method here because it'll get too long if you have to .new and then dot this other thing." And so I'll throw in that magic little trick and be like, here you go. You can call it a class method, and you still get all the benefits of your instance. I love that one. JOËL: Do you feel like that maybe defeats the purpose? In terms of the interface that people are using, if you're calling it a class method, do you lose the benefits of trying to do things at the instance level instead? Or is it more in the implementation that the benefits are not at the caller level? AJI: I think that's more true that the benefits are at the instance level, and you're getting all of that that goes along with it. And you're not carrying along a lot of what I see as baggage of the class method version, but you're picking up a little bit of that syntactic sugar. And sometimes it's even easier just to conceptualize, especially in the Rails space because we have all of these different class methods like, you know, Find is one I'm sure that we use all the time to call it on a class, and we get back an instance. And so that feels very natural in the Rails world. JOËL: I think you could make an argument that that is a form of alternate constructor. It's a class method you call to get an instance back. AJI: Yeah, absolutely. JOËL: The fact that it makes a background request to the database is an implementation detail. AJI: For sure. I agree with that. I had a similar need in a recent project where the data was kept on a third-party API. So I treated it the same way as, instead of going out to the database like ActiveRecord does, made a class method that went off to the API and then came back and made the object that was the representation of that idea in our application. So, yeah, I wholeheartedly agree with that. JOËL: So in Rails, we have the scope keyword, which will run some query to get a collection of records. But another way that they're often implemented is as class methods, and they're more or less interchangeable. How do you feel about that kind of use of class methods on an ActiveRecord object? Does that violate some of the ideas that we've been talking about? Does it sort of fit in? AJI: I think when reaching for that sort of need, I sort of fall into the camp of making a class method rather than using a scope. It feels a little less like extending some basic Rails functionality or implying that it's part of the inherent framework and makes it a little more like behavior that's been added that's specific to this domain. And I think that distinction comes into my thinking there. I'm sure there are other reasons. What are your thoughts there? Maybe it'll spark an idea for me. JOËL: For me, I think I also generally prefer to write them as class methods rather than using the scope keyword, even though they're more or less the same thing. What is interesting is that, in a way, they kind of feel like alternate constructors in that they don't give you an instance; they give you back a collection of instances back. So if we bend the rules a little bit...these are not hard and fast rules but the guidelines. If we bend the guidelines a little bit, they kind of fit under the general categories for best uses of class method that we discussed earlier. AJI: Yeah, I can definitely see that. I tend to think, or at least I think when you had first brought up the term of alternate constructors, my first thought was of one instance; you ask for a thing, and it gives you this thing back. But it's the same sort of idea with that collection because you're not getting just one instance; you're getting many instances. But it's the same kind of idea. You've asked the larger concept of the thing, the class, to give you back individuals of that class. So that totally falls in line with how I think about acceptable uses of these class methods the way that we've been talking about them. JOËL: Rails is something really interesting where a lot of the logic that pertains to a single item will live at the instance level. And then logic that pertains to a group of items will live at the class level. So you almost have like two categories of operations that you can run that semantically live either at the class or the instance level. Have you ever noticed that separation before? AJI: I think that separation feels natural to me because I came into programming through Rails. And I might have been colored in my thinking about this by the framework. The way that I conceptualize what a class is being sort of this blueprint or platonic ideal of what an individual might be and sort of describing the potential behaviors of such an individual. Having that kind of larger concept be able to work across multiple instances feels, yeah, it feels sort of natural. Like, if you were to think about this idea of a chair, then if you went in and modified what a chair is to mean, then any chair that you asked for later on would kind of come with that behavior along with it. Or if you ask for several chairs, they would all sort of have that idea. JOËL: I think similar to you; I had that outlook on that's almost like a natural structuring of things. And then, years ago, I got into the hot, new JavaScript framework that was Backbone.js. And it actually separates...it has like a model for individual instances, and then a separate kind of model thing for collections. And that kind of blew my mind. But what was interesting, then, is that you effectively have instance methods that can deal with all things collection-related, any sort of filtering, any sort of transformations. All of those are done, which you have an instance of a collection, basically, that you act on. And I guess if we were trying to translate that into Rails, that's almost like the concept of a query object. AJI: Hmm, it's sort of an interesting way to think about that. And Backbone, I feel like I did a day of that in bootcamp. But it has been some time, so I'm not sure that I've worked with that pattern specifically. But it does sort of bring up the idea of how much do you want to be in one model class? And do you want it to contain both of these concepts? If you have a lot of complex logic that is going to be dealing with a collection, rather than putting that in your model, I think I would probably reach for something like a service object that is going to be specifically doing that and sort of more along that Backboney approach maybe like a query object or something like that. JOËL: Interesting. When you use the term service object, do you mean something that's not a Rails model, just in general? Or are you talking specifically about one of these objects that can respond to call and is... I've heard them sometimes called Command objects or method objects. AJI: Yeah, that's an overloaded term certainly in the real space, isn't it? Service object, and what does that mean? I think generally, when I say it, I'm meaning just a plain, old Ruby object like something that is doing its one thing. You're going to use it to do its implementation details. They're all kind of hidden behind in private methods and return you something useful that you can then plug into what you were doing or what you need going on in some other place in your app. So it, to me, doesn't imply any specific implementation of, like, do you have call? Do you use it this way? Do you use it that way? But it's something that's kind of outside of it is either a model, a view, a controller, and it encapsulates some kind of behavior. So whether that, like we're saying, is a filtering or, you know, it's going to wrap that up. JOËL: I see. So, for you, a query object would be a service object. AJI: Yeah, I think so. You know, maybe this is one of the reasons why I generally don't like the overuse of the term service object in our space. I don't know if that's a hot take, and I'm going to get emails for this. But -- JOËL: Everybody send your angry tweets @Aji. AJI: Yeah, do it to @Aji on Twitter because I've been trying to get that three-letter handle for years. No, but if you want to talk to me, I'm @DoodlingDev. But, yeah, certainly, it does feel sometimes like an overloaded term, and I just want to go back to talking about plain, old Ruby objects. JOËL: So, service object is definitely an overloaded term. It's used for a lot of things. One thing that I've often seen it referring to are objects that respond to call. And just to keep away the confusion, maybe let's call them Command objects for the purposes of this conversation. AJI: Sounds good. JOËL: I commonly see them done where the implementation is done with a class method named call. Sometimes it delegates to an instance that also has call. Sometimes it's all implemented as a class method. How do you feel about that pattern? AJI: I don't mind the idea of a thing that responds to call. It, in a way, sort of implies that the class is sort of named as an action, which I don't like. It has an er name, and that kind of has a class named as a pattern. And that always sort of bugs me a little bit. But what I hope for when I open up one of those sorts of classes or objects is that it's going to delegate to an instance because then you're, again, picking up all of those wonderful benefits of the instance-level programming. JOËL: You keep mentioning the wonderful benefits of instance-level programming. What are some of those benefits? AJI: One of the ones that sort of strikes me most visibly or kind of viscerally when I see it is that they're very easy to understand. You can extract methods pretty easily that don't turn into kind of clumsy code of a bunch of different class methods that all have four arguments passed in because they're all operating on the same context. And when you're all operating on the same context, you have really a shared state. And if you're just passing that shared state around, it just gets super confusing. And you get into the order of your arguments, making a big impact on how you are interacting with these different things. And so I think that's sort of the first thing that comes to mind is just visually noisy, which for me is super hard to get my head around, like, well, how am I supposed to use this thing? Can I extend it? JOËL: Yeah, I would definitely say that if you have a group of class methods that all take, commonly, it's the first argument, the same piece of data and tries to operate on it, that's probably a code smell that points to the fact that these things want to be an instance that lives around it. This could be a form of primitive obsession if you're passing around, let's say, a hash, all of these, and maybe what you really want is to sort of reify that hash into an object. And then all these class methods that used to operate on the hash can now become instance methods on your richer domain object. AJI: Yeah. What do you say to the folks that come from maybe a more functional mindset or are kind of picking up on the wave of functional programming that's out there in the ethos that say that you've got a bunch of side effects when you don't have everything that your method is operating on, being passed on or passed in? JOËL: I think side effect is a broad term. You could refer to it as modifying the internal state of an object. Technically, mutation is a side effect. And then you have things like doing effects out in the outside world, like making an HTTP query, printing to the screen, things like that. I think those are probably two separate concepts. Functional programming is great. I love writing functional code. When you're writing Ruby, Ruby is primarily an object-oriented language with some functional aspects brought in. In my opinion, it's very, you know, a great combination of the two. I think they've gotten the balance well so that the two paradigms play nicely together rather than competing. But I think it's an object-oriented language first with some functional added in. And so you're not going to be, I mean, I guess you could; there is a way to write Ruby where everything is a lambda or where everything is a class method that is pure and takes in inputs. But that's not the idiomatic way to write Ruby. Generally, you're creating objects that have some state. That being said, if an object is mutating a lot of global state, that's going to become problematic. With regards to its internal state, though, because it is very much localized and it's private, nobody else gets to see it; in many ways, an object can mutate itself, and that chain stays pretty local. AJI: Yeah, absolutely. You've tripped onto another one of my favorite rabbit holes of idiomatic code, and, like, what does that mean, and why should we strive for that? But I absolutely agree that when Ruby is written to conform to other paradigms that aren't mostly object-oriented is when it starts to get hard to use. It starts to feel a little off. Maybe it has code smells around it. It's going to give me the heebie-jeebies, whatever that might mean for you or for different developers. I think we all have our things that are sort of this doesn't feel right. And you kind of dig into it, and you can sort of back that up. And whenever Ruby starts to look like something that isn't lots of little objects sending messages, is when I start to get a little on edge, maybe. JOËL: It is worth, I think, calling out the fact that Ruby is a very expressive language. And there are effectively many...you could call them dialects of it. You have sort of your pure sort of OO approach. You have what's typically written in Rails, which has some OO things. But Rails is also, in many ways, it's very DSL-heavy and, in some ways, very class method-heavy. So writing Rails is sort of its own twist on Ruby. And then, some people will try to completely retrofit a functional approach onto Ruby, and that's also a way that some people like to write their code. And some of these, you can't necessarily say they're not valid, but they're not what you'll mostly see in the wild. And they're not necessarily the approach that I would recommend. AJI: Yeah, that's the blessing, and the curse of both programming in general and such an expressive language like Ruby is that there are many different valid ways to do it. And what are your trade-offs going to be when you make those choices? I think that falls kind of smack dab into that idiomatic conversation. And it comes up for me, too, as a consultant because I try to tend towards that idiomatic, those common patterns and practices because I'm not going to live with this code forever. I need to hand this off. And the closer it is to what you might see out there in the wild more commonly, the easier it will be for the next Ruby developer to come pick it up and extend it. JOËL: So you'd mentioned earlier some of the benefits of instance programming. One of the things that I find is maybe a little bit weird when you go heavily into the class method approach is that there is only one instance of the class, and it is globally available. AJI: Are you talking about a singleton there? JOËL: Yes. And, in fact, your class is effectively a singleton, potentially with globally mutable state. I hope not, but potentially with all of the gotchas and warnings that that entails. And so, if you think of your user instance, you need a reference to it, and there can be multiple of them, and you can call methods on them. If everything is happening at the class level, there is a single user class in memory shared by anyone who wants to use it. It's globally accessible. You can all call methods on it. Yeah, in many ways, it does act like a singleton. AJI: And let's not even get into the Ruby chestnut of everything's an object. So it is an instance of a class in and of itself. JOËL: Yes. AJI: But, absolutely, it can start to act that way. But the singleton it's enshrined in the Gang of Four book of patterns. Like, so what's wrong about a singleton? I hope you can understand over the airwaves the devil's advocate that I'm playing here. [laughs] JOËL: Yes. There are little horns that have sprouted on your head right now. I think part of the problem with singletons is that, generally, they are globally accessible. There's the problem of global mutable state again. There was a time, I think, when the OO community went pretty wild with singletons, and people realized that this was not great. And so, over time, a consensus evolved that singletons are a pattern that, while useful, should be used rarely and in moderation. And a lot of warnings have been shared in the community, like, be careful not to overuse the singleton pattern or don't build your system out of singletons. And maybe that's what feels so weird about a system that's built primarily in terms of class methods for me is that it feels like it's built out of singletons. AJI: Yeah. When I think of object-oriented programming, I kind of fall back to maybe one of the ideals of it is that it represents the world more accurately or maybe more understandably. And that sort of idea doesn't fit that paradigm, does it? If you're a factory that is making widgets, there's not the one canonical widget that all of your customers are going to be talking to and using. They are going to each have their own individual widgets. And those customers can be thought of like the consumers of your methods, your objects. JOËL: The idea being the real-world thing you're simulating normally, there are multiple actors of every type rather than a single sort of generic one that stands in for everybody. AJI: If this singleton is going to be your interface or the way that you interact with each of these things that are conceptually different, like a user or something like that, then differentiating between which user becomes a lot harder to do. It takes a lot more setup and involved process in referring to this user when and that kind of thing and creating the little instances. Then you've got more kind of direct reference to a single concept, a single individual. JOËL: So what you've described is a very sort of classic OO mindset. You find the data and the behaviors that go together. You try to oftentimes simulate the world, model it in terms of actors that give and receive messages. In many ways, though, I think when you're building a system out of class methods, you're thinking about the world in an almost different paradigm. In many ways, it feels almost procedural. What are the behaviors that need to happen in my app? What are the things that need to be done? You'd mentioned earlier that oftentimes these classes or the methods on them will end up with E-R; they're all verbs. You have a thing-doer, a thing executor, thing manager. They all do things rather than having domain concepts extracted and pulled out. Would you say that that feels somewhat procedural to you as well? AJI: Yeah. I think a great way to divide it is the way that you have right there; it's these sorts of mindsets. Do you have collections of things that have behaviors, or do you have collections of behaviors that might refer to things? And where you're approaching the design of a system, either from that behavior side or from that object side, is going to be a different mindset. Procedural being more focused on that kind of behavior and telling it what to do rather than putting... I think this is probably a butchered Sandi Metz example, but putting your roommate who hates cats and a cat that doesn't want its tail stepped on in one room, and eventually, things will happen accordingly. And those two mindsets are going to end up with very different architectures, very different designs, very different ways of building these applications that we make. And, again, does that come back to...Ruby, potentially to a lesser extent but still in the same camp, is object-oriented language, and it sort of functions best when considered and then constructed in that mindset. And I often wonder sometimes if language developers and language designers make anti-patterns sort of purposefully awkward to use. Like, if you want to hide a lot of class methods, you can do the class shovels self version of things or have privateclassmethod littered all the way through your file. And it seems to me like that might be a little bit of a flag that, like, hey, you're working against the system here. You're trying to make it do a thing that it doesn't naturally want to do. JOËL: Yeah, because you'd mentioned this private_class method thing because, by default, it's hard to get class methods to be private. You have to use a special keyword. You can't just write private in the class and then assume that the methods below it are going to be private because that does not apply to class methods. AJI: Exactly. And that friction to making an object that has a smaller interface, that kind of hides its implementation, seems as though it's a purposeful way that Ruby itself was designed to maybe nudge us, developers, into a certain way of working or suggesting a certain mindset. JOËL: There's a classic Code Climate article titled Class Methods Resist Refactoring. And it mentions different ways that when you're relying heavily on class methods, it's harder to do some of the traditional refactors things like just extract method because it is clunkier because you can't have private methods as easily. You can't share state, so you have to thread variables through. I guess, technically, you can share state with things like class variables and class instance variables, but if you do that, you will probably be very sad. AJI: [laughs] Yeah, you're opening yourself up to a whole world of hurt there, aren't you? And, yeah, you're opening yourself up to a whole world of hurt there with that, aren't you? Sort of sharing data so dangerously around your app. JOËL: So I'm a big fan of test-driven development. And one of the things that TDD believes in is that test pain should help guide the design of your system and that, generally, things that are easier to test are better designed. AJI: Yeah. JOËL: It's often easier to test class methods because they are globally available singletons. I can easily stub a class. Whereas if I need to stub an instance, I need to do some uglier things like stub any instance of or stub the constructor to return a double, or do some other kind of dirty tricks like that. Does that mean that TDD would prefer a class method-based approach to writing code? AJI: I think that a surface-level reading of that might say that it does. And I think that maybe the first pass on things, if you're thinking about I want to get this thing done that's right in front of me right now and just move forward, might kind of imply that. But if you start to think about or have come back to something that was implemented in that way, anytime that sort of behavior is going to grow or change, then it's going to start to...the number of backflips that you have to do become a lot more complicated and a lot higher when you've got class methods. Because I find that, yes, you might have to stub out or pass in a created object or something like that. But if you've got a class method, especially if it is calling other class methods inside it, then all of a sudden, you have in your test this setup that looks completely unrelated to anything that you're running and testing, that you have to have all of this insight or knowledge of what those classes are doing just to set up your test framework before you can even run that. Another thing that is looked to as an axiom when writing tests that can imply this class approach is that you shouldn't change your code just for the test. If you're doing dependency injection or something like that, passing around little objects, then you're making your code more complicated to make your tests look a certain way. JOËL: That's interesting. So maybe I'm reacting to some test pain by trying to change my tests first. So I'm trying to deal with some collaborators, and it is tricky to do. And so I decide, well, the thing I want to do is I want to reach for stubbing. But then that's hard to do because it's instances. So in order to make already that compromise in my test work better, now I change the code to be nicer for the test to use mostly classes because those are global. Whereas maybe the correct path to take initially is, say, oh, there isn't test pain here because I'm trying to isolate an object from its collaborators. Maybe we need to pass an object in as an argument rather than hard coding it inside the class. AJI: Yeah, absolutely. JOËL: So I guess you follow the test pain, but maybe the problem is that you've already kind of gone down a path that might not be the best before you got to the point where you decided that you needed a class method. AJI: And I think that idea of following the test pain can be, again, there are only shades of gray; there is no black and white. It can be sort of taken in a lot of different ways. And the way that I think about it is that test pain is also sort of an early warning sign that there's going to be pain if you want to reuse this class or these behaviors somewhere else. And if it was useful somewhere, it's likely it's going to be useful in another place. And there are many different kinds of tests pain. The testing is a little easier with a class method because you're not stubbing out any instance of. You're just stubbing; really, what's the difference between stubbing out any instance of or stubbing out the class? Is that just a semantic difference? Is that -- JOËL: Because someone on the internet said that stubbing any instance of is bad. AJI: Ooh, right, the internet. I should have read that one. The thing that you can do with passing around instances or sending messages to instances as you do when you're calling a method is that you can easily swap in a different object if you need to stub it. It's similar to how you can change the implementation under the hood of an object and pass in an object that responds to the same messages and kind of keep moving forward with your duck typing. If you can go into your tests and pass it sort of an object that's always going to return a thing...because we're not testing what that does; we just need a certain response so that we can move forward with the pathway that is under test. You can do that in so many different ways. You could have FactoryBot, for instance, give you a certain shape of a thing. You can create a tiny, little class right there in your tests that does something specific, that can be easily understood what's going on under the hood here. And instead of having to potentially stub out or create all of these pathways that need to be followed that are overwriting logic that's happening in different class methods or different places otherwhere in the application, you can just pass in this one simplified thing to keep your tests sort of smaller and easier to wrap your head around all in just one go. JOËL: I think what I'm getting here is that when you design your code around instances, you're more likely to build it in a modular way where you pass objects to other objects. And when you build your code using class methods, you're more likely to write it in a hard-coded way. Because you have that globally available class, you just hard-code it and then call it directly rather than passing things in. And so things end up more coupled and, therefore, high coupling leads to more test pain. AJI: Yeah, I think you've really kind of hit on something here that the approach of using class methods is locking that class into kind of a single context or use case. Usually, it is this global thing that is this one way, and that's even kind of backed up by the fact that class methods are load-time logic instead of run-time logic. And it really kind of not only couples but it makes it more brittle and less amenable to kind of reuse. JOËL: That's a really interesting distinction. I often tend to think of runtime versus load time in terms of composition versus inheritance. Composition, you can combine objects together at runtime and get behaviors built on the fly as the code is executing, whereas inheritance sort of inherently freezes you into a particular combination of behaviors at the time of loading the code. It's something that the programmers set up, and so it is much less flexible. And that is one of the arguments why the Gang of Four patterns book recommends composition over inheritance in many situations is because of that runtime versus load time dichotomy. And I hadn't made that connection for class methods versus instance methods, but I think there's a parallel there. AJI: Yeah, absolutely. The composition versus inheritance thing, I think, goes very hand in hand with the conversation that we're having about putting your behavior on a class versus an instance because...and I don't know if this is again yielding my thoughts to 'the internet said' in that composition is preferable to inheritance. But without unpacking that right there, that is certainly something that I strive for as well. And while it might have, much like TDD, some kind of superficial, short-term complexity, it has long-term payoff in that flexibility and that reuse, and that extensibility, and all of those other buzzwords that we developers like to throw around. JOËL: So you've shared a lot of thoughts on the use of class methods. I think this could branch into so many other aspects of object-oriented design that we haven't looked at or that we could go deeper, things like TDD. We could look into how it works with the solid principles, all sorts of things. But I think the big takeaway for me is that class methods are very useful, but it's easy to use them as our single hammer to every problem being a nail. And it's good to diversify your toolset. And some tools are specialized; they're good to be used in very specific situations that don't come across very often, and others are used every day. And maybe class methods are the former. AJI: Absolutely. That hammer-and-nail metaphor was right where I was headed for too. Love it. JOËL: Well, thank you so much, Aji, for joining the conversation today. Where can people find you online? AJI: Yeah, anywhere you want to look for me: Instagram, GitHub, Twitter. I'm @DoodlingDev, so just send all your angry emails that way. JOËL: And with that, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

As developers, we care a lot about code quality. How do we know how good is good enough? When do we stop improving code? Alternatively, when working on code that's really bad, how much do you improve it before calling it a day? thoughtbot's Stephanie Minn joins Joël to chat about this and case expressions: We recently discussed these as part of thoughtbot's RubyScience reading group. Are case expressions bad? Are they equivalent to multi-way conditionals? When do you use polymorphism? This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. RubyConf 2022 (https://rubyconf.org/) RubyConf Mini (https://www.rubyconfmini.com/) Stephanie's talk at RubyConf 2021 (https://www.youtube.com/watch?v=m0dC5RmxcFk) WNB.rb (https://www.wnb-rb.dev/) Joël's RailsConf 2022 talk (https://www.youtube.com/watch?v=LOlG4kqfwcg) Ruby Science (https://books.thoughtbot.com/books/ruby-science.html) older episode on wizards (https://www.bikeshed.fm/295) TCR (https://www.honeybadger.io/blog/ruby-tcr-test-commit-revert/) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And we're here to share a little bit about what we've learned along the way. Today, I'm joined by a fellow thoughtboter, Stephanie Minn. STEPHANIE: Hi, Joël. JOËL: Welcome to the show. STEPHANIE: Thanks. Happy to be here. JOËL: Stephanie, what's new in your world? STEPHANIE: Thanks for asking. I've been working on writing a CFP for RubyConf, which you have been plugging internally at thoughtbot. I wasn't really sure if I wanted to do it, and then I found out about RubyConf Mini, which is happening as an alternative to the main conference in Houston. And that got me really excited to have some more options and just got me thinking about what I might have sitting on the back-burner that I might want to give a talk about. JOËL: That's really exciting. I'm curious, what is your process for coming up with an idea for a talk? STEPHANIE: I think they come in seasons, ideas, for me, so not even necessarily when it's conference time. But if something has been sticking in my brain for a really long time, especially as it relates to processes on teams that I'm on or my day-to-day workflow, and it's something that I keep coming back to and trying to figure out what it is about it that my brain wants to work through a process, that usually tips me off that this might be something that other people are thinking about or working through. In this case, I am planning to write a CFP about pair programming. And yeah, it's something that I've been thinking about doing for a while, and it seems kind of an evergreen topic. So I thought I would pull it out for this conference. And if it doesn't end up getting accepted, I can always resubmit again in the future. JOËL: I love that. So it sounds like you have a note or maybe an actual written notepad somewhere where you just, over the course of the year, build up ideas, and then you take a look at that when conference time comes around. STEPHANIE: Yeah, that's about it. I have just a very long-running note of half-formed thoughts. And then, when I give myself time to really reflect on how things have been going at work, I usually revisit it, and if any of them still resonate or stand out to me, I will go through and try to see if there's any content to come out of that. What about you? I know you are an extensive note-taker and ideas blogger. JOËL: I have to say I really like your approach of gathering ideas throughout the year. I've worked with many people who would love to give a talk at a conference as a professional goal but then get stuck in the I don't have any ideas. I don't know what I would talk about. And most people have a thing they could talk about. They just don't know it. And it sounds like you've done a really great job of gathering this info throughout the year so that when the time does come, you don't just freeze. You're like, no, here are the 10-20 things that I experienced or that I am an expert in or that I would love to share. And maybe there are two or three in there that would be very well-fitted for the conference you're looking at. So I love that idea. I have not done that myself personally, but maybe I should start doing that. STEPHANIE: What about you, Joël? What's up in your world? JOËL: So I've also been thinking a lot about RubyConf coming up, working on a few ideas for myself. And then, there are a few people that have reached out to me to help them craft ideas or get a little bit of feedback on their proposal. So I've been doing a lot of proposal reviews as well. STEPHANIE: What do you enjoy about reviewing other people's proposals? JOËL: I think for many people speaking at a conference is a really big, ambitious professional goal, and so helping people achieve that is really fulfilling for me. Some people might feel almost inadequate or unprepared. But because I know them, I know they've got good things to share. And so it's almost seeing the greatness in them that they don't quite see yet or that they don't feel confident about. And so being able to see that in their proposal and say, "Oh, there's a core of a great idea right here, tweak it a little bit, and that'll give you a slightly better chance with the committee and help you towards that path of being on stage for the first time," is really exciting. STEPHANIE: I spoke at RubyConf last year, in 2021, virtually. And I remember that was my first time speaking at a conference. And I was worried that my talk was not super hardcore, technical enough. But my goal for my talk was to aim it towards other developers like me who are maybe mid-level and wanting to reach this whole audience of people who are attending these conferences to learn and to level up who aren't necessarily super senior experienced developers. And it was a really great experience. People seemed to really resonate with that. So I really encourage folks to speak about things that are resonating with them at whatever point in their careers because there are so many people out there who are probably in the same boat and want to hear what you have to say. JOËL: Absolutely. I'm curious, now that you have experienced the full cycle at least once, from ideas to crafting a submission, to getting accepted, preparing a talk, delivering the talk, and then recovering from that, what are maybe some lessons learned or some things you weren't expecting the first time you went into that that now you do know going into another cycle? STEPHANIE: Yeah, the power of community; I had a lot of support from WNB.rb, a woman and non-binary Ruby community. We crafted our CFPs together and then practiced our talks together and had a working group that met every couple of weeks to give feedback on our talks as we were working on them. And it was really awesome to have that accountability, to have that support, people to tell you that your talk is good and give you a thumbs-up. And I really want to continue investing in my community that way. And I really appreciate you asking this question because I guess I do have things I've learned and would want to share that with other people in my community, and yeah, just continue to encourage folks who may not have been traditionally encouraged to speak at conferences. JOËL: Community is so powerful. Even though I've spoken at multiple conferences, I still get nervous about my talks. I have a lot of self-doubt about whether my topic is good, whether I'm sharing it in a way that's going to be impactful. And I had a magical experience at RailsConf this year where a group of us were at a hotel lobby practicing our talks the night before. And I was just still so unsure about my talk. And the feedback that I got there gave me a huge boost of confidence that I was able to ride into the next day and give a talk that I think turned out rather well. But honestly, that was my favorite moment of the conference was 11:30 p.m., a group of people in the hotel lobby taking turns practicing their talks. STEPHANIE: Yeah, I love that. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: One thing we've been doing recently at thoughtbot is every other week book club discussion, and we've been looking through the book Ruby Science published by thoughtbot. Every week, we'll have someone who is a facilitator, who has done the reading and has prepared some questions for the group. And you recently facilitated a session on the topic of CASE expressions and why they might be a code smell. That sounds like a really controversial statement. How did you approach that topic? STEPHANIE: It's funny because I was looking at the upcoming chapters to pick a topic to facilitate for this book club, and CASE statements stood out to me because I was like, oh, I know what that is; that will be easy. [laughs] But it turned out to be a bit meatier than I thought it was going to be. I'd say that I didn't really consider them a code smell until I read the chapter of Ruby Science talking about them. So I was a bit surprised because they seem so common, which is probably also why I thought it would be an easy topic. JOËL: Would you say that reading the book or that particular chapter changed your mind? STEPHANIE: I think it did only because I hadn't necessarily given them a second thought or thought of them more deeply in that way. I think that, at least in my experience, you encounter CASE expressions pretty early in your career, and you think they're a cool tool for making your conditionals look a bit nicer. And it takes probably a bit more experience, a little bit more pain using them or trying to extend them that you start to have a bit of a more higher level awareness of what might be problematic about a CASE expression. But the book club that I facilitated, we had a really engaging discussion where most folks agreed that it was a code smell but also said that it depends. JOËL: Classic consultants. STEPHANIE: Truly. One thing that someone said that was a really nice takeaway for me was that CASE expressions get a bad rap in object-oriented languages because there are typically other tools or options you can reach for that might be preferred. And someone else said that it's probably a sign that you might be doing too much in the method. JOËL: Hmm. You mentioned that there are some tools and things that might be preferred over CASE expressions. What are the common alternatives that people say you should use instead of a CASE expression? STEPHANIE: I think one simple solution that we discussed in the book club for more straightforward cases would be a hash lookup to use instead of checking for equality via CASE statement. Another solution we talked about was polymorphism, which I think might refer back to the idea of having a bit of a higher level understanding of abstractions in the codebase and what things might look like in the future, especially when you might not have too many conditionals yet in your CASE expression. Another thing that really stuck out to me in our book club discussion was another thoughtboter mentioned Sandi Metz's 99 Bottles of OOP. And in that initial solution, she presents a CASE statement as the perfectly fine solution for now. And I thought that was really interesting because, in some cases, that might be all we know about the problem, and that is perfectly fine. What do you think about that? JOËL: I love the idea of starting simple. Don't try to start with abstraction, especially if you're doing test-driven development. You have a test, make it go green, use the simplest thing, use duplication, use all the dirty tricks. And then from there, now that you know I have a test that was red and this code makes it go green, now the question isn't how do I solve the problem? It's how do I improve the solution? So we've kind of separated those two steps out, and I really like that. STEPHANIE: Yeah, I remember you mentioned that you had refactored something into using a CASE statement. And I'm curious if you want to share more about that. JOËL: Oh boy, this was a "fun" problem. Fun is in air quotes, by the way. It was a multi-step form, AKA a wizard in a Rails app, where every step submitted to the same controller, and the controller was a huge mess. It had to handle submissions from four or five different forms, some of which shared fields. And it was this huge, deeply nested conditional thing that checked if this field is present in params, that probably means we're on step three, except if this other field is also present, then it probably means we're on step four. But if this Boolean flag in the database is set to false, we might be on a variation of step three. And because there was branching, potentially, it was an absolute mess. By looking at the code, you could never know what step of the processing you were on. What I did is instead of all of these nested if else conditions, I wrote a flat CASE expression that just said, if step one, do step one logic or process step one form. If step two, process step two form and so on. So it was nice and flat. I was able to reuse some parts of the work across by making private methods or other objects, things like that. But you could easily tell in any part of the code what step you were processing. Which means if you get a new feature from the client that says, "Can you modify the behavior on step four?" Now you actually know where to go to. You go to this controller; you find the big CASE expression. You find the branch that says, "If step four," and then you drill down from there. STEPHANIE: So after refactoring that into a flat structure, did you find the code more readable? Did other folks on the project think so too? JOËL: Yes, it was unanimously loved because this is the part of the code that everybody feared to touch. It was the most awful, gnarliest code. And a few of us had touched it, and so if you did the git blame, our names would show up, which meant that anytime anybody got stuck in that code, they would reach out to us and say, "Hey, you're the last one who touched it. Can you fix this for me?" And it was a big game of not it. Cleaning it up made this code accessible to everybody on the team. STEPHANIE: And why do you think a CASE statement was the right solution in this particular case? JOËL: I think if it's a multi-step form that maybe had seven steps in it, you clearly have seven branches that you're working with. And so hiding that behind nested conditions where you try to reuse each other's branches just muddied the waters. We have a seven-way branching path; let's be honest about it upfront and do a seven-way CASE expression. STEPHANIE: One thing that we didn't really talk about as much in our book club discussion was that CASE statements can be quite readable, especially for newer developers. And even though we all did think it was a bit of a code smell, I recently encountered on my client project in a code review someone saying that they preferred a CASE statement in that situation because it was easier for them to grok. I think that's a benefit worth considering before trying to do something fancier in some cases. And I'm curious what you think about that. JOËL: I strongly agree that a CASE expression is a great place to start, especially when you have actually more than two branches. Your logic could go one of n ways. I generally like to branch earlier than later in a lot of code. It's better in my mind to have a seven-way branch at the top of your decision tree and then just straight lines down than this constantly looping back and branching again and looping back, trying to force everything down a single path when it really doesn't want to be. STEPHANIE: So, in this case, did you know that you had those seven branching paths upfront, or did you have to tease that out? JOËL: I did not know from the code. Honestly, it would be very difficult to infer that from the code. But from the product, I knew this is a multi-step form with seven steps. And so I knew what the branches were from the product description. But no, it was almost impossible to infer that from the code. Long-time listeners of The Bike Shed may remember an older episode where Steph and Chris discussed multi-step forms and how best to approach them in Rails and also in JavaScript. And one thing that did come up is that an ideal way to work with a multi-step form in Rails is to have every step be its own controller. So you have a view, it submits to a controller, which renders another view or redirects to another view which submits to another controller. And that is the direction that we went with this multi-step form eventually. Once the single controller had a big CASE expression in it, we slowly started moving each branch out to its own controller. And now we had the step one controller, the step two controller, the step three controller, and so on. And I think that was probably the best solution in the end. But we had to go through the CASE expression just to know what was safe to move out. Interestingly, this refactor is effectively replacing a conditional with polymorphism because all of our controllers are controller objects. They respond to the same interface. And so this gets classic refactor that Ruby Science suggests, which is what we did and kind of what Steph and Chris recommended if you had the luxury of starting from scratch all those episodes ago. STEPHANIE: Nice, I'm glad it turned out that way and was a lot more manageable. JOËL: It's really interesting when you're working with a situation like that where you've got really messy code, and you can make some improvements. And it's like, how far do you go? Especially because there's usually a backlog of new features that the customer wants you to implement. So I'm curious for you, Stephanie, how do you know when you've gone far enough in improving code, either in a refactor step for your own code for a feature you're writing or maybe you're trying to take a break and say I'm going to take a little bit of time today to improve this area of the code. How do you know how good is good enough? STEPHANIE: That's an interesting question. I think I encounter that in a couple of ways, either in my own work when I am tasked with a feature, and I start getting into the code, and it stresses me out and leaves me a bit confused and not sure where to go to work on my feature. That is usually a signal that I might need to pay some attention first and make the change easy and then making the easy change. The other common thing that I have experienced on teams is we collectively feel the pain of an area of the codebase. And maybe we talk about it at a developer meeting, and all agree that, yeah, we really want to give this part of the code some love and add it to the backlog. But it's tough in that case because, like you said, there are a lot of new features that stakeholders want. And we as developers want to be over here taking care of our little codebase [laughs], making sure that it is healthy and it feels good to work with. JOËL: I feel like I don't just want my codebase healthy; I want it pristine. STEPHANIE: Ooh, pristine. What does that mean to you? JOËL: I want it perfect, nice, and shiny. And, of course, it's never that, which is why it's always tempting to toss out the old code and start over and do it right this time. That's not a good thing. You have to be able to live with the messiness of everyday life and the fact that, okay, here's an idea. I think if your codebase is perfect, you've put too much work into it. You've gone too far, and you're beyond that; when is good enough good enough? STEPHANIE: Whoa, that's a big statement. JOËL: [laughs] Feel free to disagree with me here. STEPHANIE: I guess I'm curious what perfect is in this case. JOËL: I think it's subjective for the developers who are writing it. But oftentimes, the ones who are looking for perfection go way too far in their quest for that. STEPHANIE: Way too far at the expense of things like business value or other things? JOËL: I think in two ways; one, you probably ended up overengineering things to try to make it so perfect. Your design needs to have some amount of flex in it for the unknown. It's okay to have some rough corners because it's going to change. And you're going to have to redo that corner next week anyway. So you need to not go all the way in making everything absolutely perfect. The other thing is that if you are putting in the effort to make everything perfect, at some point, you hit diminishing returns. And that's not worth your time from a business perspective or even on a personal project where you're just trying to ship things. At some point, you need to make actual progress. STEPHANIE: I'm curious if you mainly hold yourself to those very high standards or if you also think about that when reviewing other people's code. JOËL: So I mentioned earlier that I want my code to be pristine. I want to be clear, that's a bad thing. I do not actually hold myself to that standard. And I try not to hold other people to that standard, either. It's sort of tempering idealism with pragmatism. So being able to say, look, can we cut scope and focus on just one thing? Or does this fulfill the need that we have? And will it hurt us if we leave it like this and come back to it later? Or that question I asked you at the beginning, is this good enough? And maybe we can come back to it eventually. STEPHANIE: I really struggle with that question sometimes because, in some ways, people talk about software as a craft. And if we were building it in a vacuum, we could fine-tune and hone it until it's this beautiful, perfect, pristine thing. But because we write software for real things in the real world, we are constrained by the needs of our users, or the business, or just the purpose of building software is for folks to use it. And in that case, part of the job is evaluating trade-offs and deciding when is good enough. But sometimes, when I'm by myself working or coding for a little while, I do get sucked into wanting to make this the best that it could be just for my own personal fulfillment and joy. And I have to pull myself out of it sometimes and take a step back and be like, is this good enough for now, good enough for other people to be able to understand, work with in the future? And sometimes, it also requires getting other people's input too. JOËL: That's really valuable. STEPHANIE: Yeah, the worst thing that could happen is squirreling away with your code, and then you emerge with something that was totally not what was asked for. [laughs] JOËL: Especially on a work project. On a personal project, it's often good to know why you're doing a thing. And so maybe you want to see how far you can get away with pushing a particular metric, whether it's you want to go extreme on the decoupling or 100% TDD, or maybe you want to try something like test && commit || revert which is a development methodology. And those are all great as learning experiments, and then you go as deep as you want. I'm going to make another hot take here, and again, feel free to tell me I'm wrong. I'm going to say that on your own personal projects, if you pursue perfection, even when it's not for work, pursuing perfection on personal projects dooms them to join the others on the pile of uncompleted projects on your GitHub. STEPHANIE: That is an interesting take. I think it depends on the goal of your personal project because I personally like to have my projects be a bit of a sandbox, and I have no expectations that they will end up being anything that other people would necessarily look at, even though I guess they just end up public on my GitHub and are just sitting there in a weird, unfinished state. But yeah, I like to use them as an opportunity to, like you said, practice those concepts that I am really excited to explore but might not necessarily have the opportunity to on whatever client project I'm currently working on. And sometimes, I end up just scrapping it, but the exercise itself was valuable for me. I'm curious, though, what types of personal projects you have that lead you to have that opinion. JOËL: I think the way I use personal projects is very similar to you in that they're generally for my own personal growth and entertainment. It's about the journey, not the destination. So I generally have no intention of making this a thing that other people will use. It's typically a way to try out a technique, or a concept, or an idea. And so, for those, going really far on a performance or quality metric can be the goal. And that's completely okay with the knowledge that I probably will not complete or ship this project. I've done a few others where I've done the opposite. I've joined Game Jam events where you typically have a hard deadline. This could be a longer one, like maybe a month or as short as a day or a weekend, and you have to build and ship something within that deadline. And then you have to really make some pragmatic choices. STEPHANIE: Yeah, that sounds like a lot of pressure. I don't know if I would necessarily thrive in that kind of environment. I really like to spend a lot of time thinking about my code and looking over it again, sometimes to the point where I might be a little bit too precious about it. I was reflecting on this recently, and I thought about back when I was earlier in my career and didn't have any idea of what clean or good code was or looked like. And I would just write the code that would make my future work and just put it up for review. And I was very blissfully naive, I think, at that point in my career where I wasn't self-conscious about it in any way. And I think I'm trying to find a good middle ground between being comfortable with whatever comes out when I do some work or write some code while also having more knowledge and experience being able to revisit it and give it a deeper look after some space and feeling good about it without spending too much precious time on it. JOËL: Yeah, it's that classic consulting; it depends. Learn to balance code quality idealism versus the pragmatic reality of your goal, which is I want to ship something, both on your personal project and at work. That perfect code is useless if you can't ship it for contexts where you actually care about shipping. And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

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

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

How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) Why has trust become so rare in the software industry? Developers don't trust their own ability to program, teammates don't trust each other to write quality code, and organizations don't trust that people are working hard enough to deliver on time. This talk by Justin Searls is a reflection on the far-reaching consequences distrust can have for individuals, teams, and organizations and an exploration of what we stand to gain by adopting a more trustful orientation towards ourselves and each other. 01:57 - Justin's Superpower: Having Bad Luck and Exposing Software Problems 04:05 - Breaking Down Software & Teams * Shared Values * Picking Up on Smells to Ask Pointed Questions * Beginner's Mindset * RailsBridge (https://www.bridgetroll.org/) 12:49 - Trust Building * Incremental Improvement * What Got You Here Won't Get You There: How successful people become even more successful by Marshall Goldsmith (https://www.amazon.com/What-Got-Here-Wont-There/dp/1846681375/ref=asc_df_1846681375/?tag=hyprod-20&linkCode=df0&hvadid=312118059795&hvpos=&hvnetw=g&hvrand=6049806314701265278&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9006718&hvtargid=pla-525029467829&psc=1) * Credibility * Reliability * Intimacy * Selfless Motivation * Authenticity * Detecting Authenticity * Laziness Does Not Exist (https://humanparts.medium.com/laziness-does-not-exist-3af27e312d01) 29:14 - Power Politics & Privilege * Leadership Empathy * Safety * Exposure; “Don't Cross The Net” * Masking (https://en.wikipedia.org/wiki/Masking_(personality)) 42:06 - Personal Growth & “Bring Your Whole/True Self” * RubyConf 2019 - Keynote: Lucky You by Sandi Metz (https://www.youtube.com/watch?v=c5WWTvHB_sA) How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers based in the United States and Canada. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JACOB: Hello and welcome to Episode 270 of the Greater Than Code podcast. My name is Jacob Stoebel and I'm joined with my co-panelist, Mae Beale. MAE: And I'm joined with another panelist, Chelsea Troy. CHELSEA: Hi, I'm Chelsea and I'm here with our guest, Justin Searls. He's a co-founder and CTO at Test Double, a consulting agency on a mission to improve how the work writes software. His life's work is figuring out why so many apps are buggy and hard to use, why teams struggle to foster collaboration and trust, and why it's so hard for organizations to get traction building great software. The Test Double Agents work with clients to improve in all of these ways and more. Hi, Justin! How are you today? JUSTIN: Hello. I'm great. Thank you so much for having me. CHELSEA: Of course. So we like to kick off our sessions by asking you, what is your superpower and how did you acquire it? JUSTIN: Well, one superpower might be that I like to give counterintuitive answers to questions and [laughs] my answer to this would be that I have really, really bad luck software and hardware. My entire life has just fallen over for me left and right. Bugs come and seek me out. In college, I was in the computer science program and so, I was around a lot of computers, like Linux data centers and stuff, and I think I went through either personally, or in the labs that I used 20 hard drive failure years in 4 years. People started joking that I had an EMP around me. So I started to just decide to lean into that not so much as an identity necessarily, but as a specialty of root cause analysis of like, why do things fail? When I see a bug, what does that mean? And to dig in to how to improve quality in software and that then extended to later in my career, when I was working on delivery teams, like building software for companies and institutions. That meant identifying more root causes about what's leading to project failure, or for teams to break down. Now I'm kind of moving, I guess, popping the stack another layer further. I'm starting to ask what are the second and third order consequences of software failing for people having for others? I see this in my family who are non-software industry family members, when they encounter a bug and I'm watching them encounter a bug, their reaction is usually to think that they're the ones who screwed up, that they're stupid, that they just can't figure it out. I'm literally watching software that somebody else wrote far away just fail and that's just no good, right? So I think that the fact that I just so easily expose problems with software and sometimes the teams that make it almost effortlessly, it's really given me a passion and a purpose to improve and find opportunities to just make it a little bit better. MAE: When you talk about software and/or teams breaking down and you're mentioning bugs. So I'm assuming that that's mostly what you mean by breaking down? I'm curious if you have kind of a mental model of software always breaks down these four ways. Teams always break down these three ways. I don't know if you have any reference texts, or things that you've come across as far as like a mental model for what is the world of breaking down? How do we characterize it? JUSTIN: That's a great question and I feel like having been basically doing this for 15 years now, I should be prepared with a better answer. I've always resisted building I guess, the communicative version of an abstraction, or a framework for categorizing, simplifying, and compartmentalizing the sort of stuff that I experience. In some ways, my approach [laughs] is the human version of machine learning where I have been so fortunate, because I've been a consultant my entire career, to be exposed to so many companies and so many teams that that has developed in me a pattern recognition system that even I don't necessarily understand—it's kind of a black box to me—where I will pick up on little smells and seemingly incidental cues and it'll prompt me to develop a concern, or ask a pointed question about something seemingly unrelated, but that I've come to see as being associated with that kind of failure. I think your question's great. I should probably spend some time coming up with quadrants, or a system that distills down some of this. But really, when I talk about bugs, that is a lagging indicator of so many things upstream that are not necessarily code related. One of the reasons I want to be on the show here and talk to you all the day is because I've been thinking a lot about trust and interpersonal relationships starting with us as individuals and whether we trust the work that we're doing ourselves, or trust ourselves to really dive in and truly understand the stuff that we're building versus feel like we need to go and follow some other pattern, or instructions that are handed to us. To kind of try to answer your question more directly, when I see teams fail, it usually comes down to a lack of authentic, empathetic, and logical targeted relationships where you have strong alignment about like, why are we in this room? Why are we working together? How do we best normalize on an approach so that when any person in any role is operating that is consistent with if somebody else on the team had been taking the same action that they would operate in the same way so that we're all marching in the same direction? That requires shared values and that requires so many foundational things that are so often lacking in teams as software is developed today, where companies grow really fast. The pay right now is really, really high, which is great, but it results in, I think a little bit of a gold rush mentality to just always be shipping, always be hustling, always be pushing. As there's less time for the kind of slack that we need to think about—baking in quality, or coming back to something that we built a couple weeks ago and that maybe we've got second considerations about. Because there's that kind of time, there's even less time sometimes for the care and feeding that goes into just healthy relationships that build trust between people who are going to be spending a third of their life working together. CHELSEA: You mentioned picking up on little smells that then lead you to ask pointed questions. I think that's really interesting because that kind of intuition, I've found is really essential to being a consultant and figuring out how to ask those questions as well. Can you provide some examples of situations like that? JUSTIN: Yeah. I'll try to think of a few. I had a client once that was undergoing—this is 10 years ago now—what we called at the time, an agile transformation. They were going from a Waterfall process of procuring 2 year, $2 million contracts and teams to build big design upfront systems that are just thrown over a fence, then a team would go and work on it, and then it would go through a proper user acceptance testing onto something more agile, I guess. Adopting Scrum and extreme programming, interpersonal process, and engineering practices. That was just meant to be more, I guess, iterative of course, innovative, collaborative, more dynamic, and able to let the team drive its own destiny. All that sounds great and you walk into the team room and they just invested millions of dollars into this beautiful newly restored historic building. I sit down with everyone and I look at them and they've got the cool desks at the time and cool open office because those were still considered cool. I sat down and I couldn't help, but—[chuckles] this is real silly. I couldn't help but notice that there was a pretty strong smell, [laughs] body odor throughout the whole room and it wasn't one person. I'm not picking on somebody here. It was that the interpersonal relationships were so afraid, the fear of failure was so strong, and the deadline pressure that had been exerted from on high was so overwhelming that there was no safety in the room. People were just scared at their job all day long and it was having a material impact that only an outsider who's walking in at 2:00 PM on a Friday detect because everyone else had acclimated. So I walked in and I was like, “Well, what do I –?” [laughs] Obviously, I'm not going to be like, “Hey, it stinks in here.” I've got to figure out a way to understand why do people feel unsafe and maybe I didn't have that sentence go through the voice in my head, but it definitely put me on a path towards to maybe the less privileged people in the room, the people who are not the managers to understand what's really going on, what pressures are they under? MAE: I love that the example includes legit real smell. So many times, especially in our industry and part of what this podcast is counteracting, is getting in touch with the fact that we are people and humans. Anyway, I love that you brought [chuckles] that home that way. Also, I wanted to say from earlier, I wasn't trying to corner you into expecting to have a philosophy. I thought you might and it was worth asking. But I recently got asked a similar question about my management philosophy and which authors do I appreciate most, or something. I've been a manager for 25 years and I'm like, “Uh. I don't know. I figure out what is needed and then I deal with that.” I don't understand how to answer. So I just want to give some – pay you back and apologize. I didn't mean to get you – [overtalk] JUSTIN: Not at all and it becomes one of those you know it when you see it. I struggle with this a lot because somebody introduced the concept years ago of beginner's mindset to me where sometimes if I'm a beginner at something, the best person to help me is not the expert—the person who's been doing it for 20 years. It's somebody who's just a few hours, or a few days, or a year, or two ahead of me because they can still remember what it felt like to be where I am right now. Because I talk a lot, because I tweet a lot, because I show up in a lot of places, and I have an outward facing sales role to potential clients and candidates, I meet a lot of people who come to me and they're like, “How do I learn how to code?” And I'm like, “I can tell you the 15-year version of this story, but it's probably going to be really depressing.” I've taken as a responsibility to like try to—and I need to do a much better job of this—be armed with either resources, or people that I trust, that I can refer folks to so that I'm not totally leaving them hanging. MAE: I love that and yes. Speaking of teaching people how to code and what you said, there's a name for it that I'm forgetting about being a teacher. If you are closer to the student, you actually are a more effective teacher. So there's just two comments. The first one is I'm a part of RailsBridge I helped found the Southeast regional chapter. So if anybody, any listeners out there still want to learn how to code, or are having that same, I don't know how to tell you about my [chuckles] zigzag story and ideally, they wouldn't all be depressing, [laughs] but I'm sure they all include some real low moments. But RailsBridge, which is bridgetroll.org, has recurring events where people can go all over the country and obviously, in pandemic times it's not as much in person, but yeah. And on the comment about teaching and when you mention talking to the people with the least privilege in the room, I'm just really sensitive and appreciative of your sensitivity to power politics and how much they impact so much of what is happening and trust. So for anybody out there who's being asked to help new people and you feel like you're still the new person, you're probably in a better position to help. So just want to offer some encouragement there. I have personally found a lot more confidence in helping people who are just behind me and that anytime you're teaching, you're learning. So just want to put those in. I love that actually your answer, instead of a quadrant, is really just the one word of trust and I appreciated the ways in which you were mentioning trust can be different things. Trust in what you're building. Trust in who's asking you to do it. Chelsea asked for a couple examples and I interrupted. So I apologize, but what are some trust building exercises that you have encouraged, or examples? Maybe even continuing that same story. Six months later, was it a fresher air in there and what are some things they did to make that happen? JUSTIN: Yeah, that story, like so many teams and companies in our industry, didn't undertake the redemption arc that I wish I could convey. I think in fact, to see a big picture problem and the desire to connect that with a big picture tidy solution, a future state where it's all rainbows and unicorns and everyone really getting along well. Sometimes that sets, for me personally and when I see consultants who are less experienced, who can see that end state in mind and they know maybe the top three hit list of stuff that needs to happen to help that organization get to where they need to be. We can sometimes set the bar so high for ourselves in terms of expectations of like, what does it mean to help them become better, that we can't help, but lose sight of the value of just incremental improvement. If I can just help restore relationship between two people on a team. I had one client years and years ago, [laughs] they were also undergoing a pretty big transition and they brought me in a – I think that what they thought they were hiring me for was to be a test-driven development coach to teach them that particular practice of TDD. They got, instead on day one, there was a room of 30 interdisciplinary cross-functional teams—some developers, some non-developers, and stuff—and I could just tell that they were like, it was a big epic rewrite from a Perl codebase that, I think they were moving to no JS and Angular as well as a chewing of cloud infrastructure at the same time, as well as Agile software practices at the same time. They were overwhelmed, they've seen this fail before, they felt a ton of pressure from the business, and they didn't even really understand, I don't think, the future business model. Even if they were successful, it wasn't clear this was going to solve systemic problems for the company. And I'm like, “Well, I can teach you all TDD. [laughs] But instead what my commitment to you all will be is that six months from now, you'll either have been successful and learned all of these things and built the thing as the business has asked you to do and then the business takes off, or I will have helped equip you with skills and ways of thinking about this industry and our work that will set you up to get much better jobs next time.” Again, the company didn't totally come together. It didn't take off like a rocket ship. The team was successful in the rewrite, which doesn't happen very often. But then you saw almost a diaspora of dozens of highly skilled people—and this was in Central Ohio—who then went to venture backed startups, some went to big, established enterprise-y kind of companies, some left the region and went elsewhere. That turned into, if I had to count, probably eight, nine additional Test Double clients [laughs] down the road where they came in and they could spot in a minute, this is a way that an outside perspective, who is here to help us at a moment of tremendous need, can move the needle just a little bit. By setting expectations realistically, being humane about it, and focused on what's best for the people involved because at the end of the day, all companies are is collections of humans. That was, I guess, more my orientation. CHELSEA: So Justin, I'm interested in your thoughts on this. I appreciate what you just shared. I worked at Pivotal Labs for a while—original labs when it was sort of a generalist's enablement. JUSTIN: Sure. CHELSEA: Very heavy on that kind of thing. One of the things that we ran into relatively frequently was similar to what you've just described wherein one of two things would happen. Either the clients were successful and there was a vastly improved, I guess, software delivery culture among the people that we were working with, or if that didn't work out, then there were individuals who took to it very well and had gained variety of skills that allowed them to go elsewhere. It happened enough times that then we would have to establish trust with potential new clients around this whole additional access, which was effectively, is this going to cause a diaspora of all of these engineers, designers, and PMs that I've managed to scrape together for this project? Do you find Test Double ever facing that, or how do you address either beforehand if product owners are aware of it, or after it happens, how do you address that with clients? JUSTIN: That's a fantastic question. Pivotal Labs was one of the companies that we looked at. We started Test Double 10 years ago. I was at the time, just starting to speak at user groups and conferences and I spent a lot of time with the people at the Boulder office at Pivotal Labs. Great people. I really appreciated the focus and the rigor and in fact, made to answer a question earlier about process, or abstraction about like, “Hey, boil it down for me.” Pivotal Labs sold a very branded, very discreet process for like, this is the way to build software and, in a sense, some of the decisions that we made when we started Test Double were a response against that. Just to say we trust the people closest to the work to make the right decisions based on tremendous experience and skills. Frankly, as we get bigger and more successful, having some somebody like me at the top of an organization who only talks at the beginning of a client relationship, which is the moment that we know the least and I've got the least amount of context, for me to go and say, “Well, this is the way that we got a test,” or whatever it is would just be ineffective and inappropriate. So to answer your question, Chelsea. Fortunately, our brand power, isn't nearly as strong as Pivotal Labs so no client has ever come to us in advance with that as a question to say, “Hey, I'm worried that you're going to train our people in this particular methodology and then they're going to leave for higher paying jobs,” or something. That's never come up in advance. In fact, one of the things that we talk a lot about is that because our consultants join client engineering teams to work with them inside of their own process, using their own tools, and their own system is we just try to be model citizens of somebody on that team. We trust our clients like, “Whatever your process is, it's apparently working for you. So let's just try it and if we have ideas for how to make that better, we will listen, we'll write them down.” But then only once we've built trust and rapport with the people on that team, will we start to share, “Hey, I've got a rainy-day list of a few things that you might want to try.” What that's actually done is has a detoxifying effect where from a context of high trust, the incongruity, the distrust, the kind of backchannel frustrations that our people pick up on because we're kind of “in the trenches” with our client folks, we're able to have multiple pathways into that client organization to help make it a better place to work. We got one of the best poll quotes that I've ever seen on our website recently. One of our clients is Betterment. They're a great financial management firm in New York where it's kind of an autopilot savings vehicle. The director of engineering, Katelyn, there said that she saw on the teams where testable people were deployed, attrition actually went down and I think it's because we help those teams to perform better. An old friend of mine named Leon Gersing, he used to have a thing he'd say. He'd said, “You can either change where you work, or you can change where you work.” Meaning you can either make the place that you're at better, or you can go find gainful employment elsewhere and we're in the make the place where people work better business, wherever possible as a first avenue. MAE: You're reminding me of a book that I'm reading right now called What Got You Here Isn't Going to Get You There. Are you all familiar with it? JUSTIN: I was so proud of my wife, because she asked for that on Audible earlier this week because I'm the person with the Audible credit and I'm like, “Oh, this is quoted in business leadership contexts left and right and all over the place. So it'll give us a touchstone to talk about.” MAE: Yeah. Well, the TLDR is so much of especially management focused and leadership focused thought is about things that you should do and this book is probably along your lines, Justin of giving the counterintuitive answer. This is here's 20 things that you might want to consider not doing and then replace it with the good behavior because that is such a stretch in real life to actually do that. It's how about you just pick a couple of these that you're a repeat offender and just stop. Just try to not do it. That's the main first thing and I've found that, a refreshing take on how to think about how to guide in ways that are building more trust and offering more safety. So definitely recommend that book. I don't know that it came out of this book, but the person who recommended it to me, my VP Scott Turnquist, who is amazing, shared that there are really four categories of things that can help build trust and it's definitely all done incrementally. So picking up on that word you said earlier, Justin, too. But the four kind of axes are credibility, reliability, intimacy, and selfless motivation. If you can demonstrate those recurringly, that is how to establish and/or course correct into a state of increased trust. So anyway, that was partly why my original statement was like, do you have this down? Because I've heard some things lately that I've been thinking about. JUSTIN: I really appreciate your perspective there and it makes me feel better because one of my commitments in life is to never write a book. But if I were to write a book, I'd probably have to come up with a tidy quadrant, a Harvard Business Review two by two, or something like that to I guess, support the good work at the people at CliffsNotes and Blinkist to boil down years' worth of work into a 13-minute podcast. I think that the advice as you expressed, it is completely valid and there's one thing that I think is a core ingredient to trust. Trust of ourselves, trust of people that we work with directly, and then trust of leadership and the people who run the organizations that we're a part of. The hardest, in my opinion, is authenticity. If you're not, I think you said credible. If you combine credible, intimacy, vulnerability, those are really useful words to prompt what I mean when I say authenticity. If I'm talking to somebody and I can lock eyes with them and I believe that what they're saying is what they actually feel and it's their true self and they believe it, then all sorts of other background processes in my head of trying to read the tea leaves of what's going on here, all the passive analysis I might do to try to understand what's the subtext that this person's operating from. That's just the form of kind of armor, or a guard that it depletes my cognitive ability to talk to the person. Authenticity is a signal that we pick up on as humans and this is why it's a miracle that we have video chat in this era and it's why I really relish one-on-one in-person interactions when I can have them. Authenticity is a signal that I can drop that guard a little bit. It's that I can really look and really listen to what the person's saying and take it at face value. The problem with just saying, “Oh, okay, well just be authentic. Just be your true self,” is that that is useless advice and way more likely to trigger somebody's defenses, or their self-doubt. When I think about authenticity in the context of a team, or an organization is that the people who are maybe not in a position of power, people who report up the chain, if they don't come across as authentic to their leaders, the leaders should not look at that as a failing of the person, but as a failure of their ability to figure out how to promote and draw out authenticity from the people who report to them. Maybe they don't have safety in the room to speak their true mind. Maybe they feel like the things that make them different from the other people that they work with are a liability, or a risk and so, they can't really bring their true self to work. It's the leader's job, when they spot inauthenticity, rather than go on a hunt like a political backchannels to try to figure out why is this person lying. What's under here? Figuring out what is it about the person's context, the environment, kind of the system that they are operating in. What could possibly be an explanation for why I can't develop an authentic connection with this person? And until you run out of every single possible explanation in that investigation, including self-reflection of what is it that I'm individually doing and how I communicate to this person that's getting in the way. Only then is it really useful to start thinking about maybe this person's not a good actor, maybe they're being duplicitous, or something. Because once you've hit that button, it is really hard to go back. So when we talk about authenticity, we often talk about the individual's responsibility to present it, to be it. If you can fake authenticity, then you can do anything, right? That is advice. It's fine. I hope that everyone feels the safety. Like I'm a cishet white dude who's pretty powerful in my little corner of the small pond. I have no problem just spouting off and being my true self and so, I should just tell other people to do that too. That's not fair. I think that what is better advice for people who are maybe not in positions of power is to be really good at detecting authenticity. When you detect authenticity and people are making their true selves known to you and you're feeling a connection with them, whether they're peers, or managers, spend more time with them, invest into those relationships, and use those people as anchors of trust. So that when you're failing to make that connection elsewhere, when you have doubts about others in the organization, you can have more points of perspective on how to best address it. MAE: I read an article yesterday that says, “Laziness Doesn't Exist.” That's the title of it and it essentially says that that same thing of what's the context in which this is happening. People don't procrastinate for fun. In fact, it usually takes more work and starting from a place of what shoes are you in, but I especially love the in what way am I impacting that person's ability to be themselves? Also, I must have said the word authenticity, because this list is credibility, reliability, intimacy, selfless motivation, but authenticity and credibility in all of these things do also have to do with the thing that I loved you bringing up about identity, power politics, and what happens and your environment is not allowing you to be credible. So another way in which people can as good peers, mentors, managers, and above can do is in what way am I bolstering these people's credibility? So always flipping it back to how are we the perp [laughs] and that's very similar to social justice, racial justice. The more we see how we are perpetuating and disenfranchising, regardless of our identity, that's where there's some hope for the humans in my mind. CHELSEA: Yeah. One of the things that I appreciate that you've both brought up, Justin and Mae, is the degree to which power gradients play a role in the way that we deal with these things. There are demographic power gradients with regard to race, with regard to gender. There are also power gradients with regards to our position in the company, with regard to technical privilege, with regard to our level of skill, with regard to the size of our network. We also, I think live in this individualist culture that has a tendency to place the responsibility on individuals to do what they can to resolve. For example, what you were saying, Justin, about how we effectively coach people to just be authentic. Maybe that coaching works fine in some context, but that's a subset of the context in which we're asking people to apply it and asking individuals to resolve this from the bottom up sometimes as opposed to looking for the systemic reasons why this is a thing that has to be solved in the first place. I'm curious as to whether you have thoughts on what a person can do, who finds themselves in a position of power, in a position of leadership in a company, for example, to address those sorts of questions with other folks who are working there. JUSTIN: I think one thing that can be helpful – and I realize your question is about what can a leader do. One thing that can be helpful is for those leaders to empathize and put themselves in the shoes of people who might not have the same privileges as you described and what would it take to—I'm waiting outside my area of expertise here—would be to think about what are the things that are in a given person's sphere of direct control, what isn't, what am I setting up, and what am I communicating in terms of expectations that I have of them? An example that came up a lot in our industry was the number of drink up events in tech in the early 2010s where there was sort of an assumption that everyone likes alcohol and when people in public drink alcohol, good things happen, which turns out isn't true, but it can also be the case. There are invisible expectations that we communicate because I'm a big fan of granting people autonomy to solve problems in their own way, to approach work the way that they feel is best. Our company has been remote from day one and a big part of that was we want people in control of everything from where they work to their home network, to the computers that they use. Because when I had that control pulled away from me in the role as developer, it just sapped my motivation, my drive, my engagement, my sense of control over the stuff that's right in front of me. When I now in a role of influence over other people, whenever I speak, I have to think about the negative space of what are the expectations that I might be conveying that are not explicit. I need to be careful of even expressing something like hobbies, or shows that I like, or stuff – especially in this remote world, we want to develop connectedness. But a challenge that I keep running into is that our ability to find mutual connection with people about stuff other than work, it rides the line really closely of communicating some other allegiance, or affiliation whether that's we talk about sports a lot because that's an obvious one, but even just interest in hobbies. So I find myself – and I realize Chelsea, I'm doing a really poor job, I think of answering the question as you asked it. I find myself only really able to even grapple with like what can leaders do to set the tone for the kind of environment that's going to be inclusive and safe for other people by really digging in, empathizing with, calling up, and dredging up what their own experience was when they were not in a position of power. If I have a secondary superpower, is I had a real rough start to my career. I was in really, really, really rough client environments that were super hostile. I had a C-level executive at a Fortune 500 company scream at me until his face was red in a room one-on-one with a closed door on a regular basis. The sorts of stuff that developed callus on me, that I look back at a lot of those experiences and I'm like, “I learned a bunch.” It's supercharged my career as an individual because it strengthened me. So the challenge that I have is what can I take from those really, really harsh experiences and translate them for people who are coming up in a way that they don't have to go through the same trials and tribulations, but that they can take away from it the lessons that I learned. And for me, it's all about not just safety for the sake of safety, but safety by which myself and others can convey the useful growth that people want to see in themselves, their skills, and their abilities that isn't diluted. That can convey the truth, the difficulty, and the challenge and how hard – Programming is really, really hard for me and I've been doing it for a long time. A lot of stuff about this is just not easy. The relationships are not easy. Like you're going to run into situations where there's massive differences between where people stand on stuff and what those perspectives look like. Navigating that is hard enough without adding a whole layer of toxicity and hostile work environment. So what's a way to promote that learning environment without just totally insulating somebody from reality. That's been, I think a challenge and attention that I see a lot of other like-minded leaders in tech trying to figure out how to create. MAE: You reminded me of a meme that someone shared with me that says, “What doesn't kill you can just regulate your nervous system, trap itself in your body, steal your sense of self, make you wish it did.” I don't know what makes you stronger means, but let's stop glorifying trauma as a life lesson we've been blessed with. [chuckles] Definitely along the same lines. JUSTIN: Yeah. Relatable. MAE: There's a thing, too about putting oneself in another's shoes and this is a place where I'm someone that can read people really well, but that makes that tricky. Because I start to trust my sense of it and I have a similar architecture going if I don't feel like I'm getting the whole story. So what's the read between the lines thing. But without a lot of exposure to a lot of very different people, and most people have not had a lot of exposure to a lot of different people, when they put themselves in the other person's shoes, they come up with a different conclusion. So I will feel hurt by people who do things that were I to put myself in their shoes would not have done that to me, or if they did, it's because of X, Y, Z about who they are, or what they think, or what is their whole context and environment. All of that is there's a tactic that we use at True Link Financial called “don't cross the net.” So you say and claim the story I tell myself about that is dot, dot. When leaders, who haven't had a lot of exposure to a lot of different people and a lot of different ideas, try to empathize and find themselves limited in that, there are other options which include one of the things you said earlier. Making it so that people can say the things on their mind so whether, or not that's persons being their authentic self this is a whole another level, but creating a place where we expect that we're all messing up and that it's okay to talk about uncomfortable things is one of my real soapboxes. It's totally okay. Yes, we are all racist. We are all sexist. We are all homophobic. There is no way to not be as a result of being in the culture we're in. We could do things to mitigate it. We can do things to name it. But if we just start from yes, we're all failing. This for me, it lowers the stakes because so many people feel that if someone brings up, “Hey, that's kind of sexist,” or “This is not supporting me in this way,” or “My credibility is not being seen because of this.” In the absence of already, yo, we're going to talk about some negative stuff sometimes, that's an introduction of negativity to the “positive, happy rainbow unicorn workplace” that you were talking about before. So one of my hopes and dreams is that we get some clouds to rain on the land to allow things to actually grow [chuckles] and this includes, yo, we are not perfect. And we are definitely doing things we don't intend all the time. JACOB: That made me think about authenticity again, because sopen about imperfection. I'm a neurodiverse person so I probably am autistic. If someone were to say to me at work, “We really want you to bring your authentic self,” probably the thing I would think is you don't want that person, [laughs] or at least without getting to know me a lot better. There's a concept called masking where it's basically, there are behaviors and traits that are exhibited by neurotypical people that just come naturally to them. By learning the hard way, I've sort of learned to do them, even if they don't feel natural at all like making eye contact, smiling at people when talking, things like that. So I think that complicates authenticity for me, which is that I'm intentionally not hiding, but choosing what parts of myself to show and what parts I just don't want to bring to work. [laughs] I don't have a clean answer for that, or a solution to that, but I think that just complicates things for me. JUSTIN: I thank you so much for sharing that and I think it's a really important perspective to bring, which is I talked earlier about sure, plenty of people's true, authentic selves, even if they were to bring them, they might be in a job, or in a space, or in a team where that wouldn't be understood as such, or appreciated, or literally safe. It's hard to tell people, “Hey, you should feel safe” when the truth when spoken would be an unsafe thing. That would be setting people up for risk, for danger, and it would be a seed of distrust, which is what we're all here to talk about avoiding. So I really appreciate you sharing that. When I talked about empathy earlier, Mae, in my brain, all that really comes through it is the E-M part of that word, like the root for emotion. I never really have been able to assume that I can get somebody's context, their perspective, and the moment that they're in into my brain well enough to role play and do a re-dramatization in black and white, sepia tones and slow motion, like this is what Justin would do if he was here. That's one reason why we trust people at our company to just do the work, because we know that they're going to have such a richer amount of data and context than we'll ever have. But one thing that I'm grateful for is that I've been able to experience what I feel like is a pretty broad range of emotion. [laughs] I'm a real emotionally volatile person. I go super high highs, super low lows and I'm just like, it's how I've been. I can't help it. So when I'm empathizing with people, I'm just trying to get in the mindset of how do they likely feel right now so that I can understand and try to do a better job, meeting them where they are. A big part of that is learning there are differences and so Jacob, of course, it's like if I worked with you, I understand that it might not be productive to bring all of yourself to work all the time. But I would hope to develop a trusting relationship with you where you can share enough so that I can know what are the boundaries that are going to be productive for you, productive for me so that we can make a connection and it's something – To make this a little bit more personal. I don't know where my career is going to go next. I founded Test Double with my partner, Todd. I was only 26 years old and we've been doing this for 10 years now. 2 years ago, we embarked on a journey of transferring a 100% of the equity of the company to our employees. So we're on an employee stock ownership plan now, it's ESOP, or any of the stuff, it is complicated because it's well regulated. We have to have outside auditors, a valuation firm, we have a third-party trustee to make sure that our people and the value of the company is transferred appropriately, treated right, and managed well. So it's naturally raised, especially in my circle of friends and family who realize that, this means that there's not an end date, but there's a moment at which I can start thinking about what my life is going to be next. The people who knew me when I was 25, 26, who look at me now, it's not that I've changed radically, or my identities are radically different, or anything. It's like, I am a very different kind of person than I was at 26, than I was at 20 before I got into this industry. I have changed in healthy ways and in maladaptive ones and in response to maybe drama and stress such that the ideal retirement that I would've imagined earlier in my life looks a lot different now where I've just kind of become habituated. I'm a really, really different person than I used to be and I'm grateful for that in almost every way. I feel like I've grown a lot as a person, but the thing about me that I really look at as an area of change is that I just work too much. [chuckles] I'm online all the time. I'm very focused on – I've optimized productivity so much that it's become ingrained in me. I understand that whatever I do next, or even if it's just changing my role inside my company, I need to find a way to create more space for slower paced asynchronous thought and learning how to, in the context of a career, not just bring your true self – I'm kind of curious Chelsea, Mae, and Jacob's perspectives. That true self might be changing [laughs] intentionally. There's a directionality and the growth isn't just learning new skills necessarily, but it might be changing core things about ourselves that will alter the dynamic of the relationships that we bring to work. CHELSEA: Yeah. I have two thoughts on that, that I can share. The first is the extent to which bringing my true self is a productive thing to do at work. So for example, my career prior to tech, I did a variety of different things to make ends meet, really a wide variety of things. I graduated directly into one of the bigger recessions. I won't tell you the exact one, because I don't feel like being aged right now, but [chuckles] it wouldn't take too much research to figure it out. I was trained to do a government job that was not hiring for the next 18 months at a minimum. I needed to figure out what to do and was trying to make ends meet. In my first year of employment, I got laid off/my job ended/something like that on four separate occasions in my first year of work and that resulted in, I do not trust when managers tell me that everything is fine. I have not ever effectively and that is something that I don't foreground that in work discussions for a variety of reasons. I don't want to scare other people. I don't want them to think I know something that they don't know about what's going to happen because I don't usually. When managers tell me, “Oh, everything's great, we're doing great,” all that kind of stuff, I just don't listen. I don't. My decisions do not take that's statement into account and I find that that's the kind of thing that I think about when I'm asked to bring my whole self, my authentic self to a place is that there are things that just sort of similar to what Jacob is saying. I'm like, “Trust me, trust me on this you don't want that.” So that's kind of the first thought in that realm. The second thought that I have around this is the degree to which work should really encompass enough of our lives to require, or demand our authenticity. So I had a variety of full-time jobs in tech and then I quit one of those full-time jobs and I was an independent consultant for a while bolstered chiefly, and I was lucky for this, by folks who had read my blog and then folks who had worked with me when I was at Pivotal. So the consulting effect of people knowing what it's like to work with you is real. That experience felt very different from a full-time position insofar as at the external validation of my work was naturally distributed in a way that it's not in a full-time position and I found that distribution is extremely comforting. Such that even though I now have a full-time job, I also continue client work, I continue teaching, and I continue writing and doing workshops and those kinds of things. This is not the chief reason that I do that, but one of the nice things about it is the diversification of investment in the feedback that I'm receiving and validation that I'm receiving. In order to do that, I have an amount of energy that I put to each of the things in my life and part of it is work, of course. But another reason that I think it works for me is that I no longer have to expect all of my career fulfillment from any one position, from any one employer, from any one place, which has worked out very well because I think that we pedal this notion implicitly that you bring your whole self to work and in return, work provides for your whole career fulfillment. But most places really kind of can't and it's not because they're terrible places to work. It's just because the goals of a company are not actually to fulfill the employees, they're just not. That's not the way that that works. So it has allowed me and I think would allow others to approach the role that a given employment situation plays in their life, from what I think is a more realistic perspective that ends up helping keep me more satisfied in any given work relationship. But it doesn't necessitate that I – I guess, for lack of a better term, it limits the degree of emotional investment that I have in any one thing, because I'm not expecting all of my fulfillment out of any one thing. But I think that to say that explicitly sometimes runs at best, orthogonal and at worst, maybe contraindicates a lot of what we talk about when we talk about bringing our whole selves to work and looking for those personal connections at work. I think there is pragmatic limit past which we maybe impose more guilt than we need to on ourselves for not doing that. JUSTIN: Yeah. Thank you so much for sharing that. I think Mae used the phrase “lower the stakes” earlier and I think that one of the problems with authenticity, the phrase “bring your whole self-trust” is that the stakes are super high because it seems like these are bullion contracts between parties. For example, you said that you don't trust managers. If I was filling out a form, like a personality inventory, or something, it's like, “Do you trust managers?” I'd say no and I think 90% of people would say no. It's sort of the economy right now. I think the economy approval rating of is the economy good, or bad is at 23%. But individuals are saying at roughly 60% levels, that they are individually doing okay in this economy. I would say the same. Like, do I trust my manager? Oh, hell yeah. I completely trust my manager right now. And to lower the stakes even further, when I've been talking about trust, it's not so much about where do I find fulfillment, or who what's my identity, or who am I being, it's about a snap orientation. It's the most immediate sphere. “Oh man, this PostgreSQL query is really slow and I can't figure it out.” Is my snap reaction, or my orientation to think, “I believe in myself enough to dig into this to figure it out”, or is it doubt myself and just kind of get lost in a sea of a thousand Stack Overflow tabs and just slowly lose my whole evening? When in a team, maybe working with them and we were in planning, or something, or maybe we're in a higher stake, let's say, a code review session and somebody makes a comment about something that I did. Is my snap reaction to doubt their motivations and think “Ah, they're just trying to passive aggressively shoehorn in their favorite architecture here,” or this is politics and gamesmanship, or is my snap reaction is to be like, “Nope, let's try to interpret the words that they're saying as literal words and take it on its face”? Like I said, I'm a highly emotionally volatile person, the weather vane shifts with me all the time and sometimes I can control it and sometimes I can just merely observe it. But the awareness of the out has been really helpful to understand [chuckles] when I hear a leader say something about the company, my reaction is I think that they've got ulterior motives and that they are probably not speaking in literal truth. If that's my snap reaction, I'm just trying to communicate that as that's a potential blind spot. Because I have a long rut of past companies that I worked for that had mission statements and vision statements that were kind of bullshit and that no one really believed in, that were just in a bronze plaque on a wall, or whatever. That's baggage that I carry. I just have to acknowledge that baggage and try to move forward. The best I can do is just be present in every moment that I'm in and to understand when I have a snap reaction, am I oriented towards what might lead me to a good outcome, or a bad one? MAE: Holy moly, so many amazing things have been shared today and Jacob, especially kudos to you for walking us into a deeper level of authenticity. Love it. Thank you. I'm, to answer some of your questions, Justin very similar to Chelsea in that tech was not my first rodeo. I didn't become a programmer until I was 37 years old and I am now 45. I'm totally fine with aging myself. Prior to tech, I did put a lot more of my identity in my job and I would usually do that job pretty much all of the hours possible and I've always worked for mission driven organizations. A lot of the things that we're talking about as far as job fulfillment and whether, or not it's a good environment, or if it's a toxic environment, there's a lot of privilege in what we're talking. My parents were paper mill workers and it was not pretty. They had me when they were 19, so they didn't have another option. That was the highest paying gig in our region and they had no education. So it was never an option to even change that. So I am someone who wants to put my whole self into what I do. It's a very working-class mode and gaining identity through what it is I'm able to do. It's also a pretty capitalist [laughs] mentality that I work to move around. But as a manager, when I am a manager, or in management, or managing managers, I'm never encouraging this everybody needs to bring their whole self to work. Although, I had this really instructive experience where one person truly did not want to have any of their self at work, that they truly only wanted to talk about work at work. We're not a family, nicely nice. I don't want to crochet together, or whatever. That is the most challenged I've ever been as a manager because my natural things are always to figure out what people need and want, and then amalgamate that across the group and see how we can do some utilitarian math and get it so that people are being encouraged in ways they would like, they are not being disadvantaged, and they have space to say when that's happening. But even still, I'm always going with the let's be buddies plan and it's not for everyone. So figuring out how to not have all of your eggs in any basket, no matter how many hours the job is, is definitely a tactic that has been successful for me. But what happens is I then am involved in so many things [chuckles] in all of the moments of life. So I still do that, but I do it by working more, which isn't necessarily the best option. The thing about the mission that I just wanted to pivot for a second and say is, we are no longer in a world where we allow failure. This is a little bit back to my earlier soapbox. The energetic reality is whatever anybody's mission statement is, that is the thing they are going to fail at, like the seamstress never has the best hemmed clothes. So when we write off anyone, or any company based their flawed attempt at the mission, we're discounting that flaws exist, [chuckles] contradictions exist. It's about where are we orienting and are we incrementally moving toward that, or away from it and not in this moment, are we this thing that we have declared because it's more of a path is how I see it than the declaration of success. JUSTIN: Yeah. Thank you so much for that, too. Because I think that one thing we didn't touch on is the universe – and we're talking a Greater Than Code podcast so it's software industry adjacent at least. The universe of people who got to stay home during this whole pandemic. The universe of people who are “knowledge workers”, or “white collar”, especially if you look at the population of the world, is vanishingly small. There was a season in my life where I was the person that you just described managing, where I just viewed myself as I was burnt out. I always wanted to be a mercenary. I had this mindset of I show up at work. “You want some great code? I'll sling you some great code.” Like I was a short-order cook for story points and feature development and that was the terms, right? I didn't want to bring my feelings to work. I didn't want to make friends with people because then God forbid, it would be harder to leave. I didn't have that available to me as a capacity at that time, but I went long enough and I realized it's not that I was missing something, or not being fed in some way by not having this emotional need filled at work. It was that I was failing to acknowledge when you say privilege, the literal privilege, that I get to wake up in the morning and think for a job [laughs] and the impact that I can have when I apply all of the skills, capabilities, and background asynchronous thoughts that are not literally in my job description. When I can bring those things to bear, I'm going to have a much, much bigger impact because what am I except for one person thinking and staring at a matted piece of glass all day, but somebody who is in a small community, or a group of a bunch of people who are in the same mode. So when I'm in a meeting, I can just be the mercenary jerk who's just like, “Hey, I'm just doing this,” and feeling like that's an emotionally neutral thing. When in fact, that negativity can be in an emotional contagion that could affect other work negatively, or and I'm not exactly – My friends who know me, I'm a stick in a mud, I'm a curmudgeon, I'm super negative. I complain constantly and I have taken it upon myself to strive to be a net increase in joy in the people that I talk to and that I interact with at work. Because it is a resource that is draining all of us all day long on its own and it needs to be filled up somehow. I have the capacity right now to take it upon myself to try to fill that tank up for the people that I interact with. So I want to touch on that because I just think it's super lucky that I get to work on a computer and talk out of a screen all day long. If I didn't have that, we wouldn't be having this conversation, I suppose, but I'm just here to make the most of it, I guess. MAE: I love that. And you reminded me of Sandi Metz's closer, Lucky You. JACOB: Tell us about it. MAE: She gave the closing talk a couple years ago and it's called Lucky You and it goes through how did we all come to be sitting in this room right now and what about redlining? What about the districting? What about all of these things that led to us to experience being here as lucky? I know you weren't saying it in that way, Justin, but it reminded me of that piece, too, which is relevant, but the talk is completely amazing and I definitely recommend it. JUSTIN: I think I mentioned it once before. The thing that brought me and our marketing director, Cathy, to think that this would be a great forum to talk a little bit about trust at work is that we're about out to – and I think that actually the day that this podcast publishes is the day that we're going to publish a new conference talk that I've prepared called How to Trust Again and we're going to post it to Test Double's YouTube channel. So we might not have a direct link for the show notes necessarily, but it'll probably be at the top of that as well as the top of our blog when the show goes live. I hope that anyone [laughs] who enjoyed this conversation will also enjoy the kind of high paced, frenetic, lots of keynote slide style that I bring to communicating about a lot of these topics while still understanding that it's just like n equals one. I'm sharing my experience and hopefully, as food for thought to maybe help you look back at your own experience and understand what connects from my experiences, my perspectives, and my context that might be useful and I hope that you'll find something. Special Guest: Justin Searls.

[00:00:28] The panelists introduce themselves.[00:01:37] We hear what everyone is most excited about being at RubyConf and the talks they are most excited about going to.[00:04:11] Jason Swett shares how he prepped for the workshops, and Nick and Emily tell us about their talks. [00:08:13] Jemma asks the panelists why they come to conferences and what brings them here.[00:11:12] Everyone here is a podcaster, so we find out why they do these podcasts.[00:15:11] The panelists share what is so special and unique about the Ruby community.[00:18:59] Find out which podcast episodes the panelists are most proud of that they put out. [00:22:42] What do the panelists think about the diversity of people they bring on to their podcasts? [00:26:33] The panelists all share some great stories about Brittany Martin, how awesome she is, how she's one of the best interviewers, and what a GEM she is!   [00:29:49] Jemma wonders how the panelists stay on top of what's going on in the Ruby community.[00:32:01] The panelists talk about how they, as podcasters, think through what might be interesting to talk about on their podcasts.[00:37:10] Find out who the panelists call their “Ruby Heroes.” [00:44:34] The panelists tell us how they find themselves consistently producing podcast episodes without suffering from burnout. Panelists:Jemma IssroffAndrew MasonJason CharnesEmily GiurleoNick SchwadererJason SwettSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterAndrew Mason TwitterJason Charnes TwitterChris Oliver Twitter Jemma Issroff TwitterEmily Giurleo TwitterNick Schwaderer GitHubJason Swett TwitterRemote Ruby PodcastThe Ruby on Rails PodcastThe Code with Jason PodcastRuby WeeklyPeter Cooper TwitterWNB.rb TwitterRemote Ruby Podcast-Episode 139: Learning in Public | Alpine & Inertia (our mental health episode)Remote Ruby Podcast-Episode 100-Upgrading Rails with Ernesto TagwerkerRemote Ruby Podcast-Episode 97-Joined by Adam Wathan: TailwindCSS, Tailwind UI, and ActionView ComponentsThe Code with Jason Podcast-Episode 28-Sandi Metz, Author of POODR (with Special Guest TJ Stankus)The Ruby on Rails Podcast-Episode 271: MEGA RailsConf 2019 Recap with Chris OliverThe Ruby on Rails Podcast-Episode 385: Minimal Flame Wars (Prettier, Parsing and Regex) with Kevin NewtonObie Fernandez TwitterThe Rails 5 Way (Addison-Wesley Professional Ruby Series) by Obie FernandezAaron Patterson TwitterCollin Jilbert TwitterBrittany Martin TwitterBrandon Weaver Twitter

Within a year of the first prototype, Prefect had their first paying customer — a Fortune 100 company. Their SaaS offering was not even publicly available yet. That was partly because they were developing a platform that allowed companies to build, run, and monitor data pipelines at scale, a problem no one else had tackled in quite the same way. Another reason was their commitment to the iteration cycle during development. By releasing the MVP early, they were able to gather feedback immediately and improve the product with incredible speed. In this episode, Prefect's CTO Chris White shares the challenges they encountered and lessons they learned along the way. We discuss: - How Prefect helps developers run and monitor data pipelines at scale - Their strategy around open source - Intentional choices made during their development journey - Building a culture that embraces mistakes Check out these resources we mentioned during the podcast: - Find design books by Sandi Metz at https://sandimetz.com/products - Find Creativity, Inc. by Ed Catmull at https://www.creativityincbook.com/about/ Want to hear more stories from high growth software companies? Subscribe to Application Modernization on Apple Podcasts, Spotify, or check out our website. Listening on a desktop & can't see the links? Just search for Application Modernization in your favorite podcast player.

[00:03:15] We start with Andrew telling us he's not a fan of code coverage metric and talks about a gem everyone uses called SimpleCov and what it does. Kevin dives into code coverage and why he doesn't believe it's a holistic measure and how code coverage can lie to you.   [00:05:40] Find out why Kevin love tests, and he explains some other downsides of focusing on code coverage and brings up Coveralls and when is it too much.[00:08:55] Andrew asks Kevin if there are some metrics that are good to track to provide value for your team. [00:15:59] Chris and Kevin chat about tools and Andrew mentions Attractor, from Julian Rubisch and possibly RubyCritic.[00:17:33] Andrew wonders how important is it that your code base is super dry, and Kevin expresses his opinion on this. He mentions Sandi Metz talking about “duplication is far cheaper than the wrong abstraction.” [00:23:24] Andrew and Kevin discuss the topic of “rules” and why Andrew doesn't like that term for programming things. [00:25:49] The topic of performance is discussed and how it goes back to what is the business value of it. Kevin talks about the tricky things of performance as well.  [00:32:00] Kevin shares some other things when it comes to measuring “good code.”[00:33:38] Andrew, Chris, and Jason share the metrics they like, they share examples,  and they talk about using SimpleCov.[00:42:14] Find out where you can follow Kevin online, and if you need a speaker at your next virtual regional meetup, go ahead and reach out to him. Panelists:Jason CharnesChris OliverAndrew MasonGuest:Kevin MurphySponsor:HoneybadgerLinks:Ruby Radar TwitterKevin Murphy WebsiteKevin Murphy RailsConf/RubyConf talksKevin Murphy TwitterThe Gnar CompanySimpleCovCoverallsAttractor-GitHubRubyCriticSandi Metz Blog-“The Wrong Abstraction”

Christian Clausen is the author of the book Five Lines of Code in the Manning Early Access Program. He advocates for a rule based refactoring system. One of the rules he uses is refactoring your methods to be five lines of code. Listen in to hear him explain why five lines of code matters and how to get there. Panel John Epperson Guest Christian Clausen Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Sandi Metz' Rules For Developers Christian Clausen - Medium Twitter: Christian Clausen ( @thedrlambda ) GitHub: Christian Clausen ( thedrlambda ) Picks Christian- Embracing Imperfection John- Fiber Gummy

Christian Clausen is the author of the book Five Lines of Code in the Manning Early Access Program. He advocates for a rule based refactoring system. One of the rules he uses is refactoring your methods to be five lines of code. Listen in to hear him explain why five lines of code matters and how to get there. Panel John Epperson Guest Christian Clausen Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Sandi Metz' Rules For Developers Christian Clausen - Medium Twitter: Christian Clausen ( @thedrlambda ) GitHub: Christian Clausen ( thedrlambda ) Picks Christian- Embracing Imperfection John- Fiber Gummy

Christian Clausen is the author of the book Five Lines of Code in the Manning Early Access Program. He advocates for a rule based refactoring system. One of the rules he uses is refactoring your methods to be five lines of code. Listen in to hear him explain why five lines of code matters and how to get there. Panel John Epperson Guest Christian Clausen Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Sandi Metz' Rules For Developers Christian Clausen - Medium Twitter: Christian Clausen ( @thedrlambda ) GitHub: Christian Clausen ( thedrlambda ) Picks Christian- Embracing Imperfection John- Fiber Gummy

01:00 - Mae's Superpower: Being Able to Relate to Other People and Finding Ways to Support Them 03:42 - Contributing to Humanity (Specifically American Culture) * Title Track Michigan (https://titletrackmichigan.org/) * Climate Change * Clean, Accessible Water * Hate & Divisiveness; Understanding Racial Justice 07:01 - Somatics (https://en.wikipedia.org/wiki/Somatics) and The Effects of Yoga, Meditation, and Self-Awareness * Flow (https://en.wikipedia.org/wiki/Flow_(psychology)) * Kripalu (https://kripalu.org/?) * PubMed (https://pubmed.ncbi.nlm.nih.gov/) * Cognitive Behavioral Therapy (CBT) (https://www.apa.org/ptsd-guideline/patients-and-families/cognitive-behavioral) * Debugging Your Brain by Casey Watts (https://www.debuggingyourbrain.com/) 12:20 - Mutual Aid: Solidarity, Not Charity * WeCamp (https://weca.mp/) * Ruby For Good (https://rubyforgood.org/) * Harm Reduction * Encampments * “We keep us safe.” * Rainbow Gatherings (https://en.wikipedia.org/wiki/Rainbow_Gathering) * Burning Man (https://burningman.org/) * Big Big Table Community Cafe (https://www.bigbigtable.org/) 33:17 - Giving vs Accepting Help; Extending and Accepting Love, Empathy, and Forgiveness * Collective Liberation * The Parable of Polygons (https://en.wikipedia.org/wiki/Parable_of_the_Polygons) * Listening: What could be of use? * 99 Bottles of OOP (https://sandimetz.com/99bottles) – Sandi Metz (https://twitter.com/sandimetz) 48:25 - The Mental Health Challenges of Being a Programmer * Celebrating Small Wins; “Microjoys!” Reflections: Casey: The word mutual aid can be more approachable if you think about it like people helping people and not a formal organization. Also: help and be helped! Jamey: Valuing yourself and the way that helps the communities you are a part of. Mae: Engaging with users using the things your building is a reward and a way to give yourself “microjoy!” This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: JAMEY: Hello and welcome to Episode 238 of Greater Than Code. I am your host, Jamey Hampton, and I'm here with my friend, Casey Watts. CASEY: Hi, I'm Casey, and we're both here today with our guest, Mae Beale. Mae spent 20 years in and out of nonprofit-land, with jaunts into biochemistry and women's studies degreeing, full-time pool playing, high school chemistry and physics teaching, higher ed senior administrating, and more. She went to code school in 2014 (at 37 years old) to gain the technical skills needed to build the tools she wished she'd had in all the years prior. So glad to have you, Mae. MAE: Thanks, Casey. Thanks, Jamey. Same for me. JAMEY: So you may be ready for the first question that we're going to ask you, which is, what is your superpower and how did you acquire it? MAE: Yeah, thank you. I think that my superpower is being able to relate to other people and find ways to support them. How did I get good at that? Well, I've dealt with a lot of pretty complicated people in my life that you have to do extra thinking to figure out. So I think I got my start with that and I've done lots of different things in life and met lots of different people and felt lots of different feelings and thought lots of different thoughts. So I think that's mostly it: living. JAMEY: I was going to say that I know from knowing you that you've done lots of things, but even our listeners who don't know you probably already know that just after listening to your bio, so. [laughter] MAE: Yeah, and there's plenty more that didn't make it in there. That's something that is fun and a joke is no matter how long people know me, there's always still something that they didn't know and so, that's fun for me. I like to surprise other people and I love being surprised by people. So it's like a little game I have with all my fun facts. JAMEY: I love that. CASEY: I've got a question: what's on your mind lately. MAE: What is on my mind lately? So many things, I don't even know where to start. One is where and how can I contribute to the future of humanity [chuckles] and American culture in particular and in the circles that I'm in, drawing it down even more. So I think about that a lot. I think about my house a lot. I just bought a house and I'm going to do each room with a color theme so it'll end up being, you walked through the rainbow. Pretty excited for that, lots of things there. And I think a lot about how to empower others and be a more and more effective communicator. I think about that a lot. Probably those are the top ones and maybe Dominion. I play that every day. So I think about that a little bit. CASEY: [chuckles] Love that game. JAMEY: Me too. CASEY: This is great. All three are really interesting. I want to start on your first one. What opportunities do you see lately, or what have you done recently, or what do you hope to do to help the world help American culture help make an impact? What are you working on? MAE: From where I sit, it seems like the most important things that any of us can attune to about even a portion of is the environment and whatever's going on with our ability as humans to respond to climate change and water, like clean, accessible water for people, and hate and divisiveness. Those three things I think are our biggest challenges. So I try to do things that end up in those spheres, if not in things that ideally have some mix of those rather than having them be silos. One of my jobs is working with Title Track Michigan, and they are a relatively new nonprofit that brings creative practice to complex problems and is specifically focused on water protection, racial equity, and youth empowerment. Once all the uprising started in 2020, we created an Understanding Racial Justice course for white people in Northern Michigan and so, I've been helping to facilitate those courses and taking as many opportunities to rethink my orientation to all those topics as well. CASEY: That's so cool. You found a group that does all of those things in one. MAE: Amazing, right? CASEY: Wow. Title Track Michigan, huh? MAE: Yeah. I found them because my life radically changed a few years ago. A lot of things changed at once like, not just a lot, all of the things. So I went on this walkabout just trying to find ways to be of service in the world without expectation, watch who I met, and where I ended up. I ended up in Michigan and getting introduced to these people who then were creating a new nonprofit Title Track. Another thing I do is I have a consultancy that I have a flagship enterprise product for nonprofit, small business administration. That is a little bit of a Trojan horse for change management and organizational development and sustainable longevity planning for organizations. So the fact that I ended up there with them at that time and way more cool synchronicities happened. That's how I met them. So it just feels right and great to have landed in that space and then to have 2020 be what it became, we were already formed and positioned to try to be of help. JAMEY: This is an abstract question. MAE: Okay. JAMEY: But what does it feel like to feel like you're doing the right thing in that way like, the right place to be? I got the sense from you telling this story that things just came together in the right way at the right time and that's a beautiful thing when it happens and you said it feels right. What does that feel like? MAE: Mm thanks, Jamey. Well, my first thought is another thing that Title Track does in that Understanding Racial Justice course and a lot of circles I've ended up in have a focus on somatic and so, body centered awareness and engagement. So I used to always think my answer was going to be emotional when people ask me, “How do I feel?” and now I hear and think of my body first so that's cool. I'll answer a couple of ways, if that's okay. When for me synchronicities happen and I feel most alive, or of use, which is important to me, my heart literally feels bigger and almost breathing like I can feel air. I don't know how to explain that. I definitely will be smiling more, my back is straighter, and I usually have a lot more to say. All of a sudden, I'll have a lot to say. Other times, I have nothing to say! For how I might've answered that question previously would be closer to having a lot of things to say, like I'm a lot more creative, making connections, getting excited, and wanting to create new things together with other people. How about you two? CASEY: Just hearing you describe that, I have thought back on times I felt really proud and engaged and I noticed my posture improved, too. That's so interesting. I've had a nerve injury for 2 years. My hands go tingly sometimes. So I'm working on my back and noticing posture all the time. Interesting how my mood like that could affect the posture. I believe it, too. JAMEY: I'm not sure that I would have called out posture specifically in that way, but now that I'm thinking about it, I think what I would say is I feel lighter. MAE: Yeah! JAMEY: So to feel less bogged down, I can see in what way that's related to posture. [chuckles] MAE: Totally. Yeah. CASEY: We all have a lot to say on this, I love it. [chuckles] This reminds me of the Flow State. So when your skills match a need and it's challenging the appropriate amount, you're in a great concentration state, but if your skills aren't enough, or if the need isn't important enough—either one—feels a little way less good, not good. JAMEY: Totally. MAE: I lived at a yoga retreat center for a little while in Massachusetts called Kripalu—it's the largest yoga retreat center in North America. I had never done yoga and I was like, “Oh, cool. I'll just go live there [laughs] and see.” Anyway, I was there for three months and they have a part of their organization dedicated to optimal human performance. They have a partnership with Tanglewood and some other places around there to see if yoga and meditation can induce more Flow State, more of the time for top performing musicians, and just to be able to have more “scientific evidence” about how physiologically we can do things to get ourselves closer to those states more often. Pretty cool work. JAMEY: Yeah. That's really interesting. CASEY: I was just doing some research on the effects of different types of yoga and meditation on anxiety. I was trying to read some of the primary sources. I like to go to PubMed first—that's my go-to. Some people do Google Scholar. It's interesting, the framing sounded in a couple of papers like, “Well, it's not as good as CBT,” and my takeaway was, “Well, it helps an amount, huh? Great, good.” [laughter] So people who can't get access to CBT should consider that and that's true anyway. Science has shown this thing we knew was helpful anyway, is helpful in an empirical sense and that's great. MAE: Totally. Casey, for anybody who might not know what CBT is, would you be willing to…? CASEY: Thank you. CBT here is Cognitive Behavioral Therapy, which is one of the most common and effective forms of talk therapy you would do with a therapist. It focuses on what some maladaptive, unhelpful thought patterns are and helps you change them. MAE: And that's coming from a psych major, right, Casey? CASEY: That's right. I talk all about that in my book, Debugging Your Brain. It's funny, but you're flipping the script here. Usually we do this to our guests. MAE: [laughter] Great! CASEY: Love it. JAMEY: There's another project, Mae that I know that you've worked on that. I'm a little bit surprised that you haven't brought up yet, but I'm going to bring it up, which is your Mutual Aid program. MAE: Thank you. JAMEY: I think that when you are talking about doing something to make an impact on the world, like that was the first thing I thought of since I know you're involved with that and I would love to hear you talk about it. MAE: Yes. Thank you. Thanks for bringing that up and I did want to talk about that and I was looking forward to hearing what you have to say about that topic as well. So when the pandemic started, you may have seen these, or become involved, but there was a whole bunch of spreadsheets starting like Google Sheets of people who had some needs and people who wanted to offer some things. Google spreadsheets are really easy first pass for people with low tech skills and no budget to just come together. But I started being invited to all these different spreadsheets from around the country that include people's name, address, phone number, CashApp name, their exact vulnerabilities and identities, and current struggles in a spreadsheet that's downloadable. It really freaked me out and I started coding that day about how can we start to do something to make these people not have to have their identity so exposed and through like WeCamp networks, Ruby for Good networks, and different Slacks I'm in of varying programmers, I started saying, “Does anybody else want to get involved?” and several people did. So we have built a platform to support mutual aid groups and what we did immediately was find some groups to figure out what their needs were instead of just what we might imagine. They were doing a lot of, we call it dispatch moderated setups where people fill out a form and then volunteers read the forms and then match people and do all the communication manually, but not having peer-to-peer things go on. The system was originally designed to support that dispatch moderated set up and once people started to go back to work in the fall and there weren't as many people able to devote as much time to volunteer, and as varying groups, especially ones that hadn't been around as long, realized they would probably need a lot more training in social work, ask things just to be more effective and figure out how to route people correctly within their community to services that might be able to help them a little more. Since the fall, we've to coding peer-to-peer solution. We have several different mutual aid groups around the country and right now, most closely working with groups in Michigan and New York state, just because that's where our networks are. Getting to launch some peer-to-peer stuff, but mutual aid itself has become a buzzword and like, what is that anyway? [chuckles] So that topic I love talking about. There's like a mutual aid saying, “Solidarity, not charity.” The whole thing is we're all in it together and we're not going to rely on different structures, or institutions that were set up most often in ways that institutionalized various forms of oppression. Just empowering people to connect with each other, have stronger networks, and build more resiliency is what's up with it, but mutual aid has been around for over a 100 years, at least as a term and a thing, but it generally, almost always springs from communities that have been disenfranchised. So when the pandemic started and a lot of new groups formed, not everybody had already checked what's already happening and a lot of different people, especially in communities of color, were surprised by like, they didn't hear that term, that's just what they do. There's been a big—along with everything else—learning of how those structures already were in place and how we can continue to grow them, and support each other as we navigate this world we're in. Jamey, I was going to ask you about your involvement with mutual aid, too and if you had anything to add to that definition. JAMEY: I was going to say that I really liked what you said about finding new ways around things that have been institutionalized. Because I think one of the things that's so beautiful about mutual aid is the way that people can help each other realize what kind of help is available and what kind of help they even might need. A story that I really like to tell that and I think about a lot is I have a friend who's involved in mutual aid in Buffalo, where I'm from and he does repair work and just is very handy in that way. So he does a lot of mutual aid repair for people and he told me that the way that this started for him is that there was a request in our mutual aid Facebook group where someone was saying, “I really need $200, or something like this because my window is broken and I need to buy a space heater because it's been getting really cold. So I need this money to buy a heater and all of this stuff.” My friend came in and was like, “Okay, but what if I just fixed your window?” It had not occurred to this person that she could ask for that. MAE: Oh, boy. JAMEY: She was coming up with all these solutions around it. So this idea of like coming together as a community and saying, ‘Yeah, I can help you, but can we help a little bit closer to the source than what you even just asked for?” I think is really powerful. MAE: Yes. I love that, Jamey. Yeah, it's the closer we can be in community with each other, the easier those asks are. Something that you said about figuring out your own needs, there is a thing and it's related a little bit to some of the other topics we've talked about where there's like the white savior thing. People want to do something for people who they think are less – they have less than them. There's a power dynamic there and mutual aid—mutual, that's the main part. So you really aren't doing mutual aid if you're not accepting help. All of us have things that we could be supportive with and things to offer. I love also having that not – there's a lot of mutual aid that is about just giving money and/or like reparation stuff. But I love when money isn't part of the equation and quantification of value isn't part of the equation. It's just like, “I have something to give and I could use something and this is how we're going to stay in community and in network and lower those barriers to have offers and asks be even easier in the future.” JAMEY: For sure. I think it's about meeting people where they are, too, because I agree about some programs are focused on money, and some people have money and can put that into the community and that's great. But maybe they don't have time to show up and do these things and other people might think like, “Well, how can I help because I don't have money,” but they have time, or they have skills. I think that everyone bringing in and saying, “This is what I have to offer with what's going on in my life right now,” and maybe it's money, or maybe it's time, or maybe it's something else that I didn't even think of that they're going to offer. [chuckles] MAE: Totally. When you were saying that, I just got a chill thinking if really every single person just that question you just said, “How can I help?” If we all did one thing, this is how to effect broad change. CASEY: How can people find the mutual aid groups near them? If they just search mutual aid, that probably gets a bunch, but they don't all say it, right? MAE: Yeah. It's a really great point. There have been some different efforts to link together mutual aid networks and there's a map, but not every network is on it because not every network even knows about it. [chuckles] So because mutual aid is so grassroots, it's not – CASEY: Right. MAE: A number of them have form 501(c)(3) is just to not be doing illegal financial transaction stuff that is problematic by having all this money go through their personal Venmo, or something. But that is what a lot of people have done. So mostly there's the Google option and the term mutual aid is getting used more and more, but there are some other phrases. I'm forgetting it right now. What's the name when they hand out medical supplies? Harm reduction, there's a bunch of harm reduction efforts. Also, in cities where there are a lot of homeless shelters, there's things around encampments and like becoming community with those folks to advocate. Another piece, major piece of mutual aid that I forgot to name is it inherently has a political engagement component in it. So one of the reasons why it is this solidarity thing is you're seeing all the humans as inherently equally valuable and that you're identifying the structural things that led to people having a different experience, or a different privilege, or a different outcome to what's going down for them. So then by identifying those together, you try to change the system to not create the problem. Whereas, to go back to that phrase charity, a lot of charities—which are awesome, I'm not trying to knock those—but a lot of them have more of a it's your fault, or shortcoming, or need that has put you where you are. Mutual aid is the way in which this is all rigged and on purpose, or not on purpose, or just the impact of the structures is how you ended up where you are so let's rejigger. JAMEY: A phrase that comes up a lot, in the protest community specifically, is, “We keep us safe and we say that at protests about security, medics and things, and wearing masks—I've seen people start to use that phrase. But I think that that's a phrase that really speaks to like what mutual aid is about, too. It's about we are doing something together for ourselves as a community, and we're not looking for something from the outside that comes in a hierarchical structure. We're just making this decision as a group of people to take care of ourselves and our neighbors and I think that's what I really love about it. [chuckles] MAE: Totally. Yeah, absolutely. And back to what you were saying, Casey, the how can people find those things? There's also just, “Hey, I've got some extra seeds,” or put a cabinet in your yard with some food in it and say free food. You don't have to associate with a “mutual aid group” to do mutual aid. It's like, that's just a blanket term, basically that offers a little bit of a cue about what those people might be up to. But it's really, in whatever way you are sharing and developing relationships with your fellow community members. This is mutual aid. JAMEY: I thought of another example of that. MAE: Yay! JAMEY: We have this in Buffalo, but I think it's a thing that we're seeing other places, too. Separate from our mutual aid network, we have a Facebook Buy Nothing group. MAE: yes. JAMEY: And people will post like, “Oh, I have this, I'm going to get rid of it. Someone come pick it up.” “Oh, I was going to donate these spoons from my kitchen. Someone can have them.” When you said seeds, that's the kind of thing you'll see on Buy Nothing and I think that's been a revolution in anything even separately from it, because I do think that money plays a part in a lot of mutual aid stuff, because folks need money for things. But in Buy Nothing, it's pointedly without money and I think that that's a very fun and cool dynamic, too. MAE: Totally. Yes. I have a couple of things I would love to say them. One is that the bringing up Facebook has started to support mutual aid. But also, I don't know if y'all have seen The Social Dilemma and just become aware of all of this tracking that's going down. There's something that is another motivator for us on the mutual aid repo is this is open source code that anybody who wants to use it can stand up their own instance and if you partner with us, connect with us, we will help you if you need us to. But it's intentionally not a multitenant app so that people have small datasets that they own and there isn't like this aggregate thing going on about local data. It's basically a small tech for the win, which is also pretty mutual aid-y. Our group, like the programmers who are most involved, meet a couple times a week and know about what's going on in each other's lives. We are mutual aid for each other, too. The energy of what, how, who we are, and what we're doing is getting put into the thing that we're building that hopefully has that same effect. So there's this nice spiral thing going on in there that I'm proud of. I think there's a lot about what we referenced earlier, institutionalization of oppression, that has to be like, there are ways to create other options and they take cultivation of and building new structures. Stuff like this as an example of that and an experiment in it. Another one that it reminded me of is when I was younger, I used to go to rainbow gatherings. I don't know if y'all know about these. It's a super hippie thing and there's regional gatherings, but there's a national gathering at a national forest every year. All these people just show up and then they build earthen stoves. There's a bunch of people who do not participate in main society; they just go to these different gatherings and travel around as a… There's plenty more to talk about rainbow tribe and even the usage of that word tribe and what goes down. I'm not going to try to touch into that, but something I love about it is there's a whole exchange row where people just sit out with things and there's no money. You're not allowed to use money. I think I was 18 when I went to my first one and I was just like, “What? This is amazing.” Like, just to imagine my life not through a currency, or that evaluated exchange, it was so inspiring to me. It still is and so, some of what you said, Jamey, reminded me of that. JAMEY: I relate a lot to that, too. Burning Man events are also no money allowed. MAE: Ah. JAMEY: When I first entered that space, that was one of the things that really spoke to me about it too. In fact, it's also no barter allowed in Burning Man. It's a purely gifting economy where if you give someone something, a lot of times they become inspired to gift you something back right there and there's an exchange that happens. But culturally, the point of it is that there's not supposed to be any expectation of exchange when you gift something to somebody. MAE: Do you know about that restaurant in San Francisco that is free, but you pay for the person behind you if you want? JAMEY: I don't know about one in San Francisco specifically, but we have a program like that similar in Buffalo. It's called Big – I'm going to look it up so I can link it up. MAE: How about you, Casey? I'm getting excited so I keep saying things. CASEY: I'm reflecting on the award mutual aid a lot through all this. I like this idea that mutual aid as it is in action and that mutual aid groups do mutual aid, but individuals can, too. MAE: Yeah. CASEY: That's a pretty powerful theme. It makes the term more approachable, especially since it's a jargon word lately. It's just grassroots-y helping each other out, however that looks. MAE: Totally. CASEY: I'm thinking a lot about what communities I'm a part of, too, that naturally have that phenomenon. It's like, I'm queer, I'm in a lot of queer groups. I'm in interest groups like musician groups and they help each other do stuff. They carpool to the practice or anything like that that's this. There's also a formal ones like D.C. Ward 6 has mutual aid groups that are named that. That's its own thing. And then even my Facebook friends, I just post like, “I have a crackpot, who wants it?” MAE: Totally! CASEY: But before today, I might not have used the word mutual aid to describe any of that because I'm not part of a formal approved mutual aid group, which is not the point of that term. MAE: [laughs] Yeah. CASEY: Just people helping people. MAE: When I was thinking about getting into tech, I, as a pretty outspoken woman who will address injustice directly if I see it, when I see it in myself and others, I wasn't sure if that was going to be a place for me. I had had some not awesome experiences with tech people before I was in tech. So I reached out to a bunch of people who were already in the biz and they spent hours talking to me about their experiences, answering all of my questions, and offering to help me. As I took the leap and went to code school and participated in a meetups and just, everywhere is mutual aid in programming, everybody is helping each other. “I have a question,” “I'm wondering about this.” This podcast is mutual aid, in my opinion. It's been really inspiring for me to be a programmer because I feel a part of a worldwide network of people who try to, especially with mixing in the open source piece, build things and offer what they can. It's awesome. CASEY: I have a challenge for people listening to this podcast. This week, I'd like you to help someone and accept help from someone, both in the spirit of mutual aid. MAE: Yes! CASEY: I'm not surprised; accepting help might be the harder half for a lot of people. MAE: Yes. JAMEY: I think that's true. [chuckles] MAE: One way I've said it before is that that is your gift to the giver. The giver doesn't get to be a giver [chuckles] unless you accept the gift from them and that people can, including myself at times, tend to over-give and that is its own challenge. So if you need to stay in the giving frame, [chuckles] you can be like, “All right, well, I'm providing this opportunity to the other person.” [chuckles] CASEY: Sometimes I've playfully pushed on an idea to people. I'm trying to help them and they say, “No, no, no. I can't accept your help because I would be indebted,” and I'm like, “You would deprive me of this good feeling I would get from helping you? Really?” [laughter] MAE: Yeah. CASEY: Thinking of it a little bit, I'm not like – [overtalk] JAMEY: [inaudible]. CASEY: Right. I'm just thinking that way a little bit, flipping it, helps some people accept the help then. MAE: Yeah. JAMEY: I think that people have so much harder of a time of extending love and empathy, and forgiveness, and all of these nice things that we might really value extending to other people, but not to ourselves. MAE: Yo, that's for real, Jamey and still on this theme, the seeing each other as equals as in community. My Mom used to say this great phrase, “There but for the grace of God, go I.” She was raised Catholic so it's got that in there, but I love that of this could definitely be me. There's a cool Buddhist practice that I learned from Pema Chödrön about you extend release of suffering to others and then you widen the circle to include yourself in it, but you don't start there. So similar to how you're saying, Jamey, that that is a challenge for a lot of people, it's just built into that practice where when you can't give yourself a break, [chuckles] imagining others in that situation and then trying to include yourself is an angle on it. JAMEY: I like that. I think also related to Casey's example of his joke. It's thinking about how what you do affects other people, I think sometimes we're better at that and if you're treating yourself bad, especially if you're in one of these tight mutual communities. If you're treating yourself bad, that's affecting the people around you, too. They don't want to see you being treated bad and they don't want to see you being miserable and they want the best for you. When you're preventing yourself from having the best, that's affecting the whole community, too. MAE: Yo! JAMEY: I hadn't really thought about it like that until right now. So thank you, Casey, for your joke. CASEY: Powerful thought. Yeah. Like the group, your people, your team, they need you to be your best. So if you want to help your team, sometimes the best way is to help yourself. It's not selfish. It's the opposite of selfish. MAE: Exactly. Another thing I've heard a bunch of the different activist groups, some phrasing that people have started to use is collective liberation and no one's free till we're all free and if we are suffering, the other people are suffering and vice versa. So figuring out how to not be so cut off from ourselves, or others, or that suffering and seeing them as intertwined, I think is one of the ways to unlock the lack of empathy that a lot of people experience. CASEY: There's a really cool visualization I like that that reminds me of. It's called the Parable of the Polygons and you can drag around triangles and squares. You can see how segregation ends up happening, if you have certain criteria set up in the heuristics of how they move. Or if some people want to be around diverse people, it ends up not happening, or it ends up recovering and getting more integrated and mixed. It's so powerful because you can manipulate the diagrams. There's a whole series of diagrams. Look it up, it's the Parable of the Polygons. MAE: Cool! That is awesome. CASEY: So I want to be around people who aren't like me and that helps. It helps with this phenomenon and the more people do that, the better. MAE: Yeah, and having grown up in a small city, that's pretty homogenous on multiple levels. When I went to college and learned that people thought differently, my world was this very rigidly defined, this is how things are. [chuckles] My biker dad, that's still his way, his lens. When you start to experience people who are not like yourself, you let that challenge your assumptions, then you end up transformed by that. I was a double major in college—biochemistry and women's studies—and I remember being in an organic chemistry class and the professor said, “Well, if that's too hard for you, you can go take a sociology class.” I raised my hand and was like, “My sociology classes challenge me on every single thing I think about the world. Your class requires me to provide rote memorization, which I'm awesome at luckily and that's how I ended up in your class.” But that is not harder. That's that story. CASEY: The last episode that I recorded was with Andrea Goulet. One of the things that kept coming up was the old-timey programming interview questions were all about math. MAE: Yes. CASEY: Which isn't necessarily what programming is about. That reminds me here of rote memorization in that class versus complex systems thinking in sociology. MAE: Totally!
 CASEY: With these two choices, I might choose a sociology person to do architecture work in my software than the rote memorization person. MAE: Totally, definitely, every time. Yeah, and that's a different lens that I have coming in to the industry from having been an administrator for so many years is our perception as programmers about what's going to be helpful is very different than someone whose day job is to do repetitive work like very, very, very simple apps. When I was in code school, I really wanted us to figure out how to make even our homework assignments be available for nonprofits and that's how my whole system in business ended up getting spun up. Oh, it was before that. My job before that, when I interviewed, I said, “Well, how long do you need someone here for? How long would you need me to commit?” and he said, “A year,” and I said, “All right, well, I'm not sure I'm the best candidate for you because I'm going to go to grad school and get a degree and be a consultant as businesses and nonprofits.” And then I was at that job for 8 and a half years before I went to code school. [laughs] But the thing about what could be of use just requires so much humility from programmers to defer to the actual employees and the workers about their experience and what could help them. Because so often, we think that we're the ones with the awesome idea and we can just change their lives and disrupt the thing. A lot of the best ideas come from the people themselves. I went to a project management training in Puerto Rico and it was a very rarefied environment of people who could pay for people to get PMP training, or whatever. The people that were in my cohort were factory project planners and not a single one of them knew anyone who worked in the factory. Like, they didn't get to know them as part of that project and they didn't have anyone in their sphere and my parents were paper mill workers. So when I'm sitting there and listening to these people talk about the worker and their lack of wherewithal, I guess, there'll be a gracious way to say it right now, I was just appalled. I try to take that into any time we are building software in a way that honors all people. CASEY: Yeah. My favorite leaders are the ones that listen to their employees and the users. I am happy with my roles in leadership positions, but the thing that makes me happy with myself is listening and if I ever lose that, I don't trust myself to be a good leader, or manager. MAE: Totally. CASEY: I could. I know it's easy when you get promoted to stop listing as much. It's the incentive structure of the system. I wouldn't blame myself if I lost it, but knowing I value it and don't want to lose it helps me hold on to my propensity to listen. MAE: Yes, Casey! Totally that. CASEY: Sometimes people have asked me, “What makes you think you'd be good at leading this?” That is literally my answer is like, “Well, I won't forget to listen.” MAE: Yeah. JAMEY: I think that it's weird the way that people create this hierarchy of good ideas and better ideas and which idea is better and put that kind of value judgment on it. When really, when you're dealing with software and trying to create something that works for the people that are using it. It's not about whether your idea is good or bad, it's about whether it's the right one for that group of people. My background, my first tech industry job was in agriculture and so, all of our customers were farmers and people that worked at farms, To admit I don't know what it's like to work on a farm in that way, it's not a value judgment about whether you're smart, or good at programming, which people act like it is. It's just a true fact about whether, or not you've ever had that experience. [laughter] CASEY: Sometimes I run workshops where we think about all the pros and cons to different ideas and when we need it, we pull out a matrix. We get a spreadsheet that has columns and rows, and rows are the ideas. A lot of decisions are made with one column, naturally like, “What's the best?” You just say like, “1 to 10, this one's the best.” But when we break it out, we have lots of columns, lots of variables like, oh, this one's easier to build, this one's higher impact. And when we break it out even further, we can weight those columns then do the matrix math and people like that, actually. Even people who are math averse. They can fill in the numbers in each of the cells and then they trust the spreadsheet to do the thing. That gets us on the same page. It depends on the context, which columns matter, which factors are important and that can completely change the situation. Even if you all agree on this one's harder than that one, the outcome could be completely different. The columns, or the context in my matrix model. JAMEY: We're reading at work 99 Bottles of Object-Oriented Programming, which Mae knows because we work together, which we haven't said yet on the show. But we're doing a book club. Your description of the matrix columns and what is relevant reminded me of the thesis of that book because it's like, there are tradeoffs. It's not that one tradeoff is necessarily more valuable than another tradeoff, it's just like what makes sense for this context that you're using and building it in, then you have to think about it in a nuanced way if you want to come up with a nuanced answer. MAE: I am so grateful to and inspired by Sandi Metz. Her ability to distill these concepts into common sense terms is so genius and moving, welcoming, accessible. So grateful, so really glad you brought that up, Jamey. One of the things that really stuck out from various talks of hers that I've been to is even if you aren't changing that code, that code does not need to change. That's bad code, but it works. That's great code, [chuckles] like working code, and splitting some of the bikeshedding that we do on code quality with business impact is a teeter-totter that I really appreciate. JAMEY: I like the way it puts value on everyone and what they're working on. Because my big takeaway from starting to read this book has been that I tend to write fairly simple code because that's what I find easy to do. [chuckles] I always felt well, other people write more complicated code than me because they know more about X, Y, and Z than me and I don't know enough about it to write something that elegant, or that complex, or et cetera, et cetera, et cetera. I had placed this value judgment on other people's code over mine and to read about code that's dissecting the value judgments we put on it and determining hey, just because maybe it's not always the best thing to overengineer something Maybe it doesn't have to be because you don't feel smart enough to overengineer it. Maybe it can just be because that's not the right choice. [chuckles] MAE: Cool. JAMEY: I thought that was really valuable to think about. MAE: Love that, Jamey. JAMEY: Boost people's confidence, I hope because I think a lot of people need their confidence boosted. [chuckles] MAE: Yo, I had no idea what I was getting into as far as the mental health challenge of being a programmer. To maintain one's self-respect, especially as an adult who was successful in her career prior to then be like, there is a whole thing about the adult learner. But to have your entire day be dealing with things that are either broken, or don't exist yet, that's your whole day. Nothing works ever basically and the moment it does, you move on to the things that aren't, or don't exist. So it's so critical to try to remember and/or learn how to celebrate those small wins that then somehow feel like insulting that you're celebrating this is just some simple things. [laughs] And then it's like, why are we making a big fanfare? But those microjoys—I've never heard that phrase as opposed to microaggression, or something. Microjoys, if we could give each other those, it could go a long because the validation is a very different experience than I have seen, or heard about, or experienced in any other industry. It's a real challenge. JAMEY: Not only is everything broken, or doesn't exist. But once it's working, you never hear about it again until it's broken again. [chuckles] MAE: Yeah. [laughs] CASEY: That's so true and it's such an anti-pattern. At USCIS, you would have every developer, who was interested, see an interview—we're working on an interview app—watch the user use the app every month at least, if not more and they loved those. They saw the context, they saw the thing they just built be used. That's positive feedback that everyone deserves, in my opinion and it's just a cultural idea that engineers don't get to see users, but they should. They do at some companies and yours can, too. MAE: Yes, Casey! We are working on that at True Link financial as well. Figuring out how to work that more in so that we all feel part of the same team more and we're not like the IT crowd and in the basement and all we have to say is, “Hello, have you tried turning it on and off again?” [laughs] JAMEY: Casey, I love that because even as you were telling that story, I was like, “Yeah, it's useful to see how people use it because that'll help you make better decisions,” and blah, blah, blah, which I feel strongly about. And then what you actually said at the end was, “and you get satisfaction out of being able to see people using your thing.” I hadn't even thought of that dynamic of it. CASEY: Yeah. It's both, happier and more effective. That's the thing I say a lot. These user interviews make you happier doing your job and make you more effective at doing them both. How can you not? MAE: Yeah. JAMEY: What's not to like? [laughter] It's true, though about knowing that people use your app. I started in consulting and a lot of the things I worked on felt a little soul crushing and not because I thought that they were bad, or unethical in any way, but just like, who is this for? Like, who cares about this? One of my most joyful experiences was one of the other products that wasn't quite like that, that I worked on when I was in consulting was an app called Scorebuilders and it was for physical therapy students have a specific standardized test they have to take and so, it's study prep for this specific test. There's like two, or three and we had different programs for them. And then I, a few years after that was, in physical therapy myself, because I have back problems and they have interns from college helping them in the physical therapy office that I went to and they were talking about studying for their test, or whatever. I was like, “Oh, that's funny. I haven't thought about that in a while. Do you use Scorebuilders to study in?” They were like, “Oh yeah. We all use it. That's what you use if you're in this program,” and I was like, “Oh, I built that,” and they were like, “What?!” They were calling all of the other people from the next room to be like, “Guess what?” and I'm like, “This is literally the best thing that's ever happened.” [laughs] MAE: Yay! CASEY: Yeah! That's such a good story in the end, but it's such a bad story. You never got to meet anyone like that earlier, really? JAMEY: Yeah. CASEY: That's common, that's everywhere, but that's a shame. You can change that. [overtalk] JAMEY: I just realized since it was consulting and not like, I didn't work for Scorebuilders. CASEY: Oh, I'm sure. It's even more hard. JAMEY: Yeah. CASEY: I'm so glad you got that. JAMEY: Thank you. It happened like 5 years ago and I still think about it all the time. [laughs] Well, we've been having a great discussion, but we've pretty much reached the point in the show where it's time to do reflections and that's when everyone will say something that really stood out to them about our conversation, maybe a call-to-action, something that they want to think more about. So, Casey, do you want to start? CASEY: Yeah. I said this earlier, but this is my big takeaway is the word mutual aid can be more approachable if you think about it like people helping people and not a formal organization. Especially since it is, by definition, grassroots-y. There is no formal stamp of approval on a mutual aid group that formalizes it. That's pretty powerful. I'll be thinking about what communities I'm part of that do that through that lens this week and I challenge listeners to help and be helped sometime this week, both. JAMEY: I think one thing that I'm going to really try and keep in mind is what we were talking about, valuing yourself and the way that that helps the community. I really liked Mae's story about including yourself after other people and using that way to frame it in your mind. Because I think that that will make it easier and thinking about like, this is something I struggle with all the time. I think a lot of us do. So I think that I really want to take that one into my life. Next time I realize I'm treating myself unfairly, I want to think, “Well, how is this affecting the other people around me who probably don't want to see me to do that?” [chuckles] MAE: Thanks, Jamey. Yeah. I have so many answers of reflections! The one I know I'm going to use immediately is this most recent one of engaging with users using the things you're building as a reward and a way to be able to get microjoy. I'm definitely going to use that word now more, microjoys, but I agree with both of what you said, too. JAMEY: Well, Mae thank you so much for coming on and chatting with us. This was really great and I think people will really appreciate it. MAE: Yay. I loved it! Thank you both so much. What a treat! CASEY: I feel like we could keep talking for hours. JAMEY: I know. [laughter] This is how I feel after a lot of my episodes. [laughter] Which is always good, I guess, but. Special Guest: Mae Beale.

On this week's episode, Steph and Chris respond to a listener question about how to know if we're improving as developers. They discuss the heuristics they think about when it comes to improving, how they've helped the teams they've worked with plan for and measure their growth, and some specific tips for improving. Rails Autoscale (https://railsautoscale.com/) Rubular regex playground (https://rubular.com/) The Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) Go Ahead, Make a Mess by Sandi Metz (https://www.youtube.com/watch?v=xi3DClfGuqQ) Confident Code - Avdi Grimm (https://www.youtube.com/watch?v=T8J0j2xJFgQ) Therapeutic Refactoring - Katrina Owen (https://www.youtube.com/watch?v=J4dlF0kcThQ) Refactoring, Good to Great - Ben Orenstein (https://www.youtube.com/watch?v=DC-pQPq0acs) Transcript CHRIS: There's something intriguing about the fact that we're having this conversation, but the thing that's recorded just starts at this arbitrary point in time, and it's usually us rambling about golden roads. But, I don't know; there's something existential about that. STEPH: It's usually when someone says something very funny or starts singing [laughs], and then that's when we immediately: record, record! CHRIS: I've never sung on the mic. That doesn't sound like a thing I would do. STEPH: [laughs] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So Steph, how's your week going? STEPH: Hey Chris, it's going really well. Normally I'm always like, wow, it's been such an exciting week, and it's been a pretty calm, chill week. It's been lovely. CHRIS: That sounds nice actually in contrast to the "Well, it's been a week," that sort of intro of "I don't know, it's been fine. It can be really nice." STEPH: By the time we get to this moment of the week, I either have stuff that I'm so excited to talk about and have a little bit of a therapy session with you or share something new that I've learned. I agree; it's nice to be like, yeah, it's been smooth sailing this whole week. In fact, it was smooth sailing enough that I decided to take on something that I've been meaning to tackle for a while but have just been avoiding it because I have strong feelings about this, which you know but we haven't talked about yet. But it comes down to managing emails and how many emails one should have that are either unread that are just existing. And I fall into the category of where I am less scrupulous about how many unread or managed emails that I have. But I decided that I'd had enough. So I used a really nice filter in Gmail where I said I want all emails that are before 2021 and also don't have a user label, so it's has:nouserlabels because then I know those are all the emails that I haven't labeled or assigned to a particular...I want to say folder, but they're not truly folders; they just look like folders. So they're essentially like untriaged or just emails that I've left hanging out in the ether. And then I just started deleting, and I got rid of all of those that hadn't been organized up until that point. And I was just like yep, you know if I haven't looked at it, it's that old, and I haven't given a label by this point, I'm just going to move on. If it's important, it will bubble back up. And I feel really good about it. CHRIS: Wow, that is -- I like how you backed me into a corner. Obviously, I'm on the other side where I'm fastidiously managing my email, which I am, but you backed me into that corner here. So, yeah, that's true. Although the approach that you're taking of just deleting all the old email that's a different one than I would have taken [chuckles] so, I like it. It's the nuclear option. STEPH: Okay, so now I need to qualify. When you delete an email, initially, I'm thinking it's going to trash, and so it's still technically there if I need to retrieve it and go back and find it. But you just said nuclear option, so maybe they're actually getting deleted. CHRIS: They're going into the trash for 30 days; I think is the timeline. But after that, they will actually delete them. The archive is supposed to be the place where you put stuff I don't want to see you anymore. But did you archive or delete? STEPH: Oh, I deleted. CHRIS: Oh, wow. Yeah. All right, you went for it. [laughter] STEPH: Yeah, and that's cool. And it's in trash. So I basically have a 30-day window where I'm like, oh, I made a mistake, and I need to search for something and find something and bring it back into my world; I can find it. If I haven't searched for it by then in 30 days, then I say, you know, thanks for the email, goodbye. [chuckles] And it'll come back if it needs to. CHRIS: I like the approach. It would not be my approach, but I like the commitment to the cause. Although you still have...how many emails are still in your inbox now? STEPH: Why do we have to play the numbers game? CHRIS: [laughs] STEPH: Can't we just talk about the progress that I have made? CHRIS: What wonderful progress you've made, Steph. [laughter] Like, it doesn't matter what I think. What do you think about this? Are you happy with this? Does this make you feel more joy when you look into your email in the Marie Kondo sense? STEPH: It does. I am excited that I went ahead and cleared all this because it just felt like craft. So I have taken what may be a very contentious approach to my email, where I treat it as this searchable space. So as things come in, I triage them, and I will label them, I will star them. I will either snooze them to make sure I don't miss the high actionable emails or something that's very important to me to act on quickly. But for the most part, then a lot of stuff will sit in that inbox area. So it becomes like this junk drawer. It's a very searchable junk drawer, thanks to Google. They've done a great job with that. And it feels nice to clear out that junk drawer. But I do have such an aversion to that very strong email inbox zero. I respect the heck out of it, but I have an aversion; I think from prior jobs where I was on a team, and we could easily get like 800 emails a day. My day all day was just triaging and responding to emails and writing emails. And so I think that just left a really bitter experience where now I just don't want to have to live that life where I'm constantly catering to what's in my inbox. CHRIS: That's so many emails. STEPH: It was so many emails. We were a team. It was a team inbox. So there were three of us managing this inbox. So if someone stepped away or if someone was away on vacation, we all had access to the same emails. But still, it was a lot of emails. CHRIS: Yeah, inbox zero in a shared inbox that is a level that I have not gotten to but getting to inbox zero and actually maintaining that is very much a labor of love and something that I've had to invest in. And it's probably not worth it for most people. You could convince me that it is not worth it for me, that the effort I'm putting in is too much effort for not enough reward. Well, it's one of those things where I find the framing that it puts on it, like, okay, I need to process my email and get it to zero at least once a day. Having that lens makes me think about email in a different way. I unsubscribe from absolutely everything. The only things that are allowed to come into my email are things that I will act on that actually deserve my attention, and so it forces that, which I really like. And then it forces me to think about things. I have a tendency to really hold off on decisions. So I'm like, ah, okay. I can go see friends on Saturday or I can do something else. Friends like actual humans, not the TV show, although for the past year, it's definitely more of the TV show than the real people. But let's say there's a potential thing that I could do on the weekend and I have to decide on that. I have a real tendency to drag my feet and to wait for some magical information from the universe to help this decision be obvious to me. But it's never going to be obvious, and at some point, I just need to pick. And so for inbox zero, one of the things that comes out of it for me is that pressure and just forcing me to be like, dude, there's no perfect answer here, just pick something. You got to just pick something and not wasting multiple cycles rethinking the same decision over and over because that's my natural tendency. So in a way, it's, I don't know, almost like a meditative practice sort of thing. There's utility there for me, but it is an effort, and it's, again, arguably not worth it. Still, I do it. I like it. I'm a fan. I think it's worth it. STEPH: I like how you argued both sides. I'm with you. I think it depends on the value that you get out of it. And then, as long as you are effective with whichever strategy you take, then that's really what matters. And I do appreciate the lens that it applies where if you are getting to inbox zero every day, then you are going to be very strict about who can send you emails about notifications that you're going to receive because you are trying to reduce the work that then you have to get to inbox zero. So I do very much admire that because there are probably -- I'm wasting a couple of minutes each day deleting notifications from chats or stuff that I know I'm not necessarily directly involved in and don't need action from me. And then I do get frustrated when I can't adjust those notification settings for that particular application, and I'm just subscribed to all of it. So some of it I feel like I can't change, and then some of it, I probably am wasting a few minutes. So I think there's totally value in both approaches. And I'm also saying that to try to justify my approach of my searchable inbox. [laughs] CHRIS: There are absolutely reasons to go either way. And also, to come back to what I was saying a minute ago, it may have sounded like I'm a person who's just on top of this. I may have given that impression briefly. I think the only time this has actually worked in my life is when Gmail introduced snooze both in the mobile app and on the desktop. So this is sometime after Google's inbox product came out, and that was eventually shut down. So it's relatively recent because, man, I just snooze everything. That is the actual secret to achieving inbox zero, just to reach the end of the day and be like, nah, and just send all the emails to future me. And then future me wakes up and is like, "You know, it's first thing in the morning. I got a nice cup of coffee, and this is what you're going to do to me, past me?" So there's a little bit of internal strife there within my one human. But yeah, the snoozing is actually incredibly useful and probably the only way that I actually get things done and the same within any task management system that I have; maybe future me will do this. STEPH: I think you and I both subscribed to the that's a future me problem. We just do it in very different ways. But switching gears a bit, how's your week been? CHRIS: It's been good, pretty normal, doing some coding, normal developer things. Actually, there's one tool that I was revisiting this week that I'm not sure that we've actually talked about on the show before, but it's Rails Autoscale. Have you used that before? STEPH: I don't think I have. It sounds very familiar, but I don't think I've used it. CHRIS: It's a very nice, straightforward Heroku add-on that does exactly what you want it to do. It monitors your web and worker dynos and will scale up. But it uses a different heuristic than -- So Heroku has built-in autoscaling, but theirs is based on response time, which is, I think, a little bit laggier of a metric. Like if your response time has gotten bad, then you're already in trouble, whereas Rails Autoscale uses queue time. So how long is a request waiting before? I think it's at the Heroku router; it goes onto the dyno that's actually going to process the request? So I think that's what they're monitoring. I may be wrong on that. But from the website, they're looking at that, and you can configure it. They actually have a really nice configuration dashboard for configure between this range, so one to five dynos at most, and scale in this way up and in this way down. So like, how long should it wait? What's the threshold of queue time? Those sorts of things. So they have a default like just do the smart thing for me, and then they give you more control if your app happens to have a different shape of data, which is all really nice. And then I've been using that for a while, but I recently this week actually just turned on the worker side. And so now the workers will autoscale up and down as the Sidekiq queue -- I think for the Sidekiq side, it's also the queue time, so how long a job sits in the queue before getting picked up. And there are some extra niceties. It can actually infer the different queue names that you have. So if you have a critical, and then a mailer, and then a general as the three queues that Sidekiq is managing, you really want critical to not back up. So you can tell it to watch that one but ignore the normal one and only use -- Like, when critical is actually getting backed up, and all the other stuff is taken over then -- Again, it's got nice knobs and things, but mostly you can just say, "Turn it on and do the normal thing," and it'll do a very smart thing." STEPH: That does sound really helpful. Just to revisit, so Heroku for autoscaling, when you turn that on, I think Heroku does it based on response times. So if you get into a specific percentile, then Heroku is going to scale up for you to then bring down that response time. But it sounds like with this tool, with Rails autoscaling, then you have additional knobs like the Sidekiq timing that you'd referenced. Are there some other knobs that you found really helpful? CHRIS: Basically, there are two different sides of it. So web and background jobs are going to be handled differently within this tool, and you can actually turn them on or off individually, and you can also, within them, the configurations are specific to that type of thing. So for the web side, you have different values that you can set as the thresholds than you do on the Sidekiq side. Overall, the queue name only makes sense on the Sidekiq side, whereas on the web side, it's just like the web requests all of them 'Please make sure they're not spending too much time waiting for a dyno to actually start processing them.' But yeah, again, it's just a very straightforward tool that does the thing that it says on the tin. I enjoy it. It's one of those simple additions where it's like, yeah, I think I'm happy to pay for this because you're just going to save me a bunch of money every month, in theory. And actually, that side of it is certainly interesting, but more of my app will be responsive if there is any spike in traffic. There's still plenty of other performance things under the hood that I need to make better, but it was nice to just turn those on and be like, yeah, okay. I think everything's going to run a little better now. That seems nice. But yeah, otherwise, for me, a very straightforward week. So I think actually shifting gears again, we have a listener question that we wanted to chat about. And this is one that both of us got very interested to chat about because there's a lot to this topic, but I'm happy to read it here. So the overall topic is improving as a developer, and the question goes, "How do you know you're improving as developers? Is your improvement consistent? Are there regressions? I find myself having very different views about code than I did even a year ago. In some cases, I write code now in a way that I would have criticized not too long ago. For example, I started writing a lot more comments. I used to think a well-named variable obviated the need for comments. While it feels like I'm improving, I have no way of measuring the improvement. It's only a gut feeling. Thanks. Love the show." And this comes from Tom. Thank you, Tom. Glad you enjoy the show. So, Steph, are you improving as a developer? STEPH: I love this question. Thanks, Tom, for sending it in because it is one that I think about but haven't really verbalized, and so I'm really excited to dive into this. So am I improving as a developer? It comes down to, I mean, we first have to talk through definitions. Like, what does it mean to become a better developer? And then, we can talk through metrics and understanding how we're getting there. I also love the other questions, which I know we'll get to. I'm just excited. But are there any regressions? And also, in my mind, they already answered their own question. But I'm getting ahead of myself. So let me actually back up. So how do you know you're improving as a developer? There are a couple of areas that come to mind. And for me, these are probably more in that space of they still have a little bit of a gut feeling to them, but I'm going to try hard to walk that back into a more measurable state. So one of them could be that you're becoming more comfortable with the work that you're doing, so if you are implementing a new email flow or running task on production or writing tests that become second nature, those types of activities are starting to feel more comfortable. To me, that is already a sign of progress, that you are getting more comfortable in that area. It could be that time estimates are becoming more accurate. So perhaps, in the beginning, they're incredibly -- like, you don't have any idea. But as you are gaining experience and you're improving as a developer, you can provide more accurate estimates. I also like to use the metric of how many people are coming to you for help, not necessarily in hard numbers, but I tend to notice when someone on a team is the person that everybody else goes to for help, maybe it's just on a specific topic, maybe it's for the application in general. But I take that as a sign that someone is becoming very knowledgeable in the area, and that way, they're showing that they're improving as a developer, and other people are noticing that and then going to them for help. Those are a couple of the ones that I have. I have some more, but I'd love to hear your thoughts. CHRIS: I think if nothing else, starting with how would we even measure this? Because I do agree it's going to be a bit loose. Unfortunately, I don't believe that there are metrics that we can use for this. So the idea of how many thousand lines of codes do you write a month? Like, that's certainly not the one I want to go with. Or, how many pull requests? Anything like that is going to get gamified too quickly. And so it's really hard to actually define truly quantifiable metrics. I have three in mind that scale the feedback loop length of time. So the first is just speed. Like, how quickly are you able to do the same tasks? So I need to build out a page in Rails. I need a route; I need a controller. I need a feature spec, those sort of things. Those tasks that come up over and over: are you getting faster with those? That's a way to measure. And there's an adage that I think comes from biking, professional cycling, that it never gets any easier; you just go faster. And so the idea is you're doing the same work over time, but you just get a little bit faster, and you're always trying that edge of your capabilities. And so that idea of it never gets any easier, but you are getting faster. I like that framing. We should be doing the same work. We should never get too good for building a crud app. That's my official stance on the matter; thank you very much. But yeah, so that's speed. I think that is a meaningful thing to keep an eye on and your ability to actually deliver features in a timely fashion. The next one would be how robust are the things that you're building? What's the bug count? How regularly do you have to revisit something that you've built to change it, to tweak it either because it doesn't exactly match the intent of the feature that you're developing or because there's an actual bug in it? It turns out this thing that we do is very hard. There are so many moving pieces and getting the design right and getting the functionality just right and handling user input, man, that's tricky. Users will just send anything. And so that core idea of robustness that's going to be more on a week scale sort of thing. So there's a little bit of latency in that measure, whereas speed that's a pretty direct measure. The third one is…I don't know how to frame this, but the idea of being able to revisit your code either yourself or someone else. So if you've written some code, you tried to solve a problem; you tried to encode whatever knowledge you had at the given time in the code. And then when you come back three months later, how easy is it to revisit that code, to change it, to extend it either for yourself (because at that point you've forgotten everything) or for someone else on the team? And so the more that you're writing code that is very easy to extend, that is very easy to revisit and reload that context into your head, how closely the code maps to the actual domain context I think that's a measure as well that I'm really interested in, but there's the most lag in that one. It's like, yeah, months later, did you do a good job? And so the more time you spend, the more you'll have a measure of that, but that's definitely the laggiest of the measures that I have in mind. STEPH: I love that adage that you shared that it never gets easier, but you get faster. That feels so relevant. I really like that. And then I hadn't considered the robustness. That's a really nice one, too, in terms of how often do you have to go back and revisit issues that you've added? CHRIS: You just write code without bugs; that's why you don't think about it. STEPH: [laughs] Oh, if only that were true. CHRIS: Yeah, if only that were true of any of us. STEPH: To keep adding to the list, there are a couple more that come to mind too. I'd mentioned the idea that certain tasks become easier. There's also the capability or the level of comfort in taking on that new, big, scary, unknown task. So there is something on the Teams' board where you're like, I have no idea how to do that, but I have confidence that I can figure it out. I think that is a really big sign that you are growing as a developer because you understand the tools that'll get you to that successful point. And maybe that means persuading someone else to help you; maybe it means looking elsewhere for resources. But you at least know how to get there, which then follows up on your ability to unblock yourself. So if you are in that state of I just don't know what to do next, maybe it's Googling, or maybe it is reaching out for help, but either way, you keep something moving forward instead of just letting it sit there. Another area that I've seen myself and other people grow as developers is our ability to reason about quality and speed. It's something that I feel you, and I talk about pretty often here on the show, but it comes down to our ability to not just write code but then to also make good decisions on behalf of the company that we are working for and the team that we're working with and understanding what matters in terms of what features really need to be part of this MVP? Where can we make compromises? And then figuring out where can we make compromises to get this out to market? But what's really important then for circling back to your idea of revisiting the code, we want code that we can still come back and trust and then easily maintain and make updates to. And then I feel like I'm rambling, but I have a couple more. Shall I keep going? CHRIS: Keep going. Those are great. STEPH: All right. So for the others, there's an increase in responsibilities that I notice. So, in addition to people coming to you more often for help, then it could be that you are receiving more responsibilities. Maybe you are taking on specific ownership of the codebase or a particular part of the team processes. Then that also shows that you are improving and that people would like you to take leadership or ownership of certain areas. And then this one, I am throwing it in here, but your ability to run a meeting. Because I think that's an important part of being a good developer is to also be able to run a meeting with your colleagues and for that to be a productive meeting. CHRIS: Cool. I like that one. I think I want to build on that because I think the core idea of being able to run a meeting well is communication. And I think there's one level of doing this job where it's just about doing the job. It's just about writing the code, maybe some amount of translating a specification or a ticket or whatever it is into the actual code that you need to write. But then how well can you communicate back out? How well when someone in project management says, "Hey, we want to build an aggregated search across the system that searches across our users, and our accounts, and our products, and our orders, and our everything." And you're like, "Okay. We can do that, but it will be hard. And let's talk about the trade-offs inherent in that and the different approaches and why we might pick one versus the other," being able to have that conversation requires a depth of knowledge in the technical but then also being able to understand the business needs and communicate across that boundary. And I think that's definitely an axis on which I enjoy pushing on as I'm continuing to work as a developer. STEPH: Yeah, I'm with you. And I think being a consultant and working at thoughtbot heavily influences my concept of improving as a developer because as developers, it's not just our job to write code but to also be able to communicate and help make good decisions for the team and then collaborate with everyone else in the company versus just implement certain features as they come down the pipeline. So communication is incredibly important. And so I love that that's one of the areas that you highlighted. CHRIS: Actually speaking of the communication thing, there's obviously the very human-centric part of that, but there's, I think, another facet of technical communication that is API design. When you're writing your code, what do you choose to expose and make accessible to collaborators? And I don't just mean API in the terms of a REST API that people are heading, but I mean a class that you have in your system. What are the private methods, and what are the public methods? And how do you think about the shape of it? What data do you expose? What do you not expose? And that can be really impactful because it allows how can you change things over time? The more that you hide, the more you can change. But then, if you don't allow your collaborators to access the bits that they need to be able to work with your system, that's an interesting one that comes to mind. It also aligns with, I don't think you were saying this exactly, but the idea of taking on more amorphous projects. So like, are you working within a system and adding a new feature, or are you designing a system? Are you architecting? The word architect that role can sometimes be complicated within organizations, but that idea of I'm starting fresh, and I'm building a system that others will then work within I think this idea of API design becomes really interesting in that context. What shape do you give to the system that we're working within, and what affordances? And all of that. And that's a very hard thing to get right. So it comes from experience of being like, I used some stuff in the past, and I hated it, so when I am the architect, I will build it better. And then you try, and you fail, and you're like, well, okay, but now I've learned. And then you try it, and then you fail for different reasons. But the seventh time you try, it may be just that time you get the public API just right on the first go. STEPH: Seven times's a charm. That's how that goes, right? CHRIS: That is my understanding, yes. STEPH: I think something that is related to the idea of are you working in a structured space versus working in a new space and then how you develop that API for other people to work with. And then how do you identify when to write a test and what to test? That's another area that you were just making me think of is that I can tell when someone has experience with testing because they know what to test and what feels important to test. And essentially, it comes down to can I deploy with confidence? But there are a lot of times, especially if you're new to testing, that you're going to test everything, and you're going to have a lot of probably useless slow tests. But over time, you will start to realize what's really important. And I think that's one of the areas where then it does start to get harder to measure yourself as a developer because all of our jobs are different, and we work with different tech stacks, and we all have our unique responsibilities and goals. So it may be hard to say specifically like, "Oh, you're really good at X, Y, and Z, and that's how you know that you're improving as a developer." But I have more thoughts on that, which we'll get to in a moment where Tom mentioned that they don't have a way of measuring improvement. Shall I go ahead and jump ahead to I have no way of measuring that improvement, or shall we talk about regressions next? CHRIS: I'm interested in your thoughts on the regressions question because it's not something that I've really thought about. But now that he's asked the question, I'm thinking about it. So yeah, what are your thoughts on that? STEPH: My very quick answer is yes, [laughs] that there are regressions mainly because I respect that our brain can only make so much knowledge readily available to us, and then everything else goes into long-term storage. We can access it at some point, but it takes additional time, or maybe it takes some practice to recall that skill. So I do think there are regressions, and I think that's totally fine that we should be focused on what is serving us most at the moment and be okay with letting go of some of those other skills until we need to refine them again. CHRIS: Yeah. I think there's definitely a truth to true knowledge and experience with, say, a framework or a language that can fade. So if I spend a lot of time away from JavaScript, and then I come back, I'm going to hit my head on a few low ceilings every once in a while for the first couple of days or weeks or whatever it is. It was interesting actually that Tom highlighted the idea of he used to not write comments, and now he writes more comments, and so that transition -- I think we've talked about comments enough so our general thinking on it. But I think it's totally reasonable for there to be a pendulum swing, and maybe there's a slight overcorrection. And you read some blog posts that tell you the truth of the world, and suddenly, absolutely no comments ever that's the rule. And then, later on, you're like, you know, I could really use a comment here. And so you go that way, and then you decide you know what? Comments are good, and you start writing a bunch of them. And so it's sort of weaving back and forth. Ideally, you're honing in on your own personal truth about comments. But that's just an interesting example to me because I certainly wouldn't consider that one a regression. But then there's the bigger story of like, how do we approach building software? Ideally, that's what this podcast does at its best. We're not really a podcast about Rails or JavaScript or whatever it is we're talking about that week, but we're talking about how to build software well. And I think those core ideas feel like they're more permanent for me, or I feel like I'm changing those less. If anything, I feel like I'm ratcheting in on what I believe about good software. And there are some core ideas that I'm just refining over time, not done by any means, but it's that I don't feel like I'm fundamentally reevaluating those core ideas. Whereas I am picking up a new language and approaching a new framework and taking a different approach to what tools I'm using, that sort of thing. STEPH: Yeah, I agree. The core concepts definitely feel more important and more applicable to all the future situations that we're going to be in. So those skills that may fall into the regression category feel appropriate because we are focused on the bigger picture versus how well do I remember this rejects library or something that won't serve us as well? So I agree. I am often focused more on how can I take this lesson and then apply it to other tech stacks or other teams and keep that with me? And I don't want that to regress. But it's okay if those other smaller, easily Google-able skills fall to the side. [laughs] CHRIS: Wait, are you implying that you can't write rejects just off the top of your head or what's…? STEPH: I don't think I could write any rejects off the top of my head. [laughter] CHRIS: Fair. All right. You just go to rubular.com, hit enter, and then we iterate. STEPH: Oh yeah. I don't want to use up valuable space for maintaining that sort of information. Rubular has it for me. I'm just going to go there. CHRIS: I mean, as long as you have the index of the places you go on the internet to find the truth, then you don't need to store that truth. STEPH: A moment ago, you mentioned where Tom highlights that they have different views about code that they wrote, even code that they wrote just like a year ago. And to me, that's a sign of growth in terms that you can look back on code that you have written and be like, well, maybe this would be different, or maybe this is still a good idea, but the fact that you are changing and then reevaluating, I think that is awesome because otherwise, if we aren't able to do that, then that is just a sign of being stagnant to me. We are sticking to the knowledge that we had a year ago, and we haven't grown since then versus that already shows that they have taken in new knowledge. So then that way, they can assess should I be adding comments? When should I add comments? Maybe I should swing away from that idea of this is a hard line of don't ever do this. I think I just have to mention it because there is one that I always feel so deeply about, DRY. DRY is the concept that gives me the most grief in terms that people just overuse it to the point that they do make code very hard to change. All right, that's my bit. I'll get off my pedestal. But DRY and comments are two things [chuckles] that both have their places. CHRIS: I don't know if your experience was similar, but around DRY, I definitely have had the pendulum swing of how I feel about it. And I think again, that honing in thing. But initially, I think I read The Pragmatic Programmers, and they told me that DRY is important. And then I was like, absolutely, there will be no duplication anywhere, and then I felt some pain from that. And I've been in other systems and experienced places where people did remove duplication. I was like, oh, maybe it would have been better, and so I slowly got out of that mindset. But now I'm just in the place of like, I don't know, copy and paste not now, there was a period where I was like, just copy and paste everything. And then I was like, all right, I think there's a subtle line. There's a perfect amount of duplication, and that's the goal is to figure out that just perfect level. But for me, it really has been that evolution, and I was on one side, and then I was on the other side, and then I'm honing back in. And now I have my personal truth about duplication. STEPH: Oh, me too. And I feel like I can be a little more negative about it because I was in the same spot. Because it's a rule, it's a rule that you can apply that when you are new to software development, there aren't that many rules that are so easy to apply to your codebase, but DRY is one of them. You can say, oh, that is duplication. I know exactly what that is, and I can extract it. And then it takes time for you to realize, okay, I can identify it, but just because it's there, it doesn't mean it's a bad thing. Perfect duplication, I like it. CHRIS: Coming back to the idea of when we look back on our code six months, a year later, something like that, I think I believe the statement that we should always look back on our code and be like, oh, what was I doing there? But I think that arc should change over time. So early on in my career, six months later, I look back at my code, and I'm like, oh, goodness, what was happening there? I was very much a self-taught or blog internet-taught programmer just working on my own. I had no one else to talk to. So the stuff that I wrote early on was not good is how I will describe it. And then I got better, and then I got better, and I hope that I'm still getting better. And it's something that probably draws me to software development is I feel like there's always room to get a little bit better. Again, even back to that adage of it doesn't get any easier; you just go faster. Like, that's a version of getting better in my mind. So I hope that I can continue to feel that improvement and that ratcheting up. But I also hope that that arc is leveling off. There is an asymptotic approach to "good software developer." People in the audience, you can't see my air quotes, but I made air quotes there around good software developer. But that idea of I shouldn't look back probably this far into my career and look back at code from three months ago and be like, that's awful. That dude should be fired. I hope I'm not there. And so if you're measuring over time, what does your three months ago look back feel like? Oh, I feel like it's a little better. Still, you should look back and be like, oh, I probably would do that a little bit different given what I know now, what I've learned, but less so, I think. I don't know, what do you think about that? STEPH: Yeah, that makes sense. And I'm also realizing I haven't looked back at my code that much since I am changing projects, and then I don't always have the opportunity to go back to that project and then revisit some of the code. But I do agree with the idea that if you're looking back at code that you've written a couple of months ago that you can see areas that you would improve, but I agree that you wouldn't want it to be something drastic. Like, you wouldn't want to see something that was more of an obvious security hole or performance issue. I think there are maybe certain metrics that I would use. I think they can still happen for sure because we're always learning, but there's also -- I may be taking this in a slightly different direction than you meant, but there's also a kindness filter that I also want us to apply to ourselves where if you're looking back three months ago to six years ago and you're like, oh, that's some rough code, Stephanie. But it's also like, yeah, but that code got me to where I am today, and I'm continuing to progress. So I appreciate who I was in the past, and I have continued to progress to who I am today and then who I will be. CHRIS: What a wonderfully positive lens to put on it. Actually, that makes me think of one of -- We may be getting into rant territory here, but we talk a lot about imposter syndrome in the software development world. And I think there's a lot of utility because this is something that almost everyone experiences. But I think there's a corollary to it that we should talk about, which is a lot of people are coming into this industry, and they're like one year in, and the expectation that one year into a career that -- The thing that we do is not easy as far as I can tell. I haven't figured out how to make it easy. And the expectation that someone's going to be an expert that early on is just completely unreasonable in my mind. In my previous career, I was a mechanical engineer, and I went to school for four years. I actually went to school for five years, not because I was bad at school, but because I went to a place that had a co-op. And so I had both three different six months experiences working and four years of classroom education before I even got any job. And then I started doing things, and that's normal in that world. Whereas in the development world, it is so accessible, and I really feel like that's an absolutely wonderful thing. But the counterpoint of that is folks can jump into this career path very early on in their learning, and the expectation that they can immediately become experts or even in the short order I don't think is realistic. I think sometimes, when we talk about imposter syndrome, we may do a disservice. Like, it's not imposter syndrome. You're just new, and that's totally fine. And I hope you're working in an organization that is supportive of that and that has space for that and can help you grow in a purposeful way. In my mind, it's not realistic to expect everyone to be an expert a year in—end rant. STEPH: Well, I would love to plus-one your rant and add to it a little bit because I completely agree. I also love the phrasing that you just said where it's not that you have imposter syndrome; it's just that you are new and that team should be supportive of people that are new and helping them grow and level up. I also think that's true for senior developers in terms that you are very good at certain skills, but there's always going to be some area of the web or some area of software development that you are new to, and that is also not imposter syndrome. But it's fine to assess your own skills and say, "That's something that I don't know how to do." And sometimes, I think that gets labeled as imposter syndrome, but it's not. It's someone just being genuine and reflecting on their current skills and saying, "I am good at a lot of stuff, but I don't know this one, and I am new to this area." And I think that's an important distinction to make because I still want -- even if you are not new in the sense that you are new to being a software engineer, but you still have that space to be new to something. CHRIS: Yeah, it's an interesting, constantly evolving space. And so giving ourselves a little bit of permission to be beginners on various topics and for me, that's been an experience that's been continual. I think being a consultant, being a freelancer that impacts it a little bit. But nonetheless, even when I go into organizations, I'm like, oh, years in technology that only came out two years ago. That's pretty fresh. And so it's really hard to be an expert on something that's that new. STEPH: Yeah. I think being new to a team has its own superpower. I don't know if we've talked about that before; if we haven't, we should talk about, it but I won't do that now. But being new is its own superpower. But I do want to pivot back to where Tom mentioned that I have no way of measuring that improvement. And I think that's a really great thing to recognize that you're not sure how to measure something. And my very first honest suggestion if you are feeling that way is to go ask your manager and ask them how they are measuring your improvement because that is their job is to understand where you're at and to understand your path as a developer on the team and then helping you set goals. So since I'm a manager at thoughtbot, I'll go first, and I can share some ways that I help my team measure their own improvement. So one of the ways is that each time that we meet to discuss work, I listen to their challenges, and I take notes; I'm a heavy note-taker. And so once I have all those notes, then I can see are there any particular challenges that resurface? Are there any patterns, any areas where they continuously get stuck on? Or are they actually gaining confidence, and maybe something that would have given them trouble a couple of weeks ago is suddenly no big deal? And then I also see if they're able to unblock themselves. So a lot of what I do is far more listening, and I'm happy to then provide suggestions. But I am often just a space for someone to share what they are thinking, what they're going through, and then to walk through ideas and then provide suggestions if they would like some, and then they choose a suggestion that works best for them. And then we can revisit how did it go? So their ability to unblock themselves is also something that I'm looking for in terms of growth. And then together, we also set goals together, and then we measure that progress together. So it's all very transparent. And what areas would you like to improve, and then what areas would it be helpful for thoughtbot or as a consultant for you to improve? And then if I am fortunate enough to be on a project with them and see how they reason about quality and speed, how they communicate the type of features they're most comfortable to work on, and which tasks are more challenging for them, I also look to see do people enjoy working with them? That's a big area of growth and reflects communication, and reliability, and trust. And those are important areas for us to grow as developers. So those are some of the areas that I look to when I'm helping someone else measure their own improvement. CHRIS: I really like that, the structured framing of it, and the way that you're able to give feedback and have that as a constant, continuous way to evaluate, define, measure, and then try and drive towards it. Flipping things around, I want to offer a slightly different thing, which isn't necessarily specifically in the question, but I think it's very close to the question of how do we actually improve as developers? What are the specific things that we can try and do? I'm going to offer a handful of ideas. I'd be super interested to hear what your ideas are. But one of the things that has been really valuable for me is exploring different languages and frameworks. I, without fail, find something in every new language or framework that I then bring back to the core things that I'm working with. And I've continued to work with Rails basically throughout my career, but everything else that I'm doing has informed the way that I work with Rails and the way that I think about building code. As specific examples, functional programming is a really interesting frame of mind, and Elm as a language is such a wonderful, gentle, friendly, fun introduction to functional programming because functional programming can get very abstract very easily. I've also worked with Haskell and Scala and other languages like that, and I find them much more difficult to work with. But Elm has a set of constraints and a user-centric approach that is just absolutely wonderful. So even if you never plan to build a production Elm application, I recommend Elm to absolutely everyone. In terms of frameworks, depending on what you're using, maybe try and find the thing that's the exact opposite. If you're in the JavaScript space, I highly recommend Svelte. I think it's been very informative to me and altered a number of my opinions. A lot of those opinions were formed by React. And it's been interesting to observe my own thinking evolve in that space. But yeah, I think exploring, trying out, -- Have you ever used Lisp? Personally, I haven't, but that's one of the things that's on my list of that seems like it's got some different ideas in it. I wonder what I would learn from that. And so continually pushing on those edges and then bringing that back to the core work you're doing that's one of my favorite things. Another is… It's actually two-fold here. Teaching is one, and I don't mean that in the grand sense; you don't have to be an instructor at a bootcamp or anything like that but even just within your organization trying to host a lunch and learn and teach a concept. Without fail, you have to understand something all the better to be able to teach it. Or as you try and teach something, someone may ask you a question that just shakes the foundation of what you know, and you're like, wow, I hadn't thought about it that way. And so teaching for me has just been this absolutely incredible forcing function for understanding something and being able to communicate about it again, that being one of the core things that I'm thinking about. And then the other facet sort of a related idea is pairing, pair with another developer, pair with a developer who is more senior than you on the team, pair with someone who is more junior than you, pair with someone who's at the same level, pair with the designer, pair with the developer, pair with a product manager, pair with everyone. I cannot get enough pairing. Well, I can, actually. I read a blog post recently about 100% pairing, and I've never gotten anywhere close to that number. But I think a better way to put it is I think pairing applies in so many more contexts than people may traditionally think of it. People sometimes like to compartmentalize and like, pairing is great for big architecture design, but that's about it. And my stance would be pairing is actually great at everything. It is very high bandwidth. It is exhausting, but I have found immense value in every pairing session I've ever had. So, yeah, those are some loose thoughts off the top of my head. Do you have any how to get better protips? STEPH: Yeah, that's a wonderful list. And I'm not sure if this exactly applies because it's been a while since I have seen this talk, but there is a wonderful talk by Sandi Metz. I mean, all of her talks are wonderful, but this one is Go Ahead, Make a Mess. And I believe that Sandi refers to or highlights the idea of trying something new and then reflecting on how did it go? And that was one of the areas that I learned early on, one of the ways to help me progress quickly as a developer. Outside of the suggestions that you've already shared around lots of pairing that was one of the ways that I leveled up quickly is to iterate quickly. So I used to really focus on the code that I was writing, and I thought it needed to be perfect before my colleagues could review it. But then I realized that the sooner that I would push something out for feedback, then the faster I would get other more experienced developers' input, and then that helped me learn at an accelerated rate and then also ship more frequently. So I'd also encourage you to just go ahead and iterate quickly. We talk about with software in general, we want to iterate on the code that we are pushing up for other people to look at and then give us feedback on and then reflect on how did it go? What did we learn? What are some areas that we can improve? I feel like that self-evaluation is huge, and it's something that I know that I frankly don't do enough because one, it also prompts us to appreciate the progress that we have made but then also highlights areas where I feel strong in this area, but these are other areas that I want to work on. CHRIS: While we're on the topic of talks that have been impactful in our journeys of leveling up as developers, I want to quickly list three that just always come to mind for me: Avdi Grimm's Confident Code, Katrina Owen's Therapeutic Refactoring, and Ben Orenstein's Refactoring from Good to Great. There's a theme if you look across those three talks. They're all about refactoring, which is interesting. That tells you some stories about what I believe about how good software is made. It's not made; it's refactored. That's my official belief, but yeah. STEPH: Love it. That's also another great list. [laughs] For additional ways to level up, there are some very specific areas where it could be maybe do code katas or code exercises, or maybe you subscribe to certain newsletters, stay up to date with a language, new features that are being released. But outside of those very specific things, and if folks find this helpful, then maybe you and I can make a fun list, and then we could share that on Twitter as well. But I always go back to the idea of regardless of what level you're at in your career is to think about your specific goals, maybe if you are new to a team and you're new to software development, then maybe you just have very incremental goals of like, I want to learn how to write a test, or I want to learn how to get better at PR review or something very specific. But to have real growth, I think you have to first consider where it is that you want to go and then figure out a way to measure to get there. Circling back to some of the ways that I help my teammates measure that growth, that's one of the things that we talk about. If someone says, "Well, I want to get better at PR review," I'm like, "Great. What does that mean to you? Like, how do you get better at PR review? How can we actually measure this and make it something actionable versus just having this vague feeling of am I better?" I think I've ended up taking this a bit more broad as you were providing more specific examples on how to level up. But I like the examples that you've already provided around education and then trying something outside of your comfort zone. So what's coming to mind are more of those broad strategies of goal setting. CHRIS: I think generally, you need that combination. You need how do I set the measure? How do I think about improvement? And then also ideally a handful of tactics that you can try out. So hopefully, we provided a nice balanced summary here in this episode. And hopefully, Tom, if you're listening, you have gotten some useful things out of this conversation. STEPH: Yeah, this was fun. We managed to take this topic and make a whole episode out of this. So thanks, Tom, for sending in such a great topic. CHRIS: Frankly, when I saw the topic, I was certain this was going to happen. [chuckles] This was an obvious one that was going to fill up the time for us. But yeah, with that, I think we've probably covered plenty here. Should we wrap up? STEPH: I'm sure there's more, but sure, let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review 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 @_bikeshed or reach me @SViccari on Twitter. CHRIS: And I'm @christoomey. STEPH: Or hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. Both: Byeeeeeee. Announcer: This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Welcome back to the Klaviyo Data Science podcast! This episode, we dive into… Required reading for data science A question we frequently get asked is: what books should I read to be a better data scientist/machine learning engineer? This may not surprise you, but there isn't just one answer — depending on the skills you have, your knowledge base, the point of your career that you're in, and many other factors, there are many books you could read that will help you learn more. This month, we cover several ways to improve the skills you need to contribute to a data science team. You'll hear about all that and more, including: Object-oriented programming, how to think about it practically, and how it can help anyone on a data science team The ethics of machine learning and AI, and why understanding AI ethics is one of your most powerful tools How Pac-Man delivers some of the most powerful data science insights of our time Mentioned this episode Some more reading or viewing that we mention in this episode: Practical Object-Oriented Design in Ruby by Sandi Metz: https://www.poodr.com/ Sandi Metz's keynote: https://www.youtube.com/watch?v=8bZh5LMaSmE Weapons of Math Destruction by Cathy O'Neil: https://weaponsofmathdestructionbook.com/ Northeastern CS 4100: https://www.ccs.neu.edu/home/jwvdm/teaching/cs4100/fall2019/ UC Berkeley CS 188: https://inst.eecs.berkeley.edu/~cs188/pacman/home.html Contact us The best place to reach the podcast is by messaging me on Twitter: https://twitter.com/lawson_m_t.

This week's discussion was inspired by an article from Sandi Metz, which you can find here. It begins with a terrific line, defining the half-life of software as, "the amount of time required for half of an application's code to change so much that it becomes unrecognizable."This topic also connected to a post we ran on the Stack Overflow blog this week,  Sacrificial Architecture: learning from abandoned systems. The author, Mohamad Aladdin, suggest that one should "think of your code quality as if it will run forever, but adapt to change as if your code will be obsolete tomorrow."Our lifeboat badge winner for this episode is Ishmael, who explained why JSON dumps your formatting and how to fix it.

This week's discussion was inspired by an article from Sandi Metz, which you can find here. It begins with a terrific line, defining the half-life of software as, "the amount of time required for half of an application's code to change so much that it becomes unrecognizable."This topic also connected to a post we ran on the Stack Overflow blog this week,  Sacrificial Architecture: learning from abandoned systems. The author, Mohamad Aladdin, suggest that one should "think of your code quality as if it will run forever, but adapt to change as if your code will be obsolete tomorrow."Our lifeboat badge winner for this episode is Ishmael, who explained why JSON dumps your formatting and how to fix it.

In this episode I talk with Tyler Williams, Software Engineer at Home Game Poker, about the contents of a blog post he recently wrote entitled Heuristics for Object-Oriented Design in Ruby. Tyler and I discuss some of the ideas in his blog post, most of which came from Sandi Metz's book Practical Object-Oriented Design in Ruby (POODR).

Jesse Spevack tells us about a conference topic he gave where big mistakes were made at his company. Having lived through the choices that they made, we chat about the lessons learned. Links https://railsconf.com/2020/video/jesse-spevack-mistakes-were-made https://akka.io/ https://love.devchat.tv/you-dont-know-js-yet-challenge40653095 https://www.driftingruby.com/learning_paths/stimulus-js https://rails-hosting.com/2020/#javascript-rails https://www.youtube.com/watch?v=UrqIgMxLKkw Picks Luke Amerliorated Windows 10 John - Among Us Dave - Bamboo Flooring Elgato Key Light Jesse - RubyConf 2019 - Keynote: Lucky You by Sandi Metz ErgoDox Moonlander The Trouble with Peace (The Age of Madness Book 2)  

Jesse Spevack tells us about a conference topic he gave where big mistakes were made at his company. Having lived through the choices that they made, we chat about the lessons learned. Links https://railsconf.com/2020/video/jesse-spevack-mistakes-were-made https://akka.io/ https://love.devchat.tv/you-dont-know-js-yet-challenge40653095 https://www.driftingruby.com/learning_paths/stimulus-js https://rails-hosting.com/2020/#javascript-rails https://www.youtube.com/watch?v=UrqIgMxLKkw Picks Luke Amerliorated Windows 10 John - Among Us Dave - Bamboo Flooring Elgato Key Light Jesse - RubyConf 2019 - Keynote: Lucky You by Sandi Metz ErgoDox Moonlander The Trouble with Peace (The Age of Madness Book 2)  

Jesse Spevack tells us about a conference topic he gave where big mistakes were made at his company. Having lived through the choices that they made, we chat about the lessons learned. Links https://railsconf.com/2020/video/jesse-spevack-mistakes-were-made https://akka.io/ https://love.devchat.tv/you-dont-know-js-yet-challenge40653095 https://www.driftingruby.com/learning_paths/stimulus-js https://rails-hosting.com/2020/#javascript-rails https://www.youtube.com/watch?v=UrqIgMxLKkw Picks Luke Amerliorated Windows 10 John - Among Us Dave - Bamboo Flooring Elgato Key Light Jesse - RubyConf 2019 - Keynote: Lucky You by Sandi Metz ErgoDox Moonlander The Trouble with Peace (The Age of Madness Book 2)  

On this week's episode, Steph describes her unique new project where they're building and presenting a training course around RSpec, testing, and TDD specific to an organization's codebase. Chris then runs some architecture choices by Steph to discuss a collection of new technologies he's considering, and more generally how we think about our experimentation budget. This episode is brought to you by: ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post The Witches (https://www.imdb.com/title/tt0100944/) The Witches (2020) (https://www.imdb.com/title/tt0805647/) Addams Family (https://www.imdb.com/title/tt0101272/) Addams Family Values (https://www.imdb.com/title/tt0106220/) Practical Magic (https://www.imdb.com/title/tt0120791/) Oculus Quest 2 (https://www.oculus.com/quest-2) SuperHot (https://superhotgame.com/) Beat Saber (https://beatsaber.com/) Rocket League (https://www.rocketleague.com/) Sandi Metz (https://sandimetz.com/) Inertia.js (https://inertiajs.com/) Svelte (https://svelte.dev/) Rich Harris (Svelte creator): Futuristic Web Development (https://www.youtube.com/watch?v=qSfdtmcZ4d0) Bike Shed episode talking about Inertia.js (https://www.bikeshed.fm/237) Another Bike Shed episode talking about Inertia.js (https://www.bikeshed.fm/240) Write Less, Do More (https://www.youtube.com/watch?v=BzX4aTRPzno) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

Happy Juneteenth! Sorry it took us so long to learn about it. Hannah invented a new phrase; it feels good. We got emails! Watch "Lucky You", the Sandi Metz talk about "luck" vs generational privilege. It's truly revelatory. Ben has been moving but also learning about the Ebonics controversy from YWA! Hannah's been reading a book that has been making her really mad but also way more educated about the history of her own country. Erin has been providing her IG followers with the most wholesome content on the internet.  HOMEWORK: - Listen to You're Wrong About (all) and The "Ebonics" Controversy episode specifically - Read Lies My Teacher Told Me by James W. Loewen (don't get it from Amazon!) - Follow @ErnBrnMerGherd on IG and look at her Fat Cats highlight - CALL US AND TELL US YOUR OBSESSION! 774-326-0420 - Follow @Nicelyprovedben, @Hanthropology, and @TooBroadPod on Twitter - Watch Ben on twitch.tv/discogreg  - Watch Erin on twitch.tv/ernbrn_og  - Watch Hannah on twitch.tv/hanthropology - Follow WayTooBroad on IG - Email us at waytoobroad@gmail.com - Listen to So Dreamy - Visit ernbrn.com - www.waytoobroad.com for anything you want - www.ernben.com for anything you need - queerworksmap.com - Please leave us a rating/review on Apple Podcasts or wherever you're listening!

We are very excited to welcome the amazing and wonderful Sandi Metz as our guest on this episode of The Rabbit Hole! We are going to be talking to Sandi about her book 99 Bottles of OOP and the new edition that is currently in the works. This new edition will take the ideas that Sandi had written about for Ruby and expand them to other programming languages. Thus our conversation takes the form of comparing the differences, strengths and weaknesses of the languages in question.

Robby speaks with author, speaker, and 40-year programming veteran Sandi Metz. They discuss why it's hard to teach maintenance skills, how humans tend to get themselves into messy situations, Sandi's "Rules for Developers", and more. You'll also hear You'll also hear some thoughts on Ruby and Rails, and how Sandi uses the phrase, "Lambs to the Slaughter".Helpful LinksFollow Sandi on TwitterWorking Effectively with Legacy Code by Michael FeathersRefactoring by Martin FowlerCodeDevotional projectPractical Object-Oriented Design99 Bottlessandimetz.com[Book] Elements of Style by William Strunk Jr.Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

Sandi, TJ and I talk about OOP in Rails; Java and COBOL; service objects and Interactors; getting bitten by snapping turtles; and Sandi's 11 bicycles.

In this episode of the DevEd podcast, the panel discusses Testing and Test Driven Development. They start the conversation by talking about automated testing with the help of unit tests using various tools available. Luis explains the terms regression testing, refactoring, mocking, continuous integration and continuous delivery (CI/CD). Everyone shares their experience with testing, mainly how and when they started learning automated testing and their journey with it so far. They then dive into the learning aspect of testing including some of the best ways to learn unit testing and give great tips and tools along the way. The next topic discussed is Test Driven Development - the definition, division of the development community into those support the methodology and those who do not, and more importantly, how effective it can be, it's benefits and drawbacks and the comparison between TDD and BDD (Behaviour Driven Development). They also talk about mocking, how testing can improve the quality of applications, and visual testing. In the end, they each mention their most favourite and least favorite testing tools. Panel Joe Eames Luis Hernandez Jesse Sanders Mike Dane Sam Julien Sponsors Thinkster.io Adventures in Angular ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Uncle Bob - TDD The Magic Tricks of Testing by Sandi Metz Code Kata TDD Kata 1 - Roy Osherove cypress Jest SuperTest Testable Picks Mike Dane: YouTube Music Luis Hernandez: Microsoft Whiteboard Jesse Sanders: Tile for Keys Star Wars: The Rise of Skywalker - Final Trailer Easter Eggs Sam Julien: Strange Planet - Nathan W. Pyle Joe Eames: Stackbit The DevEd podcast is produced by Thinkster.io and published by DevChat.TV. Question #1: What is regression and refactoring? Regression is handling new changes that affect or break legacy code, refactoring is changing the way code is written without changing the functionality. Question #2: What are ways to learn unit-testing? Learning by example, practicing using open source codes, studying existing tests from a large codebase, trying to increase code-coverage, writing simple math based tests and Code Katas. Question #3: What is TDD? Writing tests before designing the implementation code, red-green-refactor approach - write a test and make it fail (red), write code to make it pass (green) and eventually refactor the code. Question #4: What is a mock? Artificially created responses that can be used and controlled by tests.

In this episode of the DevEd podcast, the panel discusses Testing and Test Driven Development. They start the conversation by talking about automated testing with the help of unit tests using various tools available. Luis explains the terms regression testing, refactoring, mocking, continuous integration and continuous delivery (CI/CD). Everyone shares their experience with testing, mainly how and when they started learning automated testing and their journey with it so far. They then dive into the learning aspect of testing including some of the best ways to learn unit testing and give great tips and tools along the way. The next topic discussed is Test Driven Development - the definition, division of the development community into those support the methodology and those who do not, and more importantly, how effective it can be, it's benefits and drawbacks and the comparison between TDD and BDD (Behaviour Driven Development). They also talk about mocking, how testing can improve the quality of applications, and visual testing. In the end, they each mention their most favourite and least favorite testing tools. Panel Joe Eames Luis Hernandez Jesse Sanders Mike Dane Sam Julien Sponsors Thinkster.io Adventures in Angular ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Uncle Bob - TDD The Magic Tricks of Testing by Sandi Metz Code Kata TDD Kata 1 - Roy Osherove cypress Jest SuperTest Testable Picks Mike Dane: YouTube Music Luis Hernandez: Microsoft Whiteboard Jesse Sanders: Tile for Keys Star Wars: The Rise of Skywalker - Final Trailer Easter Eggs Sam Julien: Strange Planet - Nathan W. Pyle Joe Eames: Stackbit The DevEd podcast is produced by Thinkster.io and published by DevChat.TV. Question #1: What is regression and refactoring? Regression is handling new changes that affect or break legacy code, refactoring is changing the way code is written without changing the functionality. Question #2: What are ways to learn unit-testing? Learning by example, practicing using open source codes, studying existing tests from a large codebase, trying to increase code-coverage, writing simple math based tests and Code Katas. Question #3: What is TDD? Writing tests before designing the implementation code, red-green-refactor approach - write a test and make it fail (red), write code to make it pass (green) and eventually refactor the code. Question #4: What is a mock? Artificially created responses that can be used and controlled by tests.

Welcome to Elixir Wizards, today we are joined by Dr. Jim Freeze to talk about his passion for and history in Elixir and functional programming. Dr. Freeze is one of the organizers of one of our favorite things in the world, Elixir Conf! He shares his story of coming to functional programming and his early days with Elixir, what he sees as the most important aspects of the conference before diving into what is on offer for those that attend. We talk about how employers can get Elixir newcomers up to speed on the language and the most effective ways Dr. Freeze stays abreast of developments in the field. Our guest also recommends a few resources for those wanting an introduction to Elixir and makes a great argument for the usefulness of a functional approach to programming. For all this and a whole bunch more, join us today! Key Points From This Episode: How Dr. Freeze got started with Elixir and his programming background. A little bit about the early days of Elixir Conf and what the first events were like. The particulars of Dr. Freeze's doctorate and his title. Education, networking and how Elixir Conf fits into the developer hiring game. The training that is offered at the conference and the philosophy to serving attendees. Dr. Freeze's recommendations for employers bringing newbies up to speed with Elixir. How our guest continues his learning and stays focused on what is necessary. Useful resources and materials for Elixir, according to Dr. Freeze. Contemplating functional programming and its key components. Why to consider functional programming coming from an object-based background. The biggest hurdles in moving over to functional programming and Elixir. Following the data and how much the simplicity of this directive can help. Dr. Freeze's favorite thing in the functional world! Links Mentioned in Today’s Episode: SmartLogic (https://www.smartlogic.com)  Dr. Jim Freeze on Twitter (https://twitter.com/jimfreeze) ElixirConf (https://elixirconf.com/events)  Sophie DeBenedetto (http://sophiedebenedetto.nyc/) Elixir Radar (https://elixirnation.io/references/elixir-radar-weekly-newsletter-on-elixir) Phoenix In Action (https://www.amazon.com/Phoenix-Action-Geoffrey-Lessel/dp/1617295043) Geoffrey Lessel (http://www.apple.com) Saša Jurić (https://codesync.global/speaker/sasa-juric/) Sandi Metz (https://www.sandimetz.com) Special Guest: Dr. Jim Freeze.

Katrina first told us about her rocky start that had nothing to do with science or programming. She described the detours she took and how she finally woke up earning a living as a programmer some day. She explained how her first job in a fashion startup was a forming experience and how she picked her next job afterwards. We touched on her debut in public speaking and how it started an avalanche that led her -through hard work- to working for Github nowadays.Katrina is an ecosystem engineer at GitHub. She accidentally became a developer while pursuing a degree in molecular biology. When programming, her focus is on automation, workflow optimization, and refactoring. She works primarily in Go and Ruby, contributes to several open source projects, and is the creator of exercism.io, a platform for code practice and programming mentorship.Here are the links of the show:https://www.twitter.com/kytrinyxhttp://exercism.iohttps://exercism.io/bloghttps://events.codemotion.com/conferences/berlin/2019/Book: "99 Bottles of OOP", book that Katrina co-authored with Sandi Metz https://www.sandimetz.com/99bottlesBook: "Good Strategy / Bad Strategy: The difference and why it matters" by Richard Rumelt: https://amzn.to/2NoqY5oCreditsMusic Aye by Yung Kartz is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Want to be next?Do you know anyone who should be on the podcast? Do you want to be next? Drop me a line: info@devjourney.info or via Twitter @timothep.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the good word about this podcast. And please leave a rating (excellent of course) on the major podcasting platforms, this is the best way to increase the visibility of the podcast:Apple PodcastsStitcherGoogle PlayPatreonFinally, if you want to help produce the podcast, support me on Patreon. Every cent you pledge will help pay the hosting bills!Thanks!Support the show (http://bit.ly/2yBfySB)

Teaching Testing and Design Guests Betsy Haibel (https://twitter.com/betsythemuffin): CTO at Cohere (https://twitter.com/wecohere). Blogs at betsyhaibel.com (https://betsyhaibel.com/). Avdi Grimm (https://twitter.com/avdi): Head Chef at RubyTapas (https://www.rubytapas.com/). Blogs at avdi.codes (https://avdi.codes/). Penelope Phippen (https://twitter.com/penelope_zone): Works at Google, makes Rubyfmt (https://github.com/samphippen/rubyfmt), helps make RSpec (https://rspec.info/), and is on the board of Ruby Central (https://www.rubycentral.org/). Blog (https://penelope.zone). Summary After the discussions on testing and design in episodes 68 and 69, I had so much I still wanted to talk about in testing, design, and teaching testing and design. So I convened a panel with previous Tech Done Right Guests Avdi Grimm, Betsy Haibel, and Penelope Phippen to help me think through all these topics. I was very happy to have all of them on the show, and I think it's a great conversation. Stay tuned until the very end for an update about the show. Related Episodes with These Guests Avdi: 20 Years of Web Development (https://www.techdoneright.io/46), Ruby Tapas and Avoiding Code (https://www.techdoneright.io/24) Betsy: Diverse Agile Teams (https://www.techdoneright.io/38), How Set Design Can Inform Software Architecture (https://www.techdoneright.io/21) Penelope: Code Style and Community (https://www.techdoneright.io/54), Back in the Testing Weeds (https://www.techdoneright.io/33), In The Testing Weeds (https://www.techdoneright.io/004-testing-with-sam-and-justin) Notes 00:50 - Previously On: Re: Testing * Pragmatic Programmer at 20 with Dave Thomas and Andy Hunt (https://www.techdoneright.io/68) * Teaching and Learning with Sandi Metz (https://www.techdoneright.io/69) 02:53 - Testing and Design * 99 Bottles of OOP (https://www.sandimetz.com/99bottles) 05:43 - TDD Test Driven Development (https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/) Do We Need Constants (http://www.virtuouscode.com/2011/08/18/do-we-need-constants/) 09:36 - Testing, But Not Developer Testing + Sliming The Test * WikiWikiWeb (http://wiki.c2.com) 13:41 - Why + How Did You Learn TDD? 20:24 - TDD: Not a Robust Process 24:19 - Rails + Unit Testing 27:41 - Is TDD really dead? 35:06 - Keeping Code In Your Head 37:32 - Approaching the Testing and Design of Code 38:59 - What would convince you to stop doing TDD? Special Guests: Avdi Grimm, Betsy Haibel, and Penelope Phippen.

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter. Pivot a bit: Less agnostic, more useful to just lean into the technologies we use every day for a while. We'll do our best to keep the information generally useful to all software developers. Moving forward this is a Web Development Podcast covering Ruby on Rails, Javascript and React. New book: Practical Object-Oriented Design in Ruby by Sandi Metz Also known as POODR About the Author: Sandi Metz: She is one of the foremost thought leaders in clean code. If you want some amazing programming talks just look up Sandi Metz on YouTube. About the book: “The Complete Guide to Writing Maintainable, Manageable, Pleasing, and Powerful Object-Oriented Applications” About Object-Oriented Design: Object-oriented applications are made up of objects and the messages that pass between them. Messages will turn out to be the more important of the two, but in this brief introduction (and in the first few chapters of the book) the concepts will get equal weight. “In a world of objects, new arrangements of behavior emerge naturally. You don't have to explicitly write code for the spouse_steps_on_cat procedure, all you need is a spouse object that takes steps and a cat object that does not like being stepped on. Put these two objects into a room together and unanticipated combinations of behavior will appear.” “Unfortunately, something will change. It always does. The customers didn't know what they wanted, they didn't say what they meant…. Even applications that are perfect in every way… change is ubiquitous and omnipresent” WHY IS CHANGE SO HARD!? Dependencies stand in the way of change Object Oriented Design is about Managing Dependencies “In the absence of design, unmanaged dependencies wreak havoc because objects know too much about one another.” “Part of the difficulty of design is that every problem has two components. You must not only write code for the feature you plan to deliver today, you must also create code that is amenable to being changed later.” Design Principles SOLID - design: Single Responsibility - Do one thing well. Open-Closed - You should be able to extend without modifying. Consistent interface. Liskov Substitution (Swap out code underneath methods) - squares and rectangles Interface Segregation - specific interfaces Dependency Inversion - High-level modules should not depend upon low-level modules. Both should depend upon abstractions. DRY - Don't Repeat Yourself LoD - Law of Demeter - Talk only to closely related objects- the principle of least knowledge Design Patterns Service Objects, Factory, Adapter, Decorator - This book doesn't cover these. Big Up Front Design Pitfalls Design takes time Next Chapter - we really get our hands dirty Sandi Metz Links: https://www.youtube.com/watch?v=npOGOmkxuio&t=1841s https://www.youtube.com/watch?v=29MAL8pJImQ https://www.youtube.com/watch?v=8bZh5LMaSmE&t=1s Pick: JP: https://testingjavascript.com/  John: SOLID Design Patterns in Javascript https://www.youtube.com/watch?v=GtZtQ2VFweA&feature=share - - - - - New Book: Practical Object-Oriented Design

We explore how to engage an audience with public speaking veteran Chad Fowler. We talk the art of storytelling, how to surprise an audience and the pros & cons of scripted versus free style public speaking. Show Notes 1:13— We introduce our special guest for this episode, Chad Fowler. 4:16— Chad describes how he first began becoming aware of the importance of public speaking from watching his grandfather, who was an electrifying Assembly of God preacher. 6:07— We discuss the training that preachers go through that helps them learn how to best deliver a public speech using techniques like physical movement and one's position on stage to enhance the message they intend to convey. 7:35— Chad recounts an experience where his history of writing and speaking about programming in Ruby caused others to consider him “the best Ruby programmer in the world” even though they had not seen at any of the code he'd personally written.  8:50— “If you speak around a topic, you tend to be perceived as one of the leaders in that topic.” — Chad Fowler 19:02— Chad compares the experience of creating a public speaking performance to creating an improvised jazz track and how you never really know how it went you can gauge audience reaction. 20:16— Chad shares a tip about how he prepares a speech. He creates a basic outline but gives himself the freedom to improvise during the talk itself. 27:51— March discusses the difference between being under-prepared and over-prepared for a speech and Chad agrees with a comparison to creating an improvised musical piece. 31:15— We explore the tactics that stand-up comics use to prepare their material for a performance and rigorously study their audience's reactions. We also mention a few of our favorite stand-up comics and explore the unique styles they have for their performances. 35:42— Chad discusses some advice he outlined in an essay he wrote titled “On Having Something to Say”. 39:20— On getting the nerve to speak on a topic: “If you don't think you have anything to say, then you can think about what you wish you had something to say about.” — Chad Fowler 47:48— Chad explains why he never rehearses his public speaking performances. 49:45— Ian shares a trick that Rosie O'Donnell used to elevate the energy of her audience prior to a show. 54:35— We discuss the power of silence as a tactic that speakers can use to captivate audiences. 58:20— Chad shares the names of a number of speakers that he admires for their great storytelling ability. 1:01:58— Ian shares a few of his tips about how to get more comfortable with the room prior to getting on stage for a speech and Darren shares a trick that politicians use to make an audience feel more empathetic to them. 1:05:59— Ian shares the differences between speaking to large audiences versus smaller audiences and March recounts his anxiety in presenting to Bill Gates on several occasions. 1:08:47— Ian asks Chad for his advice on how to get started with public speaking.  1:13:27— Ian decides to experiment by picking one of his passions and  1:14:13— March decides to dive deeper into the talks by Sandi Metz, Katrina Owen, and Dave Thomas to get better at storytelling. 1:14:45— Darren decides to practice employing the use of silence as a tool to better engage audiences during his presentations. 1:15:19— We talk a bit about Chad's earlier decision to step back from public speaking.  Mentions Netflix comedy special: Gad Elmaleh Improv comic: Todd Barry Post: On having something to say by Chad Fowler Author & book: Michael Pollan Public speakers that Chad admires for their storytelling ability: Sandi Metz, Katrina Owen, Dave Thomas, Michael Lopp Post: How to get your conference talk accepted; inspired by Ben Orenstein Follow Us Instagram Facebook Twitter Subscribe iTunes RSS Weekly email newsletter Full Episode Transcript Better Show Blog Feedback Email: hi@bettershow.io Enjoy the show? Leave a review in iTunes! Tell two friends about the show!

Soroush: That One Optional Property Massive View Controller Sandi Metz: Nothing is Something (RailsConf 2015) Finite State Machine (Wikipedia) StatefulViewController Soroush: a state machine where invalid transitions can't compile A gentle introduction to dependent types Less gently: Dependent Types at Work D Oisín Kidney: In which I Misunderstand Dependent Types Validated Andy Matuschak: A composable pattern for pure state machines with effects Functional core, imperative shell is from Boundaries by Gary Bernhardt

In this episode, Sarah Mei, founder of RailsBridge, Director of Ruby Central, and Chief Consultant of DevMynd Software, talks about the way we write software: What's right? What's wrong? How can we do better? The conversation examines changing code and reassessing needs. i.e.: "Does it bring me joy? Should I get rid of this thing? Do I understand this code?" She also talks about what these needs mean for others on a team. Sarah Mei: @sarahmei Links: Sarah Mei: How We Make Software: A New Theory of Teams @ Brighton Ruby 2016 The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organizing by Marie Kondo Transcript: CHARLES: Welcome to the Frontside Podcast. I am Charles Lowell and with me is Robert DeLuca. We have a very special guest this week. One that I'm really excited about because the things she says and the ideas that she has - open eyes and minds all over the place, in all different types of areas that are so pertinent to the way we do our jobs. So, we'll get to it. Our guest today is Sarah Mei. SARAH: Hi. Thanks for having me. CHARLES: Like I said, we are super excited to have you here. Before we get started talking about some of the things that you've been thinking about recently, why don't you just give like a very brief introduction of how you got started with development, where you've been, and how has that brought you to where you're going right now? SARAH: You know, I actually was not one of these people that got started with it real early. I came to programming in college. I was an Engineering major. I wanted to build bridges. I wanted to be a Structural Engineer. I want to build things. I had a weird schedule the first couple of quarters of college, so I ended up taking an elective earlier than most people take it. It was a programming class in Fortran that was required for the structural engineering program. I took my class and I was like, "This is really cool." CHARLES: Wait, Fortran is what set the hook? SARAH: Yeah, and the professor of the class was like, "Well, if you think Fortran is cool. I've got some other stuff that you might like." I mean, the language and whatever doesn't really matter. What I liked about it was the fact that I could build something. I can get that same feeling of building something that you get if you build a bridge but you can do more than like one or two in your career, like you do if you're a structural engineer. I like the constant feeling of building. That's what I liked about it. So I ended up switching my major and graduating with the CS degree and coming out and doing a bunch of different things, mostly like starting in a large company and sort of doing smaller and smaller companies over time. CHARLES: Yeah, there's a lot of people in the industry who are career switchers, where they started out in something else and moved into Computer Science but I actually feel that a lot of people, like myself included, I have the degree in CS too, but that was not what I set out to do at all. It totally derailed, like the course of my life in a good way. But in that way, it's like a career switch within a career switch. ROBERT: I'm a little odd in that aspect. I came out of high school like ready to go in software. It worries me a little bit for the later half of my life. I'm like, "Oh, am I going to do software for the entire time?" CHARLES: Probably not. SARAH: That might be a good thing. You'll never know. ROBERT: Yeah. CHARLES: Yeah, seriously, what lies ahead? ROBERT: Who knows? SARAH: I feel like in a lot of places that are like, for example, in public policy and in other places where we need more people that understand tech so if we can send you out into other parts of the world knowing a whole lot about programming, that can only be good. CHARLES: Yeah. ROBERT: Yeah, this is actually kind of funny. I was telling CHARLES about this the other days, like I'm starting to view programming more as a tool to do the things that I really want to do and less as like the thing that I'm going to be doing forever. I wanted to augment and make things that I have a passion about easier. SARAH: Yeah, absolutely. CHARLES: Yeah, it's like software is eating the world so what you're doing now is just learning how to chew. ROBERT: That's a great way to put it. SARAH: You should tweet that. [Laughter] CHARLES: All right. Please continue. I'll ignore the typing sounds. SARAH: [Laughs] Switching careers is a really interesting thing because you end up with a bunch of experience that you wouldn't have had otherwise. I'm really excited actually about the next five years as we have all these folks that switched into programming from something else who are all becoming mid to senior level because they're bringing just such amazing experience from other parts of the world. CHARLES: Yeah, I know, right? It's like, "Where've you guys been my whole career?" SARAH: Right. CHARLES: It's like you understand these things, just almost like it's second nature of these things that are opaque and completely inaccessible to me. So anyhow... SARAH: That's how I got here. CHARLES: So then, after you kind of switched in college, you went out and did you just start working in programming immediately thereafter? SARAH: Yeah, I worked in a bunch of different product companies. I built products for a while. My first job actually out of college was at Microsoft up in Redmond and then I have worked at smaller and smaller and smaller companies. Then I spent about 10 years doing product stuff and then about 10 years ago, I switched into doing consulting mostly because I realized that I have a fairly short attention span for projects. And that working on a product, there wasn't anything wrong with me exactly but what would happen is when I was working with a product, I would get six months to a year into it and I'm starting to get antsy. I started to get bored and decided that I should just embrace that. And I switch to something where I am going to be on a new project every three to six months. I've been a lot happier since then. ROBERT: That's interesting. I wonder if that comes with seniority in software development and knowing your way around because consulting for me is I've gotten the experience of, "Oh, wow, I'm just finally getting a hang of this person's product or this client's product or app or whatever we're building," and it's, "All right. It's time to rotate off." It's like you just get in there and understanding everything. SARAH: There is that aspect of it for sure but even when I was much less experienced, even with my first couple of jobs, I noticed this tendency in myself to just get bored after six months on the same code base. For a long time, I thought it was because I'm not cut out for software or maybe I'm not very good at it or something. Eventually, I just realized now actually, it's just that I just need to switch projects. I'm just one of those people. That's how my brain works. I get a lot out of switching projects because the one that I switch on to, I see an entirely different way of doing things like code bases are so different. Even if you look at a hundred different Rails apps or a hundred different Ember apps, they're all so different. So switching on to somebody else's app, I learned a ton just out of that switching process. CHARLES: It sounds like the actual kind of studying the meta-level of the software is what really engages you and kind of understanding how the software came to be the way it is and not some other way. One of the factors that gave rise to that and kind of 'that's the problem' that really sunk its teeth in you, as opposed to individual business problem. Is that fair to say? SARAH: It has certainly been interesting to see different business problems and to understand different parts of industries and so on. That's definitely part of it for me but what really gets me interested is the different ways that people organize their code and by how they make the decisions that they make. ROBERT: Yeah, you get to see different problems that they've maybe put themselves into because of the way they structured something, which you wouldn't see if you wrote yourself but somebody else did and get to see, "Oh, I understand this pattern now." That's kind of been my experience out of it. I don't want to speak for you, but yeah, that's kind of how I've seen other client projects like, "Oh, this is really cool. I didn't think of a way to do this," and you get to experience many different things in many different ways. SARAH: You get to see a lot of the tradeoffs. Like a lot of times in a single code base, what would happen is I'd make a decision or we'd make a design decision of some kind. Then I'd see how it turned out. But there's no way for me to see how it would have turned out if I did it the other way. The nice thing about switching projects for me is just being able to see all of those tradeoffs, like the tradeoffs that you make tend to be pretty similar. You can see very similar situations where people do different things and how does it turn out for them. ROBERT: Right, and like one of my favorite things is where you go into a project that is totally against something, like for me it was object-oriented CSS and then you go in and you actually see it in practice, and you're like, "Oh, wow. This is turning a whole new light on it. I like this in this case." SARAH: Microservices are like that for me, where it's generally I am anti the microservice bandwagon. But then I went on one project where I was like, "Wow, they actually figured it out. This works really well. I can see why people like it," because I've seen so many work that was horribly executed. When you go on to the one where it's good and you're like, "Oh, this is why people do that. Okay." ROBERT: Yeah, it's like that light-bulb click, "Oh, yep. There's another side of this." CHARLES: Once you actually see it done right, it helps you avoid every other situation where it was done wrong and you can say, "Oh, this this was the one differentiator that made it all go right." I mean, sometimes it doesn't always boil down to that. But there's these one, two, three things that we could have done. But they were just completely and totally hidden from you because you didn't have that context. I would love to talk to you about microservices because I've certainly never seen it done right. I've heard it talked about and I've seen this beautiful world, picture-painted that looks so fantastic on the whiteboard. But I see -- SARAH: Oh, it's so beautiful, isn't it? It's like an object-oriented design diagram. I'm like, "Look at all the boxes and lines. They all line up." CHARLES: "They're beautiful." SARAH: "I can do this in Visio," and they're all like, the line, they are on the same shape. It was great. CHARLES: "And when I move this one over there, it just tells me that these two are exactly the same distance apart from that other one." Ah, so satisfying. SARAH: Yeah, and then you try and do it, is the problem. ROBERT: Then you build it and you cross your errors and everything. CHARLES: Which actually I think that brings us, recently -- we're talking on Twitter. I think that's actually very recently about kind of the difference between when we talk about software and the meta conversations we have around it. When we do talk about these abstract and perfect worlds of boxes and lines versus the actual code bases, which is the things that you've kind of been observing many, many, many since you've started consulting, and kind of the vibe between those and you know what that means. I think a lot of people aren't even aware like I certainly, before kind of reading that, wasn't really aware that that is a very, very distinct difference, like these are two very different modes for software. One that exists and one that is kind of perfect world. ROBERT: Kind of academia versus the real world, I guess. SARAH: In some ways, yeah. I remember when I was in college, we had a software design class as part of our degree program. We studied how you define objects and you write a little bit of [inaudible], like we did all this stuff. When I got out and I got into the real world and I had a job, I found it very difficult to actually apply that stuff successfully, to be able to draw a diagram and then turn it into code and have it work out the way that the diagram said it was supposed to work out. I initially thought that was because I was just not experienced enough to figure it out. But eventually, what I realized is that it doesn't work because it doesn't work. It really doesn't work to design things ahead of time and then just do them. I think there might be a certain type of person that can do that. I am not that type of person and most people aren't. I think that it takes a very unusual type of brain to be able to just draw a diagram that has already taken into account all of the things you're going to encounter once you start making it. CHARLES: Yeah, I would even go so far as to say there's probably a brain that solved that problem many, many times, that just could skip a bunch of steps. SARAH: Right, and they're not aware they're skipping them necessarily. Unless you have an entire team full of that type of brain, it's probably not a good idea in general, for the software that you're building as a group. I feel like I've been trying to talk about that concept between the difference of how we talked about software in books, in blogs, and in conference talks and then how we build the software we actually build. I feel like I've been trying to articulate that for 20 years, like since I have my [inaudible] and I was like, "This doesn't work. Why can't I make a diagram and then make it into code?" Like two days ago, I feel like I finally found a way to articulate it that captures everything that I've been trying to communicate and it was a really strange feeling. I'm like, "Wow, I finally kind of got it." One of the reasons that I came up with that, I think, is because I haven't really been thinking about it for a couple of months. I've been off and not really thinking about software stuff for a while. Oddly enough, I've been thinking about organizing my house for the last three months. All of my free time outside of my job has been thinking about like, "I've been learning how to cook, so how can I organize my kitchen so that the things I actually use every day, I don't have to dig through a drawer every single time to find them?" There's actually some interesting problems there like, "How do I make sure that all of the stuff that I need is at hand that I use all the time? All stuff that I need occasionally is still around and accessible, and then things that I don't use, I should probably just get rid of." I have this problem that I think probably a lot of people have which is that I have trouble getting rid of stuff once I have it. I live in a small apartment in San Francisco and that's not a good thing to be able to unable to get rid of things because in an apartment this size, I can let it go for a week or two maybe, but like I got to be very vigilant about it because otherwise, it just overwhelms the space. CHARLES: Yeah, there's a bunch of research that the people estimate vastly different the cost of acquisition versus the cost of loss, and they've [inaudible] way too much, like irrationally unbalanced like not wanting to lose something that they already have. SARAH: Even if I bought it for a need that I don't have any more or the need has changed or shifted. I don't buy things I don't need. There are some people that have that problem, that they buy a bunch of stuff that they don't have any particular plans for it. I don't have that problem, thankfully. I've had people in my family that have that problem which I think is why I have avoided that. But the problem I have is that once something is here, I find it very difficult to get rid of it. I look at it and I'm like, "I can think of all these reasons why I shouldn't get rid of it." Oh, that was expensive so the sunk cost fallacy of like, "Oh, I paid a lot of money for that even if it's not useful and I don't like it, I shouldn't get rid of it." Or, there'll be like a dress in my closet that I haven't worn for two years and I'm like, "Ah, maybe I should get rid of it," and I take it out and I'm like, "Oh, my God. But it looks really good on me. I like it. I should wear this. I should really wear this." So I'm going to keep it even though I haven't worn in for two years for some reason, but I should keep it anyway because it looks good. I have all these stories. I tell myself about why I can't get rid of things. A couple of weeks ago, I read a part of a book, to be totally honest with you, called The Life-Changing Magic of Tidying Up. It's written by this woman from Japan who's a professional organizer. Her name is Marie Kondo and her method is called KonMari. Basically, what it does is when you're trying to figure out whether you should get rid of something, you don't ask yourself, "Should I keep it?" What you ask yourself is, "Does this thing bring me joy? And if it brings me joy, then I keep it. If it doesn't, then I'm going to get rid of it." So that made it really easy, going back to the dress example. I'm like, "Does this dress give me joy?" And I thought about it, I was like, "No, the reason I don't wear it is because I went out to dinner and I had a bad experience at dinner so every time I look at that dress, it reminds me of that experience." And so it looks good and everything but I'm not going to wear it because it doesn't make me happy. So that was just like, "Okay, fine. I'm just going to give it away." And changing that question that I ask away from 'should I keep it' towards 'how does that make me feel' was a huge change for me because it's like, that's really easy to answer, where 'should I keep it' is a much harder question. There's these bunch of sort of ifs and maybes or what-ifs and what happens. I feel like that applying this KonMari question to stuff has changed the way that I calculate what stays and what goes in a very positive way. CHARLES: Yeah, boy, I need to get this book for several family members who will go [inaudible]. SARAH: Well, you know, I've got two kids and so there's a constant flow of stuff coming into the house. Because of the amount of space I have, there has to be a constant stuff going out. So this is something I just need to be very vigilant about and this has made it so that it takes up a lot less of my time and a lot less of my brain space, which is really awesome. It feels like it's moving my house in the right direction. I've been thinking about that sort of in various ways, on and off, for a couple of months and I haven't been thinking about software. I have this fear that like, maybe that means I'm never going to think about software again. I go through these phases where I've got like, "Oh, I'm going to come up with a bunch of new ideas," where I'm coming up with new ideas for some whatever reason. Maybe I'm making new conference talks, I'm doing stuff, and I'm thinking about software a lot. Then I go through these phases where I don't do that, like I sort of retrench and maybe... I don't know. I think about other stuff for a while. So it's been home organization for several months now. I was like this, "I'm never going to think about software again," because it's just that -- [Laughter] CHARLES: Career change. ROBERT: Oh, man. This sounds so much like my life since I moved down to Austin. SARAH: You know, I live in San Francisco and I'm not 25, I'm 40. A lot of it is like maybe I'm just too old for software now. I should just give up and live out the rest of my career doing quiet, maintenance work -- [Laughter] SARAH: Somewhere. I don't know. Then suddenly, this thing happened on Monday, where I was just like, "Oh, code, an organization." And boom! There it was. I realized, I was like, "I basically just had to give my brain some time off," like my conscious brain needs some time off from software and it wasn't that it had disappeared because what I came up with on Monday was really just how home organization applies to code because I realized that the feelings that I get when I'm trying to figure out what I should do with code are very similar to the feelings that I get what I'm trying to figure out whether I should get rid of a thing. I look at this piece of code and I'm like, "Should I change this? Should I get rid of this? Should I refactor it?" You know, why I can't get rid of that? We just spent two weeks refactoring it so I can't change it again. [Laughter] SARAH: We just put in a story for refactoring this and we spent three days and I can't go back to the [inaudible] people and tell them, "I need to change it more." Or, "I really like this code because I wrote it with someone that I really liked." CHARLES: So I don't want to get rid of it. SARAH: I don't want to get rid of it because then I would lose the memory of working with, you know. CHARLES: I actually can say that I have experienced that. SARAH: Yeah, there's a lot of reasons why you don't want to change code. What I was thinking about, like maybe I was asking the wrong question, in the same way that 'should I keep this' is the wrong question when you're talking about stuff. Maybe 'should I change this' is the wrong question when you're talking about code. Maybe it's sort of leading you in the same way with stuff that leads you down this conversation of reasons that don't really have anything to do with the essential quality of why the code is there or why the thing is there. We need something that helps us reassess our needs. So if our needs have changed, maybe you don't need that thing anymore because your needs have changed. Same way with code. If your needs have changed, maybe you don't need that code anymore, at least not in the form that it's at now. I think that question for code that, "Does it bring me joy," because joy is not something that I think is concrete enough when we're talking about code. I think the question for code is do I understand this? Do I understand what it's doing? Not just understand it like a very surface level of like, "Can I figure out what this syntax means?" But understand it more like the grok level of like, I understand this at a very deep level. I understand why it's here. I understand what problem it's solving. I understand why this abstraction is necessary. I understand how it got here. CHARLES: Yeah, how it fits into the bigger picture. SARAH: How it fits into the bigger picture, exactly, like the application. CHARLES: How it fits in with like our conventions that are just purely stylistic. SARAH: How does it fit in with the other stuff that we've been doing? How does it fit in with the product needs and the features we're trying to build and the business goals and all of that stuff, all of these different levels of understanding of why this code is here and what it does? CHARLES: Do other team members' understanding factor into that? Like, "Do I understand the way that other people understand it," so to speak? SARAH: I think that it can. But I think the important thing is whether you personally understand it. CHARLES: Okay, like it's a very personal decision. SARAH: I think it is. Hopefully, what you do is you want different people looking at the same code. You don't want just one person on a piece of code that no one else ever sees, whether it's pairing or code review or whether it's something else. It need to be really clear to someone is coming in and looking at that code what it does, what it means, and why it's there? CHARLES: Right. I guess the reason I asked the question is because a lot of times when I look at a piece of code, I try and really step outside of myself and say, "What will someone else think who has never been on this project before?" Or, "Who is on this project and they see this code, will they understand it?" SARAH: Absolutely. It's definitely a part of it when you're on a team. CHARLES: Yeah, so I'm just trying to figure out how that question factors into this framework. SARAH: I think that it depends a lot on how you distribute tasks. For example, if you work in a shop where you're pair programming most of the time, so there's always two people looking at a piece of code, 'do I understand this' is a reasonable question just for the two of you to consider, both from the fact that you can pool your knowledge but also from the fact that 'are there pieces of this that you understand that I don't understand' and vice versa. On the other hand, if you work in a shop where it's more like, "Here's the piece of code that you work on like you own this section of code." Then I think it's more important for you to be able to step outside and be like, "Okay, do I understand this? Would other people on my team understand this?" That can be a very difficult thing to assess and that's where I think it's very helpful to do things like code reviews, call people in and be like, "Hey, can I run some stuff by you. I'm trying to figure out if this is good or not," because what you want is you want a code base that is comfortable and understandable for you and for your team. Just like the thing that makes the KonMari Method powerful for stuff is that it doesn't tell you what you're going to end up with. It doesn't tell you what level of clutter versus cleanliness is good for you. It doesn't tell you. You either end up like something in one of these simple living magazines or end up something like Quarters, the TV show. There's a bunch of places in the middle, they're all fine. Everyone's going to fall somewhere differently along that line. So I've managed now that I've thought about this a lot to set up my kitchen in a way that is very comfortable for me, like I know where things are, I can find them really easily, things that I use are at hand. But other people come in, they're just like, "I have no idea where everything is," like it's very personal. The organizational system you end up with [inaudible] that you have is a very personal thing and that's why, if you look at something like staged houses, so you're selling your house, you hire someone to put in rugs and furniture and stuff and make it look like somebody lives there so that people can walk in and sort of imagine themselves in this space, they don't put any of that clutter into the stage. They don't put any books on the coffee table except the big picture books. They don't leave the remote controls on the couch. There's no plunger by the toilet. There's no like -- CHARLES: There's no Legos on the floor. ROBERT: Everything that looks good. SARAH: Everything that makes it more personal, they leave out because it looks like somebody else's mess. You go into something like that and you're like, "This is not my mess. This is somebody else's mess. It can't possibly be my house and I'm not going to buy it. ROBERT: Oh, do we do this for software in conference talks and posts? SARAH: Absolutely, we do. That's sounds very similar when you get someone new onto a project, especially if they're more senior and they'll walk in and be like this, I can't live like this. [Laughter] SARAH: This is somebody else's mess and clearly we need to make some changes. But that's the reason why they leave it out of the staged houses is because you want people to be able to imagine their own level of clutter and disorganization that superimposed on the skeleton. But real life is not that. Real life is somewhere between that and hoarders. There's a very interesting parallel there with code, which is like when we look at code, if we look at the object-oriented design textbooks, you look at conference talks, you look at blog post, sample code, it's all very staged house. It's very uncomplicated. It has no clutter in it and that's because you're supposed to be able to look at that. CHARLES: I mean, that clutter can distract the sales process so to speak. SARAH: Exactly, like they have an idea they're trying to get across and the clutter would distract people from the idea. But the problem there is the same with the staged house which it's very difficult to tell what it will be like once you move in. It's very difficult to take some of these ideas that you see demonstrated in these staged environments and take them and apply them to your code base which is probably closer to a hoarded house than to a staged house especially if it's a code base that existed for a while over time, that has been worked on by lots of different people. This is the problem that I've noticed with a lot like there's some really amazing books about software design that have come out in the last couple of years. Of course, Sandi Metz's book is at the top of my list. But the thing that people have trouble with, like they love the book. They love the book. I love the book. But then they find it very difficult to apply those principles when they sit down in front of a code base that has already been worked on for six or seven years, in some cases by maybe 50 different people, who knows, over time. How do you take those principles and start applying them in a way that moves you in the right direction? That's where people are just like, "I can't do this. I can't do this and I'm not going to do this." And it's very similar to a problem where you've got a very dirty house and you don't know where to start in order to move it towards something from the Simple Living magazines or are more like a staged house, you don't know how to start to get it in that direction and so you just kind of give up. The powerful thing about KonMari is that it doesn't give you like, "Here's what you're going to end up with it," but it gives you a way to get started on something that gives you a very easy question to answer. It moves you in the right direction. It moves your house in the right direction without being overly prescriptive about what you'll end up with. CHARLES: Yeah, what that direction even is. SARAH: What you'll end up with is personal for you, anyway. I think the question about 'do I understand this code' is similarly helpful and that it moves you and your code base in the right direction without necessarily giving you a lot of prescription about how you do it or where it goes or even where it's going to end up. It just gives you a question to ask that it tells you whether or not this code needs to change and a question is, "Do I understand it?" If I don't, it should probably change, and if I do, okay, we can just kind of leave it for now. CHARLES: So now, if you're working on a team where you have two different people, maybe different skill levels, maybe just a different temperament or different set of preferences, what do you do when the answer to that question is two different things for two different people? SARAH: Well, sort of like when you move in with someone. This is the hard part about living with somebody else, is that you have to mutually agree upon a method of keeping your house that is agreeable to both of you. Sometimes, when they say that working through a startup is like being married to someone, there's some elements of that because you basically have to figure out like, "Okay, we're going to live in this code together. If we're going to live in this code together, we better both be happy with it. How can we both be happy with it?" It involves usually, some compromise, like I really hate doing the dishes but I don't mind cooking and vice versa. You have to figure out. It really bothers me when there's socks on the floor but I don't care if you leave dirty dishes in the sink or whatever it is. You just have to have these conversations about, "What is going to make the code livable for you?" You basically want to end up with a code base that's understandable where all parts of it are understandable to everyone on the team. Now that's like an ideal. You're not going to get there. But that's kind of what you're going for. If you have two people in the code and you have disagreements about what is the right way to go, sometimes it can help to just be like, "Hey, I don't really understand this," versus, "I don't think this is the right decision and here's why I don't understand this." Sometimes, reframing the question in that way can prompt them to communicate reasons that they have for doing this that they maybe weren't able to articulate before, for example. Just like when you move in with someone, you need to have sort of this commitment to finding a level of housekeeping that you're both happy with. When you're working on the team, you do have to have sort of a mutual commitment to having a code base that everyone can live in. CHARLES: Right. I like that because having like, "I just don't understand this and here's the reason why," that being a completely totally valid answer because sometimes in a code base, where someone's brand new or maybe they're at a more junior level, they don't quite have the tools to understand it or there's a lot of steps that haven't yet taken. It's like understanding is not going to be accessible to them immediately. SARAH: And maybe that means that's the wrong decision for that code base, is that right? CHARLES: Right. SARAH: Because if something is abstracting to the point that a lot of people on the team don't get it, then it's probably not the right abstraction for that code base. That abstraction might be totally appropriate in a code base in which you've got folks that are more experienced who understand why it's there, who have the scars from previous times when they didn't do it, et cetera, et cetera, and they understand why it's there. There is sort of like intellectual understanding of like, "Yes, object-oriented design is a good thing," and then there's, I would call it almost emotional understanding of like, "Oh, yeah, there's this time that we didn't do that and that worked out badly for us." I think that folks that don't have the sort of experiential understanding, sometimes they just need to have that. They need to get that. Sometimes, what that means is you want to let them see what happens to a certain extent. Let them see what happens when you don't do that. CHARLES: Right. This reminds me actually, I've got three kids and the way our house is now versus the way it was seven years ago is wildly different -- the way that we live. You know, with our first child, I'm ashamed to admit it, like our strategy was just to kind of put safety locks all over everything: every cabinet, on the oven, not on the refrigerator, but just kind of 'childproof' the house so that we wouldn't have to change the way that we lived but it made the house really uncomfortable for our children. And kind of having observed that over the course of having the second and the third, there's not anything that we childproof really. We put the dangerous chemicals way up high, where only we can get them. It's a little bit more inconvenient if we need to access the bleach but that level of discomfort is something that we live with. We've always got cups that are set out on a cabinet that sits below the counter so we've got water cups set out so that the children can get water and stuff anytime that we want, and we try, for things that they're going to need, make sure that it's accessible if you happen to be four feet shorter. That's just a condition of who you are. So it means that the actual configuration of our house, even though it's the same house, is just radically different and it is more optimized or it's optimized as a compromise for the fact that there are people living in this house now that haven't learned how to operate everything but they just need to learn that the oven is hot and you don't go there rather than slapping a lock on it. SARAH: Your house is probably more comfortable for you as a group, right? CHARLES: Yes. SARAH: And what that means is that as the 'senior' in the house, it's slightly less comfortable for you in some ways but it's worth it. It's worth being less comfortable for you in order to increase comfort across the board for everyone in the household. CHARLES: Right, because it means that if the child needs water, I don't have to stop what I'm doing to get a cup out of the cabinet and fill it for them. SARAH: And they feel [inaudible] over the stuff in their house. They feel like they live there, like the house is for them. CHARLES: Yes. ROBERT: That builds comfort and confidence. SARAH: Yeah, I think that's a very good analogy. Anytime you have a group of people living together, everyone makes compromises in order for the house to be set up in the way that's optimized for the group. CHARLES: Yeah. "So man, how are we going to apply this to software? What's the next step? What are the concrete steps?" I guess it's just asking those questions, like asking, "Did I understand it?" SARAH: It is asking those questions and it's also, if you are one of the more experienced folks on the team, it's your job to elicit the answers to that from other people that are less experienced. They're not going to tell you. A lot of times, sometimes, they may or may not feel comfortable saying that they don't understand something. So it's your job to really try and figure out like, "Do they get this at a level that is acceptable? Do they understand why this abstraction is here at an intellectual level or at an experiential level, at an emotional level? Do they get it?" Which is not something you can really just ask. In many cases, it's your job to -- CHARLES: To just observe it. SARAH: To observe and to see how it works. If people are having a hard time understanding where things are in the code base, it could be because everything is so cluttered that you can't see anything or it could be that everything is so hidden that you can't see anything. It's sort of the staged house equivalent where everything is too abstracted, or is it the hoarded house equivalent where everything is just obscure and under piles of junk. Either way, no matter which direction you need to move towards the middle, the question is always, "Do I understand this?" ROBERT: I like this a lot. I keep on coming to the analogy of if you put a chef in a different kitchen where everything is just totally rearranged and they don't know where their knives are, where their measuring cups are and stuff, I think that plays perfectly in a software of like you put somebody into a code base that they don't know, "All right, I'll figure it out." It's not their home. It's not what they're comfortable with or used to. Yeah, I think this is making my brain work on how I can apply this. SARAH: Or if they're moving in like when you hire somebody and they 'move into your house', you need to be ready for things to change. And this is one of the reasons why I've been saying for many years in ways that I think maybe didn't quite connect as well as they could have, that really the team is the code and vice versa. Every time you add someone to the team or someone leaves the team, teams are not mutable. You get a completely new team. So, it's not like you can just sort of carry on like you did before. Every time you get someone new onto the team, everything gets reimagined, every breakdown of responsibility, every decision. You look at it in a new way when you have someone new come on to the team. If they're going to stay, like in your chef example, if this person is moving in and this is going to be their kitchen and they're sharing it with other people, then what you're going to end up with is probably something in between what it is when they get there and what they had before. They're going to bring in some ideas, you're going to keep some of your ideas and you're going to end up with something in the middle. The same thing has to happen with your code when you bring someone new onto the team. CHARLES: I really like the way that this just focuses the discussion and I know that you've talked about this a lot before, whether it's a kitchen or a house, this idea of the code not being so much the shrink-wrapped product. It's a structure, yes. It is definitely that but it's a structure that you, as people, inhabit. It protects you from certain things and it provides you certain things that you need to live. When people ask us why is a continuous delivery pipeline so important in automating all these things for deploying your software it's because the idea is this is going to be a living thing that your team will actually be living in. And every member of that team will be living in from the time they start with the company or start with the project until the time that they exit and the time that they leave. It's the actual living process that you want to make comfortable and pleasant. SARAH: And what comfortable and pleasant means will be different depending on who's on that team? It's not something that you can have like a -- CHARLES: It's not. SARAH: Right. This is why all of these things are like, "Here's how you design things." It always seemed to fall flat. I think it would be better titled like, "Here's how I did one thing once." [Laughter] SARAH: Or, "Here's what works for me." I feel like every conference talk that is about design could be, "Here's what works for me. I did this one thing once." CHARLES: You might want to try it. SARAH: You could try it. It might work for you, it might not, right? CHARLES: Right. SARAH: A lot of times where conference talks fall flat and blog post and everything else was why they're more like, "This is how you do it. This is the right way to do it." You're like, "Well, it certainly works for you." [Laughter] ROBERT: The one time I gave a conference talk, the night before I went through every slide and scrutinized it as much as I thought somebody out in the public would do it. And I think that might be where we go through in a 'stage our code'. It's like we're trying to make it perfect for somebody that might come through and scrutinize it or criticize. Because I know when I was going up to put those slides up, I wanted to make sure it was the best foot I could possibly put forward. CHARLES: Right, we don't want to be wrong but I think that's where it actually, thinking of it as 'this is what worked for me' and this is an example from my house that worked. This is a way that I organize my code and my space. That'll not take a lot of pressure off of not having like, "I am right and I'm an authority at saying that this is the right way." That's a lot of pressure. SARAH: I don't even like that. I try and frame a lot of the things that I talk about as like, "Here's the thing that works for me really well. Maybe it'll work for you too. Let me know." CHARLES: Yeah. ROBERT: Yeah, that's how I give it. CHARLES: Up until really about two years ago, I felt like that was the expectation that was put on people is to say the right thing. SARAH: That's true. And I think that there's a lot of teams where that is an unspoken requirement and that's something that we should examine. Because even within a team like 'here's a thing that works for me or here's a thing that worked on my last project' isn't very different from saying something like, "Well, industry best practice --" [Laughter] SARAH: And I think that like you get to a certain level of experience and people expect you to say things like that. In my experience, the best way to do it is 'blah'. I mean, it's not actually a super useful statement because your past experience may or may not be directly applicable to the thing you're looking at right now, no matter how experienced you are. I think that it's much more friendly to have a range of experience levels to say things like, "Well, this worked for me on this project. Let's talk about whether it could work here." CHARLES: Right, yeah. ROBERT: I really like that. CHARLES: I do. It's so hard because your human nature is to try and boil things down into a simple binary. SARAH: People would love to have a list of rules, I'll tell you that. This is a problem. This is one of the reasons why I think it's important for us to come up with these questions that you can ask that will move you in the right direction without giving you rules, that will move you in the direction of finding the rules that work for you. Because rules themselves, people really, really, really want them. But they're always misused. They're always misunderstood and what you really need are the questions that led you to those rules in the first place. That's what people really want, although maybe that's not what they are asked. ROBERT: Ah, the Steve Jobs approach. SARAH: [Inaudible] to start wearing black turtlenecks. I hate turtlenecks. ROBERT: And New Balance shoes and the jeans. [Laughter] SARAH: But yeah. I think it's one of those things where people are very hungry for guidance. But we've been giving them the wrong kind of guidance. We've been trying to give them rules. When what we really need to do is give them questions to help them develop their own judgment. ROBERT: Right. Like when I was coming up, I thought, in everything, there was a right way to do it and a wrong way to do it. I've been slowly, sadly figuring out that it's not all black and white and it's not all just logic. I've always treated programming as like, "Well, they wrote this and it's just logic so I should be able to understand this." It's been a long road to come to this conclusion that kind of like what you're talking about and this has been enlightening for me. Like you are going to solve your problems your own way, your own person, and you'll think about things differently. I really like the analogy of 'this is your house and this is how you work and live in your house'. SARAH: Right, and no one would tell you in order to be a proper human being, you have to set up your house this way. ROBERT: Exactly. SARAH: We feel comfortable telling people, in order to be a professional developer, you need to set up your code this way. I think that those are very similar statements and we should really examine a lot of these 'should' statements that are all over the place when you're talking about software. Think about whether or not they're actually serving us in our mission of doing more things with tech. Like overall, my mission here is for people to be more effective with code so that we can do more interesting things with it. I live in the TV show, Silicon Valley, essentially so I'm surrounded by these companies that are solving these little tiny problems and I'm tired of it. I want us to solve bigger ones. In order to do that, we need to get better at coding. We need to get better at managing code over time and that's what I'm trying to do. CHARLES: Because it's not going to scale, otherwise. We're out of time. We're going to have to have you on the podcast again because I don't think we've got to... what? About 15% of the things that we want to talk about? SARAH: Oh, we are overtime, aren't we? CHARLES: Yeah. But thank you so much, Sarah, for coming on and talking with everybody. You drop real quick your Twitter handle so that if people want to have follow on discussion, they can reach out to you that way, or your other preferred means of contact. SARAH: Yeah, Twitter is probably the best. My Twitter is @sarahmei, and that's mostly where I am. CHARLES: All right. Well, fantastic. As always, feel free to reach out to us too. I'm @cowboyd on Twitter. And what are you, Rob? ROBERT: @robdel12. CHARLES: All right. It's a wrap. Thank you so much, Sarah, and we'll see you in Ether and hopefully we'll have you on the podcast again sometime.

In this episode, LaToya Allen, developer at Big Cartel and founder of SheNomads talks about apprenticeship and mentoring, finding community while working remotely, how companies can be more inclusive for hiring women and people of diverse backgrounds in technology, and avoiding burnout and maintaining balance. LaToya Allen: @HashtagLaToya | latoya@shenomads.com Links: CodeNewbie Ep. 34: Newbie Story: LaToya Allen The SheNomads Podcast Garage Cowork (Polanco) Dear Tech Companies: Focus on Diversity, Not Foosball The SheNomads Job Board Women in Tech Wellness: Chicago Resources: Practical Object-Oriented Design in Ruby by Sandi Metz Exercism.io The CodeNewbie Twitter Chat Transcript: BRANDON: Hello everybody and welcome to Episode 44 of the Frontside Podcast. I'm your host Brandon Hays and I help run the Frontside. STEPHANIE: Hello, I'm Stephanie Riera and I am a developer at the Frontside. BRANDON: Awesome. And we have a special guest today, LaToya Allen. So you're a developer at Big Cartel, is that right? LATOYA: That is correct, yes. BRANDON: Cool. We wanted to talk a little with you today about your day job, your work with SheNomads, your recent blog post about inclusivity and how you balance all that stuff for people. We wanted to start, if we could, by having you introduce yourself for the listeners that don't already know you. LATOYA: Sure, my name is LaToya. I am a software developer at Big Cartel and I'm also the founder of SheNomads. BRANDON: Cool. We actually listen to your podcast and found out some cool stuff about you. One of the things is you used to tend bar. Would you be okay telling us a little bit about your story about how you got into software, what you did before that, and why you're doing this now? LATOYA: Absolutely. I was bartending in Chicago, trying to figure out what I wanted to do with the rest of my life because I knew that it wasn't staying up until 5 in the morning, making Martinis for folks even though it was fun and I do appreciate that time of my life. One day my yoga class got cancelled and I needed something to do. I ended up stumbling upon some coding tutorials and I really fell in love with it. I noticed that hours had gone by, I wasn't bored, I really felt engaged, and it didn't really feel like work to me. It felt like something that would be a cool hobby. I, like many people at that time, felt that you needed a college degree to become a software developer, so I really looked at it as more of a hobby. I started going to different meet-ups in the city and I discovered that wasn't true. And I was lucky enough to find people that are willing to help teach me when I was very early in my career. BRANDON: Cool. And I guess the rest is history now, right? You've had a couple of jobs since then and you went through an apprenticeship program and after the apprenticeship program, you're developing lots of different kinds of software. Are there any software projects you're working on now? I know I met you at Ember Conf but you're doing less of that now. Are there any software projects now that you're fun and exciting, like what languages are you using? LATOYA: At work, we are primarily a Rails app. I've been doing a lot of work in Rails, a little bit of JavaScript. I had the opportunity to learn Ember when I came on to Big Cartel. So, that was pretty cool. As far as side projects, I started an open-source project for SheNomads as a way to help teach folks how to do simple things like create a pull request in GitHub or just the basics of working with Rails. But SheNomads has become an entirely different thing since I started that, so I don't do any coding outside of work right now, unfortunately. [Laughs] STEPHANIE: How long was your apprenticeship? LATOYA: I was an apprentice at 8th Light in Chicago and I was there for one year as an apprentice. STEPHANIE: And is that where you learned Ember? LATOYA: No, when I left 8th Light, I landed a job working in FinTech for 6 months. And then after that, I went to Big Cartel and Big Cartel is actually where I learned Ember. STEPHANIE: What was your apprenticeship experience like? Do you have any advice or anything that you think really helped you along the way? LATOYA: I got to learn from some pretty great people such as Mike Ebert, Colin Jones, just off the top of my head. I learned from a ton of people when I was there. Ginny Hendry was also very helpful. Basically at 8th Light, they really focused on test-driven development and pair programming which test-driven development is a lot of fun and tests are great, that they're very in these days. I got to learn how to test-drive applications and languages such as Ruby, JavaScript, Clojure which is probably my favorite language that I'd never get to work in because it's not popular enough, I guess. I think I did a little bit of REST while I was there as well. And then I was working in frameworks such as Sinatra, Rails, and I worked in ClojureScript as well. STEPHANIE: Nice. I also wanted to ask if during this journey of becoming an engineer, were there any experiences that helped shape the way that you think today? And I'm asking this because I'm curious to find out where the 'She' in SheNomads comes from. And why not just make this a very general digital nomad type thing? Why was there a focus on being a woman? LATOYA: Because I am one. [Laughs] I'm a woman. I think that people tend to think in gender in terms of their own. So for me, it was just fair enough for all to come up with the name SheNomads. STEPHANIE: Gotcha! Obviously, there is a difference, it seems like, in becoming an engineer when it comes to being a woman. I've participated in a lot of events and usually I have women come up to me afterwards and talk to me. And they usually tell me their experiences and how they know that they haven't been participating. They know they haven't been going to hackathons and other events. And I asked them why and 90% of the time, their answer is they're just intimidated. They don't want to be the person raising their hand in a room full of guy developers and hoodies. They don't want to be seen as the amateur or the person that doesn't know. So, I wanted to see how your experience was if it was similar to that or if it was any different and see if there is anything you learned along the way. LATOYA: Look, we all know that tech has problems. I live at two different intersections in the majority of people that are in tech being I am both a woman and I am black. Being a woman – not just a woman, but being a woman of color in tech does come with its challenges. For me personally, I have never been one to shy away from raising my hand in a room or speaking up in a room. But I think that tech in a lot of ways did dole that part of my personality because I wasn't being listened to. I wasn't being considered. For example, there are plenty of times where I've been in a meeting, I've been showing my code and someone else takes credit for my work. And I just don't even bother to say anything because honestly, it's like, "What's the point?" At that point, you just find another job. Or I've been in situations where I say something to someone about the code or about a test or about a change that we should consider and then someone who happens to be male turns around and says basically the exact same thing. And while no one really reacted to what I said, people say, "Oh, that's such a great idea." I have also been in meetings where people don't even look me in the eye for the entire meeting which is very awkward when you're sitting in a room for an hour and you're the only woman in that room. And the person leading the meeting can't even bother to look you in the face. So I think that it's been an interesting journey. [Laughs] And don't get me wrong, there've definitely been a lot of positives with it. But to your question, those are some of the things that I've experienced and it certainly made me aware of how women or people who live at different intersections of the majority of folks in tech get treated and how we need to do better. STEPHANIE: Yeah. I think you and I are kind of outliers. I'm also a woman of color, I would consider, I'm a Latina. Nothing really stopped me from attending meet-ups and hackathons and I've always been very straightforward about what I know and what I don't know. So, that's never really been an issue for me but usually, I'd be probably one of two women out of a room of like 40 people. It's not very comforting. So that's why I'm wondering is there anything for women that aren't like ourselves, do you have any advice for women and for companies that want to be more inclusive, what can they do, how can they be more proactive or get over that fear or intimidation? LATOYA: Absolutely. So, one of the first things that I tell them to do when they are thinking about getting into tech is find communities that will be supportive of you because there weren't a lot of boot camps because Chicago was full of meet-ups. And because there were meet-ups like Chicago Women Developers, I was able to find that community [inaudible] and women were very forthright in sharing their experiences, both good and bad in tech. So, it definitely helped to prepare me a bit. [Laughs] But also when I had bad days, when I had times where I knew I wasn't being treated equally, it was easy to say, "You know what? I'm going to a meet-up after work because I can knock with you people." So, definitely finding a community. STEPHANIE: Sometimes, I feel like those negative experiences where you feel like you're not being respected or you're not being treated equally, at least for myself, that was like adding wood to the fire. That just made me want to succeed more. It made me want to become a developer. It just made me more passionate. I guess for other people, it can have the opposite effect. But I feel like the best revenge is to have them see you succeed. BRANDON: I wanted to ask kind of a follow-on question there about SheNomads. You talk about finding community being really important and you were lucky because you're in Chicago. But now, it seems like you're doing more travelling and there are other people that travel a lot. Is that where you found kind of a hole, the people that travel sort of nomadically? It can be difficult for those people to find a community. Is that where that comes from? Or what was the genesis of SheNomads? LATOYA: SheNomads started because when I landed the job at Bog Cartel, I knew – and I discussed this when I was interviewing with them as well, so it's very transparent. I knew for me working remote from home, that working remote from wherever I wanted home to be within reason as long as there's WiFi and espresso, I promise you I can work from there. [Laughs] So, I started my podcast actually because I had no idea how to work remotely. I had no idea how to pack a suitcase for three months and I didn't know how to find good co-working spaces. I didn't want to feel isolated while I was in the road. So, it kind of evolved. I started a Facebook group for it as well and that was very helpful because for example, I was in Tel Aviv, I was there for two weeks and I didn't know anyone and I really wanted to meet other women who worked in tech. And through the Facebook group, I was able to meet someone who ended up taking me to a co-working space that's sponsored by the government there with free food, free coffee, free WiFi where a lot of other people who happen to be digital nomads who work in tech were as well. For me, it ended up being this thing. It ended up being like an international community but that wasn't the intent when I started it. It's just like a lucky coincidence. BRANDON: And so now, you're putting a retreat together around that. Can you tell us a little bit about that? LATOYA: Yes. After I started the podcast, I started talking to them about their experiences. I knew that I wanted to really dive into it. I wanted to find a digital nomad retreat. But the thing is that the ones that I was coming across were very reflective as the tech industry as they are now. They're very young, people working for like 18-hour days and drinking beer for the rest of the time. And I looked at the attendees and it's like, "Okay, you're all men." [Laughs] And I didn't really want this thing for a week or two in a house full of drunk 22-year old dudes. It's just not for me. BRANDON: You don't want to stay in the front house, huh? LATOYA: Yeah. For me, I like my sleep, I like my yoga, I really like doing things like journaling and standing a long time. And I also enjoy what I do. So for me, I was like, "Okay, I want to be somewhere beautiful where I can have free WiFi, where I can practice yoga, and where I can talk to other people who want to work remotely but maybe want to explore a city." So I was working for Mexico City and I happen to have found the most beautiful house just south of the park. And I was speaking to one of my friends who was a yoga instructor and she said, "Yes, I will come. I will lead morning yoga. I will lead candlelight yoga at night. We could do some [inaudible] actions of people who are into it." And then I had been working in a co-working space in Mexico City and I told them about my idea. They offer to sponsor 30 hours for each attendee and that's Garage Cowork, it's in Polanco which is a gorgeous neighborhood in Mexico City. And then I used to work with a friend who's now the CTO of MealSharing.com. He said, "Hey, first of all I wish I could be at this retreat." But since it's women only, we talked about MealSharing.com sponsoring an authentic Mexican cooked meal for us. So, that's how they got involved. BRANDON: It sounds like things kind of fell together in a way that actually is going to create an experience that, I have to imagine, you're happy with the idea of. LATOYA: Absolutely. I'm very excited because if this already existed, someone else will be getting my money. But since it didn't, I just said let's make this happen and I feel very lucky that it all just kind of come together very organically. STEPHANIE: You recently had an article on Medium. I wanted to ask about that. What made you feel compelled to write this article about how companies approach what they write on their careers page? LATOYA: I had been talking to a friend who started tech a little after I did. And we had both attended the Sandi Metz POODR workshop together which is amazing. If anyone listening to this is a Ruby dove and you want to up your skills, I would highly recommend it. So we attended that workshop together, it was a great experience. I keep talking to women who are significantly underpaid, underappreciated, and are having all of these problems in tech. And so, I was just lying in bed on a Sunday night, working at careers pages and I was thinking about reasons that women leave tech because they keep coming in but it almost seems as if we're losing them too quickly. And I was thinking about these reasons why. I was looking at careers pages and it dawned on me that the careers pages of these companies were not very inviting and that I would not want to work on the companies based on those careers pages. Even though some of them, I knew people that worked at them and I knew that they were all about diversity and inclusion and they were paying women practically, if not the same, as what they're paying men. And I knew that they were positive work environments, so I knew that people were learning from them but the way the companies were presenting themselves was so different. So I thought, "If I was applying for jobs," and I'm not, I'm very happy at Big Cartel and I'm very happy with what I'm doing with SheNomads but if I was, I wouldn't apply at their company and this is why. And I just sat there that Sunday night in my bed, flipping through careers pages and I just noticed a common theme and it was that they weren't very inviting. They seemed to think that alcohol was a bigger selling point to the people they wanted to attract than things like maternity or paternity leave. Their pictures looked like they were trying to throw a party or something. I don't know. It was just – I was very surprised. STEPHANIE: Yeah, it seems to be the popular thing right now like this whole Silicon Valley vibe culture type thing. But it's interesting. I have two friends that are both recruiters for tech companies and mainly trying to find developers here in Austin. And last weekend, we were having the same conversation about how they don't like to admit it, but they have seen over ageism and just general discrimination. How they have seen countless times people that were definitely qualified for the position but because – I think one of their examples was a young lady but she was Indian. And this company that was looking, they were all white guys and they had rejected her because she wasn't "culture fit". But I find that very interesting because I think, as a company, you would actually benefit from having people of all kinds of backgrounds, someone who's 20 years old to someone who's in their 50's or 60's. They must have different sets of knowledge and experiences that could benefit the grander picture. LATOYA: You would think so, you think companies would think that way but unfortunately, a lot of people don't. For starters, if you are a person who isn't interested in working with women or people of color, you're going to look at a careers page in the opposite way that I would. You don't want to work with people over the age of 35, people with brown skin, people who identifies varying genders. Those careers pages are going to attract you. STEPHANIE: Right. LATOYA: Which is unfortunate but that's just the world that we live in right now, and I have had people say this to me as someone who is a woman and someone who is a person of color. But a lot of companies, unfortunately, once they have a base of all straight cisgendered males, for them it becomes a liability to bring in women or people that live at other intersections because they have to worry about things like the woman getting hit on because she's the only woman that these 30 or 40 men can look at all day which is ridiculous, I think. But at this point in time, sometimes they just say it's a culture fit thing when really this is a law-suing happen thing. BRANDON: I saw this rag regressive 1940's thing about a woman in the workplace. [Laughter] BRANDON: And it's both hilarious and really sad because that actually sort of regressive feeling has just kind of morphed into that law suit type of thing. It's the same exact thing of just like breaking that sort of mono-culture and people are fearful of it because they don't know what the consequences are going to be. That cost-benefit calculation doesn't happen because a lot of people in tech haven't experienced what a diverse workplace is and does and the benefits of bringing people from different backgrounds would care about different things. And so, I'm curious. We kind of talked a little bit and one of the things I want to ask you about we already kind of covered is why people don't do that. Why do people continue doing that if it's not that productive? I'm curious to see if there are things that you've seen companies do like what attracted you to Big Cartel and other companies that would be able to bring some people from different backgrounds? What are the things that companies do currently or you'd like to see them do that would make it more attractive and more inclusive? LATOYA: I think one thing right off the bat that I noticed about Big Cartel and one thing that I noticed about many companies in tech that I'm really excited about is that they put people first. And I think that when you operate from that standpoint, you're not going to have problems that come with creating a diverse or inclusive workspace. You're not going to have women wanting to leave because you're treating them like human beings. So, that's first and foremost. I think some companies really care about the people that work for them. They really care about their client base, their user base. So, for me personally, I always recommend that if people aren't happy at their current situations and they want to find something more inclusive, look for companies that put people first. That's the first thing. I think the benefits that they offer and the way that they talk about their benefits are really important. I have no intention of being a mother; there are lots of great mothers out there and it's a lot of work in the world's best [inaudible] in my mind, anyway. I also wouldn't ever interview with a company that didn't have a good maternity leave policy. It's one of the things that I look for upfront. So, even just putting your maternity leave policy and paternity leave, if you have it, on your careers page can be a really big seller. I think starting early on, once you have your core team in place, if you haven't already had women or people of color or someone who isn't like you, this may be a good time to stop and think about why that is and what you can do to pull in diverse candidates. And there's also reaching out to communities that do have them, like SheNomads is one example of many communities that exists. There are also bigger more established communities like Girl Develop It, for example. Reach out with them, host a couple of meet-ups at your space, if you have it. If you don't, figure out a way to work with them. BRANDON: Right. So you're saying if you make it a top-of-mind goal, you will find ways to reach out because there are people out there looking. LATOYA: Yeah. BRANDON: But they may just not be in your immediate vicinity. In my experience, that's the actual problem. The problem is that it's not in my proximity to see and know these people that are involved in these communities. And so, connecting into those communities naturally, organically, and through effort is a way that I've actually seen people grow that. That's how you can kind of go from saying 'I care about diversity' to actually growing a diverse and inclusive workplace. LATOYA: Absolutely. I think another thing that folks that can do is have a remote position. You get a remote culture going if it's something that you're comfortable with. I understand not everyone wants to work from home and not every company will do well having remote positions open. But if it's something you're open to, that is a great way to do it because you might be living in an area where all the people are like you. So, you're going to have trouble getting someone to drive in a car. So, there are two other ways that I was thinking that people can attract diverse candidates. I'm actually launching a Job Board for SheNomads. I got to the point -- it's actually once the article came out on Medium that a lot of people were emailing me wanting to know how they could find jobs and a lot of companies were emailing me wondering how they could find diverse candidates and like what they could do to be more welcoming to other communities. So I said, "You know what I'm going to do? I'm putting together a job board." BRANDON: So where is the job board? LATOYA: The job board you can find on SheNomads.com. BRANDON: Cool. There are a lot of things – and this is really what I wanted to drill into was the blog post helps kind of point at the problem, "Hey, your careers page is sending messages that are actively turning away people that you want working for you. You say you want a diverse workplace but it's so far down the list of your actual priorities, or at least whoever it is that's running your careers page, that you're actively turning people away that you don't even realize you're losing people through that funnel that are bouncing out before you even have a chance to meet them and know them and know what they can bring to you." And so, that's actually a really big deal and a big problem in tech. I also appreciate your jumping in and that we have some sort of concrete things a person can do. Get involved with GDI or with Women Who Code. We had a thing here in Austin and I ran the local Ember meet-up for several years and it's a lot of work and it was really challenging. One thing we noticed was that there were only two or so women, on the average, at a meet-up of 30 people. And I recognized it as a problem but I didn't feel like there was anything I could do about it. And so, I handed the reins of running the meet-up over to a group of people that included the women. And sure enough, the women were like, "You know, we might be able to do something about this." Stephanie actually got involved with this, and they held an event for women and it's changed the makeup of that meet-up significantly. You can have an impact on this stuff. You just, sometimes, have to step out and think differently about the problem. LATOYA: Yes. BRANDON: I'd like to shift gears a little bit and talk about – you're involved in so much stuff. Running SheNomads, running retreats, you have a full-time job, you're traveling a bunch and balancing all of that stuff, I have to imagine, is really tricky. And I'd like to dive into that and have you kind of talk about like do you ever get burned out? Do you feel like giving up? What do you do to manage that? Do you have preventative maintenance that you do? What is it that you do to try to keep all that together? LATOYA: One thing that I find very interesting is you asked me specifically about burn out because burn out is something that I recently experienced. I am not good at knowing that I'm setting myself up for burn out. I'm not even good at knowing that I'm in burn out until I'm there. For the most part, I think that I've gotten better as my tech career has evolved. So for example, when I first started, I was working a lot of hours. There were days when I had to be in the office at 7 in the morning because I was mentoring people who were in London even though I was in Chicago. So for me, there is no more of that. [Laughs] One thing that I really like about working at Big Cartel is that most of the team is on the West Coast, so I get to do things like sleep and if I want, I can go to the gym, I can run all of my errands before I even start my work days. Once I start my work day, all of I have to do is worry about work as opposed to waking up and not having time to do nice things for myself, not having time to run errands and I'm starting my day having all of these stuff on my mind. For me personally, working remotely allowed me to become a more balanced person as well. I don't like riding trains with crowded people. When I was working downtown, it would take me an hour to get to work every morning. If I have to go downtown in the middle of the day, it might take me like 20 minutes or half an hour just because there's not as many people running around. Also for me, I didn't particularly like going to the grocery store. At times, you can go to the grocery store if you have a 9 to 5 job. If I realize that I don't have anything for dinner, I can just tell my pair, "Hey, do you mind if we take a 20 minute break?" And then I can go to the grocery store and get whatever I want, knowing that I'm the only person at the grocery store. I mean, it gets a little bit to my inner introvert but I know myself well enough. Let's see here. Practicing yoga is something that's very important to me and taking walks as breaks is something that's very important to me. I think when you love what you do, it can be hard to take breaks. So, it's always nice to be pair programming with someone and have them say, "We haven't taken a break in a while." I find that when I work on my own, I don't take as many breaks. When I take a break, I pop my yoga mats always open. So, I'll do yoga for 10 minutes or take a nice little walk outside or just get away from my computer for a while. BRANDON: It sounds like working remotely kind of gave you the flexibility you need to implement your own self-care regimen, the one that works for you. LATOYA: Yes. And I would not have even thought to implement this regimen had it have not been for working remote, I think, because it's not as easy. It's bad enough being one woman amongst a hundred men but then you're that cliché woman with a pink yoga mat walking around the office trying to find some space. BRANDON: I actually did use to work in an office that had a yoga studio on site. LATOYA: That is so nice. BRANDON: Things like that do exist but I have to imagine that's about as uncommon as it gets. LATOYA: Absolutely. I had the idea of starting a meet up which I started in Chicago called Women in Tech Wellness. Basically, we get together and we practice yoga for an hour. And then after that, there's a little bit of networking. Luckily for me, Braintree is sponsoring the event which is so great because it allows us to keep it free. I think having free and low cost events in tech are really important because there are people that are trying to figure out how to break into this and if they have to spend $10 or $15 to go to a meet-up, they're not going to go. Also, it's nice to go to a meet-up where you might be stressed when you show up because you just left work but you know in an hour, you're going to be feeling really good. Plus the Braintree office in Chicago has this amazing atrium where we do the yoga. So when you're lying on your mat, you're looking straight up into the sky and you see plants and you see all of these amazing stuff. It's just a great place to do yoga. So, thank you Braintree. [Laughs] BRANDON: I think that's really cool. I have one question, though. Do you ever have the ironic circumstance of the things that you create to help you and other people find balance wind up actually contributing to your overall sense of being overwhelmed? LATOYA: Oh, absolutely. There's only 24 hours in a day and right now, I am all of SheNomads at SheNomads party of one. [Laughs] I would love to get to the point where I can afford to hire a couple of people just to help even if it's part time. So, absolutely. Doing a podcast is a lot of work, booking guests is a lot of work. I would say that organizing the meet-ups is fairly easy just because I'm lucky enough to have people that wanted to step in and help there. But yeah, I think having a few things on your plate other than work is always going to contribute to a little bit of imbalance. BRANDON: Stepping back and looking at the arc, you haven't been in tech for a million years but you've been in it long enough to start drawing some themes through it. If you look at your career like where it's been and approximately where it's going, are you starting to feel like there are some themes to the stuff that you do and some themes that are kind of common threads in it? LATOYA: I can tell you some themes in common threads. Yes, for my personal tech career. For me, I really care about code and I really care about people, so I'm glad that I was able to early on learn clean code and learn how to refactor and learn test-driven developments. First job I had at 8th Light taught me all those things. I think for me, that is a theme that will be throughout my career. Test-driven development, who knows, 10 years from now there could be a better way to write clean code, but for now, it's the best way I know how. And finding community, even though I am absolutely happy with where I'm working. Big Cartel does a great job at creating an inclusive space, but still I like being a part of a tech community. I know that's not for everyone but it's something that I think I will continue to do. BRANDON: From just my casual place of observation of seeing what you do, definitely finding and creating the communities that you want to see exist certainly seems to be a theme. And I think it's really cool that you do the SheNomads stuff. I think it's really cool that you run that podcast. For a person that hasn't been doing this for 15 years, I think it's really awesome that you found a community early on. It's something that certainly has accelerated my journey as a developer. I haven't been a developer forever, either. So I appreciate seeing you do all that stuff. I think it's a really good example for other people that getting involved can benefit everybody and you can have an impact in ways that are sort of uniquely yours. I mean, certainly the stuff that you do is sort of unique to you and your perspective and I think that's really cool because it winds up benefiting a lot of other people. LATOYA: Thank you. I wish I would have said that as my answer. [Laughter] BRANDON: It's sometimes easier to see from the outside in, even as a casual observer. STEPHANIE: I did want to make a comment about balance. That's something that's very important for me. It's something that I've been trying to implement in my daily life. I recently started going to the gym and I try to work out either early in the morning or in the afternoon after work. Sometimes, I realize that even when you try to do something, you still don't accomplish what you're trying to do like keeping that balance. I started this about two months ago. And last week, I realized that I was not in balance at all. I spent Monday, Tuesday, and Wednesday really focused on trying to learn certain things. I was going over Clojure actions and trying to destructure and get rid of components and change the actions from where they originally were. I'm a junior developer, so I feel like if you are an apprentice, it's really hard to not be in this state of overdrive of like you really want to accomplish things. You really want to learn as much as you can and just be a sponge and absorb everything. But if you're spending eight hours, give or take, going over these things, at the end of the day, I just feel sometimes my brain is just like it's done. I can't even formulate sentences. I can't function. I just get home and I want to keep working on this but I just literally can't. I think on Wednesday, I just had a horrible headache and I got home and I was like, "I'm just going to lay down for a little bit." Laying down turned into a 3-hour nap and I will go [inaudible] 8:00 and I felt so much better. And then on Thursday, when I came in, everything just made sense to me. All of the problems and everything that didn't make sense before made sense. And I hadn't reviewed, I hadn't done anything, all I did was I got a nap. But I feel like there's definitely this struggle when you are wanting to achieve and prove yourself and to get to this next level, it's really important to try to remind yourself to give yourself breaks even during the work day because if you can't continue, if you're at this point of mental fatigue, it doesn't matter how much longer you're sitting in front of the computer, trying to read about it in the documentation, it's just not going to do anything. So, I wanted to ask if perhaps you ever had those moments of frustration especially in the beginning as you're trying to learn all of these difficult concepts. LATOYA: For me, yes. I love taking naps. I consider myself a professional. Luckily, Big Cartel is very flexible, so if I feel like I need a nap instead of lunch, I might take a 2-hour lunch break because I'm taking a nap. And for me, there's just something about resetting my brain through sleep that allows me to be more productive in a way that's just walking away from my computer and doing something else. Also, I spent two months this summer working abroad. So, I worked from the UK, Israel, Spain, Portugal, and Norway. So I worked abroad for two months and because of the time difference, I would wake up in the morning and work for three hours and then I would have all day to do whatever I wanted which primarily meant being a tourist in some of the most beautiful places, I've been very lucky to place my eyes upon. And then I would do another three or four hours pair programming at night and I think that I was able to get more done and I had a greater sense of clarity because I had such a big break. I was only working for three or four hours and that's it and you're taking three or four break because no one else is awake yet. It's almost as if you're working two separate days. I think I would like to go back sometime soon, actually, and do that again because I'm not getting up at three in the morning here to work for three hours and then take a break. STEPHANIE: Definitely. And that makes sense. It makes sense to stimulate your brain in a different way. Looking at the beautiful buildings and reading about the history and walking around and being outside. Even just a 30-minute break can just be just so wonderful and be like a refresher for the brain. Nice. Before we go, I wanted to ask if you have any shout outs. LATOYA: I do. I will give you three resources that I tell everyone who's a junior developer, where they should look in to break into tech and what they should look for. Number one, I kind of already mentioned a little bit, but Sandi Metz has a great book called POODR. She also has a POODR workshop. If you can go to that, I highly recommend it. I know that she offers scholarships for that as well, so you can apply. Number two would Katrina Owens' Exercism. It's a great way to learn how to code. It's also an open-source project. So not only can you go to exercism.io and pick a programming language and work with people on teams to learn how to code. But if you want to contribute to the open-source project, you can. And the third thing would be the CodeNewbie twitter chat. I love it. I really need to get my stuff together and be there on Wednesday nights. I believe it's Wednesday at 8 or 9 Central – don't quote me on that. But those are the big three things I like to shout out, even though you only asked for one. [Laughs] STEPHANIE: That's perfectly fine. I was going to ask you anyway if there were any open-source projects or programs that you are involved in. LATOYA: Yes, I have been involved in exercism in the past. I think I might have mentioned this, but I tried doing open-source project with SheNomads but I would need someone who's like at least a mid-level developer to come in and help out all of the juniors and the people that are trying to get started to learn how to code because my time is very thin these days and I'm trying to maintain some level of balance. STEPHANIE: Right. And that's a huge challenge too. So, lots of time management and just time is a resource itself. BRANDON: There are a lot of mid-level developers out there that are looking for, "Hey, how can I contribute to open-source?" So, it sounds like you have a project that if people out there are looking for a way to contribute to something meaningful, then you have stuff that you could certainly use help on. LATOYA: Absolutely. If you want to contribute, you can email me or tweet me, find me on Facebook, do whatever, and I will happily add you as a contributor to the project. BRANDON: That actually is the last question I want to ask. How do people get a hold of you to volunteer for this or ask additional questions or find out more about the retreat? LATOYA: The three best ways are number one, you can go to SheNomads.com and if you wanted to find out about the retreat or the job board, there are contact forms there. Number two, I am always on Twitter. You can tweet me at either accounts. My personal account is @HashtagLaToya and then I have a SheNomads account, so it's @SheNomads for that. And then the third way is email. My email is LaToya@SheNomads.com and I always am up for answering any questions you may have. BRANDON: Awesome. LaToya, thank you so much for coming. I really appreciate you sharing your experiences with us and you've certainly learned some unique things. I think your take on self-care actually is really sharp and something that people don't think were talked about enough. And it probably [inaudible] as a developer in lot of ways and I think people can learn a lot from that. I wanted to thank everybody else that's listening to this. I'm Brandon Hays. I'm on Twitter also @tehviking. We are @thefrontside on Twitter. And Stephanie, you are also on Twitter, is that right? STEPHANIE: Of course. I'm Stephanie Riera and I'm @stefriera. And thank you so much, LaToya. It was a pleasure talking to you. BRANDON: Absolutely. Thanks everybody and thank you, LaToya. We will see you all next time.

Practical Object OO (and Cat!) Design with Sandi Metz!