TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Software How-To

    The Bike Shed

    On The Bike Shed, hosts Joël Quenneville, Sally Hall, and Aji Slater discuss development experiences and challenges at thoughtbot with Ruby, Rails, JavaScript, and whatever else is drawing their attention, admiration, or ire this week.

    Advertise
    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    399: Scaling Code Ownership and Accountability Aug 29, 2023
    Show notes

    Stephanie experienced bike camping. Joël describes his experience during a week when he's in between projects. Stephanie and Joël discuss the concept of code ownership, the mechanisms to enforce it, and the balance between bureaucracy and collaboration. They highlight the challenges and benefits of these systems in large codebases and emphasize that scaling a team is as much a social challenge as it is a technical one. Out Our Front Door Conway’s Law Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: This weekend, I went bike camping for the first time. So, it was my turn to try out the padded bike shorts and go out on a long ride, combining two things that I really enjoy: biking and camping. It was so awesome. We did about 30 miles outside of the city of Chicago to close to the Indiana border. And we were at a campground that's owned by the forest preserves where I'm at. It was so much fun. I packed all my stuff, including my tent and sleeping bags. And it was something that I never really imagined myself doing, but I'm really glad I did because I think it'll be something that I want to kind of do more of in the future, maybe even do multi-day bike camping trips. JOËL: So, what's your verdict on the bike shorts? STEPHANIE: Definitely a big help. Instead of feeling a little bit sore an hour or so along the bike ride, it kind of helped me stay comfortable quite a bit longer, which was really nice. JOËL: Would you do this kind of trip again? STEPHANIE: I think I would do it again. I think the next step for me is maybe to go even farther, maybe do multiple stops. Yeah, I was talking to my partner about it who came along with me, and he was saying, like, "Yeah, now that you've done that many miles in one day and, you know, camped overnight, you can really go anywhere. [laughs] You can go as far as you want." And I thought that was pretty cool because, yeah, he's kind of right, where I can just pack up and go and, you know, who knows where I'll end up? Not that I would actually do that because of my need to plan. [laughs] I'm not that go-with-the-flow. But there was definitely something really special about being able to get from A to B with just, like, my physical body and not relying on any other kind of transportation. JOËL: Yeah, there's a certain freedom to that spontaneity that's really nice. STEPHANIE: Yeah. And I actually went with a group called Out Our Front Door. And if anyone is in Chicago and is interested in doing this kind of thing, they do group bike camping adventures, and they make it really accessible. So, it's a very easy pace. You are with a group, so it's just really fun. They make it really safe. And I had a really great time. There was about 60 of us actually at camp, and they had rented out the entire campground, so it was just our group. And they even had a live reggae band come out and play music for us while we had dinner. And that was a really nice way for me to do it as a first-timer because there was stuff already planned for me, like meals. And I didn't have to worry about that because I was already, you know, just worrying about making sure I got there with all of my stuff. So, if that sounds interesting to you and you're in Chicagoland, definitely check them out. JOËL: That's a great way to bring in newer people to say, let's have a semi-organized thing, where all you have to focus on is the skill itself, you know, can I bike the 30 miles? Rather than planning all the logistics around it. STEPHANIE: Yeah, exactly. Joël, what's new in your world? JOËL: So, speaking of planning and logistics, this week, I'm in between projects at thoughtbot. And on the Boost team that I'm on, we've introduced a kind of special rotation for people who are in between projects where we have an internal project, where just internal strategic initiatives that we want to push forward. Whoever is unbooked gets to work on that. So, it's a small team with a very high churn. And one of the things that we do is every week; we have somebody act as the project manager for that team. And I was in between projects this week. I was assigned that project manager job. And so, I've been doing that in addition to some of the tickets myself, and that's been really interesting. STEPHANIE: Cool. I really like how that role is rotated among team members. JOËL: Yes. And the whole team itself is very high churn. So, somebody might be on that for just one week and then rotate off, and a new person comes in; maybe someone's on there a couple of weeks while we're waiting to find them a project. But we're always looking to prioritize booking people onto new client projects. And so, whoever is on that team, typically, is there for a short period of time. And so that means that the project manager role has to rotate a lot. But also, just in general, as you're managing tickets, you have to deal with the fact that people are not going to be on this project long-term. This is just, they're here for a few days, and they get some things done, and then they're moving off. And I think that presents some unique challenges in terms of the project management side of things. STEPHANIE: Yeah. What kind of challenges did you find interesting in this role for the week that you were on it? JOËL: So, in particular, I think making sure that outstanding work from the previous week gets done, especially when the people who were working on that ticket are no longer working on it. So, they may have done some partial work and then moved on to something else. And then, you have to ascertain the state of the ticket. Has it been completed? If it's only partial, what parts have and haven't? Can this be passed on to somebody else? Is there some unique knowledge that the previous person had? Has the code been pushed up? That kind of thing. STEPHANIE: So, that reminds me of something I heard about the idea of being expendable. You know, there are certain industries where anyone else with that skill set can kind of step in and take over for another worker without a lot of issues, and they can continue on doing that work. So, I'm thinking about, you know, maybe doctors or pharmacists where they have that, like, shared skill set, and everything is documented enough so that they can just take whatever their case is. And if someone is out, it's not a big deal because people can just step in. And I'm curious about if this is something that could work for software development. JOËL: I think it is important to have a team where nobody is irreplaceable. When it comes down to individual tickets, one of the things that I've been pushing for is that, at the end of the week, I would like to not see any tickets remain in the in-progress column. We're using a Kanban-style board. So, ideally, all work either moves to the done column or moves to the to-be-done column for next week. And it's no longer owned by anyone, so people have removed their faces from it. Ideally, though, if you pick up a ticket during the week, you get it to completion. So, one thing that I've been really pushing with our team this week is splitting tickets up. If this feels like it's bigger than a few days, then it needs to be split up, and part of it gets done moves to the done column. Part of it might be some work that somebody else is going to pick up next week; move that to the to-do column. And so, that way, at the end of the week, we have, ideally, a column full of things that were pushed over the finish line that are done. And then, we have a column of things to be done next week that nobody has kind of called dibs on yet. So that then next week, when we have a new group of people coming in, you don't just look at this column of to-do things. It's like, well, all of these have someone's face on them. I'm not able to pick up anything, so now what do I do? By having those all kind of fresh and available to be picked up, you make it easy for the next batch of people to hit the ground running on Monday morning. STEPHANIE: That's really interesting. You said you were doing this Kanban style, but it almost kind of sounds like one-week sprints in a way. JOËL: Kind of, because the way we book people onto clients is typically on a per-week basis. And so, if there's going to be a gap between clients, typically, it's in increments of a week. Because they're on the project for a week, it doesn't necessarily mean that we're tracking the tickets on a per-week thing. So, it's not like, oh, we're committing to doing all of these tickets by the end of a particular time or anything like that. We are working in a more Kanban style where there's a backlog, and you pull tickets, and whatever gets done gets done. What we do try to do, though, is not have individual tickets hang in the in-progress column over a week boundary. So, there's a nuance there. I guess there's some ways in which maybe it feels a little bit sprint-like. But I think we are running in much more of a Kanban-style workflow. STEPHANIE: Yeah, that makes sense. JOËL: It's really to deal with that churn and the idea that even though the ticket might stick around for a while or maybe it gets split up into multiple small tickets, the people are switching constantly. And so, making the workflow play nicely with the fact that the team is churning on a weekly basis kind of adds an extra, you know, a little bit of spice to the project management side of things. STEPHANIE: Did you find yourself being the one to break down tickets to make sure that they weren't larger than a week's worth of work? Or did you work with the developer themselves to find opportunities to break out what they were working on if we got to the mid-week and progress wasn't looking like it would be completed by the end? JOËL: I've left this up to individual developers. This is more of a broad conversation I had with our team, kind of saying, "Hey, here's our goal. We want to get some things done by the end of the week. If we don't think we can get them done, here are some strategies I recommend. I'm available to pair if people want it." But I didn't go through and estimate all the tickets and split them up. I did a little bit of, like, grooming ahead of time. So, I had a sense of when we started the week if tickets felt roughly sized correctly. But oftentimes, you know, that kind of thing, you start working on it, and then you realize, wait a minute, this is a bigger ticket than I thought. STEPHANIE: Yeah. I think even just having someone check in and be like, "Hey, how is progress? Can I support you in making sure that you're able to get to somewhere that feels completed by the end of the week so that the rest of the work is set up for someone new to take on?" That seems really valuable to me. Because as an individual, I'm like, yeah, I don't know, I'm maybe heads down just deep and trying to get my thing done, but maybe not so aware of progress and relative to how much time I've spent on it. And having just someone prompt me on that could help kind of pull myself out a little bit, you know, come out for some air and be like, oh, actually, you know, this is a good spot for me to break this down. Do you have any insights into this week that you might be bringing with you into client work or anything like that? JOËL: And I think this has just given me an even deeper appreciation for breaking tickets down. Because of that arbitrary end-of-the-week deadline, I think that forces more tickets to break down in a way that I might say, oh, well, I picked up a ticket on Thursday for a client. It can totally bleed into next week; that's fine. It's still a fairly short ticket, just, you know, I started the work later. And so, trying to make sure that tickets get scoped down really tightly, I think, is an area where I could probably benefit from that discipline on client projects as well. You know, even if I'm not doing it to the extreme, I'm doing it this week. STEPHANIE: Yeah. I would be really curious to find out if next week the folks who are on this project feel like they're in a good spot to, you know, keep on making forward momentum because they can just pull from the backlog and not have to go and do that knowledge transfer. JOËL: Right. I will see with all of this, right? Maybe even with all the conversations and things, maybe we'll end the week, and I'll have 10 cards in the in-progress column. And it'll be like, okay, we tried a thing this week, mixed success. How do we want to iterate on that idea next week? Potentially with a different team. STEPHANIE: Right, exactly. JOËL: I feel like one way to maybe summarize the type of work that I was doing this week is that it's a kind of a scaling challenge. But over time, the team itself is small, but it's constantly churning. And I think you've been working on a team where it's kind of had a similar problem but in a different dimension. You're scaling over team size, actually a massively large team, and seeing some of the challenges there. What are some of the things that you've been facing? STEPHANIE: Yeah. So, my current client project, I'm working on a codebase where there are hundreds of developers also working and committing to this codebase daily. And this codebase is really massive. There is so much stuff going on. And I've really only explored the world of the particular team that I'm on. But I recently had to do a little bit of work in some code that is owned by a different team. And I actually really appreciated the way that we were able to collaborate across, I guess, ownership boundaries. And I was really interested in talking about some of the different ways that we've seen the idea of, like, who is owning, and, like, who is accountable for areas of the codebase once you reach a certain size. So, what was really convenient about the way that I was working was that in my pull request, there was an automated step that told me I needed specific owner approval on the code that I was writing because I was touching some files that were owned by a different team. And it gave me all of the handles for the people on that team. So, I knew who to go talk to. And it ended up being that that team had a public Slack channel specifically for people outside to ask them questions about their domain. And they had a rotating ambassador system. And so, in the Slack channel, in the channel topic, it said who was the ambassador for that week. So, you know, I saw who it was. I got to @ them and say, like, "Hey, like, I'm working on some of these files for this feature for my team. And, like, here's my pull request. Could you give me a review?" JOËL: The more you're describing this, the more this is feeling very large team, almost bureaucratic systems. I'm hearing public Slack channels, which implies that teams have private Slack channels. I'm hearing, like, a rotating ambassador. One word that you mentioned that I'd like to dig into a little bit is the idea of ownership because I think that the concept of ownership is present on probably most teams, but it probably means wildly varying things. And it sounds like on your team, it's a very kind of codified thing. So, what does ownership look like on your project? STEP…

    Full show notes at the publisher

    398: Developing Heuristics For Writing Software Aug 22, 2023
    Show notes

    Want a cool cucumber salad? Joël's got you covered. Stephanie has evolved and found some pickles she enjoys. Experienced programmers use a lot of heuristics or "rules of thumb" about what makes their code better. These aren't always true, but they work in most situations. Stephanie and Joël discuss a range of heuristics, how to use them, how to come up with them, how to know when to break them, and how to teach them to more junior devs. Pickled mustard seeds The purpose of a system is what it does Intro to empirical software engineering by Hillel Wayne Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: So, as of the recording of this, summer is in full swing, and it's the time of year where we have all these, you know, fresh vegetables out, so I've been really enjoying a lot of those. I think this week; in particular, I've been going into, like, all the variations on cucumber salads. STEPHANIE: Ooh. JOËL: Yeah. So, that's been kind of fun for me. A fun thing I've been doing to spice this up is pickling mustard seeds to add as a topping. That's actually really amazing. It adds just a little bit of acidity, a little bit of crunch, a little bit of texture. And it's pretty. STEPHANIE: That sounds so delicious. And also, I was going to share something about pickles about what's new in my world. [laughs] But first, I am curious, what has been your go-to cucumber salad that you put this pickled mustard seed situation on top? JOËL: So, cucumbers and tomatoes is just the base of everything. And then, it kind of goes with random things I have in my fridge. A little bit of goat cheese on top can be a great topping, big fan of balsamic glaze. You can just get, like, a bottle of that at the grocery store, the pickled mustard seeds. I've recently been trying topping with a fried egg. STEPHANIE: Ooh, that sounds really fun. It kind of, like, adds a bit of savoriness and creaminess and maybe even, like, the crunchy fried edges. That sounds really yummy. JOËL: Particularly if you do it over easy where the center is not fully cooked. When the egg breaks, you effectively get salad dressing for free. STEPHANIE: That sounds so delicious. JOËL: Summer vegetables, they're great. STEPHANIE: They are great. Last year, I did have a cucumber garden, as in a garden, and a few cucumber plants that were too prolific for me, to be honest. I found myself overrun with cucumbers and having to give them away because we just didn't eat them enough. And this year, we scaled back a little bit [laughs] on the cucs. But I am so excited to bring up what's new in my world now because it's, like, so related, and we did not plan this at all. But I have a silly little thing to share about my own pickle journey. So, I used to be a pickle hater. JOËL: You know what? Same. STEPHANIE: Oh my gosh, incredible. Another new thing we've learned about each other. I really, like, wanted to like pickles because, you know, when you order a sandwich in a restaurant, it always comes with the pickle spear. And neither me nor my partner were into pickles, and we would always leave the spear uneaten on the plate, and we felt so bad about it. I felt really bad about it. And so, every, like, three to six months or so, I'd be like, okay, I'm going to gather the courage to try the pickle again and see if maybe my taste buds have changed, and this time I'll like it. And, you know, I would try a bite and just be like, no, no, I don't think it's for me. [laughs] But I guess I was just so primed to do something about, like, wanting to eliminate this really inconsequential food waste. But every time it happened, I would just, you know, [laughs] be, like, oh, if only I loved pickles. And I got my friend, who is a pickle connoisseur, to help me figure out, like, what pickles I might like. So, I asked her to come up with, like, a pickle sampler for me because I really hadn't tried all too many. And that actually really helped me find which ones were a little more palatable to me. So, I found out that I liked the sweeter ones. There's, like, a bread and butter pickle that can be quite sweet. Your diner pickle can be very different from a jar of, like, fancy pickles. [laughs] JOËL: Definitely. STEPHANIE: One day, she gifted me a jar of, like, Polish gherkins that were delicious. JOËL: Hmmm. STEPHANIE: I was like, wow, I can just snack on these. So, the thing that's new is that this time, I went to an Eastern European grocery store, and I bought my own jar of pickled gherkins. And that was something that Stephanie, like, two years ago, would never even do. [laughs] JOËL: That's really cool that you got a chance to sort of explore a broader range of what was available in the pickle world and then were able to find kind of your niche there and discover something new that you actually like. STEPHANIE: Yeah, it was very fun. And now I feel like my whole world has opened up to, you know, pickley and fermented things and just, like, get to enjoy even more snacks. So, to move away from pickles, recently, on my client project, I've been pairing a lot more with other client developers. And one thing that has come up is, you know, talking about our reasoning or our thought process for when we're pairing on some code. And I realized that I have built up a lot of either intuition or maybe some rules that I like to follow when I'm writing code, writing a test, or even doing a code review. And I've realized that you know, as developers, we often use these kinds of shortcuts or heuristics to help orient us as we're doing our work. JOËL: Yeah. I think that's definitely something that either comes yourself from experience or sometimes is passed along, and you get to benefit from somebody else's experience. They learned the hard way a lot of these tips and tricks, and now they kind of pass on some of these guidelines to us. Do you have any favorites that you reach for frequently? STEPHANIE: So, one way I like to approach a problem is to start messy [laughs] and to kind of see what that gets me and then where to go from there. I find that it's a little bit easier for me to draw on things that I've, you know, learned or picked up and tips once I have something in front of me to react to. So, maybe I will just go with the naive implementation and just write all of the code in one method, you know, in a class. And from there, now that it's out of my system, can I kind of come back in with a finer tooth comb and then apply more of a sustained effort to clean things up, right? And, to me, the question I find myself asking is, like, can this be extracted further? And so, you know, if I have everything in one giant method, then yes, [laughs] there is likely, you know, many opportunities to extract that, and maybe I will see something like, oh, the way that I spaced out this code that might be a signal to me that, like, these are some ideas that are grouped together, and I can pull something out there. JOËL: Do you have a heuristic around when to stop extracting? STEPHANIE: That's a good point. I think I tend to stop when I have kind of pulled out the classes that make sense to me. And, at that point, you know, like, maybe there is more extraction that can be done. But at a certain point, you know, you then get these really tiny classes that maybe don't hold their weight. And I think that's also true of methods that then call other methods, and that's the only thing that they do. Then it's like, well, is this too extracted that it's not really giving a future reader helpful information, right? I want the extraction to improve readability. And that tends to be another lens through which I am applying to this idea of, like, can I extract further? Is this extraction helpful for understanding this code? JOËL: I like the idea of looking at the code through multiple lenses. And so, sometimes you look at it through the lens of, yeah, are there enough moving parts here? Or does it feel kind of brittle and all in one place? And then sometimes completely shifting your lens and saying, you know what? Let's put myself in the seat of someone who's looking at this code for the first time. Can I understand it? So, structuring and extracting code is a big part of the work that we do. And I also happen to have a couple of heuristics that I like to use. One is separate branching code from doing code. So, if I have an if...else condition, I try not to put ten lines of logic inside each branch; instead, I have just a call out to a method so that the only thing the conditional does is to choose which path you go, and then each individual path is its own method. Similarly, if I'm writing a method, I'm not going to have a bunch of logic then a conditional mixed in together. So, my heuristic is a method gets to do one of two things. It either gets to choose a path to take or it gets to do a thing, but you can't mix and match both. STEPHANIE: Yeah, that makes a lot of sense. I really appreciate a well-named method that is, you know, determining, like, what condition needs to happen because then that helps me, yeah, like, avoid having to hold all of this information about this condition or this other condition, and this other condition in order to figure out what path I'm trying to take. JOËL: And the naming and the readability, I think, is a big part of this. Another heuristic that I like to use that kind of converges on the same result is trying to write each method at a single level of abstraction. So, if I am writing a method that has some kind of high-level terms it's using, I'm not going to also mix in a lot of low-level implementation. And then, similarly, if it's a method that's doing a lot of, like, low-level nuts and bolts things, I'm going to try not to pull in some of these higher-level domain name methods in there. And so, by separating things out so that every method reads one level of abstraction, you make it much easier for the reader to go through and figure out what's happening. Are we kind of getting that more 10,000-foot view, getting a sense of what's happening, and saying, okay, we want to process the user form, and then we want to send off an email, and then we want to, you know, write to a file? Or are we going through, okay, we're going to increment a counter so that we get exponential back off on our [inaudible 10:28] request? Those two things do not belong together in the same method. STEPHANIE: Yeah, absolutely. I really like this heuristic. And I have been applying it more and more and found it really useful for making sure that you're handling your errors correctly, especially because, at different levels of abstraction, you want to do different things with your errors, right? An implementation error that's raised because, you know, you're calling something accidentally on nil, or maybe a third-party service is down, and you get a custom error, whatever that is, those concerns are different from how you want to handle things at the controller level. And oftentimes, I see those things really mixed together, and honestly, I think leads to a lot of buggy code when you're trying to handle things that can go wrong at the wrong level of abstraction. JOËL: Yeah. Is there a good heuristic around what level you think is best to trigger an exception? Or maybe, more generally, just being aware of different levels of abstraction and knowing that catching or triggering errors at each level will have different impacts. STEPHANIE: I think more of the latter, the having an awareness of what kinds of errors might be possible and what impact that has on the user, right? The user being either an actual customer or, you know, another developer who has to read a notification from an error monitoring service. [laughs] JOËL: This is really interesting to me because I think we've now bridged the concept of heuristics into the idea of mental models. So, the heuristic is write your methods at a single level of abstraction, but that then leads into a mental model where maybe code is structured in three or four different layers. You've got a low level, a mid-level, a high level, something like that, of abstraction. And now, you can use that mental model to start thinking about what are the impacts of exceptions at each layer? And then, maybe you complete the circle by creating a heuristic that relies on that mental model, maybe, I don't know, raise in the low-level rescue at the top level or something. I'm making something absolutely arbitrary up right now. But somehow, we've gone from heuristic, which creates a mental model, which then allows us to build new heuristics on top of that, and that seems like a virtuous cycle to me. STEPHANIE: Yeah, absolutely. I think what I'm also picking up is the idea that you do need a mental model, or you do need to draw on your own ideas about something in order to apply the heuristic, right? You know, someone could tell you to separate branching code from doing code. But maybe you don't know what that means or, like, maybe you don't see why that's important. And sure, you can still apply it and try your best to follow it. But, in some ways, I think that the best heuristics are ones that you've kind of developed for yourself based on your own experience. JOËL: That's really interesting. I think once you've built from your own experience, I definitely feel like they're really impactful because you've kind of synthesized 2, 5, 10, 20 years of experience doing some of this work into, oftentimes, like, you know, a pithy one-line sentence, 5, 6 words that convey an approach that you've found works best, you know, maybe 80% or 90% of the time. The power of synthesis for your own self-learning I think it's really hard to understate. So, I'm curious if there's any other heuristics that you commonly use that you kind of created yourself based off your own experience rather than just having it be more of a broadly received idea from the community. STEPHANIE: I think, for me, it's more so that the experience has helped affirm certain heuristics and also made me feel more comfortable with letting others go. And one that I heard a lot but, like, didn't quite understand until really working through it deeper is the idea of feeling pain when you write a test, and that being a signal of opportunities to try different design with your code. And I just didn't know what that pain was at the beginning. Like, what does that even mean? [laughs] Like, how can a test cause me pain? But on my own, I realized, oh, like, actually, I get really frustrated when I need to stub out a whole method chain, right? And I find myself having to go look up how to do that or just spending a lot of time having to do something that I haven't done before. Maybe the pain comes from having to change a lot of files because, oh no, like, I also broke 20 other tests in the process. But when you're first starting out, oftentimes, you, like, don't know that that is not normal [laughs]; at least, that was true for me. And so, that was something that I had heard about, like, if you are feeling pain when writing a test, then, like, maybe reconsider your code design. But when you don't know how to identify what that pain is, and you also, like, don't know where to go from there, I find that, you kn…

    Full show notes at the publisher

    397: Dependency Graphs Aug 15, 2023
    Show notes

    Stephanie is consciously trying to make meetings better for herself by limiting distractions. A few episodes ago, Joël talked about a frustrating bug he was chasing down and couldn't get closure on, so he had to move on. This week, that bug popped up again and he chased it down! AND he got to use binary search to find its source–which was pretty cool! Together, Stephanie and Joël discuss dependency graphs as a mental model, and while they apply to code, they also help when it comes to planning tasks and systems. They talk about coupling, cycles, re-structuring, and visualizations. Ruby Graph Library Graphviz Using a Dependency Graph to Visualize RSpec let Mermaid.js Strangler Fig pattern Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I'm always trying to make meetings better for me [chuckles], more tolerable or more enjoyable. And in meetings a lot, I find myself getting distracted when I don't necessarily want to be. You know, oftentimes, I really do want to try to pay attention to just what I'm doing in that meeting in the moment. In fact, just now, I was thinking about the little tidbit I had shared on a previous episode about priorities, where really, you know, you can only have one priority [laughs] at a time. And so, in that moment, hopefully, my priority is the meeting that I'm in. But, you know, I find myself, like, accidentally opening Slack or, like, oh, was I running the test suite just a few minutes before the meeting started? Let me just go check on that really quick. And, oh no, there's a failure, oh God, that red is really, you know, drawing my eye. And, like, could I just debug it really quick and get that satisfying green so then I can pay attention to the meeting? And so on and so forth. I'm sure I'm not alone in this [laughs]. And I end up not giving the meeting my full attention, even though I want to be, even though I should be. So, one thing that I started doing about a year ago is origami. [laughs] And that ended up being a thing that I would do with my hands during meetings so that I wasn't using my mouse, using my keyboard, and just, like, looking at other stuff in the remote meeting world that I live in. So, I started with paper stars, made many, many paper stars, [laughs] and then, I graduated to paper cranes. [laughs] And so, that's been my origami craft of choice lately. Then now, I have little cranes everywhere around the house. I've kind of created a little paper crane army. [laughs] And my partner has enjoyed putting them in random places around the house for me [laughs] to find. So, maybe I'll open a cabinet, and suddenly, [laughs] a paper crane is just there. And I think I realized that I've actually gotten quite good at doing these crafts. And it's been interesting to kind of be putting in the hours of doing this craft but also not be investing time, like, outside of meetings. And I'm finding that I'm getting better at this thing, so that seemed pretty cool. And it is mindless enough that I'm mentally just paying attention but, yeah, like, building that muscle memory to perfecting the craft of origami. JOËL: I'm curious, for your army of paper cranes, is there a standard size that you make, or do you have, like, a variety of sizes? STEPHANIE: I have this huge stack of, like, 500 sheets of origami paper that are all the same size. So, they're all about, let's say, two or three inches large. But I think the tiny ones I've seen, really small paper cranes, maybe that would be, like, the next level to tackle because working with smaller paper seems, you know, even more challenging. JOËL: I'd imagine the ratio of, like, paper thickness to the size of the thing that you're making is different. STEPHANIE: At this point, they say that if you make 1,000, then you bring good luck. I think I'm well on my way [laughs] to hopefully being blessed with good luck in this household of my little paper crane army. JOËL: It's interesting that you mentioned the power of having something tactile to do with your hands during a meeting, and I definitely relate to that. I feel like it's so easy, even, like, mindlessly, to just hit Command-Tab when I'm doing things on a screen. Like, my hands are on the keyboard. If I'm not doing something, I'm just going to mindlessly hit Command-Tab. It's kind of like on your phone sometimes. I don't know if you do this, like, just scrolling side to side. You're not actually doing anything. You just want motion with your fingers. STEPHANIE: Yes. I know exactly what you're talking about. And it's funny because it's a bit of a duality where, you know, when you are in your development workflow, you want things to be as quick and convenient as possible, so that Command-Tab, you know, is very easy. It's just built in, and that helps speed up your, you know, day-to-day work. But then it's also that little bit of mindlessness, I think, that can get you down the distraction path. When I was first looking for something to do with my hands, to have, like, a little tactile thing to keep me focused in meetings, I did explore getting one of those fidget cubes; I have to say. [laughs] It's just a little toy, you know, that comes with a bunch of different settings for you to fidget with. There's, like, a ball you can roll, you know, with your thumb, or maybe some buttons to click, and it gives you that really satisfying tactile experience. And I know they work really well for a lot of people, but I've really enjoyed the, I guess, the unexpected benefits [chuckles] of getting better at a hobby [laughs] while spending my time at my work. Joël, what is new with you? JOËL: So, a few episodes ago, I talked about a really kind of frustrating bug that I was chasing down that was due to some, like, non-determinism in the environment. And it kind of came, and then it went away. And I wasn't able to get sort of closure on that and had to move on. Well, this week, that bug popped up again, and this time, I was actually able to chase it down. So, that felt really exciting. And I got to use binary search to try to find the source of it, which made me feel really cool. STEPHANIE: Oooh, do tell. What ended up being the issue? JOËL: I'm connecting to an external Snowflake data warehouse, and ActiveRecord tries to fetch the schema and crashes as part of that with some cryptic error that originates from the C extension ODBC Ruby driver package. I figured out that it's probably something to do with, like, a particular table name or something in the table metadata when we're pulling this schema that we're not happy about. But I don't know which table is the one that it's not happy with. Well, this time, I was able to figure out, by reading through some of the documentation, that I can pull subsets of the schema. So, I can pull the first n values of that schema, and it won't crash. It only crashes if I try to fetch the entire set, which is what is happening under the hood. At that point, you know, I could fetch each row individually, but there's hundreds of these. So, you know, I try, okay, what happens if I try to fetch 1,000 of these? Is it going to crash? Because it's a massive system. So, yes, I get a crash. So, I know that a table less than a thousandth in the list of tables is what's causing the problems. So, okay, fetch 500 halfway in between there. It's still going to crash. Okay, 250, 125. I then kind of keep halving all the time until I find one that doesn't crash. And now I know that it is somewhere between the last crash and this one. So, I think it was between 125 and 250. And now I can say, okay, well, let's fetch the first, you know, maybe 200 tables, okay, that crashes. And I keep halving that space until you finally find it. And then, like, okay, so it's this one right here. Now, the problem is the bad table actually crashes. So, I think it ended up being, like, number 175 or something like that. So, I never get to see the actual table itself. But because the list of tables is in alphabetical order, and I can see because I can fetch the first 174 and it succeeds, so I can tell what the previous 5, 6, you know, previous 174 are. I can pretty easily go and look at the actual database and the list of tables and say, okay, well, it's in the same order. And the next one is this one, and hey, look, there is some metadata there that has some very long fields that are longer than one might expect, specifically going over a potentially implied 256-character limit. That seems somewhat suspicious. And, oh, if we remove this table, all of a sudden, everything works. STEPHANIE: Wow, binary search, an excellent debugging tool [laughs] when you have no idea, you know, what could possibly be causing your issue. JOËL: It's such a cool tool. Like, I'm always so happy when I get a chance to use it. The problem is, you need a way to be able to answer the question, like, have I found it? Yes or no? Or, generally, is it greater or less than this current position? STEPHANIE: Well, that's really exciting that you ended up figuring out how to solve the bug. I know last time we talked about it, you kind of had left off in a space of, hopefully, we won't run into this issue again because it's no longer happening. But it seems like you were also set up this time around to be able to debug once it cropped up again. JOËL: Yes. So, binary search is really cool. It's got this, like, very, like, fancy computer science name. But in reality, it's a fairly simple, straightforward technique that I use fairly frequently in my development. And there's another kind of computer sciency fancy-sounding concept that I use all the time. You've all heard me reference this multiple times on the show. You're right; we're finally doing it. This is the dependency graph episode. STEPHANIE: Woo. [laughter] It's time. I'm excited to really dig into it because, you know, as someone who has heard you talk about it a lot, you know, and is maybe a little less familiar with graph theory and how, you know, it can be applied to my day to day work, I'm really excited to dig into a little bit about, you know, what a regular developer needs to know about dependency graphs to add to their toolbox of skills. JOËL: So, I think at its core, the idea of a dependency graph is that you have a group of entities, some of which depend on each other. They can't do a task, or they can't be created unless some other subtasks or dependent actions take place. And so, we have a sort of formal structural way of describing these things. Visually, we often draw these things out where each of the pieces is like a little bubble or a circle, and then we draw arrows towards the things that it depends on. So, if A cannot be done without B being done first, we draw an arrow from A to B. That's kind of how it is in the abstract. More concretely, this kind of thing shows up constantly throughout the work that we do because a lot of what we do as developers is managing things that are connected to each other or that depend on each other. We build complex systems out of smaller components that all rely on each other. STEPHANIE: Yeah, I think it's interesting because I use the word dependency, you know, very frequently when talking about normal work that I'm doing, you know, dependencies as in libraries, right? That we've pulled into our application, or dependencies, like, talking about other classes that are referenced in this class that I'm working in. And I never really thought about what could be explored further or, like, what could be learned from really digging into those connections. JOËL: It's a really powerful mental model. And, like you said, dependencies exist all over our work, and we often use that word. So, you mentioned something like packages, where your application depends on Rails, which in turn depends on ActiveRecord, which in turn depends on a bunch of other things. And so, you've got this whole chain of maybe immediate dependencies, and then those dependencies have dependencies, and those dependencies have dependencies, and it kind of, like, grows outward from there. And in a very kind of simplistic model, you might think, oh, well, it's more, like, a kind of a tree structure. But oftentimes, you'll have things like branches on one side that connect back to branches on the other. And now you've got something that's no longer really tree-like. It's more of a sort of interconnected web, and that is a graph. STEPHANIE: I think understanding the dependencies of your system has also become more important to me as I learn about things that can go wrong when I don't know enough about what my system is, you know, relying on that I had kind of taken for granted previously. I'm especially thinking about packages like we were mentioning, and, you know, not realizing that your application is dependent on this other library, right? That's brought in by a gem that you're using. And there's maybe, like, a security issue, right? With that. And suddenly, you have this problem on your hands that you didn't realize before. And I know that that has been more of a common discussion now in terms of security practices, just being more aware of all the things that you are depending on as really our work becomes more and more interconnected with the things available to us with open source. JOËL: I think where understanding the graph-like nature of this becomes really important is when you're doing something like an upgrade. So, let's say you do have a gem that has a security problem, and you want to upgrade it to fix that security issue. But the upgrade that includes the security patch is also a breaking upgrade. And so, now everything else in your system that depends on that gem or on that package is going to break unless you have them in a version that is compatible with the new version of that gem. And so, you might have to then go downstream and upgrade those packages in a way that's compatible with your app before you can bring in the security patch. And a lot of that can be done automatically by Bundler. Bundler is software that is built around navigating dependency graphs like that and finding versions that are compatible with each other. But sometimes, your code will need to change in order to upgrade one of these downstream gems so that you can then pull in the upgrade from the gem that needs a security patch. And so, understanding a little bit of that graph is going to be important to safely upgrading that gem. STEPHANIE: So, I know another application of dependency graphs that you have thought about and written a blog post for is RSpec let declarations and how a lot of the time when we are using let, you know, we are likely calling other variables defined by let. And so, when you are encountering a test file, it can be really hard to grok what data is being set up in your test. JOËL: Yeah, so that is really interesting because you can define something that will get executed in a lazy fashion if it gets referenced. But then not only is the let lazy and will not trigger unless it's referenced, but a let can reference other lets, which are also lazy, and only get triggered if they get referenced. So, you might have a bunch of lets defined in any order you want througho…

    Full show notes at the publisher

    396: Build vs. Buy Aug 08, 2023
    Show notes

    Joël has been fighting a frustrating bug where he's integrating with a third-party database, and some queries just crash. Stephanie shares her own debugging story about a leaky stub that caused flaky tests. Additionally, they discuss the build vs. buy decision when integrating with third-party systems. They consider the time and cost implications of building their own integration versus using off-the-shelf components and conclude that the decision often depends on the specific needs and priorities of the project, including how quickly a solution is needed and whether the integration is core to the business's value proposition. Ruby class instance variables Build vs Buy by Josh Clayton Sustainable Rails Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: My world has been kind of frustrating recently. I've been fighting a really frustrating bug where I'm integrating with a third-party database. And there are queries that just straight-up crash. Any query that instantiates an instance of an ActiveRecord object will just straight-up fail. And that's because before, we make the actual query, almost like a preflight query that fetches the schema of the database, particularly the list of tables that the database has, and there's something in this schema that the code doesn't like, and everything just crashes. Specifically, I'm using an ODBC connection. I forget exactly what the acronym stands for, Open Database connection, maybe? Which is a standard put up by Microsoft. The way I'm integrating it via Ruby is there's a gem that's a C extension. And somewhere deep in the C extension, this whole thing is crashing. So, I've had to sort of dust off some C a little bit to look through. And it's not super clear exactly why things are crashing. So, I've spent several days trying to figure out what's going on there. And it's been really cryptic. STEPHANIE: Yeah, that does sound frustrating. And it seems like maybe you are a little bit out of your depth in terms of your usual tools for figuring out a bug are not so helpful here. JOËL: Yeah, yeah. It's a lot harder to just go through and put in a print or a debug statement because now I have to recompile some C. And, you know, you can mess around with some things by passing different flags. But it is a lot more difficult than just doing, like, a bundle open and binding to RB in the code. My ultimate solution was asking for help. So, I got another thoughtboter to help me, and we paired on it. We got to a solution that worked. And then, right before I went to deploy this change, because this was breaking on the staging website, I refreshed the website just to make sure that everything was breaking before I pushed the fix to see that everything is working. This is a habit I've picked up from test-driven development. You always want to see your test break before you see it succeed. And this is a situation where this habit paid off because the website was just working. My changes were not deployed. It just started working again. Now it's gotten me just completely questioning whether my solution fixes anything. The difficulty is because I am integrating [inaudible 03:20] third-party database; it's non-deterministic. The schema on there is changing rather frequently. I think the reason things are crashing is because there's some kind of bad data or data that the ODBC adapter doesn't like in this third-party system. But it just got introduced one day; everything started breaking, and then somehow it got removed, and everything is working again without any input or code changes on my end. So, now I don't trust my fix. STEPHANIE: Oh no. Yeah, I would struggle with that because your reality has come crashing down, [laughs] or how you understood reality. That's tough. Where do you think you'll go from here? If it's no longer really an issue in this current state of the schema, is it worth pursuing further at this time? JOËL: So, that's interesting because it turns into a prioritization problem. And for this particular project, with the deadlines that we have, we've decided it's not worth it. I've opened up a PR with my fix, with some pretty in-depth documentation for why I thought that was the fix and what I think the underlying problem is. If this shows up again in the next few days, I'll have that PR that I can pull in and see if it fixes things, and if it doesn't, I'll probably just close that PR, but it'll be available for us if we ever run into this again. I've also looked at a few potential mitigating situations. Part of the problem is that this is a, like, massive system. The Rails app that I'm using really doesn't need to deal with this massive database. I think there's, you know, almost 1,000 tables, and I really only care about a subset of tables in, like, one underlying schema. And so, I think by reducing the permissions of my database user to only those tables that I care about, there's a lower chance of me triggering something like this. STEPHANIE: Interesting. What you mentioned about, you know, having that PR continue to exist will be really helpful for future folks who might come across the same problem, right? Because then they can see, like, all of the research and investigation you've already done. And you may have already done this, but if you do think it's a schema issue, I'm curious about whether the snapshot of the schema could be captured from when it was failing to when it has magically gotten fixed. And I wonder if there may be some clues there for some future investigator. JOËL: Yeah. I'm not sure what our backup situation is because this is a third-party system, so I'd have to figure out what things are like in the admin interface there. But yeah, if there is some kind of auditing, or snapshots, or backups, or something there, and I have rough, you know, if I know it's within a 24-hour period, maybe there's something there that would tell me what's happening. My best guess is that there's some string that is longer than expected or maybe being marked as a CHAR when it should be a VARCHAR, or maybe something that's not a non-UTF-8 encoded character, or something weird like that. So, I never know exactly what was wrong in the schema. There's some weird string thing happening that's causing the Ruby adapter to blow up. STEPHANIE: That also feels so unsatisfying [laughs] for you. I could imagine. JOËL: Yeah, there's no, like, clean resolution, right? It's a, well, the bug is gone for now. We're trying to make it less likely for it to pop up again in the future. I'm trying to leave some documentation for the next person who's going to come along, and I'm moving forward, fingers crossed. Is that something you've ever had to do on one of your projects? STEPHANIE: Given up? Yes. [laughter] I think I have definitely had to learn how to timebox debugging and have some action items for when I just can't figure it out. And, you know, like we mentioned, leaving some documentation for the next person to pick up, adding some additional logging so that maybe we can get more clues next time. But, you know, realizing that I do have to move on and that's the best that I can do is really challenging. JOËL: So, you used two words here to describe the situation: one was giving up, and the other one was timebox. I think I really like the idea of describing this as timeboxing. Giving up feels kind of like, defeatist. You know, there's so many things that we can do with our time, and we really have to be strategic with how we prioritize. So, I like the idea of describing this as a timeboxing situation. STEPHANIE: Yeah, I agree. Maybe I should celebrate every time that I successfully timebox something [laughs] according to how I planned to. [laughs] JOËL: There's always room to extend the timebox, right? STEPHANIE: [laughs] It's funny you bring up a debugging mystery because I have one of my own to share today. And I do have to say that it ended up being resolved, [chuckles] so it was a win in my book. But I will call this the case of the leaky stub. JOËL: That sounds slightly scary. STEPHANIE: It really was. The premise of what we were trying to figure out here was that we were having some flaky tests that were failing with a runtime error, so that was already kind of interesting. But it was quickly determined it was flaky because of the tests running in a certain order, so-- JOËL: Classic. STEPHANIE: Right. So, I knew something was happening, and any tests that came after it were running into this error. And I was taking a look, and I figured out how to recreate it. And we even isolated to the test itself that was running before everything else, that would then cause some problems. And so, looking into this test, I saw that it was stubbing the find method on an ActiveRecord model. JOËL: Interesting. STEPHANIE: Yeah. And the stubbed value that we were choosing to return ended up being referenced in the tests that followed. So, that was really strange to me because it went against everything I understood about how RSpec cleans up stubs between tests, right? JOËL: Yeah, that is really strange. STEPHANIE: Yeah, and I knew that it was referencing the stub value because we had set a really custom, like, ID value to it. So, when I was seeing this exact ID value showing up in a test that seemed totally unrelated, that was kind of a clue that there was some leakage happening. JOËL: So, what did you do next? STEPHANIE: The next discovery was that the error was actually raised in the factory setup for the failing tests and not even getting to running the examples at all. So, that was really strange. And digging into the factories was also its own adventure because there was a lot of complexity in the factories. A lot of them used hooks as well that then called some application code. And it was a wild goose chase. But ultimately, I realized that in the factory setup, we were calling some application code for that model where we had stubbed the find, and it had used the find method to memoize a class instance variable. JOËL: Oh no. I can see where this is going. STEPHANIE: Yeah. So, at some point, our model.find() returned our, you know, stub value that we had wanted in the previous test. And it got cached and just continued to leak into everything else that eventually would try to call that memoized method when it really should have tried to do that look-up for a separate record. JOËL: And class instance variables will persist between tests as long as they're on the same thread, right? STEPHANIE: Yeah, as far as I understand it. JOËL: That sounds like a really frustrating journey. And then that moment when you see the class instance variable, and you're like, oh no, I can't believe this is happening. STEPHANIE: Right? It was a real recipe for disaster, I think, where we had some, you know, really complicated factories. We had some sneaky caching issues, and this, you know, totally seemingly random runtime error that was being raised. And it was a real wild goose chase because there was not a lot of directness in going down the debugging path. I feel like I went around all over the codebase to get to the root of it. And, in the end, you know, we were trying to come up with some takeaways. And what was unfortunate was that you know, like, normally, stubbing find can be okay if you are, you know, really wanting to make sure that you are returning your mocked value that you may have, like, stubbed some other stuff on in your test. But because of all this, we were like, well, should we just not stub find on this really particular model? And that didn't seem particularly sustainable to make as a takeaway for other developers who want to avoid this problem. So, in the end, I think we scoped the stub to be a little more specific with the arguments that we wanted to target. And that was the way that we went forward with the particular flaky test at hand. JOËL: It sounds like the root cause of the problem was not so much the stub as it was the fact that this value is getting cached at the class level. Is that right? STEPHANIE: Yes and no. It seems like a real pain for running the tests. But I'm assuming that it was done for a good reason in production, maybe, maybe not. To be fair, I think we didn't need to cache it at all because it's calling a find, which is, you know, should be pretty quick and doesn't need to be cached. But who knows? It's hard to tell. It was really old code. And I think we were feeling also a little nervous to adjust something that we weren't sure what the impact would be. JOËL: I'm always really skeptical of caching. Caching has its place. But I think a lot of developers are a little too happy to introduce one, especially doing it preemptively that, oh well, we might need a cache here, so why not? Let's add that. Or even sometimes, just as a blind solution to any kind of slowness, oh, the site is slow; let's throw a cache here and hope for the best. And the, like, bedrock, like, rule zero of any kind of performance tuning is you've got to measure before and after and make sure that the change that you introduce actually makes things better. And then, also, is it better enough speed-wise that you're willing to pay any kind of costs associated to maintaining the code now that it's more complex? And a lot of caches can have some higher carrying costs. STEPHANIE: Yeah, that's a great point. This debugging mystery an example of one of them. JOËL: How long did it take you to figure out the solution here? STEPHANIE: So, like you, I actually was on a bit of the incorrect path for a little while. And it was only because this issue affected a different flaky test that someone else was investigating that they were able to connect the dots and be like, I think these, you know, two issues are related. And they were the ones who ultimately were able to point us out to the offending test if you will. So, you know, it took me a few days. And I imagine it took the other developer a few days. So, our combined effort was, like, over a week. JOËL: Yep. So, for all our listeners out there, you just heard that Stephanie and I [laughs] both went on multi-day debugging journeys. That happens to everyone. Just because we've been doing this job for years doesn't mean that every bug is, like, a thing that we figure out immediately. So, separately from this bug that I've been working on, a big issue that's been front of mind for me on this project has been the classic build versus buy decision. Because we're integrating with a third-party system, we have to look at either building our own integration or trying to use some off-the-shelf components. And there's a few different levels of this. There are some parts where you can actually, like, literally buy an integration and think through some of the decisions there. And then there's some situations where maybe there's an open-source component that we can use. And there's always trade-offs with both the commercial and the open-source situation. And we have to decide, are we willing to use this, or do we want to build our own? And those have been some really interesting discussions to have. STEPHANIE: Yeah. I think you actually expanded this decision-making problem into a build versus buy versus ope…

    Full show notes at the publisher

    395: Human Connection in a Virtual (Work) World Aug 01, 2023
    Show notes

    Stephanie had a small consulting win: saying no to a client. GeoGuessr is all the rage for thoughtbot's remote working culture, which leads to today's topic of forming human connections in a virtual (work) environment. GeoGuessr Strategies for saying no by Elle Meredith NYT Let’s Ignore Each Other in the Same Room Random question generator Transcript: JOËL: And this is just where it ends. [laughter] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm 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 have a small consulting win, or even just a small, like, win as a human being [laughs] that I want to share, which is that I feel good about a way that I handled saying no to a stakeholder recently. And, you know, I really got to take them where I can get it because that is so challenging for me. But I feel really glad because we ended up kind of coming out the other side of it having a better understanding of each other's goals and needs. And so, basically, what happened was I was working on a task, and our product owner on our team asked me if it could be done by next week. And immediately, I wanted to say, "Absolutely not." [laughs] But, you know, I took a second and, you know, I had the wherewithal to ask why. You know, I was kind of curious, like, where was this deadline coming from? Like, what was on her radar that, like, wasn't on mine? And she had shared that, oh, you know, if we were able to get it out before this big launch, she was thinking that it actually might make our customer support team's lives easier because we were kind of taking away access to something before some new features rolled out. And, you know, there might be some customers who would complain. And with that information, you know, that was really helpful in helping me understand. And I'm like, yeah, like, that seems like a helpful thing to know, so I could try to strive for it. Because I also, like, want to make that process go easier as well. But I told her that I'd let her know because I honestly wasn't sure if it was possible to do by next week. And after a little bit of, you know, more digging, kind of seeing how my progress was going, in the end, I had to say that I didn't feel confident that we could finish it in time for that deadline because of the other risks, right? Like, I didn't want to just release this thing without feeling good about the plan that we had. And so, that was my small, little win in saying no, and I feel very proud of myself for it. JOËL: I'm proud of you too. That's not easy to just do in the first place, and then to do it well is a whole other level. It sounds, though, that you came out of the other side with the client with almost, like, a better relationship. STEPHANIE: Yeah, I think so. In general, you know, I really struggle when people do end up getting into that debate of, like, "Well, I need this." And someone else says, "Well, I need this other thing." And, you know, at some point, it kind of gets a bit unproductive, right? But I think this was a very helpful way for me to see a path forward when maybe we, like, have different priorities. But, like, can we better understand each other and the impact of them to ultimately, like, make the best decision? The other thing that I wanted to share that I learned recently was there was a recent RailsConf talk by Elle Meredith, and it was about strategies to say no, and I watched it. And one really cool thing that I learned was that the word priority, you know, when it was first created, it actually didn't really have, like, a plural form. There was really only ever, like, a singular priority. And it wasn't until, I think, you know, the recent century or something like that, that people started to use it in a plural form. And that was really enlightening to me. I think it made me rethink the word and how I use it, and it made a lot of sense, too. Because at any given moment, you know, really, you can't be doing more than one thing; I mean, you can try. I know that I have been guilty of multitasking. But that, you know, doesn't always serve me. I never end up doing all of the things that I'm trying to do well. And I would be really curious to kind of, you know, when I do feel that urge, like, think a little bit about, like, what is the one thing that I should be doing right now that is the highest priority? JOËL: I would definitely second that recommendation for this talk. I actually got to see it live at RailsConf, and it was excellent. STEPHANIE: So, Joël, what's new in your world? JOËL: I got to participate in a really fun event at thoughtbot today. We got together with some other people on the Boost Team and played a few rounds of GeoGuessr. And for those who are not familiar with this game, it drops you randomly somewhere in the world in Google Street View. You can move around. And there's a timer, and you have to drop a pin on a map where you think you are. So, you're walking through the streets, and you're like, okay, well, I don't know this language. I'm not sure where we're going. You know, with the vibes going here, I'll bet, you know, this looks like maybe southern China, and then you drop a pin. And oh no, turns out it was actually Singapore. And there's all these little hints and things. People who are really into it have learned all these tricks, and they can be really good. Sara Jackson, who is our resident GeoGuessr expert, is excellent at this. But it was a good time. STEPHANIE: Yeah, it was really fun. I liked that we played a cooperative mode where we were all kind of helping each other out. And so, maybe someone is, like, exploring on the map and sees a street sign and is like, "Oh, like, that looks like this language." And someone else is like, "Oh yeah, like, that is that." Or like, "No, I think it's actually this other language," and sharing all of the different, like, pieces of information that we're finding to get closer and closer to what it might be. And then we celebrate whoever ends up getting the closest because, at some point, it's kind of just, like, just a luck of the pin, right? Where maybe you happen to click on, like, the right place. But it's always really exciting when we're like, wow, like, Sara was only 500 kilometers away in finding the exact place that we were served. So, I had a good time as well. JOËL: So, speaking of cooperative events, this was a work event that we did. We just got together and played a game. And, for me, that was a really fun way to connect with some of my colleagues. I'm curious, what are your thoughts on things that you've seen done well in companies that are remote-first that really foster a sense of connection and community among a team? STEPHANIE: I think this worked especially well today because it was kind of scheduled in regular time that we have as a team to me. And sometimes, you know, the meeting topics are a bit more work-focused. But what I really like is that anyone on the team can host one of these meetings. We have them biweekly, and we just call them Boost biweeklies. Boost is the team that Joël and I are on. JOËL: Naming is the hardest problem in computer science. STEPHANIE: It really is. But I really like that people can bring, you know, a little bit of their own flavor to this meeting. So, whoever is host just kind of comes up with something to do. And sometimes it's like show and tell. You know, other times it is more of like, you know, what's the update on some of the projects that we're doing? Other times, it's the Spicy Takes Lightning Talks that we've kind of mentioned on the podcast before. And yeah, it is just a really nice, like, time for us to get together. And I also feel like I learn something about my co-workers every time that we meet, whether it's the person who is hosting the meeting and kind of where their interests are. I think someone even did, like, chair yoga once and guided the team in doing that. Or because they are more casual, right? Sometimes we just play a game, and I really enjoy that nice break in my day. JOËL: Do you find that the particular style of these meetings makes you feel more connected to your colleagues? Would you prefer just kind of game day one, like we had today, versus maybe, like, lightning talks or a presentation on security or something like that? STEPHANIE: I actually think the diversity is what makes it special. I get to see, you know, a bunch of different sides of my co-workers and, you know, some days, the topic is a little more serious, and that can be really connecting. Another Boost Team member had hosted a biweekly where we kind of shared the challenges of, like, consulting work and, like, onboarding onto a new project and sharing what might be difficult and, like, how we might be feeling when we do join a new project. And I think that was really helpful because it was very validating for something that I thought, like, maybe I felt a little bit more alone in. And the tone was a little bit more, like, earnest and serious. But I came away with it feeling very supported by my team, right? And other times, it is just silliness and fun [laughs], which, you know, is also important. Like, we need to have fun every once in a while. JOËL: That's awesome. Do you feel like when you go to these meetings, you're looking more for knowledge or looking more for connection? STEPHANIE: I think both because knowledge sharing is also, you know, can be really helpful. Like, I have enjoyed learning that, you know, so and so is, like, a GeoGuessr expert, Sara, right? And so, if I ever, like, find myself needing [chuckles] someone to go to about my Google Street View or world geography questions, I know that I can go to her. And, like, knowing that about her, like, makes me feel more connected to her. So, I think both are true. So, we have been talking about a meeting style form of connecting in a remote workplace, but I'm really curious about your thoughts on asynchronous versus synchronous communication and how you find connection with a format that is more asynchronous, not just, you know, being in a meeting together. JOËL: That's really challenging. I think I personally find that something that's mostly synchronous with maybe a little bit of a lag works pretty well for me, so something like Slack, where it's not exactly real-time because someone could take some time to come back to me. But for working hours overlap, there's likely some close-to-synchronous conversation happening. But, you know, I can still get up and, you know, refill my cup of coffee, or it's not quite like I'm sitting in front of a camera. So, I think that, for many things, hits the sweet spot for myself. But there's definitely some things where I think you want a higher, like, information density. And that's, I think, where the synchronous face-to-face meeting really shines. STEPHANIE: Information density. I haven't heard that phrase before, but I like it. JOËL: The idea being, you know, how much information or how many words are you sharing back and forth, you know, per minute or something like that. And when you're talking on a call, you can do a lot more of that than you can going back and forth over Slack or writing an email. STEPHANIE: So, I would say that at thoughtbot, we have a pretty asynchronous Slack culture, which I think can be quite different from other, you know, places I've worked at before or other Slack spaces that I've seen. And I actually find it a little bit harder to engage in that way. We have a dev channel where, you know, people chat about different technical topics. And sometimes, you know, those threads go, like, 40 replies long. And I think you tend to engage a lot more in those. And I'm curious, like, does that scratch the itch for you in terms of that perfect, like, async, kind of some amount of lag for you to be doing other things, kind of doing your work, but then being able to come back and pick up the conversation where I left off? JOËL: Yes, that is really nice because, you know, maybe I have a meeting or something, and I'm not there when the conversation starts, but I don't miss out. And I get to join in, you know, maybe 30 minutes after everyone else. You know, sometimes you don't want to just, like, restart a conversation that's happened and is done. But some of these things will kind of be going on and off all day. And those can be really fun, especially sometimes, like, a new person joins the thread and brings in a totally new perspective or a new angle that kind of, like, breathes new life into it and kind of gives everyone a new perspective. STEPHANIE: Nice. I also think there's something to the idea of seeing more people engage with something that then invites other people to engage with it. JOËL: I would agree with that. It's definitely exciting to see a thread, and it's not like, oh, it's empty, and I'm the only one who's put a response in here. When there is a lot of back and forth, you can almost feel the excitement. And that gets me hyped to, like, keep it going. STEPHANIE: At a previous workplace in our Slack, we had a, like, virtual Jeopardy channel. JOËL: Ooh. STEPHANIE: And so, there was a little Jeopardy bot. And I guess whenever someone, you know, had a low on what they were doing, they would just start, you know, tagging the bot to pose a question. And anyone can answer, right? But once you kind of got the ball rolling, you would see other people start playing as well. And it would get really active for segments of 30 minutes or so. And I always really enjoyed that because, yeah, it was a way for me to remember like, oh yeah, there's, like, other people also, like, typing away on their little keyboards, and we're all here together. But it was really interesting to see, like, when someone got it rolling, like, oh, other people, like, joined in. JOËL: Yeah, being able to see small things like that can really build a sense of connection, even if you're not yourself directly participating. STEPHANIE: Yeah. I think another thing I've been trying out lately is letting people know that I'm in a meeting space and offering to virtually co-work. So, you know, during the early days of when thoughtbot went remote, we had a lounge virtual meeting space for people to hang out with and, you know, get that face time that they weren't getting anymore since we weren't in the office. And, you know, I think that has kind of decreased in terms of engagement over, you know, several years now. And obviously, people have a lot of meeting fatigue and stuff like that. But I was kind of in a mood to revive it a little bit because, yeah, I kind of got over the meeting fatigue and was wanting more face time with people. And the unfortunate thing, though, is that, like, no one was showing up to this room anymore. So, you know, even if someone wanted to hang out in it, you know, they go in. They see no one's there, you know, maybe they stay for a few minutes, but then they're like, okay, well, I'm just going to leave now. And a couple of thoughtboters and I have been trying to revive it where we'll post in our general channel, like, "Hey, like, I'm in this meeting room. Like, come hang out for the next hour if you would like." And that's been working well for me. I have had a few, like, really nice lounge, virtual co-working h…

    Full show notes at the publisher

    394: Submitting a Conference Talk Proposal from Start to Finish Jul 25, 2023
    Show notes

    Joël recently had a fascinating conversation with some friends about the power of celebrating and highlighting small wins in their lives. He talks about bringing this into his work life. May Stephanie interest you in a secret she learned regarding homemade pizza? RubyConf is coming! Who's submitting talks?! It's hekkin scary. Don't fret! Joël and Stephannie are here to help. Today, they discussed submitting a conference talk proposal from start to finish. Sheet pan pizza RubyConf CFP Speakerline.io WNB.rb Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we've come 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've been having a really interesting conversation with some of my friends recently about the power of celebrating and highlighting small wins in our lives, both in, like, kind of sharing it with each other, like, you know, if something small happens, it's good for me to share it with my friends. But also, where it becomes really cool is where the friend group kind of gets together and celebrates that small win for one person, and how that can be, like, a small step to take, but it's just really powerful and encouraging for a friend group. And I think that applies not just among friends but in a team or other grouping in the workplace. STEPHANIE: That's so fun. How are you celebrating these small wins, like, over text? Is that the main way you're communicating something good that happened? JOËL: It depends on the friend group. I think, like, different friend groups will have, like, a different kind of cadence for the kind of things they do. And do they all hang out together? Do they have a group text, things like that? One of the friend groups I'm a part of, we meet weekly to go climbing at a rock-climbing gym, so that's kind of our hang-out. And [inaudible 01:34], we're there to do stuff at the gym, but it's also a social thing. And it's an opportunity to be like, "Oh, you know, did that thing workout, you know, at work?" "You know, good for you," Or "Did you get this project accepted?" And yeah, when small wins come up, it's a great time to celebrate. STEPHANIE: That's awesome. I think having regular time that you see people and being able to ask them about something that they had mentioned previously is so special and really important to me, like, in bonding and building the relationship. I also love the idea of celebrating milestones. So, this is, I guess, more of a bigger win, but milestones that aren't traditionally celebrated. You know, so, yeah, we'll have, like, a party when someone graduates or someone gets married. But I also have really enjoyed celebrating when someone gets a promotion at work. And, you know, maybe that's not, like, a once-in-a-lifetime thing, but it's still so worthy of going out for dinner or buying them a drink. I also will maybe, like, send my friends a little treat if I know that they did something small but hard for them, right? And sometimes that's even, like, responding to a scary email that they had sitting in their inbox for a while. Yeah, I really love that idea of supporting people, even in the small things in life that they do. JOËL: Yeah, and that's really validating, I think when you've done something hard and then a friend or a colleague reaches out to you. And it's kind of like, hey, I saw that. Good for you. STEPHANIE: How have you been thinking about bringing this into your work life? JOËL: I think it's about being on the lookout for things that other people do. And I think one thing I like to do is kind of publicly calling that out. It sounds like a negative thing, right? But just giving people kind of a public shout-out when they've succeeded at something. I think we're all kind of socialized not to maybe talk too much about accomplishments, especially if they feel kind of small and mundane. Being somebody else, I think, gives you a lot more leeway to say, "Hey, no, Stephanie, I see that you did that thing. And maybe it feels kind of like, oh no, you're just doing your job, but I think that's cool. And I want to, you know, just give you a shout-out in the company Slack channel or something." It doesn't have to be something big. You know, I'm not sending champagne to your home. But having that opportunity to just kind of celebrate something small and say, "Wait a minute, let's pause and acknowledge that you just did something cool." STEPHANIE: Yeah, I was thinking about how that's kind of, like, amplifying the win a little bit. I've definitely done this before, too, when I see someone share a win of theirs, maybe in a smaller Slack channel or kind of a personal level, or even just to me individually. And I really want other people to know that that happened to you and that they, you know, did an awesome job. And so, I have enjoyed, you know, sharing them more publicly on their behalf if they are comfortable with it. JOËL: And I'll say on the other end of that, I think it feels really good to be acknowledged by someone else that you've done something that they recognize. It's fun to share a win with other people because you're excited, but it's doubly fun when somebody else shares it for you. STEPHANIE: I agree. I think one thing that you, Joël, do really well, actually, is sharing your own personal wins in a very casual way. That's something I've always admired about you is how you recognize the small wins for yourself. JOËL: It's taken me, I think, a long time to get to that and find a way where, you know, you are sharing things that are fun for other people to see, things that might be inspiring, things that are kind of cool, and that are not just kind of, like, self-aggrandizing, like, bragging about stuff. It can be a fine line to walk. And, to a certain extent, you're a little bit marketing yourself. But yeah, I think I've kind of hit that right balance. STEPHANIE: Yeah, I think the thing that makes it work is that there's usually, like, a challenge or something that maybe you, like, went through a journey or overcame a little bit. And I think that's what is the inspiring part that makes me feel like, oh, okay, so, like, this is a realistic thing that, you know, Joël went through and, you know, he struggled with it maybe. But then, like, ultimately, you know, had some insights or came out the other side with some learnings. And I like that it's real, right? It's not just, "Hey, like, I did this, like, cool thing." It's like, "I went on this journey." And I find that really motivating when I am in that kind of situation next time. JOËL: There's a power to stories, right? And I think especially when you can make something relatable to other people. So, it's not just like, "Hey, I did a cool thing," which, you know, is also fun. But being able to say, "Hey, I messed up," or "I, you know, had this challenging problem dropped in my lap, and here's the journey I went on to resolve it. Hopefully, it acts a little bit as like a here's a template you could follow if you're ever in that situation." But maybe also a little bit of, like, inspiration for others as well, just being like, hey, Joël, messes up sometimes. So, Stephanie, what is new in your world? STEPHANIE: Speaking of small wins, I have finally perfected our at-home pizza situation for making pizza at home, which I have been struggling with for so long. Because I always was excited by the idea of making pizza and, you know, sometimes we would make our own dough. And sometimes, we would buy store-bought dough, but it never ended up being as crispy and cooked well-done the way that I want it to. It was always, like, a little bit mushy on the inside. The dough wasn't totally baked. And I would inevitably be disappointed when I had been, you know, building that excitement for pizza. And the other week, I found a new recipe to try, and I think it will be my new go-to recipe for making pizza at home. JOËL: I don't know if I'm allowed to ask this on air, but what's the secret? STEPHANIE: The secret? Well, okay, the first secret and/or learning that I've gathered is to not put as much sauce, cheese, and toppings as you think you want to because that's definitely what contributes to the under-doneness of the dough. But I pivoted to trying a more grandma-style crust that is kind of more like focaccia; really, you know, it involves a lot of olive oil. And you're cooking it for a while on pretty high heat to ensure the crispness and, you know, that it's cooked through. And, I mean, I love focaccia bread, so I don't mind it as, you know, the base of my pizza. It is a bit different from, you know, other kinds of pizzas. And if we had, like, a really, you know, fancy pizza oven to do the, like, super high heat, like, Neapolitan-style deal, I would also really enjoy that. But you know what? That's just not the reality of my home kitchen. So, I have really been enjoying this pizza recipe by Alison Roman that I will link in the show notes. But yeah, it has really changed my at-home pizza game. And I hopefully won't have any of my, you know, soggy dough bottom problems anymore. JOËL: So, you mentioned just kind of offhand, like, oh yeah, you know, the crust is just kind of, like, how you make focaccia. It sounds like you've made focaccia yourself before. STEPHANIE: I have made focaccia at home, and so I think applying it to Pizza was a real, like, light bulb moment for me. But, you know, it's not, like, totally effortless. But I think it's a lot more forgiving than other types of bread and, therefore, other types of pizza crust. And the one really enjoyable thing about making focaccia is there's a step where you use your fingers, and you're kind of holding your hands like you're playing a piano. And you, like, press into the dough after it has risen a little bit to create dimples and, you know, lets the oil kind of seep into the little holes. And it's very satisfying. It's a very good feeling. JOËL: The kind of the tactile aspect of it? STEPHANIE: Yeah, exactly. It's very fun. [chuckles] So, yeah, it's just an added bonus to my pizza adventures. JOËL: A win on top of a win. We'll take it. So, there's some news in the Ruby community this week because RubyConf has just opened their CFP, their call for proposals. And so, they're asking for people to submit their ideas for conference talks, and if you're lucky, you get picked to speak at the conference. And, Stephanie, I know that over the course of a year, you have a document where you collect conference talk ideas so that you have ideas to work on when the CFP comes around. Are you looking at any of them to potentially submit to RubyConf this year? STEPHANIE: Joël, I have to be honest with you; so far, I only have one idea on that list. [laughs] But that is one that I suppose could eventually become a conference talk proposal. So, when I heard the news, I definitely went down the rabbit hole of revisiting that idea and kind of starting to think about if it's something I wanted to pursue. I think the answer is yes. I definitely got a big push of motivation when I was like, oh, it's open. Like, now I can just get started if I want to. And then I was like, well, it's open for a month, so I could also just sit on it a little longer, you know, put it aside and revisit it when I have a little more time. But yeah, I was pretty excited because I think it gave me the motivation I needed to really think a little more deeply about this idea that I have. Otherwise, I think it would have continued to sit half-baked in my document for a long time. JOËL: And just for all of our listeners, the CFP just opened on July 12th, and it closes on August 20th. So, if you are listening and it's before August 20th, you still have a shot to submit your idea to be a speaker. STEPHANIE: Something that I've talked about with my other friends who enjoy speaking at conferences is how they come up with proposals, and I found that we all have different approaches. And I am really interested in digging into this further with you. But I realized that, for me, I really struggle with just, like, throwing out ideas and submitting them before I feel really confident that it's something that I have interesting things to say really, or, like, kind of adding a new perspective, or maybe approaching a topic that hasn't been approached before. I feel sometimes a bit hindered by my process, where I need to feel really confident before submitting something. Because a friend of mine she was telling me that her approach is to submit CFP for topic ideas that she wants to explore further. So, maybe it is something that she doesn't know a lot about yet, and she's using this process to learn more and dive deeper, and that, you know, gives her a reason to do that, whereas that seems really scary to me. JOËL: That's really interesting because it sounds like kind of an underlying motivation for your friend for submitting these talks is curiosity, exploration. And thinking back to myself, I think I usually submit ideas that have me excited or passionate, so that's kind of my underlying motivation for a talk. What would you say is maybe your underlying motivation when you're pitching an idea? STEPHANIE: Yeah, I think, for me, it is impact and, like, having an impact, especially for something that I've struggled with and wanting to share my experience and, hopefully, sharing something where other people can relate to. It's funny you mentioned that your motivators are, you know, excitement and passion. Because another person that I kind of had this conversation with mentioned that she writes talks based on experiences that have been very aggravating [chuckles] and painful for her. So, that ends up being, you know, a big motivator because she's so frustrated. [laughs] And, you know, wants to share this journey that she went on from a point of, I guess, maybe similar to me, like, making it easier for someone else who might find themselves struggling with the same problem. JOËL: I kind of like the idea of taking that to an extreme, and you're, like, rage submitting. STEPHANIE: Yeah, I feel like there would just be an infinite number [laughs] of topics that you could come up with in that case. JOËL: Like, I'm so angry at this bug. It cost me a week of my life. And now, it is going to get the spotlight on it at RubyConf. And I get to share that moment with everyone, express a lot of emotions, and, hopefully, save everyone else from having to do the same thing I did. STEPHANIE: Yeah. Or this terrible bug cost me a week of my life, and now you all get to hear about it. [laughter] Let me tell you -- JOËL: Yes. STEPHANIE: Exactly all the problems that I had to deal with. JOËL: And, honestly, as a narrative, it kind of works, right? There are different types of talks. Sometimes you go to a talk because you really want to learn a deep topic. Sometimes I just want to go and listen to, like, a good horror story. If someone's a good storyteller, like, yes, there are lessons I can take away from it, and I can be like, okay, this is what I can do. And I heard Stephanie talk about this bug, and so I'm going to use inspiration from that the next time I hit a bug. But sometimes it's also just…

    Full show notes at the publisher

    393: Is REST the Best? APIs and Domain Modeling Jul 18, 2023
    Show notes

    It's updates on the work front today! Stephanie was tasked with removing a six-year-old feature flag from a codebase. Joël's been doing a lot of small database migrations. A listener question sparked today's main discussion on gerunds' interesting relationship to data modeling. Episode 386: Value Objects Revisited: The Tally Edition RailsConf 2017: In Relentless Pursuit of REST by Derek Prior REST Turns Humans Into Database Clients Parse, don’t validate Wikipedia Getting to Philosophy Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, this week, I've been tasked with something that I've been finding very fun, which is removing a six-year-old feature flag from the codebase that is still very much in use in the sense that it is actually a mechanism for providing customers access to a feature that had been originally launched as a beta. And that was why the feature flag was introduced. But in the years since, you know, the business has shifted to a model where you have to pay for those features. And some customers are still hanging on to this beta feature flag that lets them get the features for free. So one of the ways that we're trying to convert those people to be paying for the feature is to, you know, gradually remove the feature flag and maybe, you know, give them a heads up that this is happening. I'm also getting to improve the codebase with this change as well because it has really been propagating [laughs] in there. There wasn't necessarily a single, I guess, entry point for determining whether customers should get access to this feature through the flag or not. So it ended up being repeated in a bunch of different places because the feature set has grown. And so, now we have to do this check for the flag in several places, like, different pages of the application. And it's been really interesting to see just how this kind of stuff can grow and mutate over several years. JOËL: So, if I understand correctly, there's kind of two overlapping conditions now around this feature. So you have access to it if you've either paid for the feature or if you were a beta tester. STEPHANIE: Yeah, exactly. And the interesting thought that I had about this was it actually sounds a lot like the strangler fig pattern, which we've talked about before, where we've now introduced the new source of data that we want to be using moving forward. But we still have this, you know, old limb or branch hanging on that hasn't quite been removed or pruned off [chuckles] yet. So that's what I'm doing now. And it's nice in the sense that I can trust that we are already sending the correct data that we want to be consuming, and it's just the cleanup part. So, in some ways, we had been in that half-step for several years, and they're now getting to the point where we can finally remove it. JOËL: I think in kind of true strangler fig pattern, you would probably move all of your users off of that feature flag so that the people that have it active are zero, at which point it is effectively dead code, and then you can remove it. STEPHANIE: Yeah, that's a great point. And we had considered doing that first, but the thing that we had kind of come away with was that removing all of those customers from that feature flag would probably require a script or, you know, updating the production data. And that seemed a bit riskier actually to us because it wasn't as reversible as a code change. JOËL: I think you bring up a really interesting point, which is that production data changes, in general, are just scarier than code changes. At least for me, it feels like it's fairly easy generally to revert a code change. Whereas if I've messed up the production database, [laughs] that's going to be unpleasant few days. STEPHANIE: What's interesting is that this feature flag is not really supported by a nice user interface for managing it. And so, we inevitably had to do a more developer-focused solution to remove these customers from being able to access this feature. And so, the two options, you know, that we had available were to do it through data, like I mentioned, or do it through that code change. And again, I think we evaluated both options. But what's kind of nice about doing it with the code change is that when we eventually get to delete those feature flag records, it will be really nice and easy. JOËL: That's really exciting. One thing that's different about kind of more mature projects is that we often get to do some kind of change management, unlike a greenfield app where you just get to, oh, let's introduce this new thing, cool. Oftentimes, on a more mature project, before you introduce the new thing, you have to figure out, like, what is the migration path towards that? Is that a kind of work that you enjoy? STEPHANIE: I think this was definitely an exercise in thinking about how to break this down into steps. So, yeah, that change management process you mentioned, I, like, did find a lot of satisfaction in trying to break it up, you know, especially because I was also thinking that you know, maybe I am not able to see the complete, like, cleanup and removal, and, like, where can someone pick up after me? In some ways, I feel like I was kind of stepping into that migration, you know, six years [laughs] in the making from beta to the paid product. But I think I will feel really satisfied if I'm able to see this thing through and get to celebrate the success of saying, hey, like, I removed...at this point, it's a few hundred lines of code. [laughs] And also, you know, with the added business value of encouraging more customers to pay for the product. But I think I also I'm maybe figuring out how to accept like, okay, like, how could I, like, step away from this in the middle and be able to feel good that I've left it in a place that someone else could see through? JOËL: So you mentioned you're taking this over from somebody else, and this has been kind of six years in the making. I'm curious, is the person who introduced this feature flag six years ago are they even still at the company? STEPHANIE: No, they are not, which I think is pretty typical, you know, it's, like, really common for someone who had all that context about how it came to be. In fact, I actually didn't even realize that the feature flag was the original beta version of the product because that's not what it's called. [laughs] And it was when I was first onboarding onto this project, and I was like, "Hey, like, what is this? Like, why is this still here?" Knowing that the canonical, you know, version that customers were using was the paid version. And the team was like, "Oh, yeah, like, that's this whole thing that we've been meaning to remove for a long time." So it's really interesting to see the lifecycle, like, as to some of this code a little bit. And sometimes, it can be really frustrating, but this has felt a little more like an archaeology dig a little bit. JOËL: That sounds like a really interesting project to be on. STEPHANIE: Yeah. What about you, Joël, what's new in your world? JOËL: So, on my project, I've been having to do a lot of small database migrations. So I've got a bunch of these little features to do that all involve doing database migrations. They're not building on each other. So I'm just doing them all, like, in different feature branches, and pushing them all up to GitHub to get reviewed, kind of working on them in parallel. And the problem that happens is that when you switch from one branch where you've run a migration to another and then run migrations again, some local database state persists between the branch switch, which means that when you run the migrations, then this app uses a structure.sql. And the structure.sql has a bunch of extra junk from other branches you've been on that you don't want as part of your diff. And beyond, like, two or three branches, this becomes an absolute mess. STEPHANIE: Oh, I have been there. [laughs] It's always really frustrating when I switch branches and then try to do my development and then realize that I have had my leftover database changes. And then having to go back and then always forgetting what order of operations to do to reverse the migration and then having to re-migrate. I know that pain very well. JOËL: Something I've been doing for this project is when I switch branches, making sure that my structure SQL is checked out to the latest version from the main branch. So I have a clean structure SQL then I drop my local database, recreate an empty one, and run a rake db:schema:load. And that will load that structure file as it is on the main branch into the database schema. That does not have any of the migrations on this branch run, so, at that point, I can run a rake db:migrate. And I will get exactly what's on main plus what gets generated on this branch and nothing else. And so, that's been a way that I've been able to kind of switch between branches and run database operations without getting any cross-contamination. STEPHANIE: Cross-contamination. I like that term. Have you automated this at all, or are you doing this manually? JOËL: Entirely manually. I could probably script some of this. Right now...so it's three steps, right? Drop, create, schema load. I just have them in one command because you can chain Unix commands with a double ampersand. So that's what I'm doing right now. I want to say there's a db:reset task, but I think that it uses migrate rather than schema load. And I don't want to actually run migrations. STEPHANIE: Yeah, that would take longer. That's funny. I do love the up arrow key [laughs] in your terminal for, you know, going back to the thing you're running over and over again. I also appreciate the couple extra seconds that you're spending in waiting for your database to recreate. Like, you're paying that cost upfront rather than down the line when you are in the middle of doing [laughs] what you're trying to do and realize, oh no, my database is not in the state that I want it to be for this branch. JOËL: Or I'm dealing with some awful git conflict when trying to merge some of these branches. Or, you know, somebody comments on my PR and says, "Why are you touching the orders table? This change has nothing to do with orders." I'm like, "Oh, sorry, that actually came out of a different thing that I did." So, yep, keeping those diffs small. STEPHANIE: Nice. Well, I'm glad that you found a way to manage it. JOËL: So you mentioned the up arrow key and how that's really nice in the terminal. Something that I've been relying on a lot recently is reverse history search, CTRL+R in the terminal. That allows me to, instead of, like, going one by one in order of the history, filter for something that matches the thing that I've written. So, in this case, I'll hit CTRL+R, type, you know, Rails DB or whatever, then immediately it shows me, oh, did you want this long command? Hit enter, and I'm done. Even if I've done, you know, 20 git commands between then and the last time I ran it. STEPHANIE: Yeah, that's a great tip. So, a few weeks ago, we received a listener question from John, and he was responding to an episode where I'd asked about what the grammatical term is for verbs that are also nouns. He told us about the phrase, a verbal noun, for which there's a specific term called gerund, which is basically, in English, the words ending in ING. So, the gerund version of bike would be biking. And he pointed out a really interesting relationship that gerunds have to data modeling, where you can use a gerund to model something that you might describe as a verb, especially as a user interaction, but can be turned into a noun to form a resource that you might want to introduce CRUD operations for in your application. So one example that he was telling us about is the idea of maybe confirming a reservation. And, you know, we think of that as an action, but there is also a noun form of that, which is a confirmation. And so, confirmation could be a new resource, right? It could even be backed at the database level. And now you have a simpler way of representing the idea of confirming a reservation that is more about the confirmation as the resource itself rather than some kind of append them to a reservation itself. JOËL: That's really cool. We get to have a crossover between grammar terms and programming, and being able to connect those two is always a fun day for me. STEPHANIE: Yeah, I actually find it quite difficult, I think, to come up with noun forms of verbs on my own. Like, I just don't really think about resources that way. I'm so used to thinking about them in a more tangible way, I suppose. And it's really kind of cool that, you know, in the English language, we have turned these abstract ideas, these actions into, like, an object form. JOËL: And this is particularly useful when we're trying to design RESTful either APIs or even just resources for a Rails app that's server-rendered so that instead of trying to create all these, like, extra actions on our controller that are verbs, we might decide to instead create new resources in the system, new nouns that people can do the standard 7 to. STEPHANIE: Yes. I like that better than introducing custom controller actions or routes that deviate from RESTful conventions because, you know, I probably have seen a slash confirm reservation [laughs] URL. And, you know, this is, I think, an interesting way of avoiding having too many of those deviating endpoints. JOËL: Yeah, I found that while Rails does have support for those, just all the built-in things play much more nicely if you're restricting yourself to the classic seven. And I think, in general, it's easier to model and think about things in a Rails app when you have a lot of noun resources rather than one giant controller with a bunch of kind of verb actions that you can do to it. In the more formal jargon, I think we might refer to that as RESTful style versus RPC style, a Remote Procedure Call. STEPHANIE: Could you tell me more about Remote Procedure Calls and what that means? JOËL: The general idea is that it's almost like doing a method call on an object somewhere. And so, you would say, hey, I've got an account, and I want to call the confirm method on it because I know that maybe underlying this is an ActiveRecord account model. And the API or the web UI is just a really thin layer over those objects. And so, more or less, whatever your methods on your object are, can be accessed through the API. So the two kind of mirror each other. STEPHANIE: Got it. That's interesting because I can see how someone might want to do that, especially if, you know, the account is the domain object they're using at the, you know, persistence layer, and maybe they're not quite able to see an abstraction for something else. And so, they kind of want to try to fit that into their API design. JOËL: So I have a perhaps controversial opinion, which is that the resources in your Rails application, so your controllers, shouldn't map one-to-one with your database tables, your models. STEPHANIE: So, are you saying that you are more likely to have more abstractions or various re…

    Full show notes at the publisher

    392: Managing Changing Business Requirements Jul 11, 2023
    Show notes

    Joël has a fascinating discovery! He learned a new nuance around working with dependency graphs. Stephanie just finished playing a 100-hour video game on Nintendo Switch: a Japanese role-playing game called Octopath Traveler II. On the work front, she is struggling with a lot of churn in acceptance criteria and ideas about how features should work. How do these get documented? What happens when they change? What happens when people lose this context over time? Strangler Fig Pattern Octopath Traveler 2 Empowering other departments Transcript: JOËL: You're the one who controls the pacing here. STEPHANIE: Oh, I am. Okay, great. 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: So long-time Bike Shed listeners will know that I'm a huge fan of dependency graphs for modeling all sorts of problems and particularly when trying to figure out how to work in an iterative fashion where you can do a bunch of small chunks of work that are independent, that can be shipped one at a time without having your software be in a breaking state in all of these intermediate steps. And I recently made a really exciting discovery, or I learned a new nuance around working with dependency graphs. So the idea is that if you have a series of entities that have dependencies on each other, so maybe you're trying to build, let's say, some kind of object model or maybe a series of database tables that will reference each other, that kind of thing, if you draw a dependency graph where each bubble on your graph points to other bubbles that it depends on, that means that it can't be created without those other things already existing. Then, in order to create all of those entities for the first time, let's say they're database tables, you need to work your way from kind of the outside in. You start with any bubbles on your graph that have no arrows going out from them. That means they have no dependencies. They can be safely built on their own, and then you kind of work your way backwards up the arrows. And that's how I've sort of thought about working with dependency graphs for a long time. Recently, I've been doing some work that involves deleting entities in such a graph. So, again, let's say we're talking about database tables. What I came to realize is that deleting works in the opposite order. So, if you have a table that have other tables that depend on it, but it doesn't depend on anything, that's the first one you want to create. But it's also the last one you want to delete. So, when you're deleting, you want to start with the table that maybe has dependencies on other tables, but no other tables depend on it. It is going to be kind of like the root node of your dependency graph. So I guess the short guideline here is when you're creating, work from the bottom up or work from the leaves inward, and when you're deleting, work from the top-down or work from the root outward or roots because a graph can have multiple roots; it's not a tree. STEPHANIE: That is interesting. I'm wondering, did you have a mental model for managing deleting of dependencies prior? JOËL: No. I've always worked with creating new things. And I went into this task thinking that deleting would be just like creating and then was like, wait a minute, that doesn't work. And then, you know, a few cycles later, realized, oh, wait, deleting is the opposite of creating when you're navigating the graph. And, all of a sudden, I feel like I've got a much clearer mental model or just another way of thinking about how to work with something like this. STEPHANIE: Cool. That actually got me thinking about a case where you might have a circular dependency. Is that something you've considered yet? JOËL: Yes. So, when you have a dependency graph, and you've got a circular dependency, that's a big problem because...so, in the creating model, there is no leaf node, if you will, because they both reference each other. So that means that each of these entities cannot be created on its own, the entire cycle. And maybe you've got only two, but maybe your cycle is, you know, ten entities big. The entire cycle is going to be shipped as one massive change. So something that I often try to do is if I draw a dependency graph out and notice, wait a minute, I do have cyclical dependencies, the question then becomes, can I break that cycle to allow myself to work iteratively? Because otherwise, I know that there's a big chunk that can't be done iteratively. It just has to be done all at once. STEPHANIE: Yeah, that's really interesting because I've certainly been in that situation where I don't realize until it's too late, where I've started going down the path thinking that, you know, I could just remove this one thing, or make this one change, and then find myself suddenly, you know, coming to the realization, oh, this other thing is now going to have to change. And then, at that point, there's almost kind of like the sunken cost fallacy [laughs] a little bit where you're like, well, I'm already in it. So, why don't I keep going? But your strategy of trying to find a way to break that cyclica...that is two words combined. [laughs] I meant to say circular dependency [laughs] is the right way to avoid just having to do it all in one go. Have you had to break up a cycle like that before? JOËL: Yes. I do it on a semi-frequent basis. The fancy term here for what I'm looking for when I'm building out a dependency graph is a directed acyclic graph. That's a graph theory or a computer science term that you'll hear thrown around a lot, DAG. I often like to...when building out a series of tasks that might also form a graph because you don't just model entities in your system; you might model a series of tasks as a graph. If there's a cycle in the graph, typically, I can break that using something like the strangler fig pattern, which is a way to kind of have some intermediate steps that are non-breaking that then lead you to the refactor that you want. And I've used the strangler fig pattern for a long time, never realizing until later that, oh, what I'm actually doing is breaking cycles in my task dependency graph. STEPHANIE: Hmm. I'm curious if you have noticed how these cycles come to be because I almost imagine that they get introduced over time, where you maybe did start with a parent and then you, you know, had dependencies. But then, over time, somehow, that circular dependency gets introduced. And I'm wondering if part of figuring out how to break that cycle is determining how things were introduced, like, over time. JOËL: In my experience, this happens in a lot of different ways because I'm using dependency graphs like this to give myself a mental model for a lot of different kinds of things. So maybe I'm thinking in terms of database tables. And so those might get a circular dependency that gets added over time as the system grows. But I'm also using it sometimes to model maybe a series of tasks. So I take a large task, and I break it down into subtasks that are all connected to each other. And that doesn't tend to sort of evolve over time in the same way that a series of database tables do. So I think it's very context-dependent. But there are definitely situations where it will be like you said, something that kind of evolves over time. STEPHANIE: That makes sense. Well, I'm excited for you to get to deleting some potential code or database tables that are no longer in use. That sounds like a developer's dream [laughs] to clean up all that stuff. JOËL: It's interesting because it's...a move operation is effectively what's happening. So I'm recreating tables in another system, pointing the ActiveRecord to this new system, and then deleting the existing ones in the local database. So, in a sense, I'm kind of traveling up this dependency graph from the leaf nodes into the root and then back down from the root to the leaves as I'm creating and then deleting everything or creating in one system, and then going back and deleting in the other system. STEPHANIE: Got it. Okay, so not necessarily a net negative but, like you said, a move or just having to gradually replace to use a new system. JOËL: That's right. And we're trying not to do this as, you know, okay, we're going to take the system down and move 50 tables from one system to another. But instead, saying, like, you know, one at a time, we're going to move these things over. And it's going to be small, incremental change over the course of a couple of weeks. And they're all pretty safe to deploy, and we feel good about them. STEPHANIE: That's good. I'm glad you feel good. [laughs] We should all be able to feel good when we make changes like that. JOËL: It's going to make my Fridays just so much more low-key just, like, yeah, hit that deploy button. It's okay. So, Stephanie, what is new in your world? STEPHANIE: So this is not work-related at all. But I just finished playing a 100-hour video game on my Nintendo Switch. [laughs] I finished a Japanese role-playing game called Octopath Traveler II. And I have never really played a game like this before. I've not, you know, put in many, many hours into something that then had an end, like, a completion. So, at the end of this very long game that had a very, you know, compelling and engaging story and I was invested in all of these characters, and by the time the credits were rolling, I felt a little sad to be leaving this world that I have been in many evenings over the last couple of months. Yeah, I don't know, I'm feeling both a little sad because, you know like I said, I got really invested in this game, but now I'm also kind of glad to have some free time back in [laughs] my life because that has definitely been the primary, like, evening activity that I've been doing to relax. JOËL: It sounds like this game had a very, like, a particularly immersive world that really pulled you in. STEPHANIE: It did. It did. It has these eight, like, different characters that you follow, like, different chapters and all of their stories, and then they all kind of come together as well. And the world was huge in this game. There were so many little towns to explore. And I didn't realize I was a completionist type. But I found myself running around opening every chest, talking to every NPC, and making sure that I, you know, collected all of my items [chuckles] before moving on. I also finished all of the side quests, which is, I think, you know, how I managed to put in over 100 hours into it. But yeah, it was very immersive, and I really enjoyed it. I don't know if this will become a norm for me. I know there are some people who are, you know, JRPG diehards and play a lot of these kinds of games, but they're a real, like, time investment for sure. JOËL: Are there achievements for completing everything? STEPHANIE: Not that I can tell on the Switch. I do know that, like, on other systems, you can see your progress on having done all of the things there are to do. But I think it's actually kind of better for me to just play [laughs] to just, like, think that I've done it all but not really, like, have something that tells me whether or not I've done it because then I would feel a lot more neurotic, I think, about being able to let it go where I am now. [laughs] JOËL: Right. If we've got, like, an explicit checklist of things or a progress bar, then it feels like you got to get to all the things. STEPHANIE: Yeah, exactly. I think there are still, you know, a couple more things that I wrote down on my little checklist of tasks that I would want to do once I feel like I want to come back to the game. But for now, like I said, I watched the credits roll. I teared up a little bit, you know, thinking about and reminiscing on my adventure with these characters, and I'm ready to put it down for a bit. JOËL: Did I hear correctly that you made a checklist for this game of things you wanted to do? STEPHANIE: Yes, [laughs] I did. JOËL: That's amazing. I love that. STEPHANIE: Yeah, you know, there are just so many things almost kind of like work where I had to, like, break down some of my goals. I wanted to, like, hit a certain level. I wanted to, you know, make sure I defeat these bosses that would help me get to those levels. And yeah, I got very into it. It was definitely a big part of my life for a couple of months. I got it originally because I needed a game to play on my flight to Asia back when I went to Japan. And I'm like, oh, like, this looks, you know, fun and engaging, and it will distract me for my, you know, over 10-hour flight. Turns out it distracted me for many, many more hours over several months [laughs] since then. But I had a great time. So yeah, that's what's new for me. Again, it's something I'd never really done before. I will say though I am very behind on my reading goal as a result. [chuckles] JOËL: I feel like this is a classic developer thing to do is, like, use the tools that we're used to in our job and then apply them to other parts of our life. And now it's just like, okay, well, I made a Kanban board to track my progress in this video game. You know, or, in my case, I'm definitely guilty of having drawn a dependency graph for the crafting tree for some video game. So I feel you really strongly there. STEPHANIE: Yes, I'm nodding heavily in agreement. I think it just scratches the same kind of itch of, you know, achieving, like, little things and then achieving one big thing. JOËL: So, speaking of places that are nice to have checklists and, like, well-defined requirements, you and I were talking earlier, and you have recently found some frustration around having user stories be defined well on your current project. STEPHANIE: Yes. So I've been reflecting a little bit about my current project and noticing what I think I might call product smells; I'm not quite sure, just some things I'm seeing in our day-to-day workflow that is getting me thinking. And I'm curious to hear if you've experienced something similar. But I find myself being tasked with a ticket that is quite vague. And maybe this was written by a product owner, or maybe it was written by another developer. And it is not quite actionable yet, so I have to go through the process of figuring out what I'm really needing to do here. I think another thing that has been quite frustrating is, you know, maybe we do find out what we want to do. And, like, I'll go back into the ticket, write down the requirements that I gathered, and do the ticket. I'll ship whatever change was required, and then I'll hear back from someone in a meeting or either as a one-off request in Slack. And it'll be like, "Hey, like, actually, you know, we want this to be different." And maybe you previously said that "Oh, the value for something would be 30. But now we found out more information; it should be 20. And so could you, like, make that change?" And then I'm not really sure what the best way to document a change like that is because it, you know, maybe existed in the previous ticket, but now it has changed. And do I create a new ticket for this, or do I just go ahead and make the code change? Like, who would know th…

    Full show notes at the publisher

    391: Learn with APPL Jul 05, 2023
    Show notes

    Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it. Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out: Adventure (try something new)Passion (topic)Profit (from recent learnings)Low-risk (applicable today) = APPL Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work. Elm Practical Object-Oriented Design in Ruby Design Patterns in Ruby Quarter Life Working Iteratively Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: All right, I have a new-new thing and an old-new thing to share with you today. So the new-new thing is that I went to my first WNBA game [laughs] last week, which is also my third professional sports game ever, probably. I am not a sports person. But a rather new friend of mine invited me to go with her because they are fans, and so I was like, yeah, sure. I'll try anything once. And I went, and I had a great time. It was very exciting. I mean, I know the basic rules of basketball, right? Get the ball in the hoop. But I was very surprised to see how fast-paced it was. And, you know, I was like, wow, like, this is so much fun. There's so much going on, like, the music, you know, the crowd. It was very energizing. And then my friend actually told me that that was a pretty slow game, [chuckles] relative to how they normally go. And I was like, oh, wow, like, if that was slow, then I can't wait for a real competitive [laughs] game next time. So that's my new-new thing. I had a good time. Will do it again. I'm just, like, a 15-minute bike ride from the stadium for our team in Chicago. It's called The Sky. That's our WNBA team. So yeah, I'm looking forward to being basketball Stephanie, I guess. [chuckles] JOËL: That's really cool. How does the speed compare to other sports you've gone to see? STEPHANIE: I think this is why I was interested because I've really only seen baseball, for which I know very little. And that, I think, is, like, a much slower-paced kind of sport. Yeah, I have some memories of going to, like, college football games, which also, like, quite slow. I just remember standing around for a while. [laughs] So I think basketball might be the thing for me, at least in terms of engaging my interest. JOËL: You want something that actually engages you with the sport the whole time. It's not just a social event themed around occasionally watching someone do something. STEPHANIE: Yes, exactly. I also enjoyed the half-time performances, you know, there was just, like, a local dance team. And I thought that was all just very fun. And, yes, I had a lot to, you know, just, like, point to and ask questions about because there was just so much going on, as opposed to sitting and waiting, at least that was my experience [laughs] at other kinds of sports games. As for the old-new thing, now that it's summer, there is a local bar near me that does bingo every week. But it's not just normal bingo. It's called veggie bingo, which I realize is kind of confusing [chuckles] if you just, like, call it veggie bingo, but it's bingo where you win vegetables or, like, produce from local community gardens and other, you know, small batch food items. And I had a great time doing it last year. I met some new friends. It just became our weekly hangout. And so I'm looking forward to doing that again. And, I don't know, I'm just glad I have fun things to share about what's new in my world now that the weather is warm and I'm doing stuff again. I feel like there was one point in the winter where I was coming [chuckles] onto the show and sharing how I had just gotten a heated blanket in the middle of winter, and that was the most exciting thing going on for me. So it feels good to be able to bring up some new stuff. JOËL: Seasonality is a thing, right? And, you know, there are rhythms in life. And sometimes things are more fast-paced, sometimes they're a bit slower. That's really exciting. Did you take any produce home, or did you win anything when you went to play? STEPHANIE: I did. I won a big bag of produce the last time that I went. At this point, it was last season. But it was right before I was about to go on vacation. So I ended up -- JOËL: Oh no. STEPHANIE: [chuckles] Right. I ended up not being able to, you know, keep it in the fridge and just giving it away to my friends who did not win. So I think it was a good situation overall. That's my tip, is go to bingo or any kind of prize-winning hang out as a group, and then you can share the rewards. It's very exciting. Even if you don't win, you know, like, probably someone else at your table will win, and that is equally fun. JOËL: I think the closest I've been to that experience is going to play, like, bar trivia with some friends and then winning a gift card that covers our dinner and drinks for the evening. STEPHANIE: Yeah, yeah, that's great. I used to go to a local trivia around me too. The best part about bingo, though, is that it requires no skill at all. [laughs] I, yeah, didn't realize, again, how into these kinds of things I would be until I just tried it out. Like, that was...bingo is another thing I don't think I would have internally decided to go do. But yeah, my friends just have all these great ideas about fun things to do, and I will happily join them. So, Joël, what's new in your world? JOËL: So I've recently started a new client project. And one of the really interesting things that I've been doing on this project is trying to bring in multiple databases to back our ActiveRecord models. This is a Rails app. I've never done multi-database setups in Rails before. It's been a feature since Rails 6, but this is my first time interacting with that system. And, you know, it's actually pretty nice. STEPHANIE: Really? It ended up being pretty straightforward or pretty easy to set up? JOËL: Yeah. There's a little bit of futzing around you have to do with the database YAML configuration file. And then what you end up doing is setting up another base class for your ActiveRecord models to inherit from. So, typically, you have that application record that you would inherit from for your primary database. But for other databases, if you want a model to be backed by a table from that system, then you would have a separate base class that all of those models inherit from, and that's pretty much it. Everything else just works. A bunch of your Rake tasks get a little bit different. So you've got to, like, configure your setup scripts and your test scripts and all that thing a little bit differently. But yeah, you can just query, do all the normal things you do with an ActiveRecord model, but it's reading from a different database. STEPHANIE: That's really cool that it ended up being pretty painless. And I'm thinking, for the most part, as a developer, you know, working in that kind of codebase; maybe they don't really need to know too much about the details of the other databases. And they can just rely on the typical Rails conventions and things they know how to do via Rails. Do you suspect that there might be some future where that might become a gotcha or something that someone has to debug a little further because of the multi-database setup? JOËL: There are some infrastructure things, but I think I'm handling all of them upfront. So like I said, configuring various setup scripts, or test scripts, or CI, that kind of thing to make sure that they all work. Once that's all done, I think it should pretty much just work. And people can use them like they would normal ActiveRecord models. The one gotcha is that you can't join models across two different databases. You can't use ActiveRecord to write a query that would try to join two tables that are in different databases because the SQL won't allow for that. So, if you're ever trying to do something like that or you have some kind of association where you're trying to do some special join, that would not work. So, if somebody attempts that, they might get an unexpected error. Other than that, I think it just keeps working as normal, and people can treat it more or less as if it's one database. STEPHANIE: That's interesting. How do you model relationships between tables on the two different databases, then? Like, how would that work? JOËL: I've not gotten that far yet. For some things, I imagine just it's two queries. I'm not sure if the ActiveRecord associations handle that automatically for you. I think they probably will. So you probably can get away with an association where one model lives in one database. Let's say your article lives in one database, and it has many comments that live in a different database. Because then you would make one query to load the article, get the article ID, and then you would do another query to the second database and say, hey, find all the comments with this article ID, which is already, I think, what ActiveRecord does in one single database. It is making two queries. It's just that now those two queries are going to be two different databases rather than to a single one. STEPHANIE: Interesting. Okay. I did think that maybe ActiveRecord did some fancy join thing under the hood. And when you mentioned that that wouldn't be possible when the two tables are on different databases, I was kind of curious about how that would work. But that makes sense. That would be really cool if it is, you know, that straightforward. And, hopefully, it just doesn't become too big of an issue that comes back to haunt someone later. JOËL: Right. So pretty much, if there is a situation where you were relying on a JOIN, you will now have to make two separate queries and then combine the results yourself. STEPHANIE: Right. I also want to give you kudos for doing all the good work of setting it up so that, hopefully, future developers don't have to think about it. JOËL: Kudos to the Rails team as well. It's nice to have that just kind of built into the framework. Again, it's not something I've needed in, you know, a decade of doing Rails, but then, you know, now that I have run into a situation where I need that, it just works out of the box. So that's been really nice. So, a couple of weeks ago, we talked about the fact that we were going through review season and that we had to fill out reviews for ourselves then also fill out peer reviews for each other. You had brought up a really interesting conversation you had about reaching out to other people and trying to get feedback on what kind of review or feedback would be helpful for them. STEPHANIE: I did, yeah. Though, I think in this case, the person writing that feedback actually reached out to me, but certainly, it goes both ways. Spoiler alert - that person was Steph Viccari, former [laughs] host of The Bike Shed. JOËL: So Steph also reached out to me with similar questions. And that spawned a really interesting conversation around personal goals and what it looks like, particularly when it comes to what to learn next in technology. We started discussing things, and I listed out some different things that I was interested in. And then just kind of out of nowhere, Steph just pulls out this, like, oh, I noticed these four elements. And I'm going to list them out here because it's really cool. So these four elements were adventure, so trying something new. Passion, so something that's really exciting to you. Profit something where you can leverage some recent things that you've done to get more value out of some work you've already done. And then finally, low risk, something that would be applicable today. And it just kind of turns out that this makes a funny little acronym: APPL. And apples are often a symbol of learning. So that was kind of a fun coincidence. STEPHANIE: I love when someone is able to just pull apart or to tease out pieces of, you know, something that you might have just, like, kind of dumped all of into a message or something, and then to get, like, a second eye to really pick out the themes is so valuable, I think. And I'm obsessed with this framework. I think we might have come across something new that could really be helpful for a lot of other people. JOËL: It's definitely...I think it shows capacity for a higher level of thinking when someone's able to just look at a bunch of concrete things and say, wait a minute; I'm seeing some larger themes emerge from what you're talking about. And I always really appreciate it when I'm having a conversation with someone, and they're like, "Hey, I think what I'm hearing is this." And you're like, "Whoa, you're totally right. And I did not even know that that's where I was going." STEPHANIE: Absolutely. I'd love to go through this acronym and talk about a few different things that we've learned in our careers that kind of correspond with each of these elements. JOËL: Yeah, that sounds great. So I think, you know, the first one here is adventure, trying something new. So, what's something where you tried something new or adventurous that you think was worthwhile? STEPHANIE: Hosting this podcast. [laughs] It was a huge adventure for me and a really big stretch, I think. And that's what the idea of adventure evokes for me is, like, maybe it's uncharted territory for you, and you might have some reservations about it. But, you know, obviously, the flip side of an adventure is how fun and exciting and just new and stimulating it can be. And so I think, yeah, like, when I first started doing this with you, and even when you first asked me, I was pretty nervous. I was really hesitant. It took me a long time to, you know, think it over. I was like, do I want to commit to something that I have never done before, and it's, like, a pretty longer-term commitment? And I'm really glad I did it. It's certainly been an adventure. It's, you know, got its ups and downs. You know, not every week do I feel like that went really well, like, that was a great episode. Sometimes I'm like, that was just an okay episode, [laughs] and, you know, that's fine too. But I feel like this was really important in helping me feel more confident in sharing my technical opinions, helping me feel more comfortable just kind of, like, sharing where I am and not feeling like I should be somewhere else, like, some other level or have already known something. Like, the point is for us to share the journey week by week, and that was something that was really hard for me. So being on this Bike Shed adventure with you has been very valuable for me. JOËL: Yeah, it's sharing these new things we've learned along the way. STEPHANIE: Literally. Yes. What about you? Do you have something adventurous that you learned? JOËL: I think an important inflection point where I tried something new was when I learned the Elm programming…

    Full show notes at the publisher

    390: The Truth about Truthiness Jun 27, 2023
    Show notes

    Joël's new work project involves tricky date formats. Stephanie has been working with former Bike Shed host Steph Viccari and loved her peer review feedback. The concept of truthiness is tough to grasp sometimes, and JavaScript and Ruby differ in their implementation of truthiness. Is this a problem? Do you prefer one model over the other? What can we learn about these design decisions? How can we avoid common pitfalls? [EDI](https://www.stedi.com/blog/date-and-time-in-edi](https:/www.stedi.com/blog/date-and-time-in-edi) [Booleans don’t exist in Ruby](https://thoughtbot.com/blog/what-is-a-boolean](https://thoughtbot.com/blog/what-is-a-boolean) [Rails valid? method](https://api.rubyonrails.org/classes/ActiveRecord/Validations.html#method-i-valid-3F](https://api.rubyonrails.org/classes/ActiveRecord/Validations.html#method-i-valid-3F) Parse, don’t validate Javascript falsiness rules Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a little bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: So I'm on a new project at work. And I'm doing some really interesting work where I'm connecting to a remote database third-party system directly and pulling data from that database into our system, so not via some kind of API. And one thing that's been really kind of tricky to work with are the date formats on this third-party database. STEPHANIE: Is the date being stored in an unexpected format or something like that? JOËL: Yes. So there's a few things that are weird with it. So this is a value that represents a point in time, and it's not stored as a date-time value. Instead, it's stored separately as a date column and a time column. So a little bit of weirdness there. We can work with it, except that the time column isn't actually a time value. It is an integer. STEPHANIE: Oh no. JOËL: Yeah. And if you're thinking, oh, okay, an integer, it's going to be milliseconds since midnight or something like that, which is basically how Postgres' time of day works under the hood, nope, that's not how it works. It's a positional digit thing. So, if you've got the number, you know, 1040, that means 10:40 a.m. STEPHANIE: Oh my gosh. Is this in military time or something like that, at least? JOËL: Yes, it is military time. But it does allow for all these, like, weird invalid values to creep in. Because, in theory, you should never go beyond 2359. But even within the hours that are allowed, let's say, between 1000 and 1100, so between 10:00 and 11:00 a.m., a clock only goes up to 59 minutes. But our base 10 number system goes up to 99, so it's possible to have 1099, which is just an invalid time. STEPHANIE: Right. And I imagine this isn't validated or anything like that. So it is possible to store some impossible time value in this database. JOËL: I don't know for sure if the data is validated or not, but I'm not going to trust that it is. So I have to validate it on my end. STEPHANIE: That's fair. One thing that is striking me is what time is zero? JOËL: So zero in military time or just 24-hour clocks in general is midnight. So 0000, 4 zeros, is midnight. What gets interesting, though, is that because it's an integer, if you put the number, you know, 0001 into the database, it's just going to store it as 1. So I can't even say, oh, the first two digits are the hours, and the second two digits are the minutes. And I'm actually dealing with, I think, seconds and then some fractional part of seconds afterwards. But I can't say that because the number of digits I have is going to be inconsistent. So, first, I need to zero pad. Well, I have to, like, turn it into a string, zero pad the numbers so it's eight characters long. And then, start slicing out pairs of numbers, converting them back into integers, validating them within a range of either 0 to 23 or 0 to 59, and then reconstructing a time object out of that. STEPHANIE: That sounds quite painful. JOËL: It's a journey for sure. STEPHANIE: Do you have any idea why this is the case or why it was created like this originally? JOËL: I'm not sure. I have a couple of theories. I've seen this kind of thing happen before. And I think it's a common way for developers who maybe haven't put a lot of thought into how time works to just sort of think, oh, the human representation. I need something to go in the database. On my digital clock, I have four digits, so why not put four digits in the database? Simple enough. And then don't always realize that there's all these edge cases to think about and that human representations aren't always the best way to store data. STEPHANIE: I like how you just said that that, you know, we as humans have developed systems that are not quite, you know, the same as how a computer would. But what was interesting to me...something you said earlier about time being a fixed point. And that is different from time being a value, right? And so here in this situation, it sounds like we're storing time as a value, but really, it's more of the idea of, like, a point. JOËL: Interesting. What is the difference for you between a point and a value? STEPHANIE: I suppose a value to me...And I think we talked about this a little bit on a previous episode about value objects and also how we stored numbers, like phone numbers and credit card numbers and stuff like that. But a value, like, I might want to do math on. But I don't really want to do math on time. Or, specifically, if I have this idea of a specific point in time, like, that is fixed and not something that I could mutate and expect it to be the same thing that I was trying to express the first time around. JOËL: Oh, that's interesting because I think when it comes to time and specifically points in time, I sometimes do want to do math on them. And so, specifically, I might want to say, what is the time that has elapsed between two points in time? Maybe I have a start time and an end time, and I want to say how much distance is there between the two? If you use this time system where you're storing it as an integer number where the digits have positional values, because there's all those gaps between, you know, 59 and 99 that are not valid, math breaks down. You've broken math by storing it that way. So you can't get an accurate difference by doing math on that, as opposed to if you store it as a counter, which is what databases do under the hood, but you could do manually. If you just wanted to use an integer column, then you can do math because it's just a number of seconds since the beginning of the day. And you can subtract those from each other. And now you have these number of seconds between the two of them. And if you want them in minutes or hours, you divide by six here, 3600, and you get the correct response. STEPHANIE: Yeah, that is really interesting because [chuckles] in this situation, you have the worst of both worlds, it seems like. [laughs] JOËL: The one potential benefit is, I think, it's maybe more human-readable. Although, at that point, I would say if you're not doing math on it and you want something human-readable, you probably don't want an integer. You probably want a string. And maybe you even store it as, like, ISO 8601 time string in the database, or even just hour:minute:second split by a colon or whatever it is but just as a string. Now it's human-readable. You can still sort by it if you go from largest to smallest increment in your format. You can't do math, but then you weren't doing math on it anyway. So that's probably a nice compromise solution. But, ideally, you'd use a native, you know, time of day column or a date-time or something like that. STEPHANIE: For sure. Well, it sounds like something fun to contend with. [laughs] JOËL: One thing that was brought to my attention that I'd never heard about before is that potentially a reason it's stored that way is because of an old data format called EDI—I think it's Electronic Data Interchange—that dates from ages ago, you know, the '60s or '70s, something like that. Before, we had a lot of standards for data; this is how...an emerging standard that came for moving data between systems. And it has a lot of, like, weird things with the way it's set up. But if you're dealing with any sort of older data warehouses or older business systems, they will often exchange. And sometimes, you're going to store data in something that approximates this older EDI format. And, apparently, it has some weirdness around dates where it kind of does something like this. So someone was suggesting, oh, well, if you're interacting with maybe an older, you know, a lot of, like, e-commerce platforms or banking systems, probably airline systems, the kind of things you'd expect to be written in, let's say, COBOL... STEPHANIE: [laughs] JOËL: Have a system that's kind of like this. So maybe that wouldn't be quite as surprising. STEPHANIE: Yeah, that is really interesting. It just sounds like sometimes you're limited by the technology that you're interacting with. And I guess the one plus side is that, in your system, you can make the EDI work for you, hopefully. [laughs] Whereas perhaps if you are talking to some of those older technologies that don't know how else to convert date types and things like that, like, you just kind of have to work with what's available to you. JOËL: Yeah. And that's got me realizing that a lot of these older, archaic systems are still online and very much a part of our software ecosystem and that there's a lot of value in learning some software history so that I'm able to recognize them and sort of work constructively with them when I have to interact with that kind of system. STEPHANIE: Yeah, I really like that mindset. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, last week, we talked about writing reviews for ourselves and our peers. And one thing that happened in between the last episode and this one is Steph Viccari, former co-host of this podcast, who I've been working with really closely on this project of mine; she was writing a peer review for me. And one thing that she did that I really loved was she sent me a message and asked me a few questions about the direction of the review that I was wanting and what kind of feedback would be helpful for me. And some of the things she asked were, you know, "Is there a skill that you're actively working on? Is there a skill you'd like to start working on?" And, like, what my goals are for the feedback. Like, how can she tailor this feedback to things that would help my progression and what I hope to achieve? And then my favorite question that she asked was, "What else should I know but didn't think to ask?" And I thought that was a really cool way of approaching. You know, she's coming to this, like, wanting to be helpful, but then even still, like, there are things that she knows that I am kind of the expert on in my own career progression, and I really liked that. I think I'd mentioned last week that part of the feedback you want to be giving is, you know, something that will be helpful for that person, and centering them in it, instead of you is just a really awesome way to do that. So I was very appreciative that she asked me those questions. JOËL: That's incredibly thoughtful. I really appreciate that she sent that out to you. What did you respond for the is there something else I should know but didn't know to ask? STEPHANIE: Yeah. I mentioned that more and more, I'm realizing that I am not interested in management. And so what would be really helpful for me was to ground most of the feedback in terms of my, like, technical contributions. And also, that one thing that I'm thinking about a lot is how to be an individual contributor and still have an impact on team health and culture because that is something I care about. And so I wanted to share that with her because if there are things that she can identify in those aspects, that would be really awesome for me. And that can kind of help guide her away from a path that I'm not interested in. JOËL: I think having that kind of self-awareness is really powerful for yourself. But then, when you can leverage that to get better reviews that will help you get even further down the path that you're hoping to go, and, wow, isn't that just, like, a virtuous cycle right there that's just building on itself? STEPHANIE: Yeah, for sure. I think the other thing I wanted to share about what's new in my world that has been just a real boost to my mood is how long the days are right now because it's summer in North America. And yesterday was the summer solstice, and so we had the longest day of the year. The sun didn't set until 8:30 p.m. And I just took the opportunity to be outside. I took a swim in the lake, which was my first swim of the season, which was really special. And my friend had just a nice, little, like, backyard campfire hang out. And we got to roast some marshmallows and just be outside till the sunset. And that was really nice. JOËL: When you say the lake, is that Lake Michigan? STEPHANIE: Yes, I do mean Lake Michigan. [laughs] I forget that some people just don't have a giant lake next to them [laughs] that they refer to as the lake. JOËL: It's practically an inland sea. STEPHANIE: Yes, you can't see the other side of it. So, to me, it kind of feels like an ocean. And yesterday, when I was in the water, I also was thinking that I felt like I was just in a giant bathtub. [chuckles] JOËL: So I'm in New England, and most of the bodies of water here are not called lakes. They're called ponds. STEPHANIE: Really? JOËL: No matter the size. STEPHANIE: Oh. JOËL: I guess lakes is reserved for things like what you have that are absolutely massive, and everything else is a pond. STEPHANIE: That's so funny because I think of ponds as much smaller in scale, like a quaint, little pond. But that's a really fun piece of regional vocabulary. So one interesting thing happened on my client project this week that I wanted to get your input on because I've definitely seen this problem before, and still, it continues to crop up. But I was working on a background job that we were passing a Boolean value into as one of the parameters that we would then, you know, use down the line in determining some logic. And we, you know, made this change, and then we were surprised to find out that it continued to not work the way we expected. So we got some bug reports that we weren't getting into one of the branches of the conditional based on that Boolean value that we were passing in. And we learned, after a little bit of digging, that it turns out that those values are serialized because this job is actually saved in -- JOËL: Oh no. STEPHANIE: [chuckles] Yeah. It inherits from the ActiveRecord, actually, and is saved in our database. And so, in that process, the Boolean value got serialized into a string and then did not get converted [chuckles] back into a Boolean. And so when we do that if variable check, it was always evaluating to true because strings are truthy in Ruby. JOËL: Right. The string false is still truthy. STEPHANIE: A string false is still truthy. And we ended up having to coerce it into a Boolean value to fix our little bug. But it was just one of those…

    Full show notes at the publisher

    Previous 1 10 11 12 13 14 51 Next

    Related Podcasts

    Know How… (Video)

    1

    Know How… (Video) Education
    JavaScript Jabber

    2

    JavaScript Jabber Education
    Programming Throwdown

    3

    Programming Throwdown Software How-To
    Software Engineering Radio – the podcast for professional software developers

    4

    Software Engineering Radio – the podcast for professional software developers Software How-To
    The Changelog: Software Development, Open Source

    5

    The Changelog: Software Development, Open Source How To
    Coding Blocks

    6

    Coding Blocks Software How-To
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights