The Bike Shed

thoughtbot had an in-person Summit in the UK! Joël recalls highlights. Stephanie is loving daily sync meetings on a new project. The idea of deleting code has been swimming around in Stephanie's brain recently because she's been feeling nervous about it. Together, Joël and Stephanie explore ways of gaining confidence to delete code while feeling good about it. This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Thoughtbot summit video Gather Town Sustainable Rails episode Chelsea Troy on deleting features Unused elm-review-unused 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 today, 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: I just got back from a few days in the UK, where thoughtbot has been having an in-person Summit, where we've brought people from all over the company together to spend a few days just spending time with each other, getting to know each other, getting to connect in person. STEPHANIE: That sounds like it was a lot of fun. I've been hearing really great things about it from folks who've come back. Unfortunately, I couldn't make it this year. I got sick a little bit beforehand and then ended up not being able to go. But it sounds like it was a lot of fun just to get together, especially since we're now a remote company. JOËL: Yeah, I'm really sorry you weren't able to make it there. It would have been amazing to do a Bike Shed co-hosts get-together. STEPHANIE: I know. In the same room, maybe even record. What a concept. [laughs] JOËL: So thoughtbot is a fully remote company, and so that means that getting a chance to have people to come together and build those in-person connections that you don't get, I think, is incredibly valuable. I was really excited to meet both the people that I work with and that I see on my screen every day and people who I don't talk to as often because they're working on different teams or different departments even. STEPHANIE: What was one highlight of the time you spent together? JOËL: I'll give a couple of highlights, one I think is more on the activity side. We went bouldering as a group. This was a really popular activity. We were trying to sign up people for it, and it was so popular we had to make two groups because there were too many people who were interested. And it was really fun. There are people with a whole variety of skill levels. Some people, it was their first time, some people had been doing it for a while. And just getting together and solving problems was a lot of fun. STEPHANIE: Yes, I saw that. That was one of the things I was really looking forward to doing when I was still thinking that I was going to go. And it's cool that it had opportunities for both beginners and people who have been doing it before, which I think, if I recall correctly, Joël, you are a boulderer yourself back home. So that's pretty neat that you were able to, yeah, I don't know, maybe share some of that experience IRL too. JOËL: Yeah, yeah, I think it's great because people were able to help each other. Sometimes you have a different perspective down on the ground than you do up on the wall. And then, in my case, because I've done it a lot, I know a little bit of actual climbing technique. And so I can give some tips on, like, oh, if you're stuck and you don't know how to get past a particular point, or you don't know how to start a particular climb, or your arms are getting tired halfway up, here's maybe a small change you can make that would make things easier for you. STEPHANIE: Honestly, that also sounds like a really good metaphor for pair programming, [laughs] like, looking at things from different perspectives, you know, someone who's on the wall? I don't know what the lingo is. But it's the equivalent of someone driving in coding, the navigator having a little more perspective and being able to point out things that they might not see that's right in front of them. JOËL: I love that metaphor. Now I'm going to think of that both when I pair and the next time I climb. STEPHANIE: I love it. JOËL: I think climbing, when I do it, it's always more fun with a friend, specifically for what you were saying. I climb alone sometimes, but as much as possible, I'll reach out to another friend who climbs and say, "Hey, let's climb together." And then we can alternate on the same route even. STEPHANIE: That's cool. I didn't realize that it could be such a social activity. JOËL: It is very much a social activity, and I think that's part of the fun of it. It's challenging physically but also mentally because it's a puzzle that you solve. But then also, it's a thing that you do with friends. I think another aspect that was a highlight for me was getting a chance to connect with people from other teams, other departments within thoughtbot. I think one thing that was really nice when we were located in an office is that over lunch, or just at the water cooler, or whatever, you would connect with people who were in other teams and who were in different departments. So I might talk to people in People Ops, or in marketing, in operations just sort of in the natural course of the day in a way that I think I don't do quite as much of now that we're more remote. And I tend to talk more with other developers and designers on my team. So I think that was really great to connect with people from other teams and other departments within the company. STEPHANIE: Yeah, I know what you mean. I think I really miss the spontaneous, organic social interaction that you get from working in an office. And I think we've maybe talked about remote work on the podcast before, or previous co-hosts Steph and Chris have also talked about remote work. But it definitely requires a lot more intention to manifest those connections that otherwise would have been a little more organic in person. And so, while you all were at an in-person summit in the UK, there was also a virtual summit hosted for folks who weren't able to travel this time around, and I really appreciated that. I got to spend a day just connecting with other people in Gather Town, which is a web app that's like a virtual space where you have little avatars, and you can run around and meet up with people into virtual meeting rooms on this map. [laughs] I'm not really sure I'm describing it well, but it's very cute. It is almost like a little video game. It's like a cross between a video game and video conferencing [chuckles] software. But yeah, I think I just really appreciated how inclusive thoughtbot has been doing remote work where, like, yes, we really value these in-person gatherings, and we understand that there is a bit of magic that comes from that, but also making sure that no one's left out. And at the end of the day, not everyone can make it, but we were still able to hang out and socialize amongst ourselves in a different way. JOËL: Agreed. I think that inclusivity is part of what makes thoughtbot such a great place to work at. STEPHANIE: Speaking of inclusivity, I mentioned a few weeks ago that I joined a new project recently and had been going through the onboarding and hopping into all these new meetings. One thing that I've really enjoyed about this new client team that I'm on is that in their daily sync meetings, we all share what we're working on. But we also all share something that's new to us, which is a little bit meta because we do that on this podcast. [laughs] But each person just shares maybe something they learned at work but also usually something just totally not work related like a new show that they're watching. There's another person on my team who learns a lot of things from YouTube videos. And so he's always telling us about the new thing he learned about, I don't know, like mushrooms or whatever, or AI [laughs] through YouTube. And yeah, someone else might show a sweater that they just knit themselves. And it's been a very easy way to get to know people, especially when you're meeting a whole new team. And yeah, I've been enjoying it a lot. It's made me feel very welcome and like I know them as people outside of work. JOËL: I love that. Yeah, they're more than just people you're shipping code with. You're able to build that connection. And it sounds like that helps smooth the...maybe we can say the social aspect of onboarding. Because when you onboard onto a project, you're not just onboarding onto a series of codebases and tools; you're also onboarding onto a team, and you need to get to know people and build relationships. STEPHANIE: Yeah, absolutely. 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 you've been...is it two weeks in a new codebase? Have you gone and deleted any code yet? STEPHANIE: I wish. I am glad you asked this question because this has been a topic that has been swimming around in my head a little bit lately because this new client codebase it's very big and it's quite old. Like, I've been seeing code from 10 years ago. And it's been a really challenging codebase to get onboarded into, actually, because there's so much stuff. In fact, I recently learned that some of their model specs are so big that they have been split out into up to seven different files to cover specs for one model. [laughs] So that has been a lot to grapple with. And I think in my journeys working on a starter ticket, I've just stumbled upon stuff that is very confusing. And then I might follow that thread only to realize that, like, oh, this method that I spent 20 minutes trying to grok turns out it's not actually used anywhere. JOËL: That's a lot of dead code. STEPHANIE: It is a lot of dead code, but I am also not quite feeling confident enough to delete it because I'm new, because I have no idea what consequences that might have. So, yeah, the idea of deleting code has just kind of been swimming around in here because ideally, we would be able to, but, for some reason, I don't know, at least for me, I feel very nervous about it. So it hasn't been something that I've reached for. JOËL: That's a great question because I think in maybe Ruby, in particular, it's not always obvious if code is being used or not. When you do find yourself deleting code, how do you gain the confidence that it was safe to delete that? STEPHANIE: Yeah, that's a good question. In the past, when I've done it successfully, I'll probably post a Slack message or something and being like, hey, I noticed this code is not being used anywhere, or I'd like to delete it because why, like, I don't know, because it's been misleading me because it's just not providing any value. And then kind of give it like a day or two, and if no one speaks up about it, then I will usually go ahead. And obviously, get some code review, hopefully, get some other eyes on it just to make sure that whatever assumptions I made were valid, and then go for it. And then just watch [laughs] the deployment afterwards and make sure that there are no new errors, you know, no new complaints or anything like that. And, yeah, I think that has been my process, and I've definitely found success doing that. But I have also experienced a bad result [laughs] from doing that where one time, on my last client project, we were refactoring the signup flow. And we realized that after you signed up, you were redirected to this blank page for like 10 seconds or something. It was completely empty. There was nothing on it except a spinner, I think. [laughs] And then it would then redirect you to the dashboard of the app. And we were like, oh, we can definitely delete this. We have no idea what this is doing. We don't want to try to refactor this as part of the effort that we were doing. And so we deleted it, only to find out later from the marketing team that they had been using that page for something Google Analytics related, and we had to revert that change. And it was a real bummer because I think when we removed it, we felt good about that. We were like, oh yes, deleting code, awesome. And then having to bring it back without a clear plan of how to actually fix the problem that we were trying to solve was a bit of a bummer. JOËL: So, as programmers, we're hired to write code. Why does it feel so good to do the opposite of that, to delete code? STEPHANIE: That's a great question. I actually want to know what you think about this, but before that, I wanted to plug this Slack channel that we have at thoughtbot called Dead Code Society, where people can post their PR diffs showing more red than green, so more lines removed than lines added. And I have been really enjoying that Slack channel. It's very delightful. [laughs] But, Joël, do you have any thoughts about why it feels so good to delete code? JOËL: There are probably a few different reasons. Especially when it's not your own code, you're often not attached to it. There's often, I think, the sense when you go into an existing codebase you're just like, oh, everything's just bad, and I don't understand it. And those other coders who wrote this didn't know how to do their job and kind of be the curmudgeon character. So it just kind of feels good to remove that and maybe rewrite it yourself. I would say that's not a good mindset to go in for deleting code. I think there are positive ways where it is actually a good thing. STEPHANIE: That's fair. Just removing code because you would write it differently is not necessarily a net positive. [laughs] JOËL: But I think...so when I initially asked the question, I said, "We're hired to write code." And I think that's a bit of a false assumption built into the question. We're not hired to write code. We're hired to solve problems, to build solutions. And as much as code can be an asset in solving problems, it's also a liability. And code has varying maintenance costs that are typically not low. They vary from expensive to very expensive. And so any chance we get to remove some of that, we're removing some of the carrying costs, to use a term that we discussed a few episodes back when we talked about sustainable Rails. STEPHANIE: Yeah, absolutely. One thing that I remember you sharing about the client project that we're both on in the past is they have a very cumbersome test suite. And in some situations, you have wanted to advocate for deleting some of those tests. JOËL: Deleting tests is a really, I think, spicy take because you're trying to get better test coverage. And if your test coverage isn't great, you don't want to lose any of that. So there's definitely a loss aversion there, and we might need it later. At the same time, tests have a cost, cost to run, cost to maintain. And if they're not providing a lot of value, then the cost of keeping them around might be higher than any kind of benefit they're giving you. And I think a classic case of this is tests that have either been marked pending in the codebase with an exit or something like that or that have been marked in your CI server as muted; just ignore failures from this test. Because now you're still having to maintain, still having to execute these tests. They're costing you time, but they're giving you zero benefit. And they're just taking up space in your codebase, making it harder to read. So if you can't get these tests back into the point where they're actually executing, and you're caring about the output, then you probably don't need those tests, and they can be removed. STEPHANIE: Yeah, that's fair. I'm thinking about the perspective of someone who does not want to delete those tests. I think in the past, I've seen it and even felt it myself as someone who probably wrote the tests, kind of hoping for some ideal world where I will finally have time to go back to that test. And I already put a lot of effort into trying to make it work, and I want to make it work. I want to have the value of that test. And it's kind of like a sunk cost fallacy a little bit where it's like, I already spent however much time on it that it must have some kind of value. Because just hearing that someone else wants to delete the test can kind of hurt a little bit. [laughs] And it's tough. I do think that it's easier for someone with an outside perspective to be like, "Hey, this test is costing more than the value that it's providing." But yeah, I can see why people might have a little bit of pushback JOËL: Sometimes, the value of a test is also in the journey rather than the destination. STEPHANIE: Yeah, that's a good point. JOËL: So if you're practicing TDD, maybe you use some tests to help you drive out some functionality, help you come up with a design that you want to do. But maybe once you've actually created the design, the test that helped you get there is not actually that useful. I've heard some people will do this by writing a lot of more system tests-like tests that are very integration-heavy, that have a lot of edge cases that you might not care to test at that level, at that granularity. And so they use those to help drive a little bit of the implementation and then remove them because they're not providing that much value relative to their cost anymore. STEPHANIE: I think that's a really good point. The tests that you write for implementation can have value to you as a developer, but that's different from those tests having value to the business when you commit them to a codebase and incorporate them as part of CI and a CI that everyone else has to run as well. So yeah, I think in that case, the context definitely matters. And hopefully, you can feel good about the value that it provided but then also have that eye towards, okay, what about the business, and what values does the business have? JOËL: Yeah, and accept that the test did the job that it was supposed to do. It got you to where you needed to be, and it completed its purpose. And now it's ready to move on. STEPHANIE: Another thing that I recently read about deleting code...and this was from Chelsea Troy. She advocates for regularly evaluating features in an app and deciding whether they're providing enough value to justify keeping around and maintaining for developers as well. And I thought that was really interesting because I don't know if that's something that I'd really considered before that sometimes an app might outgrow some features, or they might not be worth keeping around because of the problems or the maintenance costs that they carry into the future. JOËL: That's fascinating because I think you're taking the same analysis we were talking about tests and then kind of like bringing it up now to the product level. Because now, we're not just talking about deleting code; we're talking about deleting functionality that a product might have. STEPHANIE: I think the challenge there is that the effects of the carrying cost of a feature is not necessarily felt by the business stakeholders, or product folks, or people operating at a higher level, but it is felt by developers. If there's a bug that's come up from this old feature, and oh, I have never seen this feature before, and now I have to spend a day learning about what this thing is before I can fix the bug. It did feel like a radical idea that maybe developers can play a part in advocating for some features to be retired, that is, you know, maybe separate from how products thinks about those things. JOËL: I think in order to be able to make those decisions or really just to be part of those conversations, the dev side needs to be really integrated with the product team and with larger business objectives. And so then you can say, look, if we take a week of one developer's time to provide the support this feature needs and we have one customer paying $20 a month for it, that's not a good business prospect. Now, is this strategically an area that we're trying to grow? And so yeah, we're doing it for one customer, but we're hoping to get 100 by the end of the year, and then it will be worth it. Then yes, maybe we keep that feature around. If this is the thing, like, we experimented for a few weeks five years ago, and then it's just kind of hang around as a legacy thing that this one person knows about and uses, then maybe it's worth saying, look, this has a high business cost. It might be worth sunsetting that feature. But it's a conversation that everybody needs to be involved in. STEPHANIE: Yeah, yeah. I like the idea of it being something more proactive versus, I don't know, something that I think I've seen at other orgs and just in general as a person who uses digital products, like, a feature or a product, just kind of dying. And probably the organization just wasn't able to find a team to continue to support it, and it just kind of kept being this burden. And then, eventually, it just was something that they had to let go. But then, at that point, you had already spent all of that time, and effort, and energy into figuring out what to do with this thing. Whereas the approach that Chelsea is advocating for is more realistic, I think, about the fate of [laughs] software products and features. And as a developer, I would get that feeling of deleting [laughs] code that is so satisfying. And I'm just not burdened by having to deal with something that is not providing value, like cumbersome tests. [laughs] JOËL: I think it's always the fundamental thing that you have to go back to when you're talking about deleting code, or features, or anything is that sort of cost-benefit analysis. Does this thing provide us any value? And if so, does that value outweigh the cost of the work we need to do to maintain it? And in the case of dead code, well, it's probably providing zero value, but it's imposing a cost, and so we want to remove it. In the case of a test that is not muted or pending, then maybe it does provide some value. But if it's really brittle and constantly breaking, and it's costing us many hours of fixing time, then maybe it's not. If we can't find a way to fix it and make it more valuable because sometimes it's the other option, then it might be worth considering deleting it. Have you ever, on a codebase, taken some time to actually seek out code that could be deleted as opposed to just sort of stumbling onto it yourself? STEPHANIE: That's a good question. I think I have not just explored a codebase just looking for stuff to delete, but I have...maybe if you had something under a feature flag and you no longer needed the flag because it was released to everyone, you know, going back to delete it because you specifically made a ticket to make sure that you went back and cleaned that up. I do really appreciate the tracking of that work in that way and just making sure you're like, hey, I want to avoid a situation where this becomes dead code. And even just making a card for it is putting that intention out there. And hopefully, someone, if not yourself, we'll take that on because it's important. JOËL: Yeah, kind of proactively trying to make sure that the work that you've done doesn't become dead code, that it gets pruned at the appropriate moment. STEPHANIE: What about you? I'm curious from your perspective as an individual contributor when you are just moving through a codebase, and you see something suspiciously [laughs] looking like dead code what you do with it. JOËL: I often like to split out a small PR just to remove that if it's not too much work and it's semi-related to what I'm doing. I'd like to give a shout-out to two tools that can help detect or confirm that something is dead code. One is Unused, written by former thoughtboter Josh Clayton. It uses, I think, Ctags under the hood to track all the tokens in an app and then tries to determine are there tokens that are orphaned, that are isolated, and are not used? And it can then build you a report. And that can be good if you're doing a code audit of a codebase or if you're looking to confirm that a piece of code that you're working on might not be, like, is it actually used or not? Another one is elm-review-unused, which is a plugin for elm-review which is Elm's linter, kind of like RuboCop. And what's really nice there is because it reads the AST, and Elm functions don't have side effects. You know that if something is not reachable from the main function that, it is completely safe to remove. You've run the script, and it will delete a bunch of functions for you that are unused, and it's 100% safe. And it is very thorough. It finds all of the dead code and just removes it. It's practically just a...it's not a button because it's a script that you run but that you can automate to run on commit or whatever on the CI. But yeah, that's an amazing experience to just have it auto clean-up for you all the time. STEPHANIE: That's really cool. I like that a lot. I think that would be really nice to incorporate into your development workflow, like you said, that it's part of the linting system and just keeping things tidy. JOËL: Yeah, I think it's a little bit harder to have something that's quite as thorough for a Ruby or Rails app just because it's so dynamic, and we've got all this metaprogramming. But yeah, maybe this would be a thing where you would want to run something like Unused or some other linting tool every now and then to just check; hey, do we have any dead code that can be removed? STEPHANIE: Yeah, absolutely. And I think this is totally a little bit different because we're just talking about tools, but I'm also thinking of red flags on a team level where I have definitely asked in a Slack channel, "Hey, I've never seen this feature before. What does it do?" and just crickets. [laughs] And even the product folks that I'm working with, they're like, "I don't know. It predates me," that being a bit of a smell, [laughs] if you will, to reevaluate some of those things. And those flags can exist on many different levels. JOËL: That's always terrifying because you're like 80% sure that this is dead code, but there's like a 20% chance that this powers the core of the app, but nobody's touched it in 10 years. STEPHANIE: Yeah, it is very scary. [laughs] JOËL: Hopefully, your test suite is good enough that if you comment out that function and then you run your test suite, that it just all goes red, and you know that that's actually needed for something. STEPHANIE: Yeah, though I think sometimes you might remove a piece of dead code, and there are some issues afterwards, and you find out, and you just revert it, and it's fine. At the end of the day, there are a lot of safeguards in place, and we've all done it. And so I think normalizing it is also very important in that it's okay if sometimes you make a mistake there. JOËL: Stephanie is giving you permission to go and delete that code today. Ship it to production, and if something breaks, it's okay. STEPHANIE: [laughs] JOËL: You can revert it. Hopefully, your company is set up where reverting commits from production is a cheap and easy thing to do, and life goes on. So I'm curious, Stephanie, have you ever gone into GitHub and checked your stats on a project to see if you're more red than green or what that ratio is for you on a given project? STEPHANIE: I have. Actually, someone else did on my behalf because I was posting a lot in that Dead Code Society Slack channel. And they then shared a screenshot of my overall contributions to a repo, and it was more red than green. I felt pretty good about myself. [laughs] JOËL: All right. Net negative but in a positive kind of way. STEPHANIE: In a positive way. [laughter] JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. [laughs] 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: Byeeeeeeee!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Joël is joined by a very special guest, Sara Jackson, a fellow Software Developer at thoughtbot. A few episodes ago, Stephanie and Joël talked about "The Fundamentals" and how many of the fundamentals of web development line up with a Computer Science degree. Joël made a comment during that episode that his pick for the most underrated CS class that he thinks would benefit most devs is a class called "Discrete Math." Sara weighs in! This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Earlier Bike Shed Episode with Sara The Linux man-pages project Gravity Falls Elm types as sets Folgers ad Brilliant.org's discrete math course mayuko Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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 a special guest, Sara Jackson, who is a fellow developer here at thoughtbot. SARA: Hello. JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world? SARA: Actually, I recently picked up crocheting. JOËL: That's exciting. What is the first project that you've started working on? SARA: I don't know if you happen to be a fan of animation or cartoons, but I love "Gravity Falls." And there's a character, Mabel, who wears many sweaters. I'm working on a sweater. JOËL: Inspired by this character. SARA: Yes. It is a Herculean endeavor for my first crochet project, but we're in it now. JOËL: That does sound like jumping into it and picking a pretty hard project. Is that the way you typically approach new hobbies or new things, you just kind of jump in and pick up something challenging? SARA: Yeah. I definitely think that's a good description of how I approach hobbies. How about you? JOËL: I think I like to ease into things. I'm the kind of person who, if I pick up a video game, I will play the tutorial. SARA: It's so funny you say that because I'm definitely the type of person who also reads manuals. [chuckles] JOËL: [laughs] I'm sure you've probably, at this point, read many sections of the Unix manual. Longtime listeners might recognize you from a previous episode we did on the history of operating systems. SARA: Yes, I am an avid reader of the man pages. In fact, I wish every command-line tool had man pages or at least more detailed man pages. Reading man pages, reading technical documentation, really, I feel like goes right in line with things like needlework, knitting, crocheting. You're following a very technical pattern description of what you should be doing, how many stitches. It's almost algorithmic. JOËL: Do you feel like the fact that you've read a lot of man pages and now that you're getting into reading crochet patterns, do you feel like that's helped you maybe become a better technical writer when you write documentation? SARA: Definitely. Yes. [laughs] There's a common meme going around on the internet of how to make a peanut butter and jelly sandwich: open jar, put knife in jar. And you see somebody putting the knife in handle first because it wasn't specific enough. When you're looking at a crochet pattern, it needs to be written very explicitly, and in the same way, technical documentation needs to be like that too. It needs to be accessible for every audience, well, most audiences. JOËL: That's a big challenge because you want to give enough detail that, like you said, you don't accidentally use the wrong end of the knife to spread your peanut butter. But at the same time, if you give all the little details, you lose the forest for the trees. And people who know how to use a knife are going to struggle to use your documentation. SARA: That is true. That's why I think it is very valuable to do something that you recommend very often, especially when writing blog posts or call for papers is, defining the audience. Who's this for? JOËL: Yeah, knowing your audience is so important when it comes to any kind of media, even if it's a talk or an article, or I guess, a crochet pattern. SARA: Precisely. JOËL: Does the crochet world have sort of the concept of patterns aimed at beginners versus patterns aimed at a more advanced audience? SARA: I would definitely say that is the case. There are more advanced stitches and techniques that you would generally not see in a more beginner pattern. And in more advanced patterns, at least speaking from a knitting perspective...I'm pretty new to crocheting, but I've been knitting for a while. In knitting patterns, simpler techniques might not be described in such detail in a more advanced pattern. JOËL: So a couple of weeks ago, Stephanie and I were discussing the fundamentals, how much of the fundamentals of web development line up with a computer science degree. I had made this comment on that episode that my pick for most underrated CS class that I think would benefit most developers is a class called discrete math. SARA: I remember this class. It was a love-hate relationship. I am a big fan. JOËL: Would you describe yourself as a math person? SARA: I don't think so. No. JOËL: Because I know I hated math for the longest time. And I don't really find that math, in general, has been that helpful for software. There's kind of the stereotype that I'll sometimes hear from people when they find out that I write code for a living. They'll say things like, "Oh, you must be so good at math." And it's like, no, calculus was really hard for me, and I struggled and did not like it. SARA: I feel like that's a big reason why folks go into programming; the computer can do the math for you. JOËL: Right? It is a computer. It is a math machine. SARA: I mean, how many folks in computer-related fields got their start on a TI-83, programming in that thing? JOËL: A lot of people. Someday it might be fun to do an episode on the sort of common origin stories that you hear from people in the software industry, a lot of people programming a calculator, a lot of people I hear coming from Neopets. SARA: Yeah, Neopets and MySpace, editing the profile pages with CSS, HTML. JOËL: But that's an episode for another time. I think, in my experience, discrete math was not like all the other math that I did. It felt so practical, like, this is math for programmers is how I felt it was even though that's not how it's sold in university. What was your experience? SARA: My concept was very much like, this is logic. This is very hard. By hard, I mean firm way of looking at the world and defining the logic behind things when you think about proofs and set theory. JOËL: So we've been throwing around the term discrete math, and many of our listeners might not be familiar with what it is. If you had to describe discrete math to someone who is not familiar with it, what would you say? SARA: Math that's discrete. [laughter] Sorry, sorry. JOËL: What does discrete mean? SARA: When I think of discrete math, I think of logic, definitions, how data relates to each other, that sort of thing, as opposed to ones and zeros. JOËL: Yeah, discrete math; it felt like it was very much like a grab-bag class. It just involved so many different branches of math, and you kind of get a little bit of an intro of like ten different topics, all of which apply and are helpful when you're writing software. So I got a little intro to a couple of different forms of logic, propositional logic, and predicate logic. I got an intro to Boolean algebra. I got an intro to set theory, an intro to combinatorics, talked about recursive functions from a mathematical perspective, an intro to graph theory. Probably like a few more. There are like ten different things. You just got a little intro to them, spent a couple of weeks on each topic. But I felt like that was enough to give me a lot of value that I still reference on a daily basis in my work. SARA: Absolutely. One of the parts of discrete math that really stuck with me are computational models like Turing machines, pushdown automaton, finite-state machines. Learning about those, analyzing them really helped me break down algorithms and break down my code and look at, okay, for this specific input that I have for each of these variables, what are we doing? JOËL: So what does that look like in your daily work? You've got a complex card, and you see that it's a difficult feature to implement. And in your mind, you say, okay, let me try to describe this as a finite-state machine, and maybe you draw a diagram or something like that. SARA: Yeah, I will, actually. I'll draw a diagram, or I'll draw like a pseudocode out on paper. I'll think about all the different kinds of inputs that I would expect or not expect, which itself is not finite, but we try. And then what is the output that I would expect? What is the outcome that I would expect from, say, a user enters one, a user enters Sara, a user enters purple? What would the outcome be? Do I have those vectors captured in my code? And that also goes into TDD. JOËL: Do you feel like knowing about Turing machines or finite-state machines has made it easier for you to PDD? That's a connection I haven't heard before. SARA: Yeah, I think so because a Turing complete computational model is deterministic. That means that every possible path that could be got into from where you're at any path exists between the two. Sometimes it might mean rejection or an error, but the path has been defined. And thinking about that when it comes to tests, I feel like has been so helpful for me of like, I can't just think about the happy path. I can't just think about it's exactly what it needs to be. It's also what if it's not there? What if it doesn't exist? What if it's 0? What if it's empty? What if it's a different data structure? JOËL: That's really fascinating to me because I feel like I encountered some of these practical applications of it much later when I was learning about types and learning about Elm and sort of that community's approach to designing data structures. And one thing that they say a lot is that you should make impossible states impossible when you design a type, and the way that they tend to approach that is thinking of types as if they were sets. And so you think of a set of...the Boolean type is a set that has two elements because there are true and false. An enum might have, you know, if it's a three-element enum, that is, three elements. But then you start having things like records which are kind of like a hash in Ruby, which might have, let's say, two elements in them. And if it has a Boolean and an enum value, now those two multiply times each other. And so now you have two times three, six possible states. And maybe the problem you're trying to model only has five, and so you've sort of inadvertently added an extra state. They tend to talk about it a little bit more through the lens of sets and the lens of combinatorics, which are other elements of discrete math that give you mental models to deal with this. And so talking about all the different possibilities, that's combinatorics. Thinking of a type as a set and talking about its cardinality, that's set theory. So those were things that I would do when I was writing Elm programs on a daily basis, but I never made the connection back to finite-state machines. SARA: I feel like those marry so well together, those concepts. You can see combinatorics and set theory of objects and of where they can go. And that goes right into graph theory. JOËL: Oooh, I love me some graphs. SARA: [laughs] JOËL: Listeners of the show will know that I am a huge fan of dependency graphs and as a tool and as a model that can be applied to a lot of things, so thinking in terms of maybe the dependencies of your program like packages. But it can also be in terms of tasks to be done and so thinking in terms of a larger feature, breaking it down into smaller features, all of which depend on each other. And depending on how that dependency graph is structured, what order do you need to complete them in order to ship them independently? SARA: I love that. And it reminds me of graphs that represent state, like, finite-state machines sort of things where you can actually infer where you're going to end up based on where you are for certain types of graphs. And I feel like you can use that in programming. You can use that in proofs where you have the, okay, you've solved for the zero case. You've solved for the one case. Now let's solve for N+1 anytime in the future. This all feels very full circle in my mind. [chuckles] JOËL: I think that's very apt. And a really powerful thing that I've noticed is having different mental models to approach the same problem or different logical or analysis techniques to interact with the same problem. And so when you look at something through the lens of a finite-state machine, or through the lens of a graph, or through the lens of a set, or through the lens of combinatorics, you might be looking at the same problem. But by having different perspectives to look at it, you gain different insight and hopefully helps you come to a better solution. SARA: Absolutely. And I love that discrete math gives us those different tools to be better programmers. It's something that I enjoy. And I enjoyed the classes as much as they were extremely difficult. And I love the idea of being able to share those tools with other people that might not have learned about them. JOËL: You were talking about seeing things from different perspectives and how they kind of line up. There are some equivalences that I found were really fun between, let's say, sets and Boolean algebra, the operations that you can do. So things like ANDing two values is similar to doing an intersection on two sets, and ORing two values is similar to doing a union. Interestingly, we have preserved that in Ruby. Array has operators where you can combine arrays using set operations, and it has the single pipe, which we typically read as OR to union two arrays. I want to say it has a single AND that you can use. It's used to intersect two arrays. SARA: I actually used that sometime within the last year, I remember. JOËL: So, if you've ever wondered why those two particular operators to do set operations instead of a union method, now you know. SARA: I love set operations. I recently made an update to thoughtbot's internal tool hub, and I used set unions there. [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: If you had to sell a colleague on the value of discrete math, what would be the example that you would use? SARA: What if I told you that you would never have to wonder what the results might be in a given situation of true and false? JOËL: That's deep. Do you want to know all the secrets of the universe? SARA: Let me introduce to you truth tables. JOËL: Oh, I love a good truth table. Yes, such a simple tool, but it pays so much. SARA: Absolutely, especially in a world where we have unless as an operator. JOËL: Unless gets me so much in Ruby, especially when there are compound expressions. So you say do something unless condition one or condition two, and then I have to think, wait, when does this happen? SARA: I have to read it to myself in English, not this and not that. [chuckles] JOËL: So that's interesting because when you translated that in English, you changed the operator that's being used. SARA: I totally did. JOËL: Unless a condition or other condition. And your brain was smart enough to flip that; mine is not. SARA: [laughs] JOËL: But what's happening here is, and you would learn this in a discrete math class, De Morgan's Laws that say what happens when you negate compound conditions. And you have to negate each of the individual conditions and also flip all the operators, so all the ANDs turn into ORs and the ORs turn into ANDs. And so I always have to remember to do that in my mind when I see an unless or when I see someone negating a compound condition. So now, in my mind, every time I'm reviewing code on a pull request, and I see negating a compound condition, it's just a sort of red flag for there's quite possibly a bug here. And maybe leave a comment asking the author, "Did you really mean to do this?" And like you said, maybe even write out a truth table just so that myself I know that the correct behavior is happening. SARA: It is a good example of a code smell because if it's hard for you to understand or me to understand, sure, it made sense when it was written, but code is read more than it's written. It should be easy to read and understand. So it's definitely easy to introduce a bug at that point like you were saying, worth commenting on. JOËL: You log on to your machine at the beginning of the day, open up a PR, and you're just like, oh yes, I love the smell of De Morgan in the morning. SARA: [laughs] Nothing like De Morgan in your cup in the morning. JOËL: [laughs] Yes. Oh, now I really want to -- SARA: A DeMorgan in the morgen. [laughter] JOËL: Now I really want to see a spoof of that Folgers ad. SARA: [laughs] For some reason, the jingle is escaping me, but it's there. JOËL: It's an ad for a brand of American coffee. SARA: Yes, for those that were not in America during the '90s to see the commercial, [singing] the best part of waking up is De Morgan in your cup. JOËL: [chuckles] That was amazing. SARA: [laughs] Hopefully, we don't get a copyright strike for that. [laughter] JOËL: You know what? That is the sell for why you should learn discrete math. SARA: Yes. What are some other ways you find discrete math around in your day-to-day life? JOËL: I think the most practical part is working with Booleans because writing conditional code writing Boolean expressions is something that I do multiple times every day. And I think anybody who's done programming for any length of time gets some amount of intuition around working with Boolean expressions. Having spent a little bit of time studying them, you learn some patterns. You learn ways of working with them. And a common thing that I will often see in Ruby code is people will overuse the if expression when you could have used a Boolean expression instead. So I've seen things like if condition return true, else return false, which is just identity. I've also seen more complex things which will say, "If value one is true and value two is true, return true; otherwise, return false," or some fancy things with early returns that, in the end, are just reimplementing Boolean AND. So knowing about a little bit of basic Boolean algebra, being comfortable with combining things using AND and OR rather than just writing early returns, I think, gives a much richer toolkit and something that is much more scalable. And, of course, for those situations where there are complex conditional code, having truth tables as a tool in your back pocket is just absolutely invaluable. SARA: 100%. When those get so complex, definitely realizing it's worth maybe breaking up a chain of Boolean logic into separate mini-methods if you need to. There's nothing like seeing a whole bunch of stuff ANDed together that are only kind of related. [laughs] JOËL: There's a form of logic that you dig into as well called predicate logic, and there's a whole set of things you can do with it. But two things that stood out to me were these two operators that apply a condition to a whole set of values. And they either claim that a certain thing is true for at least one of the elements in a set or for every value in a set. And the interesting thing is that if you claim that something is true for all elements, in order to falsify that claim, you only need to find one counterexample. You don't need to check every item. If I can find one, and maybe it's the first item in this set that is wrong or that contradicts the logical statement that I'm trying to make, then I've immediately disproved your entire statement because you claimed that this was true for every element. SARA: And it's hard learning these sorts of fundamentals from computer science; it's hard to not apply that to real life and hear somebody using a statement, "Every this, all of that." I immediately come back with, "Well, some of them." [laughs] I'm that guy, yep. JOËL: The person at the end of a conference talk who puts up their hand and says, "So this is not really a question. It's more of a statement." SARA: [laughs] I found this one example. Yeah, I'm a stickler for specificity, for sure. Thanks, discrete math. JOËL: It definitely helped me be much more nuanced in the way that I speak. I tend to not speak in absolutes or superlatives because of that class. SARA: Yeah, I very frequently use the term a non-zero amount of times to describe, for example, there exists one in a set. JOËL: There's also another interesting aspect of this, which is when you see a chain of ANDs, so condition, and condition, and condition, and condition, and condition, you're effectively making the assertion that something is true for all elements or that all these conditions are true. Therefore, it only takes one for the whole thing to evaluate to false. And I want to say the fancy name for this is annihilation, where you can have a giant chain of conditions that are ANDed together, and they're all true, but if any single one of them is false, then the whole chain evaluates to false. SARA: And this is where you can get a little clever with the order in which you put those in your AND where you have the least heavy lifting checks first so that they fail first. Or if you have things that need to check for nil, check them after. Check the basic stuff first. Let it almost short circuit; let it fail fast, as they say. JOËL: Yeah, these are all performance tricks that I think, even if you don't have a discrete math background, you might have picked up. You know about short-circuiting. You know about trying the cheap checks first. And now you know a little bit of the theoretical background of why. SARA: [singing] Where do we go from here? [laughs] JOËL: So we have these sort of logical operators that will claim that something is true for all elements of a set or at least one element of a set, and those are kind of theoretical. They're useful if we're trying to set up a logical proposition. But these exist in code, in Ruby, as part of the enumerable module. Enumerable has two methods; they are any and all. And you can use those methods to claim that all items in an array will evaluate to true when the given block runs or that at least one evaluates to true for items in that array. SARA: What's the word where you're taking out some of a set? Slice but not slice. There's intersection [crosstalk 26:46] union, so not a set theory one, no. JOËL: Like getting the inverse? SARA: Maybe. I don't know. JOËL: I feel like there's a term for getting the inverse of a set. SARA: Not the inverse. JOËL: Because you can get the inverse of the intersection or something. SARA: Yeah. I think I'm just going to go along the lines of being able to slice out what you want with select and how you can then chain an enumerable on that. JOËL: Okay. Okay, I see. So you're making a connection from enumerable to set theory. SARA: Mm-hmm. JOËL: Excellent. SARA: Even if you don't necessarily want every item in your enumerable, your array, your hash, you can use things like select and reject to get a subset for a certain condition, and you can slice out based on a condition. And then you can then apply any or all to that. And so I want all of the even numbers, and now for all of these even numbers, such and such should be true for the set. JOËL: So now we've made a connection between enumerable and predicate logic. And we've also made a connection to set theory. SARA: It's coming full circle again. [laughs] Discrete math is everywhere. JOËL: So if you use the enumerable module in Ruby, which you should be (It's one of the best parts of the language.), you're doing discrete math every day, and you didn't know it. SARA: You're welcome. JOËL: So we've seen that a lot of us are interacting with elements of discrete math every day and that learning a little bit about it more formally can help us be a bit more mindful in how we code every day. It can give us the mental models to solve and analyze problems that we encounter daily. For those listeners who might want to dig a little bit more deeply into discrete math, do you have any resources there that you recommend? SARA: Well, not sponsored, but brilliant.org is a pretty good resource for things like math, computer science, for the very least. I'm sure it has other courses, but those are the ones that I've kind of looked at on some YouTubers' free trial. [chuckles] And I liked their approach to teaching, and I think it has got a low barrier to entry for learning these topics. I would definitely recommend that, so brilliant.org JOËL: It's funny you mentioned that they sponsor a lot of technology, science, and math YouTubers. So for those listeners who are interested in checking it out, maybe look up some YouTubers and see if they have a free sign-up code. SARA: Mayuko is a good YouTuber for that. I believe she gets sponsored by Brilliant occasionally. She's a software engineer out in California. JOËL: Clearly, we're not sponsored because we don't have a code to give out. SARA: [laughs] Sponsor us, Brilliant. JOËL: [laughs] Host at bikeshed.fm SARA: [laughs] JOËL: All right. Well, with that, shall we wrap up? SARA: Yeah, let's do. 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: Byeeeeeeee!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Stephanie is joined today by a very special guest, Andrea Goulet. Andrea founded Empathy In Tech as part of writing her book Empathy-Driven Software Development. She's also the founder of the community Legacy Code Rocks and the Chief Vision Officer of two companies: Corgibytes and Heartware (which provides financial support to keep Empathy In Tech running). Stephanie has strong opinions about the concept of "Makers and Menders" that the Corgibytes folks have written/spoken about, especially around those personas and gender stereotypes. Andrea joins Steph to evolve the conversation and add nuance to the discussion about legacy code/maintenance in our community. This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Makers and Menders from Corgibytes Empathy in Tech Legacy Code Rocks Forget Technical Debt — Here's How to Build Technical Wealth Equal Partners by Kate Mangino Sustainable Web Development Episode Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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., And today I'm joined by a very special guest, Andrea Goulet. Hi, Andrea. ANDREA: Hello, thanks for having me. STEPHANIE: So here on The Bike Shed, we like to start by sharing something new in our world. Could you tell us a bit about yourself and anything new going on for you? ANDREA: Yeah, so I have a background in strategic communications, and then kind of made a windy journey over to software. And so, for the past 13 years, I've been focused on modernizing legacy systems. And legacy is kind of a loose term; something you write today can be legacy. But essentially, we kind of help modernize any kind of software, any language, any platform, any framework. And so, over the course of doing that, in the work that I did before I came to software, I had a very technical understanding of empathy and communications and had just done a lot of that. And I just noticed how much that mattered in creating healthy and sustainable codebases. So now I'm kind of taking that experience, and I've got a book contract called "Empathy-Driven Software Development." So I've been working on just diving into a lot of the really deep research. So that's been kind of my focus for the past two years. And it's been really surprising because there were things that were positioned as truths, and then it's like, wait a second, neuroscience is completely upending everything. So it's been a fun learning journey. And I'm excited to share some of the things that I've learned over the years, especially [laughs] in the past two years with this book. So that is the new thing with me. And it's...I was telling you before it just feels like a constant new thing. Anybody who's written a book...it's the hardest thing I've ever done, so... [laughs] STEPHANIE: Yeah, that sounds tough but also kind of exciting because you're learning so many new things that then kind of shape how you view the world, it sounds like. ANDREA: Yeah. Yeah, it really does. And I think I really like diving into the details. And I think what started this was...my business partner, Scott, at the time, really embodied the stereotypical 2010 software developer down to the scruffy beard and dark-rimmed glasses. And what I found incredibly interesting was he had this belief of I'm good with machines, but I'm bad with people. And he just had this really deeply ingrained. On the flip side, I had this belief of, oh, I'm good with people, but I'm bad with machines. I'll never learn how to code. And I found that really interesting. And personally, I had to go through a journey because we went on...it was the first time either of us had ever been on a podcast. So this was about ten years ago. And at the end of the podcast, Scott was the only one on there. And he said, you know, the person asked about his origin story and about our company Corgibytes. And he was like, "Yeah, you know, Andrea is amazing. She's our non-technical founder." And by that time, I had been coding next to him for like three years. And I was like, why the heck would you call me non-technical? And I just felt this...what is it that I have to do to prove it to you? Do I have to actually go get a CS degree? I know I'm self-taught, but does that mean that I'm not good enough? What certificates do I need? Do I need to sit down next to you? Do I need to change my lifestyle? Do I need to look like you? So I was really upset [laughing] and just thinking through, how dare you? How dare you label me as non-technical? And Scott is very quiet and patient, great with people, I think. [laughs] And he listened and said, "I use the words that you use to describe yourself. When we were in a sales meeting right before that phone call, I paid attention to how you introduced yourself, and I pretty much used the same words. So when you call yourself technical, I will too." That shattered my world. It shattered my identity because then it put the responsibility of belonging on me. I couldn't blame other people for my not feeling like I didn't belong. That journey has just been so profound. This is what I see a lot of times with empathy is that we have these kinds of self-identities, but then we're afraid to open up and share. And we make these assumptions of other people, but, at the same time, there's real-world evidence. And so, how do we interpret that? In addition to this, Scott...like, part of the reason I called myself non-technical was because all of the people I saw who were like me or had my background, that's the word that was used to describe someone like me. And when I would go to a conference, you know, I have a feminine presentation. And this was ten years ago. My very first conference was 300 software developers, and there were probably about 295 men. And I was one of five women in the room. And because I looked so different and because I stood out, the first question that anybody would ask me, and this was about 30% to 40% of introductions, was, "Are you technical or non-technical?" And I had to choose between this binary. And I was like; I don't know. Am I technical? Like, is it a CEO that can code? I don't know. But then I have this background. And so I would just default to, "No, I guess I'm non-technical," because that's what felt safe because that's what they assumed. And I just didn't know, and I didn't realize that I was then building in this identity. And so then, as part of trying to create a warm and inclusive organization, we did one of the unconscious bias surveys from Harvard. And what astonished me when I did that myself was that I didn't have a whole lot of bias, like, there was some. But the most profound bias was against women in the workplace, and it stood out a big one. I was like, how is it that I can be someone who's a fierce advocate, but then that's my own bias against people like me? What the heck is going on? So really exploring all of this. And I think Scott and I have had so many different conversations over the years. We actually ended up getting married. And so we have a personal reason to figure a lot of this stuff out too. And when we start to have those conversations about who am I and what's important to me, then all of a sudden, we can start creating better code. We can start working together better as a team. We can start advocating for our needs. Other people know what we need ahead of time. And we're not operating out of defensiveness; we're operating out of collaboration and creativity. So the book and kind of everything is inspired by my background and my lived experience but then also seeing Scott and his struggles, too, because he had been told like, "You're a geek. Stay in the computers. Stay in the code. You're not allowed to talk to customers because you're bad at it," and flat out was told that. So how do we overcome these labels that people have put on us, and then we've made part of our own identity? And which ones are useful, and then which ones are not? Because sometimes labels can create a sense of community and affinity and so how do we know? And it's complicated, but the same thing, software is complicated. We can take skills like empathy and communication. We can look at them schematically and operationalize them when we look at them in kind of detail. So that's what I enjoy doing is looking under the hood and figuring out how does all this stuff work? So... [laughs] STEPHANIE: I did want to respond to a few things that I heard you say when you're talking about going to a conference and feeling very much in the minority. I went to my first RailsConf in 2022, my first RailsConf in person, and I was shocked at the gender imbalance. And I feel like every time I used the women's restroom; I was looking around and trying to make a connection with someone and have a bit of a kinship and be like, oh yes, you are here with me in this space. And then we would have a conversation and walk out together, and that felt very meaningful because the rest of the space, you know, I wasn't finding my people. And so I feel that very hard. I think this is also a good time to transition into the idea of makers and menders, especially because we have been talking about labels. So you all talked about this distinction between the different types of work in software development. So we have greenfield work, and that is writing code from scratch, making all the decisions about how to set up an application, exploring a whole new domain that hasn't been codified yet. And that is one type of work. But there's also mender-type work, which is working in existing applications, legacy code, refactoring, and dealing with the complexity of something that has stood the test of time but may or may not have gotten a lot of investment or care and bringing that codebase back to life if you will. And when I first heard about that distinction, I was like, yes, I'm a mender. This is what I like to do. But the more I thought about it, I started to also feel conflicted because I felt pain doing that work as well. ANDREA: Oh, interesting, yeah. STEPHANIE: Especially in the context of teams that I've been on when that work was not valued. And I was doing maintenance work and fixing bugs and either specifically being assigned to do that work or just doing it because I knew it needed to be done and no one else was doing it. And that had caused me a lot of frustration before because I would look around and be on a team with mostly White men and be like, why aren't they picking up any of this work as well? And so I was thinking about how I both felt very seen by the acknowledgment that this is work, and this is valid work, and it's important work, but also a little bit confused because I'm like, how did I get here? Did I pigeonhole myself into doing this work? Because the more I did it, the better I got at it, the more comfortable and, to whatever degree, enjoyed it. But at the same time, I'm not totally sure I was given the opportunity to do greenfield work earlier in my career. That could have changed where my interests lie. ANDREA: Yeah, it is. And it's funny that you mentioned this because I actually I'm a maker. But yeah, I created this community, and I'm known for this thing. And I had a very similar experience to how do I exist as someone who's different in this kind of community? And I think part of it is, you know, there's a great quote by George Box, who is a statistician, and he says, "All models are wrong; some are useful." And I think that's kind of the whole idea with the maker-mender is that it is a signal to be like, hey, if you like fixing stuff...because there is so much shame, like, that's what we were responding to. And Scott had the opposite problem of what you have experienced, where he was only allowed to work on greenfield work. They were like, "No, you're a good developer. So we want you working on features. We won't let you fix the bugs. We won't let you do the work that you like doing." And so that's why he wanted to create Corgibytes because he's like, "This work needs to be done." I am so personally passionate about this. And when we were having these conversations 13 years ago, I was talking to him about product/market fit and stuff like that. And I was like, "You like fixing software, and there's a lot of software out there to be fixed." I just was very, very confused as to why this kind of existed. And we had been told flat out, "You're never going to find anybody else like Scott. You're never going to be able to build a company around people who find a lot of joy in doing this work." And I think that this comes down to identity and kind of the way that Legacy Code Rocks was built too. A lot of the signaling that we put out there and the messaging and stuff really came from Scott's feeling of, like, I want to find more people like me. So being in the women's bathroom and like, how do I find more menders? Or how do I find people...because we were walking through a Barnes & Noble, and it was like a maker fest, maker everything. And he's like, "I don't have a community. There's nowhere for me to go to create these meaningful connections," exactly like you were saying. "I have maybe two people in my network." And then we were at a conference in 2015. We were at the large agile conference. And it was one of the first ones that I've been to that had a software craft track. And we met like 20 people who were really, like, I just saw Scott light up in a way that I hadn't seen him light up because he could geek out on this level that I hadn't seen him do before. And so when I asked, like, "How do you guys stay in touch afterwards?" And they're like, "Oh no, we don't. We don't know how to build a community." And it's like, well, okay, well, we can get that started. To your response of like, how do you operate when it is presented as a binary? And it's like, am I this, or am I this? This kind of gets down to the idea of identity-wise, is it a binary, or is it a spectrum? I tend to think of it kind of like an introvert-extrovert spectrum where it's like there is no wrong or right, and you can move in different places. And I think being able to explain the nuances of the modeling around how we came up with this messaging can get lost a lot of times. But I'm with you, like, how...and that's kind of something now where it's like, okay, maybe my role was to just start this conversation, but then everybody's having these ideas. But there are people who genuinely feel seen, you know. STEPHANIE: Yeah, that's really interesting because what I'm hearing is that when there's this dominant narrative of what a developer should be, and should be good at, and what they should do, it's kind of like what you were saying earlier about how hard it was for you to claim that identity yourself. People who feel differently aren't seen, and that's, I think, the problem. And I'm very, very interested in the gender aspect of it because one thing that I've noticed is that a lot of my female developer friends do do more of that mending work. So when you talk about feeling like there was no community out there, it just wasn't represented at the time, you know, a decade ago for sure. And still, even now, I think we're just starting to elevate those voices and that work. I wanted to share that at thoughtbot; we have different teams for different business verticals. And so we do have a rapid validation prototyping team. We do have a greenfield like MVP, V1 product team. And then we also have a team, Boost, the team that I'm on. That is more team augmentation, working with legacy code and existing systems. And it was not lost on me that Boost has the most women. [laughs] ANDREA: Yeah, because you have the concept of cognitive load and mental load. STEPHANIE: Yes. ANDREA: Women at home end up taking a lot more of this invisible labor that's behind the scenes. Like, you're picking the kids up from school, or you're doing the laundry, or all these things that are just behind the scenes. And this was actually something...so when Scott and I also got married, that's when I first became aware of this, and it was very similar. And it was, okay, how do I...because Scott and I, both in our business and in our personal partnership, we wanted it to be based on equity. And then also, like, how do I show up? And for me, the hardest thing with that was letting go of control where it's like, it has to be a certain way. It's hard for me to comment on the broader enterprise level because what I see at Corgibytes is we have gender parity. That's been pretty balanced over the course of our..., and we're a small boutique company, so it's different. But then, in the larger community of Legacy Code Rocks, it tends to be more male. There are actually fewer women in there. And I think, too, like there's this idea of testers and QA, like, I think that falls in there as well, and that's heavily dominant. And I think sometimes it's like, oh...and I think this kind of comes to the problem of it, like, it's the way that we think about the work in general. And this might be useful just to think about kind of the way that it came about was, you know, makers and menders was we were putting together [laughs] actually this talk for this conference that we went to. And my background in marketing, I was trying to wrap my brain around when is it appropriate for mending? And I had my marketing degree. It's like, oh, the product lifecycle. And Scott's retort was, "It needs to be a circle. We're agile, so it needs to be a circle." And I was like, this doesn't make any sense. Because look, if you have maturity and then you have it...oh my gosh, it'll link back to innovation, and then you can do new stuff. And so yeah, I think when we describe makers and menders, and this is true with any label, the idea in the broader model is that makers and menders aren't necessarily distinct, and your team should 1,000%...everyone should be contributing. And if you only have one person who's doing this work, you're at a detriment. That's not healthy for your codebase like; this should be baked in. And the mender is more of like, this is where I get my joy. It's more of an opt-in. But I think that your observation about the invisible labor and how that gets translated to maintenance work is accurate. A lot of times, like when Scott was describing his thing, it's like, there's the movie "Office Space." I might be dating myself. But there's this guy, Milton, and it's like, "Just go to the basement." He was told maintenance is where good software careers go to die. [laughs] And so over the years, it's like, how do we celebrate this and make it more part of the maker work? And it's similar to how introverts and extroverts...it's like, we all work together, and you need all of it. But there is an extrovert bias. And extroverts are seen more as, oh, they have leadership traits and stuff. But increasingly, we're starting to see, no, actually, that's not the only way that you can be effective. So I think it's hard. And I think it does come down to belonging. And I think that there are also different cultural impacts there. And it comes down to just a lot of different lived experiences. And I so appreciate you sharing your point of view. And I'm curious, what would help you feel more like you belong? Is it the work and the environment that you're in that's kind of contributing to this feeling? Or is it other things in general or? STEPHANIE: Okay, so I did want to address real quick what you were saying about mental load and household labor because I think I really only started thinking about this after I read a book called "Equal Partners" by Kate Mangino, where she talks about how to improve gender equality at home, and I loved that book so much. And I suddenly started to see it everywhere in life and obviously at work too. And that's kind of what really drove my thinking around this conversation, maintenance work being considered less skilled labor or things that get offloaded to someone else. I think that really frustrates me because I just don't believe that's true. And to get back to what you were asking about what would make me feel more seen or valued, I think it's systemic. But I also think that organizations can make change within their cultures around incentives especially. When you are only promoted if you do greenfield work and write thousands of lines of code, [laughs] that's what people will want to do. [laughs] And not even just promotions, but who gets a kudos in Slack? Or when do you get positive encouragement? As a consultant, I've worked on different client teams that had different values, and that was when I really struggled to be in those environments. I have a really strong memory of working on a greenfield project, but there was another male developer who was just cranking out features and doing all of this work and then demoing it to stakeholders. But then there was one feature that he had implemented but had faked the data. So he hadn't finished the backend part of it but just used fake data to demo the user interface to stakeholders. And then he moved on to something else. And I was like, wait; this isn't done. [laughs] But at that point, stakeholders thought it was done. They thought that it was complete. They gave him positive feedback for finishing it. And then I had to come in and be like, "This isn't done. Someone needs to work on this." And that person ended up being me. And that was really frustrating because I was doing that behind-the-scenes work, the under-the-hood work for something that had already been attributed to someone else. And yeah, I think about that a lot and what systems or what the environment was that led to that particular dynamic. 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! STEPHANIE: Do you have any advice for leaders who want to make sure there's more equity for people who like to do mending and legacy code work? ANDREA: Yeah, absolutely. I am so grateful for your questions and your perspective because this is not something that's talked about a lot, and it is so important. I wrote an article for First Round Review. This was in 2016 or 2017. And it was called "Forget Technical Debt — Here's How to Build Technical Wealth," and so if you want to link to it in the show notes. It's a really long article and that goes into some of the specifics around it, but it's meant for CEOs. It really is meant for CEOs. And I do think that you're right; some of it is that we have lionized this culture of making and the work that is more visible. And it's like, oh, okay, great, here's all the visual design stuff. That's fantastic, but then recognizing there's a lot of stuff that's behind the scenes too. So in terms of leaders, I think some of it is you have to think about long-term thinking instead of just the short-term. Don't just chase the new shiny. Also, you need to be really aware of what your return on investment is. Because the developers that are working on maintaining and making sure that your mission-critical systems don't fail those are the ones that have the highest value in your organization because if that system goes down, your company makes money. Greenfield work, yes, it's very...and I'm not downplaying greenfield work for sure. I'm definitely, [laughs] like, I love doing that stuff. I love doing the generating phase. And at the same time, if we only look towards kind of more the future bias...there's a great book that we were featured in called "The Innovation Delusion" that talks about this more in general. But if we only look at the visible work that's coming, then we forget what's important now. And so for leaders, if you're running a software company, know where your mission-critical systems are and recognize the importance of maintaining them. That's the very first step. The second step is to recognize the complexities of a situation, like, to think about things in terms of complex systems instead of complicated systems. And I'll describe the difference. So when I came to software, I had been working in the creative field, like in advertising, and branding, and copywriting, and all that. And we got inputs. We kind of ran it through this process, and then we delivered. And we did a demo and all of that stuff. It was when is the timeline? When is it done? Big air quotes. And we were pretty predictably able to deliver on our delivery day. Sometimes things would go wrong, but we kind of had a sense because we had done the same pattern over and over again. You don't get that in legacy code because the variables are so immense that you cannot predict in the same way. You have to adopt a new strategy for how do you measure effectiveness. And the idea of measuring software productivity in terms of new features or lines of code, like, that's something that goes all the way back to Dykstra [laughs] in the 1970s around, is that the right way? Well, a lot of people who code are like, "No, that's not." This is a debate that goes back to the earliest days of computing. But I think that the companies that are able to build resilient systems have a competitive advantage. If a leader wants to look at their systems, whether that is a social system and the people in their organization or whether or not it's their software if you look at it from a systems thinking, like, there are interactions that I need to pay attention to not just process, that is super key as well. And then the last one is to recognize, like, one of our core values is communication is just as important as code. I would be remiss to neglect empathy and communication in part of this, but that really is so important. Because when we position things in terms of...and I don't know as much about thoughtbot and kind of the overall strategy, but kind of an anti-pattern I have seen just in general in organizational behavior is that when you structure teams functionally and silo them, you're not getting that diversity of thought. So the way that we approach it is, like, put a mender on a maker team because they're going to have a different perspective. And then, you can work together to get things out the door faster and value each other's perspectives and recognize strengths and shadows. So, for me, as a maker, I'm like, I've got a huge optimism bias, and we can go through all this stuff. And for Scott, it's like he struggles to know when he's done. Like, for me, I'm like, cool, we're 80% done. I got it. We're good to go. And for Scott, he'll work on something, and then it's like, I have to stop him. So recognizing that we help each other, that kind of thought diversity and experience diversity goes across so many different vectors, not just makers and menders. But I think, to me, it's about reframing value so that you're not just thinking about what it is right now in this moment. And I think a lot of this comes down to investor strategy too. Because if you've got an investor that you're trying to appease and they're just trying to make short-term monetary gains, it's much harder to think in terms of long term. And I think it's developers understanding business, business understanding the struggles of developers and how they need lots of focus time, and how estimating is really freaking hard, and why if you demand something, it's going to be probably not right. And then coming up with frameworks together where...how can I describe this in a way? So to me, it really is about empathy and communication at the end of the day when we're talking about interactions and how do we operationalize it. STEPHANIE: I like what you said about reframing value because I do believe that it starts from the top. When you value sustainability...my co-host, Joël, had an episode about sustainability as a value in software development. But then that changes, like I mentioned before, the incentive structures and who gets rewarded for what type of work. And I also think that it's not only diverse types of people who like doing different types of work, but there is value in doing both. And I know we talked about it being a spectrum earlier, but I strongly believe that doing the legacy code work and experiencing what it's like to try to change a system that you are like, I have no idea why this decision was made or like, why is the code like this? That will help inform you. If you do do greenfield work, those are really important skills, I think, to bring to that other type of work as well. Because then you're thinking about, okay, how can I make decisions that will help the developers down the line when I'm no longer on this project? ANDREA: Exactly, which is a form of empathy. [laughs] STEPHANIE: Yeah, it is a form of empathy, exactly. And the reverse is also true too. I was thinking about, okay, how can working in greenfield code help inform working with legacy code? And I was like, oh, you have so much energy when the world is completely open to you, and you can make whatever decisions to deliver value. And I've really struggled working in legacy code, feeling like I don't have any options and that I have to repeat a pattern that's already been set or that I'm just kind of stuck with what I've been given. But I think that there is some value in injecting more of that agency into working with legacy code as well. ANDREA: Well, and I think, too, I think you hit it on the head because, like I said, with the mental load at home, it was like, I had to be okay with things failing where it's like, it wasn't exactly the way I would do it, and I had to be okay with that. Like, oh, the dishes aren't put in the dishwasher exactly the same way I would do it. I'm not going behind it. And like, okay, it's not perfect. That's...whoo, it's going to be okay. And I think that's kind of what we experience, too, is this idea of we have to figure out how we work together in a way that is sustainable. And I think that, similar to my experience with the technical, non-technical piece, there is an onus. Now, granted, I want to be very careful here to not...there is trauma, and there is absolutely horrific discrimination and abuse. And that is not what I'm talking about here in terms of power dynamics. I am talking more about self-identity and self-expression. And I think that if you are in a community like makers and menders, yeah, we're less represented. There is a little bit of an onus, the technical, non-technical, like the onus of understanding what non-technical means and where I can push back is really important work for me to do. Because what I was surprised with was everyone there, like, when I started asking...so my response ended up being, "Help me understand, why did you ask that question?" And I took ownership of the narrative. And it was like, oh, well, what I found was that most of the people were like, if you're a recruiter, I don't want to waste your time with a bunch of stuff that you don't want to talk about. And then being able to say, "Oh, okay, I can see that, and you assumed that I was a recruiter because of the way I looked. And I understand the intention here. Next time, if I'm at a software conference, assume that I know how to code and assume that I'm here for a reason." And a great opening question is, "What brought you here?" I'm like, oh, okay, when we ask a close-ended question, we position things as a binary, like, are you technical or non-technical? That creates a lot of cognitive dissonance, and it's hard. But if I open it up and say, "What brought you here?" Then I can create my own narrative. There is an aspect of setting boundaries and pushing back a little bit like you said, agency. And that can be really hard because it gets at the core of who you are, and then you have to really explore it. And what I found, at least, is in the majority, there have been exceptions, but in the majority of the male-dominated groups that I've been in in my career in software, the majority are very welcoming and want me to be there. But I feel inadequate, and it's more impostor syndrome than I think it is people being discriminatory. Learning about the differences between that and where is my responsibility and where's your responsibility in this that's a tough tension to play. STEPHANIE: Absolutely. And I think that's why it's really important that we're having a conversation like this. I think what you're getting at is just the harm of the default assumption that is chronic, [laughs] at least for me sometimes. And you mentioned earlier the history of computing a little bit. And I was really excited about that because I did a little bit of digging and learned about women's history in computing and how after World War II, programming, you know, there were so many women. In fact, I think by 1960, more than one in four programmers were women, and they were working on mission-critical work like for NASA for, you know, during World War II for code-breaking. And I read that at the time, that work was deemed boring and tedious, and that's why men didn't want to do it. They wanted to work on hardware, which was what was the cool, creative, interesting work. And the computing work was just second class. That's changed, but in some ways, I'm thinking about, okay, where are we now? And to what degree are we kind of continuing this legacy? And how can we evolve or move beyond it? ANDREA: Yeah, you're absolutely right. And in some of the research for the book, one of the things I learned is a lot of people know the name, John von Neumann. He created the von Neumann architecture, that is the foundation of all the hardware that most of us use today. And the very first kind of general purpose digital computer, ENIAC, all...I think it was eight of the people who were programmers for that were women. That team was led by John von Neumann's wife, Klára, and you never hear about Klára. You have to go digging for that. And The Smithsonian actually just about 8, 10 years ago did a big anniversary and then realized none of those women were invited to the press conferences. They were not invited. And so there is kind of this...similar to generational wealth, it's the thing that gets passed down. Like, if you're in the rooms in the early days...there was a quote by John Backus, who created FORTRAN and the Backus–Naur principle, where he talked about programming in the 1950s. He has an essay, and he was like, yeah, I mean, an idea was anybody who claims it, and we never cited our sources. And so it was whoever had the biggest ego was the one who got credit. And everyone's like, great; you're a hero. And so I think that's kind of the beginning of it. And so if you weren't invited into the room, because in the 1950s, in addition to gender, there was legislation that prevented...we weren't even allowed to use the same bathrooms. You had White bathrooms and Black bathrooms. So you had very serious barriers for many different people getting into that room, and I think that gets to the idea of intersectionality as well. So the more barriers that you had, the harder it was going to be. And so then you get the stereotypes, and then you get the media who promotes the stereotypes. And so that is what happened to me. So I grew up in the '80s and '90s, and just every movie I watched, every TV show portrayed somebody who was, quote, "good" with computers in a very specific way. I didn't see myself in it. So I was like, oh, I'm not there. But then, when I talk to Scott, he's like, "Oh, I never saw that. I never saw the discrimination. I just saw this stuff." That's part of it is that if you were in that position where discrimination, or difficulties, or stereotypes had been invisible to you, the onus is on you to learn and to listen. If you are in a situation where you feel like you have been in the minority, the onus is on you to find ways to become more empowered. And a lot of times, that is setting boundaries. It's advocating for yourself. It's recognizing your self-worth. And those are all things that are really hard. And saying, hey, if we want to be sustainable, everyone needs to contribute. I'm happy to train everyone, but this is not going to work. And being able to frame it, too, in terms of value, like, why? Why is it a benefit for everyone building that empathy? And you're right, I mean, there are absolutely cultures where...who was it? I think it was Edward Deming. And he said, "A single person is powerless in the face of a bad system." And so if you're in a system that isn't going to work, recognizing that and can you move into a different system? Or can you change it from within? And those are all different questions that you've got to ask based on your own fortitude, your own interests, your own resources, your own situation. There is no easy question. But it's always work. And no matter who you are, it's always work. [laughs] STEPHANIE: Yeah, yeah. I joined as co-host of this podcast just a few months ago. And I had to do a lot of reflecting on what I wanted to get out of it and what my goals were. And that's why I'm really excited to have you on here and to be using this platform to talk about things that are important to me and things that I think more people should know about or think about. So before we wrap up, Andrea, do you have anything else you want to say? ANDREA: I want to reinforce that if you feel joy from mending, it's awesome. And there are communities like legacycode.rocks. We have MenderCon, and it's a celebration of software maintenance. So it can be really great. We have a virtual meetup every Wednesday. And there's a kind of a core group of people who come, and they're like, it's like therapy because there are a lot of people who are in your situation where it's like, I'm the only person on my team who cares about automated tests, and I have no idea like...and just having people who kind of share in that struggle can be really helpful, so finding your community. And then I think software maintenance is really, really critical and really important, and I think we see it. Like, we're seeing in the news every day in terms of these larger systems going down. Just recently, Southwest Airlines and all of these flights got canceled. The maintenance work is so, so valuable. If you feel like a mender and you feel like that fits your identity, just know that there is a lot of worth in the work that you are doing, an immense amount of worth in the work that you are doing, and to continue to advocate for that. If you are a maker, yes, there is absolutely worth in the work you're doing, but learn about menders. Learn how to work together. And if you are a leader of an organization, recognize that all of these different perspectives can work together. And, again, reframe the value. So I am so grateful that you framed the conversation this way. It's so important. I'm very, very grateful to hear from you and your point of view. And I hope that you continue to push the narrative like this because it's really important. STEPHANIE: Aww, thanks. And thank you so much for being on the podcast. ANDREA: Yeah, yeah, absolutely. Thanks for having me. 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: Byeeeeeeeeee!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Stephanie raves about more software development-related zines by Julia Evans. Joël has been thinking about the mechanics of rolling dice. Stephanie also started on a new client project that Joël has already been working on for many months. They talk about onboarding. This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Julia Evan's Wizard Zines Why's Poignant Guide To Ruby Learn You A Haskell For Great Good Mazes for Programmers thoughtbot dotfiles rcm Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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 got a very exciting package in the mail the other day that I wanted to share with you. So I think I've mentioned her on the pod before, but I got a package of software development-related zines by Julia Evans, and I'm going to share a few of the titles that I got. So I picked up, "Oh shit, git!" [laughs] Can I swear on this podcast? I don't know. I guess we're going to find out. Or maybe we can just make the executive decision that it's fine. [laughs] I also got "Hell Yes! CSS!", "The Pocket Guide to Debugging," which I think I mentioned previously. I had seen the PDF version before, but now I have this cute, little, I don't know, six-inch book that I can carry around for all of my debugging needs. Who knows? Maybe I'll be out in the world and just need to pull it out [laughs] and debug something while I'm on the train; who's to say? And then I also picked up "HTTP: Learn Your Browser's Language!" So I'm really excited to have these little illustrated digest-sized resources. I think they'll look really cute on my shelf next to my more intense hardcore technical books like "Design Patterns" and "Practical Object-Oriented Design in Ruby" or whatever. I'm really excited about the more creative endeavors people have done with creating educational resources about software development. In fact, I think last time when we talked about creativity and creative expression, we totally missed the world of side projects. And I've really just enjoyed when people illustrate things and make stuff a lot more accessible to a wider audience than a traditional textbook or more text-based heavy resources. JOËL: I love when people go for a bit more of the playful or quirky when dealing with technical topics. And this is a great example. I love Julia Evans' work. But I'm also reminded of things like "Why's (poignant) Guide to Ruby," "Learn You a Haskell for Great Good!" or even...I forget the title of it. But there's a book by...I think it's Jamis Buck on mazes. And it's told in this sort of quirky style in a narrative. But it's all about maze-solving algorithms but told through the eyes of characters who are wandering through a maze, and it's just delightful. STEPHANIE: Aww, that's so cute. I love that. I also just had the thought that these things would make great gifts for a fledgling developer or a developer in your life who, if you don't want to get them something super specialized or technical or whatever. There are so many, like you said, quirky and fun things out there that I'm sure they'll appreciate. So, Joël, what's new in your world? JOËL: I play D&D regularly with some colleagues at thoughtbot. And recently, I got to thinking about the mechanics of rolling dice. Specifically, what dice can be rolled together? Like, can I roll multiple dice at the same time? And which one do you have to wait for the outcome of a previous roll before it makes sense to roll it? That was really interesting to me because I think that connects to a lot of other things that we do in software, where sometimes some things are independent. You can do them at the same time. And then, other times, you have to wait for the outcome of the first thing before you can even start doing the second thing. So I think, in many ways, it's a great metaphor for the difference between parallel versus series operations. STEPHANIE: I think it's very funny that you found a way to connect D&D to software development. I'm just imagining you rolling your die and then while you're doing that, having some revelation like the math lady meme or whatever, just thinking about, whoa, if this outcome happens, then [laughs] what happens? I have not joined in on our company's D&D campaign, but I do like that y'all post little updates about the story in a public space for the whole company to check out. So sometimes I've been searching for some message in our company's knowledge base, and I have stumbled upon a post about the campaign so far and what happened in last night's session, you know, how all the adventurers fought the big bird, [laughs] and it is very delightful to me. JOËL: It's a really fun way, I think to be creative. I think I enjoy the role-playing side of it a little bit more than just the mechanics of rolling dice, even though the thing I was excited to share today is rolling dice is fun. It is kind of like doing improv, where you're trying to figure out what would your character do and how do they respond to what other people say? It's fun, but it's hard. STEPHANIE: One burning question I have is, does anyone do voices for their characters? JOËL: Absolutely. Aji Slater, who was on a previous episode of this podcast, is part of this campaign, and their character has some really fun voices. STEPHANIE: That's awesome. I'm really interested in joining as a guest or something. But yeah, the improv aspect of it kind of freaks me out. I bet it's a really welcoming group. And if other people are getting into it, then I can get into it too. JOËL: Yeah, this group is very, very low-key. Most people playing, I think, are fairly new to the game. So it's very friendly, very kind of tolerant of, oh, you didn't know this rule existed, that's totally fine. We'll make it work, things like that. STEPHANIE: Nice. So another recent development in my world is that I started a new client project, actually the same client that you've been working on for many months, Joël. JOËL: Yes, the same client but different teams within the client. So we don't get to necessarily interact with each other day to day. But it is interesting that now we get to share knowledge about how this application works with each other. STEPHANIE: Yeah, yeah. And I don't think we've gotten a chance to work together even in the same world like this before. So that's kind of exciting. JOËL: How has the onboarding been for you? STEPHANIE: So, one onboarding development that was surprisingly easy and felt good was setting up a new laptop. So the client company shipped a laptop to me to use for all of their work. And I had to set up just the laptop from scratch, so I could develop on it. And I was able to do that pretty painlessly with the help of the dotfiles that I had previously put together and all of the configurations that I had exported and uploaded to like a cloud drive. And so I was able to have that up and running within a day with all of my favorite keyboard shortcuts, applications, all my little preferences, and that felt really good. So I'm going to pat myself on the back [laughs] for past Stephanie's efforts in making current Stephanie's life easier. JOËL: I'm curious, do you use thoughtbot's dotfiles as the base for your development environment, or do you use something custom? STEPHANIE: I have my own personal dotfiles that I have in a GitHub repo. But I think I did, at one point, go through thoughtbot's dotfiles for inspiration. I found that it has just a lot of extra stuff that I don't really need, but I do like that it's out there. So if any folks want a place to start with having a laptop setup configuration, you should definitely check that out. And we can link that in the show notes. JOËL: I really like the tool rcm, which is also by thoughtbot that allows you to have a modular system of dotfiles that you can pull from a few different sources and combine together. STEPHANIE: Oh, that's neat. I hadn't known about that one. That's cool. JOËL: It's a suite of command-line tools that allows you to pull probably from a git repo. And it might be several, and then trying to pull them all to the right place on your machine to be executable. So, in my case, I have the thoughtbot dotfiles and then also some personal ones. And it just kind of merges them together based on some rules and creates all the dotfiles in my home directory for that. STEPHANIE: Nice. I think the one thing that I do need to keep up on is pushing updates to the dotfiles when I make changes locally because I did have to pull in a few things that I had adjusted or made tweaks to that didn't make it to the source that I was pulling from on this new machine. This is actually my fifth MacBook that I own [laughs] just from remnants of jobs and clients' past. And one day...I keep telling myself that I'll have to return one of the older ones that I'm not using anymore, but as of now, I am an owner of five computers. [laughs] JOËL: Just start mining Bitcoin on the idle ones. STEPHANIE: Oh. [laughs] That's genius. I guess that's definitely a better use than them just sitting in my drawers. JOËL: I guess you're paying for power, and that's kind of the whole point, so... STEPHANIE: That's fair. JOËL: What are some things that you like to do when you onboard onto a new project? STEPHANIE: So, aside from my laptop adventures, when I joined this new project, I had a few things in mind that I wanted to achieve during this onboarding process. One of the things I think I want to get better at is understanding the business when I'm onboarding onto a new client. I think this is an area that previously I hadn't really focused on, but I'm now understanding is actually really important to being set up for success on a team. And so, as consultants, we're dropped into a client project oftentimes when things are already moving. And they kind of clearly have some things that they were hoping we could help with. But I am hoping to also use this time to just take a bit of a step back and ask questions about, like, what is the product? And what are its core features? And who are its users? And also, what's the direction of the business? Can I get some more context on how things are right now? We're so frequently brought in and being like, okay, like, you're going to work on this project but without the context of is the business scaling right now, or what are its struggles? We aren't quite able to make as informed decisions as we could if we had been at the company for longer and had just seen things change and had more of a feel of why we're doing what we're doing. JOËL: I love that you're asking all those questions upfront. I feel like coming in onto a new project, and that can be as a consultant, or it could be just starting a new job, is the perfect time to just be asking all of those questions. And people, I think, appreciate when we ask those questions. Sometimes I think as consultants; we can sometimes be afraid that, oh, if we're asking these sorts of basic questions, people might think less of us. But I think the opposite happens where because we're asking those foundational questions about the business model, about the future of the product, about how the technical architecture works, people really appreciate that we're asking those foundational questions where other people might not. So it actually helps build credibility rather than hurting credibility. STEPHANIE: Yeah, and I think they are really important in making the right technical decision, too, because it can help inform where you spend your time refactoring or evaluating whether this shortcut is worth it to meet this deadline or if it's not because of the bigger picture and where things are headed. If anything, I've learned that being a developer really isn't just about being in the code but having as much information as possible so that there is less ambiguity and you have more clarity to make the right choices when you do have to write the code. Another key aspect that I have become a lot more observational about, I think, is understanding the team that I'm joining, especially what their process is, how they communicate. One thing that's kind of funny about seeing a lot of different companies and how they work as consultants is they might claim to use agile, but in reality, it is a little bit different than that. And you can have that perspective as an outsider. Things like pointing an estimation is kind of all over the place in the industry. So I really like to make sure I fully understand how the team does that and what points means to them. I think another thing that I want to do during my onboarding time this week and as I'm getting to know developers on the client side is learning about the pain points that they're feeling. And, yeah, just getting more of a feel about what's top of mind for them and where is a good space to invest my time and my energy. Lastly, some more basic stuff is communication. Another thing about being a contractor that's challenging is that we don't normally get the full onboarding experience that full-time hires do. And so we may or may not have an onboarding mentor or a buddy and finding out, okay, who is the right person that I should be asking questions to? Or where's the right space for that? When you join new teams, are there any other things that you like to take into consideration? JOËL: I like that you talked about understanding the team's process. One thing that I often like to do pretty early on is make some kind of small code change but then have it go through the full process of coding on my machine to deploy it in production. And so just find some small change in the code that needs to be done, and maybe it's an easy bug fix or something. But just so I can walk through all the steps and find out what the team's process is. What are some sort of weird things that this team does that other people might not that I need to know about? Where does review happen? Is there a staging environment, unexpected ways which my change might get rejected? Things like that. So walking through the entire, I guess you could say software development lifecycle, kind of speedrunning is, I think, a really valuable exercise to do really early on a new project. STEPHANIE: Yeah, that's a great point. Like I mentioned, I think that looks so different for every team. And I'm now learning about new tools and SaaS products that I have never seen before. And even though I have an understanding of the software development lifecycle in general, just learning those quirks is very valuable so that you can be a contributor as soon as possible. JOËL: I like to contribute on day one, if possible, so kind of in order of...I don't want to say order of priority. But the order of things that I often do on a new project is one, clone the repo, try to run the setup script, or manually step through instructions in the README. Depending on the repo, that might be 10 minutes. That might be all of my first day. Number two, try to run the test suite. STEPHANIE: Yes. JOËL: Number three is figure out what went wrong for me in step one or two, make a fix for it, commit it, and open up a PR for it, and that's my contribution. If I can do those three things on day one, I feel like that is a solid first day. STEPHANIE: That's great. I love that. What can you do to help improve this process and make it just a little bit better for someone else? I think another good first-day task might be automating a part of that process that is currently manual and kind of annoying. 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! STEPHANIE: So once you've cloned the repo and you're poking around the codebase, what are some things that you notice when you're looking at the code? JOËL: Ooh, that's always fun. In a Rails application, there are a few files I almost always open first in a new project just to get a feel for it. Number one is the routes file. What does that look like? Is it huge? Is it small? Are there a lot of non-standard routes in there, not just standard RESTful resources? That's going to tell me a lot about how things are structured. I can probably even get a sense of what controllers are large, what controllers have 20 non-RESTful actions in them just by looking at the routing file. The other place I like to look at is the user model. Generally, that just collects so many methods. And so I can also often get a feel about the app just by looking at that. And then from there, it's pulling on connections and trying to say, okay, well, what seems to be the core model of this app that everything coalesces around? And maybe for an e-commerce app, it's some kind of product, or maybe for an insurance product, it might be some kind of policy object. And so you find that, and then you find all of the core business logic around there. And that can often give you a really good picture of what the app is like. STEPHANIE: Yeah, a few other things I would add to that list of things to check out is the Gemfile. I like to look at that to see what gems are familiar to me. Do they have authentication, common authentication gems that I've used before? Or is there a lot of stuff that's new to me? And it also kind of tells you, are they more likely to reach for a library or try to build something themselves? I liked that you mentioned that you try to run the test suite early on. I think test coverage is a good place to investigate as well if they have any metrics, you know, that also tells you that it is or isn't something they value. And then seeing like, okay, what parts are well-tested and what parts are a little less tested? I'm really glad that you pointed out how much information you can glean about controllers because then, once you're poking around in there, that can tell you a lot about where are the scary parts of the app? I've found that to be really interesting. You know, sometimes you can just open up a file and be like, whoa, [laughs] and have kind of a gut reaction. Other times, you might pick it up from other developers, and you might start hearing about areas of the app that they are a little nervous to touch. JOËL: I definitely connect with that. I feel like many products have a particular file that is kind of scary and that people don't want to touch. And sometimes, people will tell you upfront, sometimes, you just discover it yourself. And I've been on projects where it's like, oh no, we have a ticket that's come up. It's fairly straightforward, except we know whoever picks it up is going to have to touch the scary file, and I'm not it. STEPHANIE: Yeah, absolutely. JOËL: I'm curious if you run any kind of automated tooling to try to understand a little bit more about the code. So I'm thinking things like maybe Flog or Flay or some of those tools to get a feel for maybe what are the hotspots in the application, anything like that that you like to look for? STEPHANIE: That's a great point. I think the only times I have invested energy into doing that has been more when I'm doing a code audit for a client, which, in some cases, is a separate service that clients can pay consultants for. But I can see the value of doing it when you're joining a team for the first time. JOËL: In a sense, I almost feel like we do a kind of abbreviated code audit for ourselves as part of onboarding. STEPHANIE: That's fair. I wonder if you can use those tools and scope it in a way to the particular team or areas in the codebase that you know that you'll be working on. JOËL: You mentioned the Gemfile earlier. And one thing that maybe seems super obvious is checking version numbers for things like Rails and Ruby because that will significantly impact how development is going to work. Is this a Rails 3 app, or is this a Rails 7 application? STEPHANIE: Yeah, yeah, that's a great point. I am glad you mentioned that because I think that's probably the very first thing [laughs] that I would do just to set my expectations around what I'm working with. JOËL: I feel like it's one of those things that's often just told to you when somebody helps you onboard. It's like, "Okay, you can clone the repo. It's over here. By the way, this is a Rails 3 app. We're kind of behind the times. Here are some weird things we've had to do to keep it alive. We have this other team. They're in this back room over there, slowly working on a Rails 4 upgrade. It's been in progress for four months, but we think we're pretty close. Can't wait for Rails 4." STEPHANIE: Oh God. [laughs] I think the alternative is a developer being like, "Oh yeah, we just upgraded to Rails 7," and they're all really excited and feeling really good about it, [laughs] as they should be, because I think that Rails upgrades are an important thing to stay on top of. And it is really great when you are working on a project that gets to be up to date there. JOËL: Yeah, Rails upgrades are interesting because I feel like when you're proactive about them, they're not that bad, especially more modern versions. I think Rails has gotten a lot better about making those upgrades smoother today than they were ten years ago. But when you're not up to date about them, when you've just kind of procrastinated on doing the updates, every month or year that you wait to do the update makes it so much harder to do that update when the time comes. Because now more gems have fallen out of date, more things have now been abandoned that you just can't use. A lot of community knowledge is just not around as much anymore. Because Rails 3...I forget when Rails 4 came out, probably about ten years ago. So people who remember how things were done idiomatically ten years ago, some of that knowledge has kind of passed on. It's not as prevalent as knowledge around Rails 6 or Rails 7 is. STEPHANIE: 100%. I think I heard someone at thoughtbot identify themselves as a post-Rails 5 generation developer. And I loved that because it really tells you a lot about just their experience. And it's kind of fun. I can imagine some kind of BuzzFeed quiz or something that's like, what Rails generation are you? But yeah, I've certainly seen pro-con lists about joining different projects, and a con might be the app is still on Rails 3. And then, if the app is on a very new version of Rails, that's usually in the pro column because folks are excited about getting to have all that good, new stuff. What do you look out for in terms of design patterns in a codebase? Is that something that kind of sets off your radar at all? JOËL: One thing that will definitely make me raise an eyebrow is heavy use of metaprogramming. I've been bitten by that a lot on projects. Some things are way too clever by half. So a lot of metaprogramming typically means it's going to be difficult to read and follow the flow of logic in the code. And also, there might be some unexpected bugs. Or I found once a memory leak that happened because of some weird metaprogramming. So that definitely makes me a little bit skeptical of part of the code. STEPHANIE: Yeah, that's fair. And it also just makes it hard to understand the domain when you have no idea where things go. And you have to just find out later when you are debugging and are in the middle of desperately trying to figure out how this app works. So I can see how that is a little suspicious. I think one thing that I am reevaluating for myself when I notice design patterns is trying to figure out, do I want to perpetuate them? Do I want to follow them? And in the past, I have been more likely to just follow an existing pattern in the codebase. But one thing that I'm hoping to do moving forward is to simply ask, how do decisions get made around patterns? Who gets to introduce them? Are they documented? What does that process look like? Do you have a conversation with the team about it? Just so that I have more tools in my toolbox, I think if I ever do find something that I feel really strongly about, that should be different than what I'm seeing in the codebase. So kind of expanding my skill set there. JOËL: I think that's a fantastic question to ask, and I've done this on previous projects. And sometimes, the answers are just absolutely illuminating. So you see a weird pattern, and you ask, like, "Oh, where does that come from? Why do we do that?" And some will say," Oh yeah, that was Bob back in, you know, 2017. He read an article and was really a fan of this thing, and he put it everywhere. Nobody else really understood the pattern, but we haven't really been able to change it. And he's no longer with the company, and now we just kind of...it's there." Or sometimes it's like, "Oh, great question because you see, we have this subtle business problem. And we've got to reconcile these two pieces of technology with also this expectation that our customers have. And so we came across this pattern, and we decided to use it." And it's these things where just looking at the code with no context, you're like, that's weird. Why would you want to do that? And then, when you understand the underlying problem, it makes so much sense. It's like, okay, I don't love this pattern, but it's the correct solution here, and I fully support having that here. It's a tricky problem at the intersection of technological problems and business problems, and this was the best way we could solve it. I'm not always super happy, but it is the right choice. STEPHANIE: Yeah, I've heard someone describe that as code archaeology in a way that all codebases have a story to tell about how they got to the current state that they're in. And I have certainly struggled with this but trying to approach joining a new team and working on a new codebase, especially if it's legacy code, from a place of curiosity rather than being combative about it. And just going through the git commits or just simply asking members of the team, like, "Hey, what's going on here?" and getting to hear some of those fun stories. JOËL: Yeah, most code exists for a reason. It's not just people writing things just because, particularly code that, you walk in as an outsider and think, oh, that's bad code or looks weird. It's usually for a reason. People aren't just purposefully writing this to trigger you two years down the road. It's also important...as a new person onboarding onto a project, people care about your perspective. As an outsider, oftentimes, it's really rich to bring in an outside perspective. But it's also not a great look to come in and just immediately be like, "Oh, we need to tear this thing down," or "This is so bad." It's important to build trust with the team. And as with so many things in life, seek to understand before running your mouth. STEPHANIE: Wow, how insightful, Joël. [laughs] Speaking of building trust, can we talk a little bit about different strategies we have for doing that? JOËL: Yeah. As a new person on the team, you really want to build a strong connection with the client and to build that trust because then you can be more effective in doing your job. You can bring more value to the client. What are some ways that you like to get that moving in a positive direction early on a new project? STEPHANIE: I think setting up channels of communication is really important, so, ideally, having a one-on-one with a manager or a team lead because that is a great place to make sure that the work you're doing is aligned with what they think you should be doing. So figuring out what their expectations are, like, what do you expect me to get done in my first week? And then what do you want me to be doing by the first month? That is important because we might think about all the things we would love to improve about this codebase or like influence on the team. But if that is not lined up with their views of what success looks like, then we're not quite delivering on the value that we [laughs] had hoped that we would. Another thing that I'm starting to notice a lot more, and we talked a little bit about this previously when we talked about the value of sustainability in web development, but learning what the team's values are and also what the organization's values are because that will really inform the behavior of folks on the team and the decisions that they make. So some values that come to mind are transparency, or collaboration, or growth, or speed. Like, if you find out those underlying foundational pillars, that can really help you orient yourself in your work and being like, okay, I know that this organization really focuses on these kinds of things, so I would like to try to make decisions that uphold or are in line with the things that are important to them. JOËL: I want to really second your comment about good communication. That is one of the most powerful things you can do to build credibility to build trust with another human being, and that can happen in a lot of ways. Like you're saying, some of it is setting up actual communication channels with a manager. Some of that can be the things we mentioned earlier, like asking questions about the architecture, trying to learn all about the product and the business. That can also be being active in that particular team's Slack channel. Sometimes new people come on to a team, and they're a little bit more timid, and they're just kind of not present. And so kind of coming in and...like, you don't want to take over the channel but being active in the channel, asking your questions in that channel, even just talking about your onboarding experience being like, "Hey, I'm running through...I got stuck on this thing. Here's the thing I did to get unstuck." People love seeing that. And it helps them to feel like you're actively participating from day one. STEPHANIE: Yes, that is a great transition to what I wanted to make sure to say at the end of this is that your onboarding experience matters. I know that when you're joining a new team, you might feel a lot of pressure to start contributing and make sure that you are providing value. But your onboarding experience should be inclusive, and you should advocate for your needs. Like, if you don't have access to credentials or there are just various blockers to your onboarding, that's a big deal, and it should not be a gatekeep-y process. Everyone wants you to be able to do your job, and so if you're running into those issues, it's definitely important to raise those concerns for yourself and also for anyone else who comes along the way. Also, everything is new, and will probably feel uncomfortable. If you're anything like me, I feel a lot of pressure to prove myself when I join a new team and start contributing left and right. But it's just important to remember that when all this stuff is new, feeling uncertain or feeling confused and just being in that beginner's mindset again can be uncomfortable, but that is totally normal. JOËL: I feel like something I sometimes do that ties all of these ideas together is when I'm encountering some new code or a new problem, to help myself understand it, I will diagram it. But oftentimes, it can be nice to share that diagram in the team's Slack channel and to say, "Hey, I'm new to the project, and I was exploring this area, and I kind of diagrammed it." Just talk a little bit about the thing that you're doing and maybe what you learned about it. People love that. Visuals are a really powerful tool. And you might be surprised that there might be some team members that have been on the project for a while who never really understood that part of the code. And so they will latch on to what you've shared and be like, "Oh, thank you, because now I finally have a feel for that part." Or maybe you didn't get it quite right, and somebody will follow up and say, "Hey, I love your diagram, but you have a misconception here. There's actually a different piece that connects here." And then you can have a conversation, and you just revealed a blind spot. And so I've found that that can be a really positive way to get started. STEPHANIE: Yeah, absolutely. Joël Quenneville, professional diagrammer. But even if you don't draw a diagram, putting your assumptions out into the world and how you understand things I think is really valuable because, yeah, it's like you are showing your learning path and also being open to receiving feedback if it's not quite right and, hopefully, spreading knowledge all around. So I love that. JOËL: This reminds me a little bit of the episode we had with Steve Polito about learning in public. And he was focused more on learning about Rails, and open source, and things like that. But there's a sense in which you can sort of learn the product or learn the codebase. And public means your team channel. So you can say, "Hey, I'm digging into this model, and here's how I understand the way things work. It's a bulleted list of three things." You might get some good comments on that. You might get other people who appreciate it. So kind of learning the internals of a product within the public confines of a team, I think, is a really good framework as well. STEPHANIE: Absolutely. 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: Byeeeeeeee!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Joël has been fighting autoloading in a Rails app recently, and it's been really unpleasant. Stephanie has been experimenting with how she interacts with Slack. What are "the fundamentals"? People often argue for the value of Computer Science classes for the jobbing programmer because we need "the fundamentals." But what are they? And does CS really provide that for us? This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. RailsConf talk on autoloading Joël's RubyConf Mini talk Stephanie's RubyConf Mini talk Fun, Friendly Computer Science by Mercedes Bernard Achieving Fast Method Metaprogramming: Lessons from MemoWise by Jemma Issroff and Jacob Evelyn Episode on specialized vocabulary Episode on what to learn Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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: I have been fighting autoloading in a Rails app recently, and it's been really unpleasant. This is an older Rails 4 application, so we don't have Zeitwerk, any of the fancy modern things. But the problem I'm encountering is that people write code that references a constant somewhere. And if that constant is not named in the conventional way so that it would load from the proper file, it will raise a NameError at runtime when you try to execute the code. And then you want to reference that constant with a big asterisk there because if anybody else has happened to have loaded that constant correctly either by a manual require or some other method, then that constant will already be in scope, and so you don't get a NameError. So it causes a situation where you have a lot of non-deterministic failures in the code that are not easy to always reproduce either locally or even in the test suite. STEPHANIE: That sounds really frustrating because you must be getting errors left and right that you weren't expecting and then have to deal with. I'm curious, though, because you use the word non-deterministic. But in some ways, I'm thinking that you could perhaps grep or search the codebase for places where we're requiring constants like that and perhaps even audit that. Has that been something you've thought about, or do you think that's possible at all? JOËL: I don't think just grepping is going to be good enough because it's anytime you use a constant, and that's a class name, a module name. Things like that are probably the most common cases. If you're just referencing a constant like an array or a string, it's probably defined in the same file, so you're probably good. But if you're trying to include a module, or inherit from another class, or you want to instantiate another class somewhere, then you can run into issues if the class name or the namespacing for it doesn't line up with the file name so that when Rails tries to autoload it, it doesn't find it where it expects. STEPHANIE: Got it. Okay, that makes more sense to me now. JOËL: When I interviewed at thoughtbot, one of the questions that I was asked, and I don't know if that's still in our interview anymore, was, "Tell us about one of your favorite features in Ruby." And then, "If you could remove one or change one thing about the language, what would you change?" And I think the goal of that was to see if people had enough expertise in the language to both have something they really liked about it but also know the warts; what are the places that are hard to work with? And I definitely know that I said enumerable is my favorite part of Ruby because enumerable is amazing. I feel like, at the time, I didn't have a great answer for what I would change, but I don't remember what I said. I think today, if I had to answer that question, I might say the global namespace for all constants where just because you load another file, it might change what constants are available in a way that can really lead to some surprising behavior sometimes. STEPHANIE: It's really funny that you mentioned enumerable because I think, at this point, you've been at thoughtbot for almost a decade, and you recently gave a talk about the enumerable module. [laughs] And so it sounds like that's something that's still one of your favorite and beloved features of Ruby. So that's really fun. I also agree that autoloading is very opaque to me, especially, like you mentioned earlier; things can be totally different depending on what Rails version you're running. And it sounds like, ideally, when it works, it works. And hopefully, someone has done the legwork of making it effective for you. But when something goes wrong, then something that you had kind of taken for granted prior becomes really hairy. JOËL: I think for those who are interested in digging into really deep how autoloading works in Rails and how it's sort of changed over time, there was a keynote at RailsConf last year that dug into that. That is an excellent talk to listen to. STEPHANIE: Yes, that keynote from RailsConf 2022 about how Zeitwerk was developed by Xavier Noria, Xavier with an X. I was there too. That was a really awesome keynote. And I found it really interesting because, again, it was about this whole aspect that I just took for granted and had never really thought about. And I'm glad that someone else [laughs] figured it out for me. So that was a great reference. Speaking of conference talks, in prior episodes, we had mentioned the talks that you and I gave at RubConf Mini back in November, and the videos for those talks are out. So if you want to check out Joël's talk about enumerable or my talks about pair programming and non-violent communication, we'll link the videos of those talks in the show notes. JOËL: Excellent. So, what's new in your world, Stephanie? STEPHANIE: I've been experimenting with how I interact with Slack. So I used to be very distracted by Slack as someone who needs to mark everything as read in order for the little red badge to go away or for the bold channel name to become unbold. I was constantly clicking around in Slack whenever I had it open for the sake of completing that task of reading messages, even if I wasn't necessarily in a space to fully read or even had time to be spending distracted on Slack. But naturally, I would like, oh, click on this channel because it's bold, so I've unread messages. And then I'd get sucked in and be like, oh, I totally lost like five minutes of my time [laughs] and have forgotten what I was doing prior. So I started experimenting with using Slack as an inbox instead, so more of a pull than push in terms of receiving notifications. And I think it's been working well for me. I've also been leaning on Slack's native keyboard shortcuts instead of using a mouse to interact with the Slack client because that helps me avoid that distracted clicking or going into this channel just to see what's up, and that has also been just okay. I think their keyboard navigation is not my favorite. There are no customization options. So at one point, the shortcut to close the thread window pane was conflicting with my 1Password keyboard shortcuts, so I had to change my 1Password situation. And whenever you have to learn keyboard shortcuts for something different and in ways that might clash with your regular muscle memory for other applications, it's kind of annoying. But that's my journey with using Slack mostly on the keyboard so far. JOËL: What kind of impact have you seen on your focus since you've been using this workflow? STEPHANIE: I think it's been helpful for me to tune out things that I just can't prioritize my time and energy to at the moment. So I'm also pretty decisive when it comes to muting and leaving channels. I'm not in a ton of fun, casual channels because, again, I find them a little bit distracting. If I do want to go see cute dog content, I will go into the pets channel. But it's easier for me to have that be an intentional decision that I'm making as opposed to, oh, look, there are more messages in the dog channel. [laughs] Let me go check them out now. I think it has helped me focus my time and energy on the things that are most important to me. And the trade-off there is that I missed out on some content, but I think that I've become okay with that. And the channels that I am more subscribed to, like our dev channel that we've mentioned on the podcast before any project or team-related communications those, are top of mind for me. And when I do need a little bit of a break and do need some fun banter, I will hop into other channels for that. JOËL: So you brought up a little bit of this idea of FOMO around Slack channels. I think there's an area where our industry at large has a lot of FOMO, and this is around the computer science degree. A lot of people that are in the industry do not have one. There are a lot of different paths that can come into becoming a developer. Some people are entirely self-taught. Some people have gone through a bootcamp. Some people have kind of transferred from other similar or not at all similar industries. So there are a lot of different journeys that people have. But for many people, if you don't have that, there is some FOMO around, “Did I miss out on something?” And there's a word that people always kind of toss around when talking about computer science and specifically the things you might be missing out on if you don't have it, and that is the fundamentals. You might be missing out on the fundamentals or, oh, well, what if I don't know the fundamentals, then I'm faced with a problem? And I won't know what to do, or it might make me learn more slowly. Is that something that you've heard thrown around? STEPHANIE: I agree that the word fundamentals is extremely vague. In fact, I'm just going to say it: I have no idea what most people mean when they say the fundamentals, or at least I think they could mean a lot of different things. And so when that term is used, maybe I should just be asking for clarification [laughs] because I think that we could be talking about a lot of different things. Before we get into what fundamentals of programming or computer science or whatever means to each of us, Joël, do you want to share a little bit about where you're coming from in terms of any education prior to becoming a developer? JOËL: Sure. So I do have a CS degree. I actually learned to code before college. I read some books, did some tutorials on the internet, played around with some code on my own, had a lot of side projects, and even at some point was, freelancing a few small projects as well. But I always struggled trying to build projects larger than a certain size. I felt like they would sort of implode under the weight of their own complexity. I definitely felt like there's got to be some underlying fundamentals that I'm missing, some theory of writing code that would explain how to structure things in a way that scales. And this is not scaling to millions of users; this is scaling beyond 100, 200 lines of code, maintainability. And so, I had really high hopes for a computer science degree. And honestly, I think I was a little bit disappointed. I learned a lot of other interesting theoretical things, but not a lot that was actually answering that underlying problem. And I didn't really get the answers I was looking for until I started working more in the industry, doing various internships and then later on full-time jobs as well. And just over the years, that has sort of built up a lot of answers to those questions that I had. But I didn't necessarily find them in my computer science degree, so I have mixed feelings. STEPHANIE: I had no idea that you were doing that level of coding prior to studying in college. That's really cool. Now that I'm thinking about it, I think that's the case for a lot of people. They might get a taste of coding when they're young. It was true for me. I was a young girl on the internet in the early days writing HTML and CSS on neopets.com. And that is also how I got my first taste, and kind of wanted to explore further. So, in college, I studied journalism actually. That was where my interests were at the time. But I did take some computer science courses on the side and ended up completing it as a minor. But I'm with you that the education I got didn't quite match up with what I was expecting. In fact, I kind of struggled, I think, because there weren't a lot of more relatable applications to what I was learning, and so I was very bored and disengaged, I think. And so when I came out of college, I didn't think I wanted to do software development, or programming, or anything like that because I didn't love taking those classes. And, I don't know, I'm going to get into my whole career history today. But I basically fell into the role of development. It was kind of like, oh, you have these coding skills; we need these coding skills. I was like, okay, I guess this is my job now. [laughs] And I think you and I are actually kind of similar in the sense that once you started doing the work, you started to see a lot of the things that you had learned previously that you could then apply. Does that sound right? JOËL: Yes. And I think maybe more so over the years, there are some things where it's like, oh, with a five-year mark, it's like, oh, finally now I feel like I've got enough practical experience where I can start to appreciate some of these underlying things, or I'm getting into things beyond just the basics of writing a simple Rails app where I start to need some of those other concepts. And some of those it's five years, some of those are ten years. And so it's sometimes nice to have something to go back to. Although after ten years, there's only so much I remember, so sometimes it's just having a keyword that I can Google and dig into further. 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 earlier, you mentioned that fundamentals is a bit of a weasel word; it means different things to different people. So I'm curious for you, what do you think of when you think of fundamentals And, maybe more specifically, from the perspective of a web developer? STEPHANIE: Yeah, I want to caveat this by saying that I think you can learn these different skills in many different ways; that could be formal education, that could be a bootcamp, that could be self-taught. But these three categories are what I think are useful education for a web developer. So firstly, understanding how computer systems work at the abstraction you're using and maybe even one level lower. So this is likely the programming language or framework and the tools that you're using, and I think a lot of bootcamps teach this. They want to teach you the skills you need to get a job and do that job. The second category, I would say, is more theoretical. So the theories of computer science and math that you and I alluded to earlier as not having been super practical at the time that we learned them. I guess that's probably why they're called theories. [laughs] But I'm thinking like algorithms, data structures, and other concepts like O notation or whatever. And then thirdly, this one, I think, doesn't get talked about enough. But there's this whole world of practical skills that we do in the industry that I don't quite think are taught in either environment, so that looks like reading code and reviewing code, especially as it relates to working in an existing application as well as writing tests and documentation, and, in general, working with other people. I think a lot of programming education focuses on the act of writing code when I think there's a lot to learn from reading code and analyzing it. And that's something that I have been thinking a lot about the more I spend doing it in my job. JOËL: I like the way you've sort of broken these down into more relatable categories rather than just this generic idea of the fundamentals. I think when people think of the fundamentals, they're probably thinking mostly of your category two, the more theoretical underpinnings. Some of those are actually quite relevant, I think, to the day-to-day work that we do. And then some of them are very kind of abstract and maybe even to the point of mostly being relevant if you're doing research but not that interesting if you're writing code on a day to day. Does that sound about right to you? STEPHANIE: That's fair. I revisited a series of blog posts and conference talks that my friend Mercedes Bernard gave called "Fun, Friendly Computer Science," that was aimed towards people who didn't have a formal CS background to give them a vocabulary or some exposure to computer science concepts that would be helpful in day to day programming work. And one thing that stood out to me was the idea of set theory and how working with relational databases is pretty much working with set theory, even if you don't use that vocabulary or reference those underlying concepts. I think another aspect of these theoretical fundamentals that companies might interview people on, like algorithms or data structures, there's also a lot of talk about how those aren't part of your day-to-day jobs. And yes, knowing about them is useful, but the benefits of working in an existing programming language is that those have all been figured out for you. And you are just using those data structures and have to worry a bit less about how they are working under the hood. That's not to say you should know nothing about them, but I think I had mentioned earlier maybe it's helpful to understand things at a lower level than what you're working with. And that can come up when you run into problems that those data structures aren't quite able to help you solve, and you need something different, or you need to be a little more creative. But I would say that almost all of the time, you have the luxury of not having to think about that. JOËL: It's interesting you mentioned set theory because I was thinking of a set theory metaphor here, which is we have a set of things, which is what a traditional computer science degree will teach you. We have a set of things that are the quote, unquote, "fundamentals." And there's definitely an intersection between those two sets, but they don't totally overlap over each other. And so there are some things in a computer science degree that are absolutely going to be fundamentals that you need to use and that you're going to use in your day-to-day job. You don't have to learn them through CS. You can learn them from all sorts of other sources. And then there are also some things in CS that are maybe not part of the fundamentals. All knowledge has value. And so these things can be mental models, or they can connect to other things. But they're not necessarily fundamental to you being able to do a good job as a working developer out in the world. And again, this will vary a lot depending on the type of development that you're doing. I'm mostly thinking of web development because that's what you and I do, both front end and back end. I want to come back to something that you mentioned earlier because I feel like when everybody thinks of the fundamentals of computer science, the first thing that comes to mind are data structures and algorithms. Those are the things that you're working on when you're doing leet code. They are the kind of things you get asked on interviews. It's the kind of thing that's kind of fun to show off to other people. And it sounds like you're saying that data structures and algorithms are actually kind of overrated; that's a hot take. STEPHANIE: I think it's overrated if you are working in web development. Like we were talking about earlier, at that level of abstraction, you're using the tools of the language to build software that works for your users. Like, I am really not thinking all that much about how to implement a linked list or something like that. [laughs] I have my trusty hash in Ruby. I can use an array if I need to and just put my data in there, and that is perfectly fine and acceptable. And I have not really needed to do anything too fancy beyond that. In fact, I think you and I have talked a lot on this podcast about paradigms and design patterns. And those are the things that I find really interesting and want to learn more about at this point in my career and because they're more relevant to my day-to-day work. And I think we should be interviewed on the work that we will be doing. JOËL: I think that lines up a lot with my experience as well. I have had to implement some trees, some linked lists, and things occasionally throughout time. I think especially working in Elm, sometimes is a little bit more lower-level data structures to work with or to construct. And sometimes you might need that to know some basics around things like trees if you're operating over the DOM, which is a tree, things like that. But, again, a lot of those things are already pre-built for you. So having the 10-minute version might be good enough to get what you need to do. I think one thing that's probably the most useful thing that I would pull out of an algorithms class is the concept of a binary search, not just literally how do I implement a binary search on an array or a linked list but the idea of it and then taking that and applying it to a very broad set of problems. And a classic one is when you're debugging, and there are all sorts of ways that your program might fail. And if you are looking at it just process of elimination, just one little thing at a time, it's going to take you forever to check every possible cause. But if you can find a way to eliminate half of the possibilities, and that might be by putting a conditional high in your decision tree, or there are a lot of different ways you can do that, all of a sudden, it makes it much easier to narrow down your search and to find a bug. And so that is a technique that I think is just hugely valuable that you learn in an algorithms class, but that can be generalized to all sorts of problems. I'm curious, in writing in Ruby, or JavaScript, or any of the web languages that we tend to write in, have you ever had to calculate the big O of a method or function you've written? STEPHANIE: Only in the context of performance and Rails performance. The only times I think I've ever really pulled it out is when I am seeing a database query that is O of n or worse, and then I rewrite the function to avoid that inefficiency. Otherwise, I think most functions are perfectly fine, and there's no need to really optimize for that the first time around. Though, I am going to plug another conference talk that I watched recently from Jemma Issroff and Jacob Evelyn about their developing of a gem called MemoWise which involves memoization and caching. But they did a really cool job of deep diving into the source code of their gem to make things as efficient as possible. And that did involve investigating different O notations and stuff like that. 111 JOËL: Yeah, I found that in practice, most performance bottlenecks on the web tend to be I/O bound rather than CPU bound. I just realized I threw out some fancy technical terms that you probably would learn in a CS degree, and that might feel confusing for those who don't have that background. So that means that your problem is slow. It's waiting on, usually, some sort of network or file system, or database, or something like that rather than waiting for processing speed. As an aside, we've talked about the value of having specialized vocabulary and names to add to problems. So that is a value that you get out of a more formal education path is that you do learn some of those technical terms. And that can sometimes help you to build a mental model of the solutions you can apply to a problem. STEPHANIE: I might have mentioned it in that episode, but I do think I learned best, having had to wrestle with something in my personal life and experience and then going out and seeking more information about it and learning about it. And at that point, it's much more interesting to me because I can relate it to something that is in front of me as opposed to reading a textbook and trying to imagine ways that this information would be useful. A lot of these concepts, it's totally okay to go explore them once you need them. You're right that it is tough if you have no idea where to even begin or what to search for, or what to look for. But I don't know; I think maybe I'm just being efficient with my time this way. [laughs] JOËL: I'd like to throw a metaphor at you that you kind of introduced earlier when you were talking about Slack and how you're trying to change from a push to a pull mode, and I think this can apply to learning as well. Any sort of push approach to learning, you're kind of pre-learning some things because you think they're going to be useful or they might power some more learning. And it's going to be good to have that sort of already there in the situation where you need it. Then that might be going to do a four-year degree, or maybe that's just saying, this year, I want to learn a little bit of this theoretical idea to build some better understanding of the quote, unquote, "fundamentals." And that could just be sort of general continuing education that you do. But sometimes, like you said, it's just in time. You say until I encounter a problem, it's like, okay, this problem is slow. I don't know a whole lot about performance. Let me go read up about performance. And then you get to be like, oh, the first question you ask is, is your problem I/O bound or CPU bound? What does that mean? Okay, now there are different strategies for how you deal with things and different analysis tools. And then you go and learn that at that moment rather than having learned it the summer before because you just were trying to fill out a sort of broader foundation for your knowledge. STEPHANIE: Wow. Excellent callback. Again, only you can find multiple ways to reference something [laughs] I said earlier. I also really enjoy listening to someone who's an expert at something or particularly knowledgeable talk about something that they're excited about. And so I was thinking that I don't have as robust of a computer science education as some of my peers or coworkers, but I know that I have people to go to with my problems. Like you, for example, you might pull out, oh, this reminds me of graph theory. [laughs] I know we've talked about dependency graphs a lot on this podcast. And, in some ways, I am absorbing that education through you. And maybe in the future, I will encounter something that reminds me of a conversation we had, and I have a starting place. So I think having people with diverse backgrounds in this field can be really valuable as well. JOËL: I love that because that means that even in your day-to-day, there's kind of a sort of mix of push and pull that's happening. You might just be having a conversation with somebody, and they're really excited about dependency graphs, and they tell you why they're excited about it. And that's maybe a little bit more of a push because you don't immediately need it, but you're gathering some knowledge. But then you might also be encountering a problem on a client, and then you ask in our dev channel, "Hey, I'm encountering this sort of problem. What should I do?" And somebody says, "Oh, you might want to look into calculating the big O of this function because that looks suspicious. Tell me about that." STEPHANIE: Exactly. And now it's my turn to call back to my Slack anecdote earlier because I do think in this field, there's just an infinite amount of things to learn. And I do have to accept that I'm not going to learn everything. And I have found a way that works for me, you know, that combination of, oh, here's a problem I'm facing. And I really need to find out what is going on in this C code so I can better understand this Ruby code I'm writing or something like that. Or people sharing different insights that they have, and I'm getting that information that way. And you said it earlier that however you receive this information or get this education, there's no one way to do it. There's no one correct way. JOËL: And I think everybody does a mix of both, right? You've mentioned several times that you had attended a conference talk, or read a book, or read an article on a topic related to more theoretical underpinnings. And I'm pretty sure you weren't going to that talk because you had a problem that needed to be solved, and you're like, oh, if only I could get the answer, this is where I'll get it. It's probably a little bit more in preparation, saying, oh, I'm at a conference. The whole point of a conference is to get some information ahead of time. And this particular topic sounds like it would be helpful. Does that sound right? STEPHANIE: Yeah, that is a really great way of putting it. I hadn't thought of it that way. But that also kind of checks off the box of listening to someone else explain things to me [laughs] that they've already done a lot of research on and feel excited enough to share with the world. And that is inherently more interesting to me than reading a textbook. JOËL: Oh yeah. Textbooks are boring. We'd done a whole episode recently about where to focus our learning. So I think if listeners are interested in digging deeper into that and maybe the push versus the pull, there are a lot of great thoughts there as well. STEPHANIE: So before we wrap up, are there any underrated quote, unquote, "fundamental" computer science topics or concepts that you think are particularly valuable to you and your work as a developer? JOËL: I would like to plug discrete math as a topic. And I know we've talked about, oh, there are some theoretical ideas that are maybe very firmly in the theoretical realm and aren't that useful in day-to-day work, and math sounds like it would be in that branch. But discrete math is basically all the practical math that is useful to you as a developer. It's kind of a mishmash of 10 different subjects. So it's a bit of an overview of here's an intro to Boolean algebra. Here's an intro to propositional logic. Here's an intro to predicate logic. Let's talk about set theory. Let's talk about combinatorics. Let's talk about recursive functions from a mathematical perspective. Let's talk about a little bit of graph theory. So it just touches on a bunch of these topics, and they're all generally quite useful. I find things like Boolean algebra I use absolutely every day because writing Boolean expressions is a thing that we do all the time in our code. And you might think there's not that much to doing Boolean expressions. And you might even have picked up on some of the patterns by yourself just by doing the work long enough. But there are some really interesting laws and rules that can be applied and analysis techniques that, even in just the small portion of a course dedicated to that topic, you get a lot of value out of it. So I would recommend either digging into some of these topics a little bit on your own, so digging a little bit into Boolean algebra, digging a little bit into set theory, or digging into discrete math as a whole, sort of looking at all the different little sections together. I think that really gives you a lot of tools to improve your day-to-day work. STEPHANIE: That was a great sell on discrete math. And who knows? Maybe you've influenced some of our listeners to go check that out. 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: Thank you so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Stephanie shares that she's been taking an intro to basket weaving class at a local art studio, and it's an interesting connection to computer science. Joël eats honeycomb live on air and shares a video that former Bike Shed host Steph Viccari found from Ian Anderson. It's a parody to the tune of "All I Want For Christmas Is You," but it's all about the Ruby 3.2 release. In this episode, Stephanie and Joël shift away from literature and lean into art. Writing code is technical work, but in many ways, it's also aesthetic work. It's a work of art. How do you feel about expressing yourself creatively through your code? This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Weaving, Computing, and the Jacquard Loom Ian Anderson's Ruby Christmas song Dan McKinley's Boring Technology Club slides Simple English Wikipedia Geepaw Hill's Twitter thread about levels of thinking Julia Evans's debugging puzzles Tomorrow, and Tomorrow, and Tomorrow by Gabrielle Zevin Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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'm really excited to share that I've been taking this intro to weaving class at a local art studio. I'm actually a few weeks in, and it's wrapping up soon. But one thing that I found really cool at the very first class was that the instructor mentioned that weaving was, in some ways, a predecessor or inspiration to modern computing. And he said that, and I got really excited because surely that meant that I would be good at this thing [laughs] and this craft, and then I promptly kind of forgot about it. But I was inspired the other night to look up this history to just learn more about weaving and its connection to computer science. And I learned that, in particular, the invention of something called the Jacquard loom really led to early computing machines because, basically, weaving involves threading horizontal and vertical fibers. And the way you do it if you thread the horizontal fiber, also called the weft, over or under the vertical fibers, called the warp, you get different patterns. And so with the Jacquard loom, this invention utilized punch cards as instructions for basically binary code, and that would tell the loom how to raise and lower those vertical threads, which would then lead to a beautiful pattern. And after that invention, this previously very laborious process became automated. And that also had a really big impact on the textile industry. And fabric became a lot more available at a much lower cost. So that was a really cool little history lesson for me. JOËL: That is really cool. So are you saying that punch cards, as we know them from early computing, were borrowed as a concept from the weaving industry? STEPHANIE: Yeah, that's at least what I've read. I can see now how complex weaving tapestries and patterns set the stage for more complex computations. And I don't know if I'm going to keep going down this weaving journey. I liked the intro class because it was very chill, and I got to use my hands. And I had a little bit of fun making, I don't know, like ten by 12-inch little tapestry. But yeah, I've definitely seen other more advanced weavers make really beautiful textiles and fiber arts. And it's really cool to see the application of that detail-oriented skill in different formats. JOËL: Are you going to try to make your own punch cards? STEPHANIE: That's an interesting evolution of this skill [laughs] for sure. I think what I really did like was the hands-on approach. And so the punch cards did make this process automated. But I personally enjoyed the switching of the threads and pulling them through and doing it with my hands instead of something that's kind of turned into automated machine work. Does that inspire you in some way? JOËL: I think sometimes it's interesting, right? As software people, we sort of have the two urges. We work in so much automation. When we see a process, we would love to try to automate it ourselves, even if it's been done before. So, oh, could I build a small, automatic mechanical loom using punch cards? That sounds like a fun automation challenge. At the same time, so much of my daily job is automation that sometimes it's nice to kind of remove automation entirely from the picture and, like you said, just work with your hands. STEPHANIE: That's a really interesting way to think about it. I do believe that people have different reactions to it, like you said, where they're like, "Wow, I can use my skills to do this really cool thing." On the other hand, you might also respond with, "Wow, I've done this automation code-writing work for eight hours. So now I really want to do something completely different." And I think that's the camp that I was in, at least when I first signed up for this class, just having space, like three hours a week, to sit and not look at a computer and deal with the physical realm. JOËL: So here's the other route that I think a lot of software people take, and that is, here's a fun mechanical process that can be automated. What if we simulated it virtually? So what if I create a program where you can sort of create your own punch card, like, decide where you want to punch the holes? And maybe these are just radio buttons or something or checkboxes in a grid on a webpage. And then, the program will output an SVG that is the thing that would have been woven if you'd used it in that pattern. And so now you can kind of play around with, like, huh, what if I punch here? What if I unpunch here? And you get all these patterns out, and you could just get to try it around. STEPHANIE: That's fascinating. I can't believe your brain went there. [laughter] But yeah, the idea that it's not actually about the pattern itself but the holes that you make, that part being the creative process and then what comes out of it then being a bit of a surprise or just something organic that's a really interesting take too. JOËL: Something that I find is really fun about software and things created from software is this sort of really short feedback loop in terms of trial and error. So if you were actually having a weaving machine and you made a physical punch card, and then you try something, and you realize it's not quite right, the machine weaved something you didn't quite like, now you've got to set it up again. You probably have to start from scratch with a new punch card because you can't really unpunch holes unless maybe you can put tape over it or something. That trial-and-error feedback loop is much shorter. Whereas with a program, you just pause the simulation, punch-unpunch some holes, restart, and then you just kind of keep trying. And there's something fun about that creative exploration when you've got that really tight feedback loop. STEPHANIE: That's fair. I think perhaps that actually might be why doing it manually, and by it, I mean weaving, gives you a little bit more room to [laughs] debug if you will, because you can see when something goes wrong. And this actually happened to me in class earlier this week where I didn't thread the fiber over instead of under. And I was like, oh, this doesn't look right. Like, that's not the look I'm going for. And then I could kind of quickly see, oh, I missed a thread over here and unravel and do it again. Whereas what you just described, if the punch card is wrong and then you create this big piece of fabric, at that point, I'm not really sure what happens then. If someone out there is a weaving expert and knows the answer; I would be very curious to know. JOËL: Now I kind of wish we'd had this conversation last month because, in early January, there was a game jam event that happened. It's a yearly or biyearly Historically Accurate Game Jam, and they select a theme, and then everybody has to submit a game, or a simulation, or something, an interactive program that fits with the theme. And this year's theme was the Industrial Revolution. And I feel like simulating an old automated loom with punch cards would be the perfect fit for something that's small enough that I could build it in a week without spending 10 hours a day working on it. It fits within the theme, and it's still kind of fun. STEPHANIE: Wow, that would have been a really great idea. If there was an award for best fitting the theme, I think that would have won because then you're also tackling the history of computing. I was talking about earlier the loom obviously being...or the automated loom also really playing a big role in the Industrial Revolution. And, I don't know, maybe this is our future club, Joël, and we're going to get into video game development. [laughs] What's new in your world, Joël? JOËL: There are two things. One is that today former Bike Shed host, Stephanie Viccari, shared a video with me from Ian Anderson. This was made last December to the tune of All I Want For Christmas Is You. But it's all about the, at that time, upcoming Ruby 3.2 release. It is amazing. The lyrics talk about the different features that are upcoming. It rhymes. It's set to meter. I am just blown away by this. And I'm just really hyped [laughs] about this video. STEPHANIE: You sent it to me and I gave it a watch before we sat down to record, and I also loved this video. It was so fun. And I think Ruby has a bit of a tradition of releasing new versions around Christmas time. So if this became a tradition, that would be very fun, and maybe instead of singing Christmas carols, we'll be singing new Ruby version carols around the holidays. JOËL: I feel like if Ian wants to do another one next Christmas, now that you have the precedent, it'd be a great space to try something to the tune of Last Christmas because now you can reference back last year's song. STEPHANIE: Yeah. I might as well just go all in and create a whole Christmas album of Ruby anticipation carols. [laughter] JOËL: Yeah, really excited about that. Kudos to Ian. And for all of our listeners, we'll link the video on the show notes of the podcast. Go and check it out; it is worth the two and a half-minutes of your life. STEPHANIE: Agreed. JOËL: The other cool thing, for the past few episodes, we've been talking a lot about hexagons and how they show up in nature, and bees, and how they build their honeycombs and whether that is sort of by design or sort of just happens by nature through sort of external forces. And so this week, I went out to the store, and I bought some real honeycomb. And I'm going to try it on air. STEPHANIE: [laughs] Oh my gosh, I didn't realize that's what was happening. [laughter] Okay, I'm ready. JOËL: All right, I'm going to take a slice. STEPHANIE: Wow. For research. JOËL: For science. STEPHANIE: Wow, that is a big bite. [laughs] JOËL: Hmmm, it's basically crunchy honey. STEPHANIE: So I've enjoyed honeycomb in that raw form on ice cream. I really like it on there and oatmeal and stuff like that. I think it's a little bit waxy. Like, once you get to chewing the bits at the end, that part is a bit of a less pleasant mouth-feel [laughs] in my opinion. What are you experiencing right now? JOËL: Yeah, so like you're saying, the honey kind of dissolves away in your mouth. You had this really fun mix of textures. But then, in the end, you do end up with a ball of [laughter] beeswax in your mouth. STEPHANIE: Oh no. JOËL: Which I understand is completely safe to eat, so... STEPHANIE: Yeah, that's true. JOËL: I'm just going to eat the whole thing. STEPHANIE: I think it's kind of like swallowing gum. [laughs] JOËL: Which apparently does not last for seven years in your digestive system; that's a myth. STEPHANIE: Wow, debunking myths, trying honeycomb. You're welcome, to all The Bike Shed listeners out there. Investigating the important things. JOËL: What is interesting is that we're talking about the structural power of hexagons. I can cut a pretty thin slice of the comb, and it doesn't fall apart. It still has a lot of strength to it, which is nice because it means that the honey doesn't just go splashing everywhere. I can cut up a fairly thin slice, pick it up, it still holds the honey, put it in my mouth, and it doesn't make a mess. STEPHANIE: The bees know what they're doing. [laughs] Cool. Would you eat raw honeycomb again? JOËL: Well, I got a whole block, and I had one tiny slice. So, yes, I will be eating the rest of this. STEPHANIE: [laughs] JOËL: I don't think this will be a regular thing in my weekly groceries. But I would bring this out again for a special occasion. Or I can see this fitting nicely, like you said, on maybe certain breakfasts, even on a charcuterie board or something. STEPHANIE: Oh yeah, that's a really good use for it. JOËL: In some ways, it's nice because it's a way to have honey without having to have it on something else or having to eat it with a spoon. It's honey that comes with its own carrying vessel. STEPHANIE: That's great. Yeah, like a bread bowl for soup. [laughs] JOËL: Exactly. Bees make their own bread bowls for honey. STEPHANIE: [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, for the last couple of weeks, we've been joking that this is turning into the Stephanie and Joël book club because we've been talking about a lot of articles and books. Today, I'd like to shift a little bit away from literature and lean into art. Writing code is a technical work, but in many ways, it's also an aesthetic work. It's a work of art. How do you feel about the idea of expressing yourself creatively through your code? STEPHANIE: So this is interesting to me because it's actually quite different from what we've been talking about in recent episodes around the idea of writing sustainable code, code for other people to read. Because if you are writing code purely for creative expression and just for yourself, that will look very different than what I think folks have kind of called boring technology, which is choosing the patterns, the tools, the frameworks that are tried and true, and just kind of sticking to the things that people have solved before. And so, in some ways, I don't know if I really get to express myself creatively in the code that I write, which I think is okay for me because I don't really consider myself someone who needs a creative outlet in my work. What about you? What thoughts do you have about this? JOËL: I think it's interesting the way you described it. I'm almost wondering if I'm making maybe a comparison to physical architecture; maybe you almost have a sort of brutalist perspective on the things you construct. STEPHANIE: [laughs] JOËL: So they're functional. They're minimal. They are not always the prettiest to look at, but they're solid. Does that metaphor sound about right to you? STEPHANIE: I feel like I have to make a pun about SOLID, the design patterns, and code. JOËL: Ooh. STEPHANIE: [laughs] But I think I like brutalist, I mean, the term itself. I don't know if I necessarily identify with it in terms of my work and output. But the idea that the code that I do is functional is, I think, particularly important to me as a developer. And I don't just mean, like, oh, the code works, so it's done, but functional for whatever need I'm solving and also for the people who are working with this code again in the future. I mentioned boring technology. There's a talk that I'm kind of referencing by Dan McKinley, and you can check out his slides at boringtechnology.club. And he talks about this idea of decision-making and how that relates to writing boring or creative code. And he also references Maslow's hierarchy of needs. And so, ideally, if you're working in an existing codebase, all the low-level decisions have been made for you. And then you can kind of traverse the hierarchy and focus your creativity on the high-level problems that you're trying to solve. So maybe you're not necessarily expressing your creativity in the syntax or whatever pattern you're using, again, because a lot of those things have been solved. But where the creativity comes from is the particular domain or business problem you have and the real-world constraints that you're faced with. And how do you figure out what to do given those constraints? JOËL: I think that lines up a lot with my own experience as well. I think as a newer developer, syntax is sort of the thing that's top of mind. And so, maybe trying to get clever with syntax is something that I would focus on more. Sometimes that's trying to get code really short and terse. Sometimes it's because I want to try. Can I do this thing with a particular piece of syntax, or even just does it look pretty? I think now, in my code, I am actually kind of boring with my syntax. I, probably when I write Ruby, mostly use a kind of slimmed-down set of syntax and don't use the full expressive power of the language for most of my day-to-day needs. So basic things with objects, and methods, and blocks, sort of the basic building blocks that we get from Ruby regular conditionals, if...else, and a few other nice things that the language gives us. But, in many ways, it almost feels like...I don't know if you've ever seen the simplified English Wikipedia. STEPHANIE: No, I haven't. What is that? JOËL: They're treating it, I think, like a separate language, but it is a version of Wikipedia in English with a more restricted vocabulary to try to make the content more accessible to those that might struggle with more standard English. So it's a sort of smaller subset of English. And, in many ways, I feel like a lot of the day-to-day Ruby code that I write is simplified, Ruby. STEPHANIE: Wow, that's really interesting. I think this also goes back to the specialized vocabulary episode we talked about. And is there value in keeping things accessible, and straightforward, and boring but at the cost of being able to express yourself with everything you have available to you? This is a bit of a tangent, I guess, but I grew up speaking Chinese with my parents, but since then, I have really lost a lot of that vocabulary. And, in some ways, I really struggle with communicating in Chinese because I feel like I'm not able to express myself exactly the way I want to in the way that I can in English. And when I'm talking to my parents, yeah, that's been a bit of a challenge for me because I do really value being able to say things the way that I mean, and I'm not able to have that with my limited vocabulary. So I can also see how people might not enjoy working within these confines of boring syntax and boring frameworks. JOËL: Sometimes it's nice to give yourself a sort of syntactical restriction, but they're very low-level when it comes to most of what we do for programming. And I think that's sort of what I've learned as my career has evolved is that programming is so much more than just learning syntax. So kind of like with art, maybe it's nice to restrict yourself to say, oh, can I do something with only a particular brushstroke technique, or restricting myself to a particular palette or a particular medium? And that can foster a lot of creativity. So, similarly, I think you could do some things like playing Code Golf, not on production code; please don't. STEPHANIE: [laughs] JOËL: But as an experiment in a side project or just almost as a piece of art, that can be a really interesting problem to solve and give you a deeper understanding of the language. And I'm sure there are plenty of other syntactical limitations you could put on yourself or maybe fancy things you would like to explore and say, "Well, this is over the top. We don't need to structure it in this way or use this syntax. But I want to sort of push the boundaries of what can be done with it. Let's see where I can take it." STEPHANIE: That's really fair. And I think it relates back to what I was saying earlier about perhaps creativity when writing software products comes from the constraints of the business of, in some ways, physical aspects of development. In the Dan McKinley talk, I mentioned about choosing boring technology. He generally recommends against bringing in a new language or framework because of the costs, the carrying cost of doing that, and the long-term maintenance to consider. But he instead suggests turning the question on its head and being like, how can we solve this problem with the current technology that we do have? And I think that relates to what you were saying about being able to push the boundaries of a particular medium or tool and in a way that you might not have considered before. JOËL: Exactly. And I think going back to the analogy with art; sometimes it is nice to restrict yourself to a particular brushstroke or something like that to try to foster creativity. But oftentimes, you want to explore creativity in much higher-level ways. So maybe you're not restricting things like brushstrokes and color, and, instead, you want to explore lighting. You want to explore maybe certain ways of mixing colors. There are all sorts of, I think, higher-level ways that you can be creative in art that's not just the mechanics of how you apply pigment to canvas. And we see the same thing like you were saying, in code where there's a lot of higher level business problems. Generally, how do we want to structure large chunks of the code? How do we want to build abstractions? Although that can also be a dangerous place to get too creative in. STEPHANIE: Yeah, absolutely. Do you consider yourself a creative person or need a creative outlet? And how does writing code or software development play a role in that for you? JOËL: I would say, yes, I consider myself a creative person. And I would consider coding, in general, to be a creative endeavor. I sometimes describe to people that writing code is like building something out of infinite legos. You're constrained only by the power of your imagination and the amount of time you're willing to put into constructing the thing that you're building. Of course, then you have all sorts of business constraints. And there are things you want to do on a work project that are probably not the same as what you would want to do on a client project or on a personal project. But there's still creativity, I think, at every level and sometimes even outside of the code itself. Just understanding and breaking down the business problem can require a ton of creativity before you even write a single line of code in your editor. I was reading a Twitter thread the other day by @GeePawHill that sort of proposes that there are sort of four steps in evolution of kind of the mindset that programmers go through over their career. And I'd be curious to hear your thoughts on this evolution if you kind of agree with it or disagree with it if that maybe lines up with some of your experience. So this Twitter thread proposes four levels of thinking that we go through. I think we can kind of jump between these levels at various points in our work. So we might do all of these in a day, but to a certain extent, they also follow a little bit of a progression in our career. So the first level is thinking in terms of syntax; that's just knowing the characters to type in the editor. The second level is thinking in terms of code, that's, thinking a little bit more semantically. So now, instead of thinking, oh, do I need if then curly brace, then closed curly brace? Now we're thinking more in terms of, okay, I need a branch in the flow of control for my logic here. And at that level, maybe you don't even need to think about the syntax quite so much because you're so comfortable with. It kind of just fades away. Building beyond that, now you're thinking in terms of your paradigm. So Ruby is an object-oriented language, so you might be thinking in terms of what objects do I need to represent this problem and how do they need to talk to each other? And the sort of underlying semantics of, oh, do I need a conditional here or not? Those might start fading away because now you're thinking at a slightly higher level. And then, finally, thinking in terms of change sets. Now you're thinking less in terms of the language itself and more in terms of the business problems and how the current behavior of the software is different and needs to change to get to where we want the behavior to be. STEPHANIE: I think I disagree a little bit with the idea that it's a progression. And I'm thinking about how when you have a beginner's mind, anything is possible. And in some ways, if you are new to coding, before you have that understanding of what is and isn't possible, anything is possible. And so, in some ways, I've worked with people who are super new to coding, and the ideas that they come up with for how to make a change at that highest level that you were just describing, in some ways, make sense. You can be like, oh yeah, that actually is something we can do and an idea that you might eventually get to from someone more experienced, having followed those different levels of progression and reaching a place where you're like, I know exactly what tools or the details about how to do this. But when you have that beginner's mind, and you don't have the details of the how, I think you can still think about those problems at a higher level, and that is valuable, and maybe they'll need help implementing along the way. And I think that that could be a really interesting area of collaboration that perhaps we don't do enough in this industry because it's very mentorship-focused where it's like, okay, I have more experience, and so I'm going to teach you what I know. Whereas if you bring someone with a totally fresh perspective along, what ideas can you generate from there? JOËL: I think we definitely exist in all of these layers every day as developers. I think, looking back at myself as a newer developer, I tended to maybe work bottom-up when I tried to solve a problem. And I think that now I probably tend to work sort of in the reverse order, start by thinking in terms of changes and then work my way down. And so syntax, at that point, is the last thing that I'm thinking about. It's really an implementation detail. Whereas I think as a new coder, syntax was super important. Was your experience similar to that, or did you have a very different journey? STEPHANIE: It's funny that you mentioned it because I think when I was new to development, there were so many syntactic things that I didn't understand that I just kind of like blurted out of my brain when I was reading code and was then trying to latch on to the important pieces of information that I needed to know, which often meant class names or method names. Pieces that I could grab onto and be like, okay, I'm seeing that this method then calls this other method or whatever. And, yeah, what you were saying about implementation details falling away, I kind of did that at the beginning of my career a little bit, at least at that syntactic level. So, yeah, I think I'm with you where we all exist at different parts of this framework, I suppose. And that journey could look different for everyone. JOËL: So we're talking about ways to be creative at higher levels. And one way that I find has been really fun for me but also really useful has been bringing in dependency graphs as a tool for design. You knew I had to mention dependency graphs. STEPHANIE: We got there in the end. [laughter] Cool, go on. JOËL: I think it's been really good sometimes in terms of modeling change sets because dependency graphs can be a great tool for that, but also sometimes in terms of trying to understand what the underlying business problem is and how it might translate into code structures where things might be tightly coupled versus not. And so, drawing it out visually is a really powerful design tool. And because now I can look at it in two-dimensional space, I can realize, oh, I see something that feels like it's maybe an anti-pattern or might be a problem here. There's a cycle in my graph; maybe we should find a way to break that. Maybe we need to introduce some dependency inversion and break that cycle, and now our graph is acyclic. And so I think that's where there can be a lot of creativity that happens, even when you're not writing code at that point. You're just sort of talking about how different pieces of the project or even different subproblems...you're not even talking about if they're implemented in code, but just saying this subproblem is related to this subproblem, and maybe I would like to find a way for them to not have a connection to each other. STEPHANIE: I'm glad we got back to this dependency graph topic because I stumbled upon something that I'm curious to hear your opinion on. I have been following Julia Evans' work for a little bit now. And she recently released a new zine about debugging. And at the end of the zine, she includes a link to these choose-your-own adventure puzzles that she has created, specifically to teach you about debugging and how to do it. And so it's basically a little detective game, and you kind of follow along with this bug. And she gives you some different options about how would you like to find a little bit more information about this bug? And what approach would you take? And you make some different selections, and then as you go, you get more information about the bug. And that helps inform what next steps you might take. And, one, I think this is a great example of a creative project about software development, even though it's not necessarily your day-to-day work. But then she also uses a tool called Twine, which is for creating non-linear stories, or puzzles, or games. And it got me really thinking about the multi-step wizard we've been talking about and this idea of looking at a problem in different mediums. It also reminds me of if you have a designer on your team and they're doing prototyping, they usually have some kind of user interactivity that they have to codify. And they are making those decisions about okay, like, if you are at this step, then where do you go next? And those are all things that you've talked about doing as a developer, I think, at a later point in the future lifecycle. And I'm now just kind of thinking about how to integrate some of that into our workflow. Do you have any thoughts about that? JOËL: I had one of the coolest experiences in my career when I was doing a front-end project where we were building a typeahead component that was pulling data from a remote server and then populating a drop-down. And the designer and I sat down and just started to look through all the different states that you could be and how you could move from one to another. So it looked like maybe you start the typeahead is empty; it's just a text box. And then as you start typing, maybe there's a spinner that shows up. And then maybe you have some results, or maybe you don't have results. And those are two different entirely states that you could be in. And then, if you backspace, what happens? And what if something goes wrong on the server? Like, we just kept finding all these edge cases. And we built out a diagram of all the possible journeys that someone could take, starting from that empty text box, all the way to either some sort of error state or a final state where you've selected an item. But, of course, these are not necessarily terminal because in an error state, maybe you can just start typing again, and you sort of jump back into the beginning of the flow. So we did this whole diagram that ended up looking very much like a finite-state machine. We didn't use the term, but that's kind of what it ended up being. And I think we both learned a lot about the problem we were trying to solve and the user experience we were trying to create through that. There was just a lot of back and forth of, like, oh, did you think about what would happen if we get no results here? Have we thought about that state? Or it's like, okay, so now we're in an error state. What do we do? Is there a way to get out of it, or are we just kind of stuck? Oh, you can backspace. Okay, what happens then? STEPHANIE: Yeah, I mean, we've been talking about creativity as a solitary process. But I think that that goes to show that when collaborating with other people, too, that process can also be very fun and creative and fulfill that need outside of the way the code is written. JOËL: In many ways, I think working with somebody else, and that gets made at the intersection of two or more people's work, is probably the most creative way to build software. STEPHANIE: That actually reminds me of a book I read last year called "Tomorrow, and Tomorrow, and Tomorrow." And it's about these two friends and their journey creating video games together. And it kind of follows several decades of their life and their relationship, and their creative and collaborative process. And I really loved that book. It was very good, especially if you like video games. There are a lot of great references to that too. But I think what you were saying about that fulfillment that you can get with working with other people, and that book does a really good job examining that and getting into our need as humans for that type of collaboration. So that's my little book rec. It goes back to our conversation about designing a game. Again, maybe this is [laughs] what we'll do next. Who knows? The world's our oyster. 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: Thank you so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Expert Maggie Appleton discusses the importance of diagramming in coding, the squint test for code clarity, cardinality of types, honeycomb hexagon construction, the strangler fig pattern for legacy code, and finding time to refactor. Hosts reflect on impactful articles of 2022, embracing coachability, and strategies for code improvement.

Stephanie talks about hosting a Soup Group! Joël got nerd-sniped during the last episode and dove deeper into Maggie Appleton's "Tools for Thought." Stephanie has been thinking a lot about Sustainable Web Development. What is sustainability? How does it relate to tech and what we do? This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Maggie Appleton's Tools for Thought Tangrams Tessellation Hexagons are the Bestagons Sustainable Web Development with Ruby on Rails Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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'm excited to share a winter survival idea for folks out there who are, like me, in a very cold place where all your friends don't want to hang out [laughs] and bear the cold temperatures of deep winter in January. Because tonight, I'm hosting my first soup group where I'm basically just going to make a really big batch of soup and have my friends come over with bread, and we're going to eat soup and bread and be cozy. And I'm really excited because I was trying to figure out a way to combat the winter blues a little bit. And, yeah, I think this time of year can be really tough after the holidays to get people together again. At least for me, I was feeling like I haven't seen my friends in so long. And I was like, well, I could just be the person to take the initiative [laughs] and be like, "Come over to our place." And the goal is to eventually do this regularly and just have this low-stakes open invitation for anyone to come and show up however they want to. It doesn't have to be, like, big pressure or anything. And if they can't make it at any one time, then there will hopefully be one in the future where they can make it, so I'm excited. After this, I am going to make soup for ten people, and it's going to be great. [laughs] JOËL: I love this idea. Soup on a cold day is just the coziest thing. STEPHANIE: Yeah, exactly. I definitely wanted to just make people feel warm and cozy. And that's what I want, so I'm really doing this for myself. [laughs] JOËL: And you know the advantage of hosting is you don't have to go outside. STEPHANIE: Yeah, that's the real thing is I'm probably going to kick everyone out at like 11:00 p.m. and then go straight to bed, and it's going to be great. [laughs] JOËL: Have you been experimenting with a particular kind of soup recently? Are you going to bring out an old favorite? STEPHANIE: Yeah, I'm excited to make ribollita today, so kind of like a Tuscan style of veggie hearty soup. And I've just been bookmarking soup recipes left and right. [laughs] And I've outsourced the bread situation. So I'm excited to see what kind of bread people bring. And yeah, it'll be very fun and kind of surprising in a comforting way. JOËL: I'm not familiar with this soup. It's ribollita you said? STEPHANIE: Yeah, that's it. JOËL: You said it's a vegetable soup. STEPHANIE: Yeah, mostly veggies and beans. So I have this giant cabbage, a lot of kale, multiple cans of Great Northern white beans, and they're all going to get mixed together. And we'll see how it turns out. I'll update the podcast on how the soup group goes. It is the inaugural one. So I can't think of a time that I made that much soup before. So, hopefully, it goes well. We'll find out. So, Joël, what about you? What's new in your world? JOËL: So, in the previous episode, we talked a little bit about some of the things you had learned about note-taking. And you'd mentioned an article by, I think, Maggie Applebon -- STEPHANIE: Maggie Appleton. JOËL: Appleton...on tools for thought. It was linked in the show notes of that episode. And I went back and read that article, and it was so good, particularly the section, I think, on historical tools for thought and how they, over time, were sort of groundbreaking in helping us to either remember things or to think about problems or ideas in a different way, or to sort of interrogate those ideas and see if we think they're true or helpful. And these were things like writing or the number system but even some more fancy things like the scientific method for the Cartesian coordinate system. STEPHANIE: Yeah, I was really excited to share this with you because I think it was the intersection of a lot of your different interests, including note-taking, diagrams, history, and human cognition, so I'm glad that you found it interesting. JOËL: I definitely got nerd-sniped there. STEPHANIE: [laughs] JOËL: I think one thing that really struck me was the power of having multiple different representations for ideas. And one that jumped out at me was the Cartesian coordinate system, which, among other things, a really powerful tool that gave people...when this was invented, it allowed you to convert algebra problems into geometry problems. And so now, something that used to be an equation you can draw as a triangle or something. And we know how to find the area of a triangle. That's been known since the ancient Greeks and even earlier. And so now a problem that sounded hard is now easy, or at least we have a different way to think about that problem. Because if this equation is equivalent to a triangle, what does that mean? And vice versa, you can use this to convert geometry problems into algebra problems. And so sometimes the power of a new tool for thought might be in that it allows you to sort of convert between two other existing ways of representing things. And making those connections, all of a sudden gives you a whole new way of thinking about things. That blew my mind. STEPHANIE: Yeah, I agree. I think the other really cool thing is that a lot of these ideas that humans are discovering also already existed in the natural world. So when you are talking about math, you can see representations of math in plants and nature, and I was reminded of how honeycomb from bees is one of the strongest shapes. And yeah, it's really neat to draw inspiration from a lot of places and learn from things that, like, figured it out before we did. JOËL: Have you seen the video on YouTube called "Hexagons are the Bestagons?" STEPHANIE: No, I have not. Tell me more. JOËL: It's a video on YouTube. We can link it in the show notes. Basically, the hexagon shows up everywhere in nature in part because it has a lot of really fun mathematical properties. It's one of the few shapes that you can use to completely cover a surface. So if you want to subdivide a two-dimensional surface into smaller shapes without leaving any empty spaces between them, you really don't have that many options. I want to say it's like squares and triangles and hexagons are the only shapes that can do that. And hexagons have these really fun properties around strength. They also are one of the best balances between volume versus the amount of material that it takes to give you that volume and for strength and things like that. So it's good for honeycombs because you can store a lot of honey for very little amount of wax. But it's also good for all sorts of structural engineering because you can build things that are very strong yet light because they require very little metal or other material to create them. STEPHANIE: When you're saying hexagons filling a lot of space, I also thought about how they've become kind of popular in tiles or interior design in kitchens, and bathrooms, and stuff. [laughs] I've definitely seen that trend a bit. [laughs] So that's really cool just to see, like, yeah, this thing in the natural world that we have adopted for other uses. It's really fun. JOËL: I want to say this idea of taking a 2D space and being able to completely cover it without spaces with a shape is called tessellating a plane. It's a fancy term for it. And if you want to do it with just a single shape, I think there are only like three or four shapes that can do it. STEPHANIE: That's really interesting because it reminds me of those tessellation puzzles that I used to play with as a kid. Do you know what I'm talking about? JOËL: You're thinking like a tangram or something different. STEPHANIE: Yeah, yeah, tangram, that was...oh my gosh, those were fun. Wow, I was learning math as a young child, [laughs] just didn't even know it. JOËL: Another random fun fact: the logo for the Elm programming language is a tangram. STEPHANIE: [Gasps] JOËL: And the community is sort of encouraged to then remix it because the tangram is just a square tessellated out of a bunch of these shapes. But then, if you're building a library or you've got an event or something, the community will take those shapes and remix them into some other shapes that might fit your event. STEPHANIE: That's really cool. Is it a metaphor for how Elm can be used in different ways? [laughs] JOËL: I'm not sure about the story behind the logo. We'd have to look that up. STEPHANIE: That'll be a good adventure for later. [laughs] JOËL: In...I want to say Moroccan art, but I think it might be broader than just Moroccan. It might be more broadly North African or Moorish or whatever you want to call that. There's a long history of building these tessellations, I think, out of tiles, but maybe other things as well where you're doing it with a variety of shapes. So you might start...a classic one, I think is an eight-pointed...is it eight, or? I think it's an eight-pointed star, and then you sort of add other shapes around it. And those can create patterns that take a long time to repeat. And there are these beautiful geometric patterns that just keep on going and expanding without necessarily repeating over a lot of space. STEPHANIE: Whoa. That kind of blows my mind a little bit. It seems so counterintuitive, but then I feel like there are a lot of things in math that are like that as well. JOËL: So, yeah, I think a classic pattern you might start with something like an eight-pointed star. And then maybe to fill in the spaces around that central star, you might put some squares, and then maybe you put some triangles around that, and you sort of keep trying to fill in. And maybe eventually you get to another eight-pointed star, but it's not always perfectly symmetric. STEPHANIE: Someone should make a board game or something out of this idea. [laughs] JOËL: Oooh. STEPHANIE: I bet there's one that exists. But I'm just thinking about people who like jigsaw puzzles and that being the next level challenge of, like, can you figure out how things fit together without the confines of a little jigsaw shape? [laughs] JOËL: Right, right. You have a rectangle shape that you have to perfectly fill in with all of these other smaller shapes, and there is a single solution that will work. You have to figure it out. STEPHANIE: I personally would be very overwhelmed, [laughs] but it sounds fun at the same time. JOËL: So those are a lot of thoughts that I've been having inspiration reading that article that you shared on a previous episode. Have you been reading anything interesting recently? STEPHANIE: I have. I'm really excited to talk about this topic because during my investment time this past week, I've been thinking a lot about it, taking a lot of notes in Obsidian, which is a callback to the last episode, and yeah, I'm excited to kind of get into it. So what I've been reading is Sustainable Web Development with Ruby on Rails by ‎David Bryant Copeland. And I think a lot of fellow thoughtboters have referenced this book or talked a little bit about ideas from this book; at least, I've seen discussion about it in Slack, so that's kind of why I wanted to pick it up. But what really blew my mind was honestly the first chapter where he talks about why he wrote this book and basically what sustainable web development is because it is a little bit, maybe, like a buzzy word. It's like, what is sustainability? How does it relate to tech and what we do? And he basically gets down to it by saying that the software that we write is sustainable if it continues to meet our needs years into the future or has longevity and continues to be something we can iterate and work on and not feel that pain or friction, and we feel like we want to, and we feel joyful working on this codebase. So that was kind of my interpretation of his definition about sustainability. JOËL: I love that definition of sustainability about code that can grow and live for a long time. And I feel like that's not a universal value in the tech industry. And on the extreme end of that, you'll have teams that promote the idea that maybe every few years, you should throw out your old codebase and rewrite. I want to say some teams at Google may have done that as a practice for a while, and, of course, then people quote that as a best practice. To a certain extent, I want to say that's kind of what happens with Basecamp in that there are multiple versions of Basecamp. And I want to say each of those is a fresh Rails app. So there's a sense in which those or that style of development is not sustainable in the definition that you were just giving there. How do you feel about that? STEPHANIE: I definitely think the industry has a bias towards newness and change. And a lot of people want to pick up the hot, new technology and, like you said, rewrite code, especially when it's become hard to work with. And honestly, I think that could be its whole own episode, rewrites because I think you and I have pretty strong opinions about it. But I genuinely think that most of our work is, at least, you and I on the Boost team, in particular here at thoughtbot, where we embed on existing client teams, and usually, that means legacy code as well, but I think that the work of development is mostly extending existing code and trying to sustain applications that have users and are working for users. And I think that that's certainly a value that I wish were highlighted more or were invested in more because sometimes that change or wanting to hop on to do something different or do something new has a lot of consequences that I'm not sure we talk about enough as an industry. 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: It's interesting you mentioned the types of projects that we tend to be on. I feel like there are a lot of projects that I've been brought on where my goal, specifically coming onto this project, was to make the software more sustainable for the team. It's very easy to sort of start moving very fast in the beginning with a greenfield app, and then eventually, a lot of your choices catch up to you. And then, as your team grows and your product grows, it becomes less and less sustainable. And that's often the point in the lifecycle of the product where I might join the team and try to help make things better for them. I love the keyword sustainable. I don't think that's one that I've used a lot, but it's a great label to put on that kind of work. STEPHANIE: Yeah, I agree. I think what you mentioned earlier, too, about values that, really stuck out to me in this book because it basically says, "This book is for you if you value these three things: sustainability, consistency, and quality." And all of the recommendations and techniques that he then presents in the rest of the book, using Rails, those decisions are recommended with those three values in mind. And I think, one, those values are personally important to me as a developer. But it also helped me develop some guiding principles around decision-making and provided a lot of clarity around times that I've been on teams where we were doing things that didn't quite align with my values, and I didn't enjoy it. And I couldn't really figure out why. But now I'm able to see that, oh, perhaps this team or organization was valuing something like speed, or profit, or change, or something like that that I just fundamentally value differently. And that was kind of where my internal friction or contentment or discontentment was coming from when working on these teams. So, yeah, that was really clarifying for me. JOËL: Would you say, for you, when you talk about these values, that these are fundamental or ultimate values for you when you write code? Or are they values that are a good way to sort of be a means to some other end? You know, for example, sustainability, do you care about sustainability just for its own sake? Or do you care about it because you want a product to be able to live for a long time? You're building for ten years or 20 years or however long you want this project to last. STEPHANIE: I think the thing with values is that they are really fundamental to a person's identity or belief system. In fact, the definition that I'm kind of working off of here is that values are those fundamental beliefs that drive our actions. And so when you say, like, are values driving how you write code? I think they drive everything. [laughs] But the point that he makes in this book is like, here's how they drive code and technical decisions. So the book is actually quite specific about technical recommendations that he has in the context of Rails. And it's funny because we're talking pretty abstractly and big picture about values and things like that. But then I think it's because he sets the stage to be like, everything I recommend here is what I believe to be sustainable, and good quality, and consistent. And just for an example, one of the recommendations he makes is to, when you're kind of setting up a greenfield application, is to use a SQL schema instead of the default ActiveRecord DSL, so using a structure .SQL file. Because, in his eyes, having the flexibility to write SQL and use the most you can with those tools when it comes to database work is more sustainable in the long term than using the DSL that might not have all the tools available to you that SQL does. And so he kind of gives his reasoning about, like, this is what I recommend, and here's why it contributes to sustainability, in my opinion. And so I have found myself, while I'm reading along, either agreeing, like, oh yeah, I can see his reasoning here, or maybe even disagreeing because I might think about things differently or have other considerations in mind that are more important to me and what sustainability means to me. But what I hopefully want to take away from the framework or understanding of values is evaluating technical decisions that I make based on my values as an individual but, more importantly, the values of the team or organization. JOËL: I love mental frameworks like that that give you clarity into your own thought processes or how you make decisions moving forward. Sometimes you can look at something that's very concrete. Somebody gives you some advice on maybe structuring your database schema, and that might be helpful in and of itself. But if you came away with a larger thought process, I think that's doubly valuable. As an aside here, I love this approach to writing where he sort of lays down almost like preconditions for this book. If you don't agree on these values, this book is not going to be very helpful for you. And then also, here are situations where this advice is not going to apply. Now that I've put down all these edge cases for the rest of this book, I'm going to be speaking very decisively; these are the things I recommend and not have to caveat myself all the time. It's like, yes, I know there are some edge cases where you might not want to do this if it's a one-off script or whatever it is. We've already dealt with all of those upfront. And now, I can be very confident and very direct for the whole rest of the book. And I feel like that's something I struggle with in some of my work sometimes is. I care a lot about nuance, and my audience probably cares about edge cases even more than I do. They probably care too much. Because I say something that's generally true most of the time, and I know somebody's already thinking about the one edge case where that's not true. And that doesn't matter for the main point I'm trying to make. So it's always a struggle to know when to caveat a statement that I'm making. But if you caveat too much, then you undermine your whole point. And so I like this idea of putting some caveats up front and then just saying, like, now we're in the 80% case. Within the 80% case, these are things I think are true. STEPHANIE: Yeah, that's a really good point. I agree he is very clear about the intended audience. And so when you read this book, you are either on board because you value the same things he does, or you're not because you are focused and your goals are things that are different from him. So I think it was really helpful to get on the same page, even in a piece of content or in a piece of writing. Because I want to use my time well as a reader, so I want to make sure that what I am consuming makes sense for me, and I will find it worthwhile. David takes a really strong stance on what quality means. And even though that is a pretty subjective value, he describes it as doing things right the first time and acknowledging the reality that we likely won't have the time to go back and clean things up after they've been shipped. So, on this client project, I found myself wanting to refactor things as part of my process, suggesting different implementations to do things the quote, unquote, "right way," or the best way we could, and not everyone shared that sentiment. I sometimes got pushback, and that was challenging for me to figure out how I wanted to navigate that situation and what I was willing to let go and what I wasn't. And so I'm curious if you've ever been in a consulting position like that where maybe the team and organization's values were a little bit different from your understanding, or if they just weren't clear at all, and you were driving towards something that seemed very nebulous. JOËL: I think I've been on both sides of that, both sometimes saying, "Look, we need to maybe slow down," or "Here's a thing that we need to do otherwise that's going to cost us on the longer term. Here's an area where we need to invest in quality today." And sort of on the other side where I'll feel like someone is really pushing an overengineered solution claiming it's going to make life a whole lot better, "If we invest three months upfront today, and maybe in three or four years, it'll pay off if certain things happen," that don't really necessarily line up with the immediate goals. A lot of this, I think, comes down to understanding the client, and their business, and their goals. Sometimes there is a really important deadline for something that has to happen based on an event in the real world. If you were building software for something that had to do with, let's say, the World Cup, you don't want it shipping in January 2023. That's just pointless. And so you've got to prioritize shipping things. And sometimes you say, "Okay, well, do we ship a few broken things? Or do we prefer to ship something that's a little bit smaller, more tightly scoped, but that holds well together?" That again, you have to really understand the client, their business, their needs. So I think for me those values of sustainability, quality...I forget what the third one was that you'd mentioned. STEPHANIE: Consistency. JOËL: Consistency, yes. They all sort of inform how it's going to mesh with the product I'm working on, the goals of that product. Where's it going in the next three months, six months, 12 months? Where's it coming from? Who's the team that I'm working with? Am I with a team of 300 people that are just committing to the main branch all the time with no tests, and we're constantly fighting regressions? Then sustainability looks very different there than a one other-person team, and we're trying to ship something for the World Cup. STEPHANIE: Oh yeah, I have a lot of thoughts there too. Because I do agree that it can look different and sometimes shift a little bit depending on the situation. What you were just describing about team makeup that is really interesting to me because, yeah, sustainability can look different for different teams. If you have, let's say, a lot of earlier career developers on your team, maybe you really want to focus on readability and making sure that they're able to navigate the codebase and figure things out over something like more advanced patterns and skills that will just cause them friction. But maybe you have a team where you all agree that that's what sustainability means to you is choosing those more advanced technical patterns and committing to them and figuring out how to maintain that because it's important to you. And the other thing that you brought up that is also mentioned in this book is that the more information developers have about the future and direction of the business, the better code we can write. For some reason, I've found myself in situations where I don't know all too much about what we are working towards or what the goals of the business are both in the short term and the long term. And I try to make the best guess I can. But I think in those scenarios, at least moving forward, I would really like to be better about pushing product folks or leadership to explain to me why we're doing what we're doing, kind of share the information that they have so that we can build the best product that we can. I think sometimes that information doesn't get shared for some reason. They kind of think that engineers are going to go do their engineer thing, and we'll focus on long-term strategy over here. But yeah, I truly believe that the more information we have, the better quality work we can produce. JOËL: I 100% agree. And I think that's what we see in a lot of classic agile literature talking about things like cross-functional teams or even the client or the product team should be integrated with the development team. You're all one team working together rather than someone has an idea, and then the technical team executes on it. We see that also in some of the domain-driven design literature as well, where oftentimes projects start, and you sit down with a subject matter expert, and they just walk you through all of the business aspects. And particularly for the purpose of domain-driven design, you talk about a lot of the terms that make sense for the business. You build up a glossary of terms. I think they call it a ubiquitous language of things that are specific to your business and how does that work on a day-to-day basis. STEPHANIE: Do you have any strategies for getting more clarity around the work and why you're building it if it's not yet available to you? JOËL: I think there are sort of two scenarios where you have to do that; one of them that comes up maybe more often for us as consultants is onboarding onto a new client. There's a whole new business that we may know nothing about, and we have to learn a lot of that. And so, as part of the onboarding process, I think it's really valuable to have conversations with people who are not part of the dev team to learn about the business side of things. On a per-feature basis, if you've already been onboarded on a project, you've been there for a while, it's often good to go back to the person who maybe created a ticket, a product person who's asking for a feature, and ask, "Why? Why do you want this?" Ideally, maybe that's even part of the ticket-creating process because the two teams are more integrated, and product team is like, here's a problem we're trying to solve. Here's what we think would be a solution. Or maybe even just "Here's a business problem. We need a technical solution. Can you do that for us?" But I've often followed up with people outside of the engineering team to ask follow-up questions. And why are we doing this? And sometimes it's even you have to do like five Whys where it's like, "Oh, we're doing this because we need to do this thing for this customer. They asked for it." And it's like, "Okay, well, why are they asking for that?" "Oh, it's because they have this problem." And why are they having this problem?" And eventually, like, "Oh, I see. Okay." The real solution has nothing to do with what was asked, and you come up with something that's maybe much tighter scoped or will better solve, and everybody's a winner in that case. But it does require following up. So I guess the short and boring answer is talk to people outside the engineering team. STEPHANIE: That's a great point. I think the questions that we as engineers ask can drive more clarity to product people as well if we continue to ask those five levels of why in ways that they maybe didn't think about either. We have the opportunity to do that if we want to do our work well, too. That's kind of exciting to me that it isn't just okay, we're handed some work to do, and they've done all of that strategic thinking separately. And having to implement those details, we can kind of start to chip away at what are we really doing here? And you mentioned talking to people outside of the engineering team. I just was thinking that pairing with non-developers would also be a really great task to do, especially when you get a ticket that's a bit ambiguous and you have questions. And you can always comment on the ticket or whatever and ask your questions. But perhaps there's also a good opportunity to work things through synchronously. In some ways, I think that is a more natural opportunity for that conversation to evolve rather than it being like, okay, I answered these questions, and now I'm going to move on to whatever else I have to do. JOËL: So you mentioned pairing. It's often good to have someone maybe outside the development team pair with you on a technical thing, but sometimes it's good to flip the script. If you're building especially software for an internal team, it can be really valuable to just shadow one of them for a couple of hours or a day. I did a project where we were building a tool for an internal sales team. And I had the privilege to shadow a couple of the sales members for a few hours as they're just doing their job. And I'm just asking all the questions like, "Oh, why do you do it that way? And what is the purpose behind this?" And I learned so much about the business by doing that. STEPHANIE: I love that we took this idea of sustainable development and went beyond just technical design decisions or aspects of how we do our jobs. Because there is so much more that we can do to foster the value of sustainability or whatever other values that you might have, and yeah, I feel really excited to try both these technical strategies from the book and also the collaborative aspects as well. JOËL: I'm really excited about some of these ideas that are coming up from the book. I think today we basically just talked about the introduction, the idea of sustainability. But I think as maybe you read more in the book, maybe we can do another episode later on talking about some of the more specific technical recommendations, how they relate to sustainability and maybe share some of our thoughts on that. STEPHANIE: Yeah, I definitely am excited to keep y'all updated on this journey. [laughs] JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. JOËL: Show notes for this episode can be found at bikeshed.fm. This show has been 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. Byeeeeeeee!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Joël's been traveling. Stephanie's working on professional development. She's also keeping up a little bit more with Ruby news and community news in general and saw that Ruby 3.2 introduced a new class called data to its core library for the use case of creating simple value objects. This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Maggie Appleton's Tools for Thought Episode on note-taking with Amanda Beiner Obsidian Zettelkasten Evergreen notes New Data class Joël's article on value objects Episode on specialized vocabulary Primitive Obsession Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. 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 little bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been traveling for the past few weeks in Europe. I just recently got back to the U.S. and have just gotten used to drinking American-style drip coffee again after having espresso every day for a few weeks. And it's been an adjustment. STEPHANIE: I bet. I think that it's such a downgrade compared to European espresso. I remember when I was in Italy, I also would really enjoy espresso every day at a local cafe and just be like sitting outside drinking it. And it was very delightful. JOËL: They're very different experiences. I have to say I do enjoy just holding a hot mug and sort of sipping on it for a long time. It's also a lot weaker. You wouldn't want to do a full hot mug of espresso. That would just be way too intense. But yeah, I think both experiences are enjoyable. They're just different. STEPHANIE: Yeah. So, that first day with your measly drip coffee and your jet lag, how are you doing on your first day back at work? JOËL: I did pretty good. I think part of the fun of coming back to the U.S. from Europe is that the jet lag makes me a very productive morning person for a week. Normally, I'm a little bit more of an evening person. So I get to get a bit of an alter ego for a week, and that helps me to transition back into work. STEPHANIE: Nice. JOËL: So you've also been on break and have started work again. How are you feeling productivity-wise, kicking off the New Year? STEPHANIE: I'm actually unbooked this week and the last week too. So I'm not working on client projects, but I am having a lot of time to work on just professional development. And usually, during this downtime, I also like to reassess just how I'm working, and lately, what that has meant for me is changing my note-taking process. And I'm really excited to share this with you because I know that you have talked about this on the show before, I think in a previous episode with a guest, Amanda Beiner. And I listened to that episode, and I was really inspired because I was feeling like I didn't have a note-taking system that worked super well for me. But you all talked about some tools you used and some, I guess, philosophies around note-taking that like I said, I was really inspired by. And so I hopped on board the Obsidian train. And I'm really excited to share with you my experience with it. So I really like it because I previously was taking notes in my editor under the impression that, oh, like, everything is in one place. It'll be like a seamless transition from code to note-taking. And I was already writing in Markdown. But I actually didn't like it that much because I found it kind of distracting to have code things kind of around. And if I was navigating files or something, something work or code-related might come up, and that ended up being a bit distracting for me. But I know that that works really well for some people; a coworker of ours, Aji, I know that he takes his notes in Vim and has a really fancy setup for that. And so I thought maybe that's what I wanted, but it turns out that what I wanted was actually more of a boundary between code and notes. And so, I was assessing different note-taking and knowledge management software. And I have been really enjoying Obsidian because it also has quite a bit of community support. So I've installed a few plugins for just quality-of-life features like snippets which I had in my editor, and now I get to have in Obsidian. I also installed things like Natural Language Dates. So for my running to-do list, I can just do a shortcut for today, and it'll autofill today's date, which, I don't know, because for me, [laughs] that is just a little bit less mental work that I have to do to remember the date. And yeah, I've been really liking it. I haven't even fully explored backlinking, and that connectivity aspect, which I know is a core feature, but it's been working well for me so far. JOËL: That's really exciting. I love notes and note-taking and the ways that we can use those to make our lives better as developers and as human beings. Do you have a particular system or way you've approached that? Because I know for me, I probably looked at Obsidian for six months before I kind of had the courage to download it because I didn't want to go into it and not have a way to organize things. I was like; I don't want to just throw random notes in here. I want to have a system. That might just be me. But did you just kind of jump into it and see, like, oh, a system will emerge? Did you have a particular philosophy going in? How are you approaching taking notes there? STEPHANIE: That's definitely a you thing because I've definitely had the opposite experience [laughs] where I'm just like, oh, I've downloaded this thing. I'm going to start typing notes and see what happens. I have never really had a good organizational system, which I think is fine for me. I was really leaning on pen and paper notes for a while, and I still have a certain use case for them. Because I find that when I'm in meetings or one-on-ones and taking notes, I don't actually like to have my hands on the keyboard because of distractions. Like I mentioned earlier, it's really easy for me to, like, oh, accidentally Command-Tab and open Slack and be like, oh, someone posted something new in Slack; let me go read this. And I'm not giving the meeting or the person I'm talking to my full attention, and I really didn't like that. So I still do pen and paper for things where I want to make sure that I'm not getting distracted. And then, I will transfer any gems from those notes to Obsidian if I find that they are worth putting in a place where I do have a little bit more discoverability and eventually maybe kind of adding on to my process of using those backlinks and connecting thoughts like that. So, so far, it's truly just a list of separate little pages of notes, and yeah, we'll see how it goes. I'm curious what your system for organizing is or if you have kind of figured out something that works well for you. JOËL: So my approach focuses very heavily on the backlinks. It's loosely inspired by two similar systems of organization called Zettelkasten and evergreen notes. The idea is that you create notes that are ideas. Typically, the title is like a thesis statement, and you keep them very short, focused on a single thing. And if you have a more complex idea, it probably breaks down into two or three, and then you link them to each other as makes sense. So you create a web of these atomic ideas that are highly interconnected with each other. And then later on, because I use this a lot for either creating content in the future or to help refine my thinking on various software topics, so later on, I can go through and maybe connect three or four things I didn't realize connected together. Or if I'm writing an article or a talk, maybe find three or four of these ideas that I generated at very different moments, but now they're connected. And I can make an article or a talk out of them. So that's sort of the purpose that I use them for and how I've organized things for myself. STEPHANIE: I think that's a really interesting topic because while I was assessing different software for note-taking and, like I said, knowledge management, I discovered this blog post by Maggie Appleton that was super interesting because she is talking about the term tools of thought which a lot of these different software kind of leveraged in their marketing copy as like, oh, this software will be like the key to evolving your thinking and help you expand making connections, like you mentioned, in ways that you weren't able to before. And was very obviously trying to upsell you on this product, and she -- JOËL: It's over the top. STEPHANIE: A little bit, a little bit. So in this article, I liked that she took a critical lens to that idea and rooted her article in history and gave examples of a bunch of different things in human history that also evolved the ways humans were able to express their thoughts and solve problems. And so some of the ones that she listed were like storytelling and oral tradition. Literally, the written language obviously [laughs] empowered humans to be able to communicate and think in ways that we never were before but also drawings, and maps, and spreadsheets. So I thought that was really cool because she was basically saying that tools of thought don't need to be digital, and people claiming that these software, you know, are the new way to think or whatever, it's like, the way we're thinking now, but we also have this long history of using and developing different things that helped us communicate with each other and think about stuff. JOËL: I think that's something that appealed to me when I was looking at some of these note-taking systems. Zettelkasten, in particular, predates digital technology. The original system was built on note cards, and the digital stuff just made it a little bit easier. But I think also when I was reading about these ideas of keeping ideas small and linking them together, I realized that's already kind of how I tend to organize information when I just hold it in my brain or even when I try to do something like a tweet thread on Twitter where I'll try to break it up. It might be a larger, more complex idea, but each tweet, I try to get it to kind of stand on its own to make it easier to retweet and all that. And so it becomes a chain of related ideas that maybe build up to something, but each idea stands on its own. And that's kind of how in these systems notes end up working. And they're in a way that you can kind of remix them with each other. So it's not just a linear chain like you would have on Twitter. STEPHANIE: Yeah, I remember you all in that episode about note-taking with Amanda talked about the value of having an atomic piece of information in every note that you write. And since then, I've been trying to do that more because, especially when I was doing pen and paper, I would just write very loose, messy thoughts down. And I would just think that maybe I would come back to them one day and try to figure out, like, oh, what did I say here, and can I apply it to something? But it's kind of like doing any kind of refactoring or whatever. It's like, in that moment, you have the most context about what you just wrote down or created. And so I've been a little more intentional about trying to take that thought to its logical end, and then hopefully, it will provide value later. What you were saying about the connectivity I also wanted to kind of touch on a little bit further because I've realized that for me, a lot of the connection-making happens during times where I'm not very actively trying to think, or reflect, or do a lot of deep work, if you will. Because lately, I've been having a lot of revelations in the shower, or while I'm trying to fall asleep, or just other kinds of meditative activity. And I'm just coming to terms with that's just how my brain works. And doing those kinds of activities has value for me because it's like something is clearly going on in my brain. And I definitely want to just honor that's how it works for me. JOËL: I had a great conversation recently with another colleague about the gift of boredom and how that can impact our work and what we think about, and our creativity. That was really great. Sometimes it's important to give ourselves a little bit more blank space in our lives. And counter-intuitively, it can make us more productive, even though we're not scheduling ourselves to be productive. STEPHANIE: Yes, I wholeheartedly agree with that. I think a lot about the feeling of boredom, and for me, that is like the middle of summer break when you're still in school and you just had no obligations whatsoever. And you could just do whatever you wanted and could just laze around and be bored. But letting your mind wander during those times is something I really miss. And sometimes, when I do experience that feeling, I get a little bit anxious. I'm like, oh, I could be doing something else. There's whatever endless list of chores or things that are, quote, unquote, "productive." But yeah, I really like how you mentioned that there is value in that experience, and it can feel really indulgent, but that can be good too. 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 you mentioned recently that you've had a lot of revelations or new ideas that have come upon you or that you've been able to dig into a little bit more. Is there one you'd like to share with the audience? STEPHANIE: Yeah. So during this downtime that I've had not working on client work, I have been able to keep up a little bit more with Ruby news or just community news in general. And in, I think, an edition of Ruby Weekly, I saw that Ruby 3.2 introduced this new class called data to its core library for the use case of creating simple value objects. And I was really excited about this new feature because I remembered that you had written a thoughtbot blog post about value objects back in the summer that I had reviewed. That was an opportunity that I could make a connection between something happening in recent news with some thoughts that I had about this topic a few months ago. But basically, this new class can be used over something like a struct to create objects that are immutable in their values, which is a big improvement if you are trying to follow value objects semantics. JOËL: So, I have not played around with the new data class. How is it different from the existing struct that we have in Ruby? STEPHANIE: So I think I might actually answer that first by saying how they're similar, which is that they are both vehicles for holding pieces of data. So we've, in the past, been able to use a struct to very cheaply and easily create a new class that has attributes. But one pitfall of using a struct when you're trying to implement something like a value object is that structs also came with writer methods for all of its members. And so you could change the value of a member, and that it kind of inherently goes against the semantics of a value object because, ideally, they're immutable. And so, with the data class, it doesn't offer writer methods essentially. And I think that it freezes the instance as well in the constructor. And so even if you tried to add writer methods, you would eventually get an error. JOËL: That's really convenient. I think that may be an area where I've been a little bit frustrated with structs in the past, which is that they can be modified. They basically get treated as if they're hashes with a slightly nicer syntax to interact with them. And I want slightly harder boundaries around the data. Particularly when I'm using them as value objects, I generally don't want people to modify them because that might lead to some weird bugs in the code where you've got a, I don't know, something represents a time value or a date value or something, and you're trying to do math on it. And instead of giving you a new time or date, value just modifies the first one. And so now your start date is in the past or something because you happen to subtract a time from it to do a calculation. And you can't assign it to a variable anywhere. STEPHANIE: Yeah, for sure. Another kind of pitfall I remember noticing about structs were that the struct class includes the enumerable module, which makes a struct kind of like a collection. Whereas if you are using it for a value object, that's maybe not what you want. So there was a bit of discourse about whether or not the data class should inherit from struct. And I think they landed on it not inheriting because then you can draw a line in the sand and have that stricter enforcement of saying like, this is what a data as value object should be, and this is what it should not be. So I found that pretty valuable too. JOËL: I think I've heard people talk about sort of two classes of problems that are typically solved with a struct; one is something like a value object where you probably don't want it to be writable. You probably don't want it to be enumerable. And it sounds like data now takes on that role very nicely. The other category of problem is that you have just a hash, and you're trying to incrementally migrate it over to some nicer objects in some kind of domain. And struct actually gives you this really nice intermediate phase where it still mostly behaves like a hash if you needed to, but it also behaves like an object. And it can help you incrementally transition away from just a giant hash into something that's a little bit more programmatic. STEPHANIE: Yeah, that's a really good point. I think struct will still be a very viable option for that second category that you described. But having this new data class could be a good middle ground before you extract something into its own class because it better encapsulates the idea of a value object. And one thing that I remember was really interesting about the article that you wrote was that sometimes people forget to implement certain methods when they're writing their own custom value objects. And these come a bit more out of the box with data and just provide a bit more like...what's the word I'm looking for? I'm looking for...you know when you're bowling, and you have those bumpers, I guess? [laughs] JOËL: Uh-huh. STEPHANIE: They provide just like safeguards, I guess, for following semantics around value objects that I thought was really important because it's creating an artifact for this concept that didn't exist. JOËL: And to recap for the audience here, the difference is in how objects are compared for equality. So value objects, if they have the same internal value, even if they're separate objects in memory, should be considered equal. That's how numbers work. That's how hashes work. Generally, primitives in Ruby behave this way. And structs behave that way, and the new data class, it sounds, also behaves that way. Whereas regular objects that you would make they compare based off of the identity of the object, not its value. So if you create two user instances, not ActiveRecord, but you could create a user class, you create two instances in memory. They both have the same attributes. They will be considered not equal to each other because they're not the same instance in memory, and that's fine for something more complex. But when you're dealing with value objects, it's important that two objects that represent the same thing, like a particular time for a unit of measure or something like that, if they have the same internal value, they must be the same. STEPHANIE: Right. So prior to the introduction of this class, that wasn't really enforced or codified anywhere. It was something that if you knew what a value object was, you could apply that concept to your code and make sure that the code you wrote was semantically aligned with this concept. And what was kind of exciting to me about the addition of this to the core class library in Ruby is that someone could discover this without having to know what a value object is like more formally. They might be able to see the use of a data class and be like, oh, let me look this up in the official Ruby docs. And then they could learn like, okay, here's what that means, and here's some rules for this concept in a way that, like I mentioned earlier, felt very implicit to me prior. So that, I don't know, was a really exciting new development in my eyes. JOËL: One of the first episodes that you and I recorded together was about the value of specific vocabulary. And I think part of what the Ruby team has done here is they've taken an implicit concept and given it a name. It's extracted, and it has a name now. And if you use it now, it's because you're doing this data thing, this value object thing. And now there's a documentation page. You can Google it. You can find it rather than just be wondering like, oh, why did someone use a struct in this way and not realize there are some implicit semantics that are different? Or wondering why did the override double equals on this custom class? STEPHANIE: Yeah, exactly. I think that the introduction of this class also provides a solution for something that you mentioned in that blog post, which was the idea of testing value objects. Because previously, when you did have to make sure that you implemented methods, those comparison methods to align with the concept of a value object, it was very easy to forget or just not know. And so you provided a potential solution of testing value objects via an RSpec shared example. And I remember thinking like, ooh, that was a really hot topic because we had also been debating about shared examples in general. But yeah, I was just thinking that now that it's part of the core library, I think, in some ways, that eliminates the need to test something that is using a data class anyway because we can rely a little bit more on that dependency. JOËL: Right? It's the built-in behavior now. Do you have any fun uses for value objects recently? STEPHANIE: I have not necessarily had to implement my own recently. But I do think that the next time I work with one or the next time I think that I might want to have something like a value object it will be a lot easier. And I'm just excited to play around with this and see how it will help solve any problem that might come up. So, Joël, do you have any ideas about when you might reach for a data object? JOËL: A lot of situations, I think, when you see the primitive obsession smell are a great use case for value objects, or maybe we should call them data objects now, now that this is part of Ruby's vocabulary. I think I often tend to; preemptively sounds bad, but a lot of times, I will try to be careful. Anytime I'm doing anything with raw numbers, magic strings, things like that, I'll try to encapsulate them into some sort of struct. Or even if it's like a pair of numbers, it always goes together, maybe a latitude and longitude. Now, those are a pair. Do I want to just be passing around a two-element array all the time or a hash that would probably make a very nice data object? If I have a unit of measure, some number that represents not just the abstract concept of three but specifically three miles or three minutes, then I might reach for something like a data class. STEPHANIE: Yeah, I think that's also true if you're doing any kind of arithmetic or, in general, trying to compare anything about two of the same things. That might be a good indicator as well that you could use something richer, like a value object, to make some of that code more readable, and you get some of those convenient methods for doing those comparisons. JOËL: Have you ever written code where you just have like some number in the code, and there's a comment afterwards that's like minutes or miles or something like that, just giving you the unit as a comment afterwards? STEPHANIE: Oh yeah. I've definitely seen some of that code. And yeah, I mean, now that you mentioned it, that's a great use case for what we're talking about, and it's definitely a code smell. JOËL: It can often be nice as you make these more domain concepts; maybe they start as a data object, but then they might grow with their own custom methods. And maybe you extend data the same way you could extend a struct, or maybe you create a custom class to the point where the user...whoever calls that object, doesn't really need to know or care about the particular unit, just like when you have duration value. If you have a duration object, you can do the math you want. You can do all the operations and don't have to know whether it is in milliseconds, or seconds, or minutes because it knows that internally and keeps all of the math straight as opposed to just holding on to what I've done before, which is you have some really big number somewhere. You have start is, or length is equal to some big number and then comment milliseconds. And then, hopefully, whoever does math on that number later remembers to do the division by 1,000 or whatever they need. STEPHANIE: I've certainly worked on code where we've tolerated those magic numbers for probably longer than we should have because maybe we did have the shared understanding that that value represents minutes or milliseconds or whatever, and that was just part of the domain knowledge. But you're right, like when you see them, and without a very clear label, all of that stuff is implied and is really not very friendly for someone coming along in the future. As well as, like you mentioned earlier, if you have to do math on it later to convert it to something else, that is also a red flag that you could use some kind of abstraction or something to represent this concept at a higher level but also be extensible to different forms, so a duration to represent different amounts of time or money to represent different values and different currencies, stuff like that. JOËL: Do you have a guideline that you follow as to when something starts being worth extracting into some kind of data object? STEPHANIE: I don't know if I have particularly clear guidelines, but I do remember feeling frustrated when I've had to test really complicated hashes or just primitives that are holding a lot of different pieces of information in a way that just is very unwieldy when you do have to write a test for it. And if those things were encapsulated in methods, that would have been a lot easier. And so I think that is a bit of a signal for me. Do you have any other guidelines or gut instincts around that? JOËL: We mentioned the comment that is the unit. That's probably a...I wasn't sure if I would have to call it a code smell, but I'm going to call it a code smell that tells you maybe you should...that value wants to be something a little bit more than just a number. I've gotten suspicious of just raw integers in general, not enough to say that I'm going to make all integers data objects now, but enough to make me pause and think a lot of times. What does this number represent? Should it be a data object? I think I also tend to default to try to do something like a data object when I'm dealing with API responses. You were talking about hashes and how they can be annoying to test. But also, when you're dealing with data coming back from a third-party API, a giant nested hash is not the most convenient thing to work with, both for the implementation but then also just for the readability of your code. I often try to have almost like a translation layer where very quickly I take the payload from a third-party service and turn it into some kind of object. STEPHANIE: Yeah, I think the data class docs itself has an example of using it for HTTP responses because I think the particular implementation doesn't even require it to have attributes. And so you can use it to just label something rather than requiring a value for it. JOËL: And that is one thing that is nice about something like a data object versus a hash is that a hash could have literally anything in it. And to a certain extent, a data object is self-documenting. So if I want to know I've gotten to a shopping cart object from a third-party API, what can I get out of the shopping cart? I can look at the data object. I can open the class and see here are the methods I can call. If it's just a hash, well, I guess I can try to either find the documentation for the API or try to make a real request and then inspect the hash at runtime. But there's not really any way to find out without actually executing the code. STEPHANIE: Yeah, that's totally fair. And what you said about self-documenting makes a lot of sense. And it's always preferable than that stray comment in the code. [laughs] JOËL: I'm really excited to use the data class in future Ruby 3.2 projects. So I'm really glad that you brought it up. I've not tried it myself, but I'm excited to use it in future projects. 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: Byeeeeeeeeeeeeee!!!!!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed

Happy New Year! It's 2023 🎉 Joël and Stephanie chat about developer resolutions or things they'd like to do this year and then discuss componentization and branching strategies. This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack. Joël's Elm Meetup talk wasn't recorded but the slides are here Joël hasn't published an article on the 3 principles of branching, but he does discuss them in this twitter thread Making Impossible States Impossible Cardinalities Component-Driven Development Storybook BEM View Components at GitHub Confident Ruby Case Expressions Episode 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, as of the time that this episode goes live, it's the new year; it's 2023. Happy New Year. STEPHANIE: Happy New Year, Joël, and Happy New Year to our listeners. JOËL: So, new year is oftentimes where people like to take maybe resolutions or plan a little bit out of their year. I'm curious, Stephanie, do you have any developer resolutions or things that you'd like to do this year? STEPHANIE: So, I think last episode, we were talking a little bit about reflection, especially in terms of career progression. And I may have mentioned that I don't really believe in New Year's resolutions. [laughs] But I do think that one intention that I have for myself is to chill a little bit. I think the fall of 2022, for me, was really hectic, exciting but a little busy in terms of speaking and content creation; you know, we started doing this podcast together. And so I do think that winter is my time of hibernation. Development-wise, one goal that was really inspiring for me that you shared is writing ten blog posts a year. And I think I might keep that in the back of my head as we get into the new year and maybe start to at least just have it in my mind. So if I see anything that comes up, I can be like, oh yes, I had this intention to write more blog posts, which I think might be helpful to just marinate on even during my chill time. Because when I do finally feel productive and energized again, I can at least have been thinking about it. And I think doing that reflection and marinating is also work, even if it doesn't end up turning into an artifact or anything like that. And so yeah, that's my plan for the beginning of the year, at least. And then, on a personal note, I'm on a journey to be warm this winter and not be miserable and cold. So as a recovering Californian in Chicago these days, I have just always wanted to stay in and be a little bit of a hermit in the winter because I just have a hard time with the cold. But then I learned that you can just buy things that will help keep you warm. And so, a recent purchase of mine was a heated, portable blanket. So I will definitely be repping that in my Zoom calls and on the couch. And I've just gotten really stocked up on the warm weather accessories, so fingerless gloves and the like. So I'm excited to just not be miserable this winter. That's my plan for the new year. JOËL: You'll have to report back on how well that goes, how you feel about that blanket. STEPHANIE: Oh yeah, I definitely will. Maybe I'll even wear it when we're recording. JOËL: Maybe next year we can make a gift guide. STEPHANIE: That would be so fun. I would like that: a gift guide for developers or the developer in your life. JOËL: Right. Fingerless gloves just because it looks cool. [laughs] STEPHANIE: I'm wearing them right now. Yeah, I can type, and my hands stay warm, highly recommend. JOËL: So it's not just a hacker thing to look cool. It actually works. STEPHANIE: I would say so. As someone who has very cold extremities, it's been a good solution for me. JOËL: You'd mentioned in a previous episode talking about conference talk ideas that you like to marinate in sort of build up a file of ideas over the course of a year. And it sounds like you're taking that approach but then also applying it to smaller form content like blog posts over the course of this winter. STEPHANIE: I think so. I realized something about myself is that I am a bit of a slow cooker in terms of coming up with ideas, especially if they're rooted in experience. I think it takes me the process of going through something like going through a client project and then honestly, three months later being like, oh, now I can have some distance from it and be like, oh, this is what I was thinking, or this is what I noticed or observed, which I think that's just how I am, and that's okay. I recognize that I don't necessarily churn out content all the time, and, for me, it kind of does feel more like seasons or cycles. JOËL: So it's funny you mentioned the ten blog posts goal, and that's what I was going to share for my developer goal for the year. I've had that for the past several years. It's a really fun goal to have, I think, because it's aggressive enough that it requires me to put out a fair amount of content, but it's also achievable. That being said, as of the time of this recording, which is at some undisclosed time prior to the New Year, I only have eight articles that are live on the thoughtbot blog. So for all you listeners in the future in 2023, if you're curious if I achieved my 2022 goals, go check the thoughtbot blog and see did I successfully publish the last two before the end of the month. STEPHANIE: One thing you had mentioned to me off-air was that you do also tend to backload blog posts towards the end of the year once you realize that that deadline is coming up. Do you think you will do something differently in 2023? JOËL: I would like to write a little bit more early in the year. I think I'll have to figure out exactly how I want some of my goals to play out. I think I mentioned this in the previous episode; two large themes that I've wanted to focus on are ways to invest in our team and our teammates and then creating content, so things like blog posts, like this podcast, like conference talks. Those were two broad themes that I had given my year in 2022. And I really enjoy those. I think I would want to repeat those themes for 2023 as well, so figuring out exactly how I'm going to interweave them, something I'm going to iterate on. STEPHANIE: Have you considered breaking down that yearly goal into smaller time intervals, so maybe two or three blog posts a quarter? JOËL: That might be a better way to do it to make sure that I'm on track. I give myself this as a goal. I'm not super hard on myself if I don't hit it, although I have hit it for multiple years. If I only have eight blog posts this year, that's still an accomplishment I'm proud of. And I think there's some good content that I put out. So I will not be distraught if I don't hit the 10, but it's good to be aiming for something. STEPHANIE: Yeah, that's a good mindset to have. I also have a personal goal of reading 52 books a year. And this will be my third year attempting to do so. Or, I guess I have been successful in 2021 and 2022 now. But I remember when I first wanted to do it; I didn't tell anyone because I was terrified of not meeting that goal and just feeling a bit disappointed in myself. And so, I just kept it to myself and didn't mention it to anyone until I got to around 40 or 45 bookmark, and then I could confidently tell people about my goal because, at that point, I was on track and feeling pretty confident that I was going to finish it. So that's my strategy [chuckles] is to not tell anyone until I am pretty much there and then share, and people can be impressed. JOËL: I feel like there's always a bit of a tension there where when you've got a goal, sometimes you don't want to tell people about it because you don't want to say a thing and then disappoint other people and not get it done. But in some ways, for me, when I can get a goal out of my head and out into almost the real world by telling someone, it makes that goal more real and maybe inspires me to work harder towards it but also maybe helps me believe in myself a little bit more because I've said it out loud. And, I don't know, maybe saying it in front of a mirror would have the same effect. But getting it out of just my thinking pattern and saying it, "This is what I think I'm going to achieve. This is what I'm trying to do," somehow makes the goal more real for me, makes it more achievable. STEPHANIE: That makes sense. It's like the difference between saying, "I think I'm going to do this," and "Okay, I'm going to do this." JOËL: Right. And maybe there's a little bit of social pressure too, if I tell someone, now I don't want to disappoint them. That can be bad because it causes me to doubt myself, but in small amounts, it can maybe help me to push through moments of doubt or moments of feeling like I want to give up. STEPHANIE: Yeah, I mean, either way, even if you only ended up with eight blog posts in a year, people are just really excited that you're putting content out there. And they're not counting how many posts you put out. JOËL: In a sense, it's purely a vanity metric for me to know my progress. STEPHANIE: So I have one thing that happened this week that I would be curious to get your input on. On my client project, I was tasked with making a small UI change to a navigation menu that existed as a separate React project within our Rails repo. And so the task was for...we had this little caret icon that was used in the mobile nav, and the designer wanted it to be reused somewhere else on the desktop nav menu. And I was digging through the codebase looking to see where the caret was already. And I realized that it was done with CSS on the menu label. So it was really coupled to this menu label and wasn't reusable in that current state. So it took me a little while to figure out how to pull out the seams and extract it into its own component so I could reuse it where I needed it to. And so I was trying to figure out how we got here because we are using the styled-components library, which should encourage componentization. And I was just thinking about different approaches to building UI features from scratch. And I did a little bit of digging and learned about component-driven development, which suggests the idea of building each component in isolation and thinking through all the relevant states that it might exist in for at least your first couple of use cases and then combining them to create larger components, and then ultimately pages. And that was interesting to me because it's a little bit different from a strategy that I'm used to, especially if you're implementing a new page or template where you just kind of scaffold out all of your HTML elements that you need. But then when you add on styling, those primitive components, you might end up having a lot of duplication if you are creating very generic things like buttons that end up being coupled to the page that you're working on, especially if you are putting them on the page in a very specific way. And you might add CSS rules like margins or padding that, again, is coupled to that particular UI that you're building. So I'm curious if you've really thought about building UI from a component level and starting small and then building out or if you also take it from a top-down approach. JOËL: It's interesting that you mentioned that the component approach really deals with figuring out state. And I think that's probably an area where it shines a lot when you have situations where components can have multiple states. And it's very easy when you're looking at much more of a scenario-driven approach where you just want to say, oh, I want this form input to look like this, like this one mock. But that was only showing the happy path. And you didn't think about all those other states. And so, for situations where you might have a lot of states, the component approach, I think, is really interesting. I had a really fantastic experience a few years ago pairing with a thoughtbot designer on fairly...well, what we thought was going to be a simple form input. And it turned out that it had a lot of edge cases and funny state things that could happen. And we ended up drawing what essentially was a...you might call that a finite-state machine in a more formal sense. But it's basically a diagram where we show the state of the input. And then we would say, what are the different things that can happen that might transition it into another state? So maybe it starts empty, but then you start typing, and then something happens, or you have an invalid value, and then something happens. But then, from the invalid state, can you come back to the empty state? Can you come back into the typing state? At what point do we show a read error? Do we clear it out while you're typing? Even after you have an error, this particular input was also backed by some remote data. So it was like a typeahead kind of thing pulling data from a server. And there were a lot of extra edge cases for things like, oh, we're waiting for results, or no results matched, or we got exactly one result. And so that was really interesting. We ended up building up this whole diagram where we showed all the transitions that could happen, the ways you can loop back to a previous state, and it forced us to think about a lot of edge cases that we wouldn't have thought of otherwise. STEPHANIE: That's really interesting. I think the transitions between different states definitely can get really complicated. While you were saying that, I was reminded of Storybook, the tool for building out components in isolation. And one thing that I really like is that they encourage you to think about different states and edge cases as almost like user stories. I think they're called stories. And you can use their DSL to extract those pieces of information and basically think through kind of what you were saying, but it's built into the tool. And so it really encourages that thought process. Because I definitely have run into just trying to build out a basic button or something but then having all of these questions that I have to ask designers while I'm implementing it to be like, what should happen here? Or, like, what should it look like when it's disabled, or what happens when it, like you mentioned, gets back data that it wasn't expecting or something like that? JOËL: Sometimes you have situations where your page doesn't have a lot of state, or your components don't really have a lot of state. And it really is just a static page. In those situations, now you're looking at questions more of reusability rather than state management. And you may or may not want some kind of componentized approach for that. That might be a little bit different depending on, like; you may not be using React if it's a completely static page. So maybe this is server-rendered, and you're trying to componentize using Rails helpers. Or you're using something like BEM the CSS...I don't know if you'd call it a framework or a structural approach of defining classes that are in a more componentized approach so that you can reuse styles. So there are a lot of ways to reuse and componentize. Even though I think oftentimes when we talk about visual components, we're often thinking about React. STEPHANIE: Yeah, I also did a little digging into ViewComponents because I was, again, just kind of trying to think of a mental model for how to approach building out UIs. And in their docs, they have a really good example about their process for using ViewComponents at GitHub. And basically, the progression is that they implement a single use case component that might live as it is for a while until there is some other use case for that component, and then maybe it's adapted for general use in multiple locations. And then, if it turns out to be like a really good generic building block, they actually extract it into their open-source component library called Primer, I think is what it is. So that was an interesting process for me as someone who just kind of like did that first step of pulling out this little piece into its own component. And then, right now, it isn't necessarily quite ready for being reused in a bunch of different ways. But I think that was a good first step in setting it up to be able to. JOËL: Definitely. I think it's easy to overDRY or, in this case, it's almost like over abstract in preparation for reuse that might never happen. But oftentimes, it's an incremental thing where you do as much as it makes sense for your current scenario while also leaving yourself the option to easily keep going down that path for future scenarios where there is more duplication. And then, if those scenarios never come, then great, you've saved yourself some work. And if the scenarios do come, then hopefully, it's easy to take the next step. I gave a talk several years ago at an Elm meetup. Elm is a front-end language that compiles down to JavaScript. And in Elm they don't have components in the same way that React might have. Everything is just functions because of its very functional DNA. And I was talking about how to structure the view layer in terms of functions and how to do so cleanly in a way that is reusable. And one guideline that I had for myself for structuring this kind of code is that a function can either do something or it can branch, but it can't do both. So if a function (But you can think component here.) is splitting in two different situations, then it doesn't get to have any logic inside it. It just calls out to some other component. And the only thing that it does is say, "I'm a branching component. If this happens, pull this other subcomponent; otherwise, bring in this subcomponent and maybe set up some arguments or something like that." And then the other child components that are rendering various pieces of UI, they don't get to branch. They are just given this data, render it in this way. STEPHANIE: That makes a lot of sense. I think that also reminds me of the philosophy of separating your components to be container components or presentational components, where there are some that are just focused on what is being rendered and others that have more of that logic in determining what should or should not be displayed. 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: It's interesting that we're talking about branching, how to structure it, how to model components that deal with branching or that have to be called from a branch because branching is something that I've been thinking about a lot for the past couple of years. One thing I noticed that we tend to do as developers is that we really, really want to force everything down a single path as much as possible. Like, there is a main path, and then if you have to branch off of it, you go off on the side path. As short as possible, find a way to merge back onto the main path. But there is one single main path in your program, and everything tries to merge back into it. Have you encountered that in your own coding journey? STEPHANIE: Do you mean having a lot of conditionals along this single path that might take you elsewhere but then, in the end, are just little tangents, and you're trying to get back to that main execution of code? JOËL: Yes. An example of that might be dealing with a value that is potentially nil in Ruby or null in JavaScript. And so you check if that value is present, and then you do some things. And then you want to do something else, so you have to, again, check if the value is present and then potentially do the next step. And then, again, check if the value is present. And you end up repeating this conditional multiple times. We have some constructs that make this a little bit nicer. Ruby has the lonely operator that will just sort of keep passing that nil down in a safe way. But it is still doing a nil check at every step of your long chain of actions you're trying to take because that value is potentially null at every step. STEPHANIE: The lonely operator being the safe navigation operator. Is that right? JOËL: Yes, that's right. That is another name for it. STEPHANIE: Okay, cool. Glad we're on the same page. JOËL: The &. We have some quirky names for operators in Ruby. STEPHANIE: Yeah, we sure do. I hadn't heard of lonely before, so that was a really cool tidbit for me. JOËL: There's also the spaceship operator, which is the less than equal greater than for comparing objects with comparable. STEPHANIE: Ooh, I like that. I've also heard squid operator for interpolating Ruby in ERB. JOËL: Nice. STEPHANIE: I think, in my experience, I have seen that chaining of the safe navigation operator and the chaining of checking for nil in code that doesn't quite utilize the Tell, Don't Ask principle where you have to check for nil and all the objects down the line rather than having that functionality extracted in a method that is then, in my opinion, more correctly co-located with the relevant domain model. So I'm curious if you think that the conditionals themselves are an issue or if it's just the way that they were implemented or where they exist. JOËL: In this particular case, I would say the conditionals are a code smell, and they're probably extraneous. You're checking the theme value for null again, or maybe you're checking a derived value for null that you don't need to because you've already checked it earlier. It's code that is not confident because the uncertainty from that initial nil has sort of bled through all of your code. A classic solution to this problem is to try to push the uncertainty to the edges of your system. And a great resource for that is the book Confident Ruby by Avdi Grimm, which talks about all sorts of techniques for dealing with a lot of those uncertainties that you deal with in code and how to push those to the edges of your system. STEPHANIE: Thanks. That does actually remind me of what you were saying about componentization and having that outer component make the decision, and then everything else inside of it doesn't need to worry about it anymore. JOËL: I think it's all kind of connected. I've come up with sort of three, let's call them principles, that I try to use when structuring code that I think are kind of the same idea viewed from three different points of view, or maybe all kind of converge towards the same ideas. The first one being what I showed earlier, the idea of separating branching code and doing code into two separate places. The second one being to try to branch early, push conditionals higher up your decision tree. And the final one being to keep the code within a single method or component or whatever your structuring element is at the same level of abstraction. So if you're writing at a higher level calling a lot of lower-level methods, that's great. But then don't mix in some lower-level concerns there. Extract those out to a private method or another object or a component and bring those in, and keep everything at a high level in your high-level components, and then everything at a low level in your low-level components. STEPHANIE: Yeah, that makes sense. I think that is perhaps closer to what I was trying to say earlier, where I think conditionals can be okay if they are in the right place. So if you have a controller and you see a bunch of conditionals, I think if that conditional-checking is related to something like rendering, that feels a bit more okay to me as opposed to seeing conditionals that then execute a procedure or a bunch of different things that might be better extracted somewhere else. JOËL: I think there are two classes of conditional that you have to think about. Some conditionals are just unnecessary. You're doing extra work that is not required by the code because the code is poorly factored, and so you're having to do this extra work. This commonly happens, I think, in large code bases where they're modified over time, and you get this big, scary large method, maybe with deeply nested code, and you want to just make one modification in it. But you're afraid to break other things, so you wrap it in a conditional. But then everybody else is doing the same. And then you've got this giant tangle of conditionals, some of which are duplicating each other, some of which will never be called just because it's poorly factored, and it just grew that way over time. And so those, if you're sitting down and looking at cleaning up that code, many of them can be entirely eliminated just by structuring things in a cleaner fashion. STEPHANIE: Yeah, I've definitely experienced what you're talking about. And I think it does provide a lot of value once someone figures out what the heck is going on with all of these conditionals and wraps their head around it if they're able to refactor it to eliminate some of that complexity that has just downstream effects for everyone working in that code. Like, they don't have to do the work of trying to figure out what is going on, especially for unnecessary logic in the first place. JOËL: I think a classic case I've seen of this is dealing with wizards where you have a bunch of different steps, and they might be all handled in one place. And a classic way that I've often seen people attempt to do this is say, well, there are a lot of things that might be shared between different steps. Or, again, we want to do this one single linear path. And so you might have, say, one giant Rails controller that accepts inputs from all the possible steps in the wizard. And then it will just say, if this parameter is present, do this action; else, if there is other parameters present, do this action. It's not even like do this step one action or do the step two action. It might be if the user's name and email are present, then save some data to this table, else if a phone number is present, trigger this background job elseif all these things. But what gets tricky is then you don't know which combinations can happen together. And then later on, when this gets really big, and you're trying to modify it, and it's like, oh, the customer wants another field on the screen that shows the phone number. But maybe you don't want a background job to be triggered in that case, or maybe it shows up on a different page that you also want to show the phone number on, but now you want the behavior to be slightly different for both of them. And so it gets into this really big tangled mess. It's also impossible to read that code and know what is going to be executed for each step. So my general preferred approach for that kind of situation...and actually, we have an older episode of The Bike Shed where Steph and Chris discuss this in detail, and their recommendation was similar. So the trick is to branch early, and instead of having a single logical path, it's just check condition, do a thing, keep going. Check condition, do a thing, keep going. You have branching at the top level that says, if step one, do the step one things; if step two, do the step two things; if step three, do the step three things. And you can have shared logic between them. You might have some private methods that call each other. And all that is fine. You can have levels of abstraction, all the goodies that you're used to. But now you have a much simpler branching structure because you branch once at the top level. And that might be a four, or five, six, seven-way branch, which is complex. But there is no more branching down below it. After that, it's five or six linear paths going down instead of one giant path with a bunch of branches on it that merge back onto the main path. STEPHANIE: Speaking of condition with multiple branches, I think we also talked a little bit about this in a previous episode you and I did on case expressions where you talked about how you handled that wizard with a flat case statement. So if folks want to hear more about our opinions on case expressions, I definitely recommend you check out that episode. JOËL: One thing that I think is really interesting is that when you have extra if...else expressions that you don't need, and maybe they're nested in a certain way, or they're just like really long, you create more paths through your decision tree if you were to model this as a decision tree, then you actually want...so going back to the case of the wizard, the way that you structure it with a case expression is there's one, let's say a five-way branch, and then after that, it's just linear paths. So there are five unique ways to traverse that decision tree, which is exactly the number of ways that you want. In the original implementation that I talked about where everything is an independent condition that says if this param is present, do a thing, keep going. If this other param is present, do a thing, keep going. And any combination of those might stack up together. Well, now we've got a combinatorial explosion because what if the phone number is present but also the first name and email? Do we do all of those things together? And so it's hard for the reader to understand because there literally are a lot of paths that can happen. And many of them are invalid paths. They shouldn't happen. STEPHANIE: Yeah, I don't want to be anywhere near a combinatorial explosion based on that term. But, yeah, I think it's also very descriptive of what it feels like to have to parse through a bunch of nested conditionals like that to figure out where you are or what is going to happen next. JOËL: I mentioned earlier on this podcast that I've done a lot of work with the Elm language. And when they're designing types in their community, they often use the expression make impossible states impossible. And so they'll look at the data structures that they're using and ask, "Are there ways that this data structure can be used to represent values that don't make sense in my domain? And can I change that representation, the definition of these data structures such that it now becomes impossible?" There are some heuristics that you can use to try to make that happen. There's also a bit of a more mathematical way to think about it, which is thinking in terms of cardinalities, which is how many different types of values can be expressed by a given type. So you think a Boolean can only be one of two values, true or false. That is a type with a cardinality of two. You can do this exercise with different primitive types. But also, once you start combining types together, for example, you've got a pair of Booleans. You've got two values, each of which could be in two different states, and so now those two cardinalities multiply. You've got four possibilities for a type that is a pair of Booleans. This becomes a really interesting analysis when you start thinking about using this to model a state of your application. So let's say you're trying to model something that has three possible states, and you say, oh, I'm going to use two Booleans to model this. It's problematic because two Booleans have four states, but the thing you're trying to model has only three. And so now you're absolutely going to get in some weird invalid state for that one extra combination that you didn't account for. Maybe that's false and false. I see that happen a lot, even in database design, where you have two Boolean flag columns that interact with each other. And it's like, oh, but they should never both be false because that's some error state that should never happen, and, of course, inevitably, it does. What was really exciting to me was thinking about this mantra of making impossible states impossible. Can we apply that to branching? In the way that I've structured my code, there should be the same number of possible branches through my decision tree as there are actual paths through the domain that I'm trying to model. So if it is a wizard with five steps, I want my decision tree to have five paths. If my decision tree has more than five paths, then maybe that's a sign that I need to refactor the implementation because I now have some extra invalid paths that I need to trim. STEPHANIE: I think the phrase making impossible states impossible is really interesting because that mindset would be really helpful to avoid that defensive coding. I think that shows up as all of those unnecessary conditionals and checking for nil values because you just don't know, even though logically, you might know that it's not possible based on the domain or the business logic. But we all have seen that no method on nil error come up in our error monitoring service. And you're like, oh shoot, I have to fix that. And you reach for it using that safe navigation operator. And so yeah, the idea of writing confident code, not defensive code (They're opposites to me.), is definitely something that I want to keep in mind. JOËL: I think something that I'm getting out of this episode is also the value of interacting with other language communities and pulling in ideas from there and how that can enrich the way you think about code in a different language. This episode has talked about components in React in JavaScript. We've talked about architectures and CSS. We've pulled in some typing techniques from Elm and how that might maybe help us think about conditionals in Ruby. So it's a very polyglot episode. And I think that enriches our vocabulary and enriches our toolset, even when we're not coding in those languages. STEPHANIE: Yeah, absolutely. I think it also shows that a lot of these things are universal. Even though there might be different paradigms, a lot of them kind of, like you said, are enriched by knowledge from other philosophies or frameworks, or it all kind of converges. JOËL: There's a famous quote, and I've seen it attributed to many people, so I'm not even going to try. And it goes something like this: "History may not repeat itself, but it certainly does rhyme." And I feel like maybe we've got a little bit of that going on here in that the problems and solutions might not exactly replicate across languages and paradigms, but they certainly do rhyme. STEPHANIE: That's a very, Joël thing to bring up, I think. JOËL: [laughs] STEPHANIE: Classic pulling from history to explain the present. 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: Byeeeeeeee!!!!!!!! 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.Sponsored By:Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.Support The Bike Shed